>-----Original Message----- >From: boot-architecture <[email protected]> On >Behalf Of François Ozog >Sent: Monday, April 27, 2020 9:59 AM >To: Boot Architecture Mailman List <[email protected]>; dte- >[email protected]; team-ledge <[email protected]> >Subject: Re: DTE-8 DeviceTree lifecycle: the basics > >+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.
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 >> [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://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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
