Hi Angelo,
> Subject: [RFC] Linux-less boot
>
> Hi Jan, Peng, all,
>
> We currently have a better understanding of Peng's work [1] and manage to
> somewhat reproduce his results on another NXP board, the IMX8QM.
Good.
> Since you showed interest in this, we would like to start implement something
> a bit more portable and user-friendly.
>
> In this regard, I would like to share some design choices:
> - Jailhouse image stays more or less the same, all the code is added into a
> loader, expanding Peng's work to make it more portable (across Arm v8
> boards for now) and generic. The loader will boot and init everything that
> jailhouse and the inmates need. Without the loader jailhouse can be started
> exactly like it was before.
> - The loader is platform-specific, and thus it's necessary, at compile-time, to
> have a parameter that specifies the target (something like `BOOT=` or
> `TARGET=`), using the root-cell information to fill the correct addresses and
> compile only the necessary drivers. Without the parameter, the loader is not
> compiled.
I am not sure about x86. But for AARCH64 and RISC, let uboot pass
a table to the loader, the table contains all platform specific things. The format
should be defined by jailhouse community.
Or use device tree, but that means needs to import libfdt to jailhouse.
> - There is going to be a "sync" function at some point, probably when loading
> the module, that can update the status of jailhouse so that the cells created at
> boot time are controllable. The idea is to have the same situation as if
> jailhouse was started with the `enable`.
Agree.
>
> Finally, we would also like to hear from Peng, to understand his current plan
> so that we don't step in each other's toes.
Ah. I was crazy busy in the past days on some remoteproc work, so stop the
Loader work for a while. but the other work will be done in a few days, and
I will back to this:)
Actually this feature is planned in our software release, and I need to have
the loader related stuff checked in NXP tree in the end of April.
My planned stuff are:
arm32+arm64 inmate cell with arm64 jailhouse.
Real cache color with Linux root cell + one inmate cell, and considering fit
jailhouse into SRAM.
As you listed, userspace tool support.
Considering MMU for loader. But not sure this really needed currently.
It is good we could reuse the work between, but not sure I could wait
until then, because I have a tight schedule.
Thanks,
Peng.
>
> [1]
>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups
> .
google.com%2Fforum%2F%23!topic%2Fjailhouse-dev%2FIZEFz-e2lh4&d
> ata=02%7C01%7Cpeng.fan%
40nxp.com%7C8ae0f1ab40054707b2af08d7d24
> 3be6f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6372090607
> 11306332&sdata=r8uxIgLOTqIMydWTlo6rDdaerSPd12MRnURPIUDA9X0
> %3D&reserved=0
>
> Angelo
>
> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit
>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups
> .
google.com%2Fd%2Fmsgid%2Fjailhouse-dev%2FCADiTV-1QiRhSWZnw%252
> BkHhJMO-BoA4sAcOmTkQE7ZWbHkGh3Jexw%
2540mail.gmail.com&dat
> a=02%7C01%7Cpeng.fan%
40nxp.com%7C8ae0f1ab40054707b2af08d7d243b
> e6f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637209060711
> 306332&sdata=L4PCq2Lo6FlAqzw%2FhPr0p7dhtG3DrOsfRl%2BBtBV7lA
> w%3D&reserved=0.