On Mon, 27 Apr 2020 at 17:39, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 27.04.20 11:15, François Ozog wrote:
On Mon, 27 Apr 2020 at 08:24, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:
On 4/27/20 6:29 AM, François Ozog wrote: > +boot architecture > > Le sam. 25 avr. 2020 à 19:26, François Ozog <francois.ozog@linaro.org <mailto:francois.ozog@linaro.org>> a > écrit : > >> Hi >> >> I would like to start the discussion on DTE-8 as LEDGE is going to need What does DTE-8 refer to? Google wouldn't find it.Sorry, that is Linaro JIRA project reference. Please disregard.
>> 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 toaddress:
>> - DTE-8 DeviceTree lifecycle: BL32 (BL32 may mask some devicesuntil
>> 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 followingentities:
>> - 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 originatesfrom
>> bl32.dtb >> - BL33 (let's assume U-Boot) has a tree <BL33> which originatesfrom
>> 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. Above you say BL33 can be Linux. So BL33 may be board specific. Also BL32 is not required to be board specific. >> >> 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". Do you want to describe the current state of device trees or adesired
state?I was referring to a "desired state" but we may want to do both.
In the current world Linux may supply one or multiple device treesfrom
which BL33 is expected to load one and pass it to Linux. For some devices it may be happy with the device tree passed from thefirmware.
>> >> All DTBs shall be derived from a single source repository. The current state is: Linux, U-Boot, and EDK2 use device trees from there own repositories. They may be synchronized or not. Often they differ to an extent that makes booting Linux impossible. Linux and firmware havenon-synchronized
release cycles. So you cannot expect device-trees to be synchronized.Trying to synchronize development cycles is definitively not a goal. Identify what shall describe what is a goal. As a principle, some entities "own" elements of the boot process. For instance, in my view, BL31 "owns" PSCI services (because BL31 offers them) and RAM (because BLE is doing DDR controller setup and is in the same development tree as BL31). So BL31 device tree vision of PSCI and RAM shall be leveraged by "downstream" components such as BL33 and THING rather than "ignored" by providing their own vision. How this is best done is unclear at this stage and is referring to
III.1.2.
Linux development does not care who else is using device trees and changes device tree bindings and device specific device treesaccording
to its needs from release to release. You cannot expect Linux to boot with a device tree supplied with an elder Linux version.Linux just consumes ACPI tables. Is there any reason not to organize DT life cycle for new and selected hardware driven by the vendor making the hardware?
There are notable SoC vendors and board vendors who don't upstream their changes themselves. Just have a look at the linux-sunxi and linux-meson communities.
The result is that after two years there are no updates for the SoC packages of our mobile phones and hence no updates by the mobile phone manufacturer. Let's hope that the Android Open Source Project ameliorates the situation.
The same problems exist for routers and IoT devices.
Some vendors might even be happy about the obsolescence of their devices.
Any model relying on vendors only could dismiss a lot of hardware.
I see.... Far from ideal...
But my question was more in the sense: if a vendor wants to be proactive and organize its product lifecycle the way described, are there any technical hurdles that would prevent it? For the guys that do not maintain their DT or upstream in general: I wouldn't try to change their attitude, so the situation would remain essentially as it is today: separate DT definitions in many projects and no life-cycle.
Best regards
Heinrich
Let's assume
- BL33 passes the Linux kernel the DT that has been produced during its
build (let's call it kernel.dtb).
- the platform is partitioned with a type-1 hypervisor
(BL31->U-Boot->Xen), Linux is assigned 2 devices, all others are virtio What shall be the DT minimal behavior? Would it make sense to mark the associated control memory as "no-map" in the "reserved-memory" node? Is pruning the device from DT a good option? (Pruning feels "dangerous" because one device may be described with multiple nodes and no current technology allows to programmatically identify those nodes). If the above two are not done, how device drivers react when the areas described in the kernel.dtb are either all zeroes or not mapped?
>> >> 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 asingle
>> 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 . Forinstance,
>> 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. This may hold true for some devices. Or BL33 may use its own device tree.I think BL33 shall use its own device tree separate from BL31 and THING. But some nodes shall come from BL31 (PSCI, RAM).
>> >> Current wisdom is BL31 manipulates the BL33 tree. This would require BL33 to pass a reference to its tree back to BL31. Where is this done?RPI4 does that when it boots Linux directly. Rockship uses this to pass console in a "chosen" node. As part of a PoC, I had to find a solution for booting Linux as BL33: I integrated a DT in the "NT-FW-CFG" (non-trusted firmware config) FIP element and had BL31 stage it with PSCI and RAM bindings.
>> >> 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 This can also be a chosen node, e.g. defining the UART to use for output.Yep, there is also another chosen node that is interesting to talk about: "linux,cma" illustrates the content of the chosen node is driven not only by firmware but also pure THING configuration aspects.
>> * 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 aUEFI
>> table shall be referring to the same tree (a single tree in memory, two >> access methods). According to the UEFI spec you can either pass a device tree or anACPI
table to the operating system.And that is the model I think the industry shall adopt concretely ;-)
Best regards Heinrich >> >> 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 ComputingGroup*
>> T: +33.67221.6485 >> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog >> >> -- > François-Frédéric Ozog | *Director Linaro Edge & Fog ComputingGroup*
> T: +33.67221.6485 > francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/boot-architecture >--
François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog