On Mon, 27 Apr 2020 at 13:04, Priyanka Jain <[email protected]> wrote:
> >-----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. > Yes, we are not. > 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? > DT sub-modules is not a good idea as confirmed by U-Boot and Linux communities. We need to find a way to generate/extract a DT source for a particular "user" (TFA, BL32, BL33). and as BL33 can be quite diverse (U-Boot, EDK2, Linux, Xen...) there is no such a thing as a BL33 "DT profile". U-Boot can be BL33 or an EFI application. So I believe there is no U-Boot profile either. The master repo shall accommodate to be consumed by an entity (U-Boot, EDK2, Linux...) in a specific context (BL33, EFI app, OS) > > >> - 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 > No. The U-boot repo shall be able to regularly syncup (timing to be decided by the U-Boot community) with a master repo (where consistency across all views can be checked). That is a complex topic to resolve. I hope we can find consensus in this discussion thread. And based on the concept of ownership, there should be a mechanism for BL31 to pass information to BL33 and beyond about the things it owns. I just had a particular example with https://patches.linaro.org/patch/129595/: TFA PSCI exact behavior shall be properly visible by Linux kernel through BL33. We don't want Linux to view what BL33 thinks TFA does. > > 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 > -- 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
