+boot architecture Le sam. 25 avr. 2020 à 19:26, François Ozog <[email protected]> a écrit :
> Hi > > I would like to start the discussion on DTE-8 as LEDGE is going to need > results soon. I'd like to keep it high level, general principles, not too > precise on implementation details. Let's take overlays and other > complications out of the discussion until we share a vision for the basics. > > When we have concluded this discussion cycle we will need to address: > - DTE-8 DeviceTree lifecycle: BL32 (BL32 may mask some devices until > given credentials...) > - DTE-8 DeviceTree lifecycle: overlays > - DTE-8 DeviceTree lifecycle: tooling > - DTE-8 DeviceTree lifecycle: chain of trust > > Is the following correct? > Is it complete on the target reduced scope? > Is the discussion series/roadmap complete, is the order right ? > > Cordially, > > François-Frédéric > > > I - Definitions > > Let's consider there are four trees used by the following entities: > - TFA which spans BL1, BL2, BL31 has a tree <TFA> which originates from > tfa.dtb > - BL32 (let's assume OP-TEE) has a tree <BL32> which originates from > bl32.dtb > - BL33 (let's assume U-Boot) has a tree <BL33> which originates from > bl33.dtb > - THING, the "thing" that is booted by BL33, has a tree <THING> which > originates from thing.dtb and manipulations from BL33. > > The THING can be a Linux kernel, a bsd kernel, grub, shim<arch>.efi, > efibootguard.efi, Xen, Hafnium or many other possibilities. > BL33 is assumed to be U-Boot but it can be EDK2, Linux Kernel, Hafnium, > Xen or other thing. > > A tree is not dtb. A tree is the result of loading a DTB with or without > manipulations. > > II - Build time assumptions > > It is assumed that TFA, BL32 and BL33 are board specific while THINGS is > board agnostic. > > As a result of this architectural decision: > - tfa.dtb, bl32.dtb and bl33.dtb can be built by the build process of the > respective entity TFA, BL32, BL33. > - thing.dtb is purely describing hardware and has no "chosen" nodes for > instance, it may contain architectural/platform/board specific > "reserved-memory". In other words, nothing that can tie it to a particular > "thing". > > All DTBs shall be derived from a single source repository. > > The bindings of a single piece of hardware, may differ depending on the > entity that needs it (there are many ways to implement that aspect, let's > not talk about implementation yet). > For instance, a display panel for BL33 can be represented as a single > small node while the same display panel can be controlled out of several > large nodes by a downstream Operating System. > > III - Lifecycle > > Out of all possible transitions, let's consider BL31->BL33 and > BL33->THING. Transitions are opportunities to pass DT information from one > entity to the other that complements the static *.dtb . For instance, > passing PSCI interface information, memory reservations, PCI IO ranges... > > III.1 BL31->BL33 > > III.1.1 nature of manipulations > typically, PSCI interface may be injected as well some memory > reservations. > > III.1.2 manipulation operational considerations > There are three possibilities for passing this information: > - BL31 manipulates the BL33 tree to add/change nodes > - BL33 asks BL31 to add/change nodes > - BL31 passes an interim tree that BL33 will merge into his. > > Current wisdom is BL31 manipulates the BL33 tree. > > III.2 BL33->THING > > III.2.1 nature of manipulations > * operational > - board information (part numbers, serial numbers...) > - memory layout (beyond the typical 4G) > - IO specifics (PCIe...) > - reserved areas for runtime services (UEFI for instance) > - os.dtb > * THING dependent elements > - chosen for "command line" or other aspects > > III.2.2 manipulation operational considerations > In the case of UEFI interface, os.dtb passed as DT artifact or a UEFI > table shall be referring to the same tree (a single tree in memory, two > access methods). > > BL33 will operate all necessary manipulations on os.dtb before passing it > to the THING. The THING (grub, efiapp, kernel) can further operate > manipulations, it is outside scope of the discussion. > > > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > [email protected] | Skype: ffozog > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
