+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
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 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.
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.
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 a desired state?
In the current world Linux may supply one or multiple device trees from 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 the firmware.
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 have non-synchronized release cycles. So you cannot expect device-trees to be synchronized.
Linux development does not care who else is using device trees and changes device tree bindings and device specific device trees according to its needs from release to release.
You cannot expect Linux to boot with a device tree supplied with an elder Linux version.
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.
This may hold true for some devices. Or BL33 may use its own device tree.
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?
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.
- 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).
According to the UEFI spec you can either pass a device tree or an ACPI table to the operating system.
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 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://lists.linaro.org/mailman/listinfo/boot-architecture
On Mon, 27 Apr 2020 at 08:24, Heinrich Schuchardt 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 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 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.
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 a desired 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 trees from 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 the firmware.
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 have non-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 trees according 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?
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 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.
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 aspectsIII.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).
According to the UEFI spec you can either pass a device tree or an ACPI 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 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://lists.linaro.org/mailman/listinfo/boot-architecture
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 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. 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 a desired 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 trees from 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 the firmware. >> >> 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 have non-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 trees according 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.
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 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. 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 a UEFI >> 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 an ACPI 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 Computing Group* >> 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 Computing Group* > 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
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
Sent from my iPhone
On 27-Apr-2020, at 9:46 PM, François Ozog francois.ozog@linaro.org wrote:
On Mon, 27 Apr 2020 at 17:39, Heinrich Schuchardt <xypron.glpk@gmx.demailto:xypron.glpk@gmx.de> wrote: On 27.04.20 11:15, François Ozog wrote:
Ebbr sbbr specifications, Linux for example expects them as part of firmware. It seems based on hardware separation there would be separate device trees. For example Linux will not be able to see crypto accelerator which is used by optee for example. How to address these?
Regards
On Mon, 27 Apr 2020 at 08:24, Heinrich Schuchardt <xypron.glpk@gmx.demailto:xypron.glpk@gmx.de <mailto:xypron.glpk@gmx.demailto: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> <mailto: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 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. 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 a desired 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 trees from 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 the firmware. >> >> 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 have non-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 trees according 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 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. 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 a UEFI >> 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 an ACPI 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 Computing Group* >> T: +33.67221.6485 >> francois.ozog@linaro.org<mailto:francois.ozog@linaro.org> <mailto:francois.ozog@linaro.org<mailto: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<mailto:francois.ozog@linaro.org> <mailto: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> <mailto:boot-architecture@lists.linaro.org<mailto:boot-architecture@lists.linaro.org>> > https://lists.linaro.org/mailman/listinfo/boot-architecture<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data=02%7C01%7Cpoonam.aggrwal%40nxp.com%7Ce081093386a44c69250108d7eac664ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637236010162203675&sdata=%2B8bjof2XF8UyRM63N8dffWFBmQb6e2vXbhbHa918Cwg%3D&reserved=0> >--
François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org <mailto:francois.ozog@linaro.orgmailto:francois.ozog@linaro.org> | Skype: ffozog
-- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&...] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@linaro.orgmailto:francois.ozog@linaro.org | Skype: ffozog
On Mon, 27 Apr 2020 at 18:53, Poonam Aggrwal poonam.aggrwal@nxp.com wrote:
Sent from my iPhone
On 27-Apr-2020, at 9:46 PM, François Ozog francois.ozog@linaro.org wrote:
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:
Ebbr sbbr specifications, Linux for example expects them as part of firmware. It seems based on hardware separation there would be separate device trees. For example Linux will not be able to see crypto accelerator which is used by optee for example. How to address these?
I guess this will be one of the results of the mail thread. That is a
very good point to address: The OS will have a restricted vision of the platform through DT because either it cannot (secure world hardware such as crypto accelerator, EEPROM, flash...) or it was prevented rights to by configuration (hypervisor limited set of devices assignment ). I assume the secure world devices are not confidential. Is it safe to assume we are dealing with devices whose description is public but targeted at different secure states of the processor? If not, we may need to add a layer of authorization to the central repo. The two restrictions require different provisions. - The secure world devices may be visible in a central repository but not importable for non-secure context - the hypervisor requires manipulation on the DT to be passed to Linux. those manipulations may be in some cases pruning devices, or may become part of overlays technologies (to be discussed later).
Regards
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 ownrepositories.
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 besynchronized.
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 toBL31.
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 furtheroperate
>> 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
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-----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
On Mon, 27 Apr 2020 at 13:04, Priyanka Jain priyanka.jain@nxp.com wrote:
-----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.
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 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
boot-architecture@lists.linaro.org
-
François Ozog -
Heinrich Schuchardt -
Poonam Aggrwal -
Priyanka Jain