Hi,Stefan
The run-script you are using is an automated test, which remote-controls the test board by using >Tcl/expect. Therefore, if you use the unmodified run-script to control the Linux instance via serial line >manually, it won't work. The 'expect' mechanism holds control over the serial line I/O. That means >everything you type in will not be sent to the other side.
If you want to use the test-scenario in a non-automated fashion, you either replace the very first >"run_genode_until ..." with "run_genode_until forever", or you simply do not use the run-script to connect to your test-board, but use a terminal emulator like "picocom" directly.
Please, first evaluate whether it accepts input events with "direct" serial-line access. I'm wondering that >you see a _blinking_ terminal but no input events are shown.
Sorry,but I can not fully understand what you mean. Now I am using i.mx53 quick start borad and the borad is connected to my PC through it's UART DB9 connector. I managed this through a USB to serial converter. Also , I use a serial debug tool that is "minicom" to get the output of the board and input my command.Through the minicom , I can input command to linux , such as "ls mkdir wget... etc" , also ,I can open the kernel module that I implemented to issue "smc" to switch to tz_vmm to execute some code. It works fine when I use the genode 18.05. However ,when I changed to the hard-float version that you provided , I found this odd problem. Also, I have found that even I din't input any command the linux will get stuck after a period of time after startup. I have tried to replace the "run_genode_until..." with "run_genode_until forever" but the result haven't changed. This problem has bothered me for a few days, I will be very grateful if you could give me some help.
------------------ Best wishes
On Sat, Nov 17, 2018 at 02:53:47PM +0800, lzSun wrote:
Hi,Stefan
The run-script you are using is an automated test, which remote-controls the test board by using >Tcl/expect. Therefore, if you use the unmodified run-script to control the Linux instance via serial line >manually, it won't work. The 'expect' mechanism holds control over the serial line I/O. That means >everything you type in will not be sent to the other side.
If you want to use the test-scenario in a non-automated fashion, you either replace the very first >"run_genode_until ..." with "run_genode_until forever", or you simply do not use the run-script to connect to your test-board, but use a terminal emulator like "picocom" directly.
Please, first evaluate whether it accepts input events with "direct" serial-line access. I'm wondering that >you see a _blinking_ terminal but no input events are shown.
Sorry,but I can not fully understand what you mean. Now I am using i.mx53 quick start borad and the borad is connected to my PC through it's UART DB9 connector. I managed this through a USB to serial converter. Also , I use a serial debug tool that is "minicom" to get the output of the board and input my command.Through the minicom , I can input command to linux , such as "ls mkdir wget... etc" , also ,I can open the kernel module that I implemented to issue "smc" to switch to tz_vmm to execute some code. It works fine when I use the genode 18.05. However ,when I changed to the hard-float version that you provided , I found this odd problem. Also, I have found that even I din't input any command the linux will get stuck after a period of time after startup. I have tried to replace the "run_genode_until..." with "run_genode_until forever" but the result haven't changed. This problem has bothered me for a few days, I will be very grateful if you could give me some help.
Ok, I see. So forget about the run-script mechanisms. I was just fearing, that you could not interact with the Linux console anyway, because of the run-script's auto-mechanisms. But, if you insert the kernel module interactively that is obviously not the case.
After thinking about your issue again, I can imagine the origin of the problem. The referenced patch that enables general FPU usage on ARM for base-hw did not encountered ARM TrustZone and virtualization extensions yet. Sorry for not being aware of that in the first place. Unfortunately, this is a more invasive patch. The exception-vector assembly code for both kinds of world-switch needs to be extended to encounter the FPU switch too. By now, it was not encountered, because the Genode user-land made no use of the FPU. I can not guarantee when we will deliver a solution to that.
Actually, that doesn't need to be your problem anyway. Because, I can imagine that the guest Linux OS in the form we provide it in that test-scenario does not make use of the FPU. In general, there are lot of potential pitfalls when you increase the optimization level of the compiler, make aggressive use of the FPU everywhere in the software stack. The whole runtime behaviour changes, and it might make problems visible we are not aware of yet.
With other word: there might be a lot of work to do, until you successfully finish to run a whole Genode stack with -O3 and Linux running in the secure world. Please, consider that when prioritizing what you want to achieve.
Best regards Stefan
Best wishes
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
lzSun -
Stefan Kalkowski