+boot architecture
Le sam. 25 avr. 2020 à 19:26, François Ozog francois.ozog@linaro.org 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 francois.ozog@linaro.org | Skype: ffozog
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog