On Mon, Oct 30, 2017 at 07:54:53AM +0100, Jan Kiszka wrote: >On 2017-10-30 02:53, Peng Fan wrote: >> Hi Jans, >> >> Thanks for you reply. >> >> On Fri, Oct 27, 2017 at 06:37:54PM +0200, Jan Kiszka wrote: >>> On 2017-10-27 09:29, Peng Fan wrote: >>>> Hi, >>>> >>>> I am bring up jailhouse hypervisor on i.MX8 and now gic-demo works, but >>>> when I trying non-root cell Linux, I came across a few questions. >>> >>> Nice. If that target happens to be a commonly available eval board, >>> maybe you can share your configs. >> >> Not ready now. The configs I wrote are at very early stage. After I >> could pass a realy SD controller to non-root cell Linux, and if it still >> not work, I'll post out the configs. > >Great, looking forward! > >> >>> >>>> >>>> To devices assigned to non-root cell Linux, where to configure >>>> clock,pinctrl,power domain? >>> >>> We do not have a proper support for partitioning those things, primarily >>> as they are fairly SoC-specific. If you are lucky, you can partition >>> some things along register boundaries. Otherwise, you need to make the >>> root cell enable/tune what you need in the non-root cell and then freeze >>> that state by taking control from the root cell. >> >> Thanks for the info. I may need to use root cell to configure them. >> >>> >>>> Is Big.Little(A53+A72) supported? >>> >>> I didn't try, but I expect it work as long as all cores are exposed as >>> if they were equal. >> >> In my case A53 is the first cluster, A72 is in the second cluster. A72 runs >> faster that A53, so when enabling jailhouse, A72 will first finish >> initializing jailhouse. > >Who is managing the cluster switch, Linux or something in firmware? In >order to let Jailhouse do its work properly, all cores need to be >enabled by it during setup, not just one cluster. IOW, all cores need to >be seen by Linux as individual cores.
firmware handles cluster. In my case it is CPU 4 ... OK (A72) CPU 5 ... OK (A72) CPU 2 ... OK (A53) CPU 3 ... OK (A53) CPU 0 ... OK (A53) CPU 1 ... OK (A53) .... When A53 backing to Linux side, A53 reports parking CPU. Jtag shows stage1 - stage 2 MMU table corrupt. If I use JTAG to let CPU 4/5 later than CPU0/1/2/3, no corrupt. Since there is a small hardware issue now, I could not make sure software/hardware issue. I'll continue debug. > >> But When A53 returns back to Linux, A53's stage1-stage2 translation seems >> failure. When >> I use jtag to dump,mmu table is corrupt, then A53 reports "FATAL: forbidden >> access (exception class 0x20)". >> >> If I use jtag to debug and let a53 first finishes initializing jailhouse, no >> exception, >> A53 A72 both works. I have not try enabling non-root cell, the issues are >> met when >> enabling root cell. >> >> In hypervisor/arch/arm64/entry.S >> There is " /* AARCH64_TODO: ARM architecture supports CPU clusters which >> could be", so >> I am not sure whether big.little support are ready or not. I am still >> debugging. >> >>> >>>> In non-root cell Linux, I use same uart as root cell Linux, but when >>>> non-root cell Linux panic when non rootfs found, root cell console still >>>> work normally. So non-root cell linux are using phyiscal uart as console >>>> or not? >>> >>> That question I do not yet fully understand. Keep in mind that Jailhouse >>> moderates access to resources like MMIO or interrupts, not to devices. >>> In most cases, it has no clue if there is a particular device behind >>> some accesses (one exception from that: GIC). >>> >>> When you assign the MMIO region(s) of a UART to two cells at the same >>> time, you may see weird results with both cells access it >>> simultaneously. Moreover, you cannot assign an interrupt to two cells at >>> the same time. So one cell may become unhappy if it does not receive >>> interrupts - or if it does but unexpectedly. >> >> I'll try assigning the other uart for non-root cell Linux. >> >>> >>>> >>>> Which kernel branch should I use? queues/jailhouse or >>>> queues/jailhouse-ivshmem2 at git.kiszka.org?p=linux.git;a=summary >>> >>> Stick with queues/jailhouse unless you are particularly interested in >>> ivshmem-v2 (and also use the corresponding Jailhouse branch). >> >> Thanks. >> >>> >>>> >>>> Another question. >>>> Is it possible to use an RTOS as root cell? or is this the correct >>>> direction? I think rtos will boot quickly then Linux, could be used in >>>> automotive Cluster and Linux in non-root cell for infortainment. >>> >>> That should be possibly, but no one implemented that so far (to my best >>> knowledge). In fact, I chatted with folks about such scenarios at the >>> Automotive Grade Linux meeting last week as well. >> >> Do you have more information to share from your talk to AGL? >> > >You can find the slides here: >https://schd.ws/hosted_files/aglammeu17/12/AGL-AMM-2017-JailhouseOnWheels.pdf Thanks for the slide. Great to see IVI + bus gate way and IVI + Cluster usage. > >>> >>> Which RTOS do you have in mind, a commercial one or some open source >>> project? >> >> I would like to use open source projects, such as RTEMS. But graphic support >> is not that good. Also AArch64 support is not ready. >> Do you have some recommendation except RTEMS? And if using rtos as root >> cell, do you have >> some ideas how to proceed, seems jailhouse now heavily relys on Linux? > >I don't know which open source RTOS is already running well in AArch64 >mode. We were discussing Zephyr as potential boot loader for Jailhouse, >but that is also only supporting 32-bit mode so far. It seems to gain >x86-64 support soon, and that may open it up for AArch64 as well. As far as I know, Zephyr is mainly for IoT usage and ARM Cortex-A is not supported. I'll give a try on RTEMS first. > >Porting the root cell support from Linux over to an RTOS shouldn't be >too hard. You first of all need to study the bootstrap process and make >sure that RTOS is able to boot all cores and load the required images >into memory. On ARM, you also need to provide a hypervisor stub like >Linux does so that Jailhouse can take over EL2. During runtime, not much >is needed except loading images again and issuing some hypercalls to >control the non-root cells. If you leave out cell monitoring, sysfs, PCI >device handling, the control driver should be rather simple. Great thanks. Thanks, Peng. > >Jan > >-- >Siemens AG, Corporate Technology, CT RDA ITP SES-DE >Corporate Competence Center Embedded Linux > >-- >You received this message because you are subscribed to the Google Groups >"Jailhouse" group. >To unsubscribe from this group and stop receiving emails from it, send an >email to jailhouse-dev+unsubscr...@googlegroups.com. >For more options, visit https://groups.google.com/d/optout. -- -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
