-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of François Ozog Sent: Monday, April 27, 2020 9:59 AM To: Boot Architecture Mailman List boot-architecture@lists.linaro.org; dte- all@linaro.org; team-ledge team-ledge@linaro.org Subject: Re: DTE-8 DeviceTree lifecycle: the basics
+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.
1)We are not trying to create single device tree image. We are still expecting that there can be different images for u-boot, Linux, etc but we will use single source code to maintain device-tree code?
- 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.
Build process related query. Suppose bl33 is u-boot. Do you mean that device tree code will be moved out of u-boot repo and then u-boot will need to use this single source device-tree repo to build image like u-boot-dtb.bin
Thanks Priyanka
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 BL33->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 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lin aro.org%2Fmailman%2Flistinfo%2Fboot- architecture&data=02%7C01%7Cpriyanka.jain%40nxp.com%7Cfdc5abec5 30a4ecc676a08d7ea63ab92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 C0%7C637235586119943659&sdata=QTmviXOFI4ztNm1GvHMQVJ1rgTR9 5feJbj9gYUjjYvQ%3D&reserved=0