On 14.12.19 10:51, Mani Sadhasivam wrote: > > > On Fri, 6 Dec, 2019, 1:39 PM Jan Kiszka, <[email protected] > <mailto:[email protected]>> wrote: > > On 05.12.19 20:32, Mani Sadhasivam wrote: > > Hi Jan, > > > > On Thu, Dec 5, 2019 at 1:38 PM Jan Kiszka <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > [re-adding the mailing list] > > > > On 05.12.19 09:07, Jan Kiszka wrote: > > > On 05.12.19 08:49, Mani Sadhasivam wrote: > > >> > > >> > > >> On Thu, Dec 5, 2019 at 1:09 PM Jan Kiszka > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > >> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>> > > wrote: > > >> > > >> On 05.12.19 08:14, Mani Sadhasivam wrote: > > >> > Hi Jan, > > >> > > > >> > On Thu, Dec 5, 2019 at 12:36 PM Jan Kiszka > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > >> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > >> > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>>> > > >> wrote: > > >> > > > >> > On 02.12.19 19:43, Manivannan Sadhasivam wrote: > > >> > > Hello, > > >> > > > > >> > > I can see that the Zephyr RTOS has been > mentioned in > > the FAQ as > > >> > > one of the ported OS for non-root cells. > > >> > > > > >> > > Is there any reference code I can look into? > > >> > > > >> > There is x86 support for Zephyr as Jailhouse > "inmate". > > Check out > > >> > zephyr/boards/x86/x86_jailhouse/doc/board.rst. If you > > run into > > >> trouble, > > >> > report to the communities. > > >> > > > >> > > > >> > Ah, just noticed that it got removed some time ago: > > >> > > > >> > > > > https://github.com/zephyrproject-rtos/zephyr/commit/f3611fdd0c8ca54a9f19bc56a14b4a2fdadaffe3#diff-bb9445fa64739ef6a5a6b59d520deb07 > > >> > > > >> > > >> Too bad they didn't reach out... > > >> > > >> > But this could be helpful! > > >> > > > >> > > >> Partly. For ARM, you likely don't need so may changes, > see below. > > >> > > >> > > > >> > > > >> > We could probably also easily support ARM, but > the last > > time this > > >> > question came up, there was still not A-core > support in > > Zephyr > > >> which is > > >> > a precondition. > > >> > > > >> > > > >> > That's what I'm trying to do on IMX8M EVK in spare time. > > There is > > >> an ongoing > > >> > PR for adding Cortex-A support in Zephyr, so I'm > planning to > > >> utilize that. > > >> > > >> That is good news. If you combine that with the device tree > > description > > >> for inmates, actually those for the Linux cells, you should > > be able to > > >> boot without code modifications. > > >> > > >> > > >> Don't we need MMU support in inmate? The current ARMv8 PR > doesn't > > have the > > >> MMU support. > > > > > > Technically, we don't. Earlier versions of our demo inmates were > > running > > > without MMU as well, but as that implies running without > caches as > > well, > > > we changed that. In any case, the inmate starts in reset > state, means > > > with MMU (and caches) off. > > > > > > > > > I got it working partially(not fully though). What would be the > Flash and > > SRAM address would you recommend? The Flash start address should > > be 0x0 since that's the CPU default start address, how about SRAM? > > I didn't play with targets where SRAM was involved so far, but I could > imagine that it will be easiest to map it at a location where it would > appear physically in exclusive use as well. > > > I just got it working. FWIW, the wip commits are > here: https://github.com/Mani-Sadhasivam/zephyr/commits/jailhouse > > There are couple of caveats though: > > 1. Zephyr places the vector table at the start/base address and the > reset entry next to it. But jailhouse didn't seem to find the reset > entry and it always tries to start from the base address. Is there any > config option available for fixing this? Since the vector table size is > fixed, it should be relatively simple to make it start from that address > I believe.
You can set jailhouse_cell_desc.cpu_reset_address for that. > > 2. Currently the GICv3 Rdist address is hardcoded for 2nd core but in > ideal case we should find it based on MPIDR value as done in jailhouse > inmate demo. I'm getting faults while trying to read MPIDR_EL1 system > register, so need to debug it. > Sounds promising! Maybe I will find some time to give it a try during the holiday season. Jan -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/e7f1ff75-7fbe-d608-6fd9-6e9323037e34%40web.de.
