Hi,
This is a quick reminder that we will not have an EBBR call today and the next
one will be on Aug 27. [1]
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Posting to boot-architecture list for more visibility.
---------- Forwarded message ---------
From: Casey Connolly <notifications(a)github.com>
Date: Mon, Jun 30, 2025 at 12:33 PM
Subject: [devicetree-org/dt-schema] schemas: chosen: document
devicetree-path property (PR #167)
To: devicetree-org/dt-schema <dt-schema(a)noreply.github.com>
Cc: Subscribed <subscribed(a)noreply.github.com>
Background
With more and more laptops, dev boards, and other products shipping
with both an EFI capable bootloader and relying on devicetree, there
is an increasing problem with trying to ensure that a devicetree is
loaded and that it will work with the kernel/OS version being booted.
This is less of an issue on vertically integrated embedded platforms,
but with ARM SystemReady gaining prevalence and the abundance of cheap
dev boards there is a growing desire to boot generic OS installer/disk
images on these devices.
In some cases the platform doesn't see many devicetree changes and
works well with a range of kernel versions, the board can just provide
it's own devicetree in firmware and it will work just fine. However
there are many platforms where this is not the case, unintentional
breaking changes can be made to drivers or DT, or new features being
enabled can break compatibility with older kernels.
In these cases, the best way to maximise the chance that the generic
OS image will boot is if it can load the devicetree blob which was
installed alongside the kernel (something most mainstream distros do).
To enable this there has to be a consistent way to determine which dtb
(and overlays) were embedded into the firmware provided devicetree.
This new property enables exactly this usecase by making it possible
to embed the information into the dtb itself at build time. A proposed
implementation of this for U-Boot is available here 1.
The devicetree paths are all appended to some versioned prefix
(typically the kernel version) which would be known by the OS loader
when you choose a version to boot.
Prior effort
Previous attempts have been made to work around the issue of DTB
loading, U-Boot attempts to search some well-known (unversioned) paths
on the ESP using it's internal fdtfile variable (which has to be
constructed in a platform specific way, see below). This has mixed
results and doesn't work on distros like Fedora and Debian which
install dtbs to version-specific subdirectories.
On the EFI laptop side (where they don't provide any DTB) the
dtbloader EFI driver effectively implements the same logic as U-Boot,
guessing generic paths and using an internal unreliable map of SMBIOS
hardware IDs to file paths, this has been the go-to for many folks for
a while now but it's clear that it doesn't scale and that distros
won't be keep to ship it. It gets more complicated when you consider
secureboot as well which would require signing the driver.
File path as API
This proposed solution does have a potential stumbling block, as it
effectively cements the idea that the dtb path is API.
I believe this is a bridge that was already crossed long ago when
extlinux and later GRUB and systemd-boot gained a way to specify a
devicetree blob to load, since all distros use the upstream file
naming, any renames already potentially cause devices to become
unbootable after a kernel upgrade...
That being said, it's clear that the current way files are named is
often arbitrary and definitely inconsistent. I would propose a
solution like enforcing a way to convert between the root compatible
property and the file path, this provides consistency and removes the
need to store this arbitrary additional data needed to locate the dtb
on the ESP during boot.
An ugly attempt to best-effort this conversion for Qualcomm boards
today can be found at 2.
Why not store this data elsewhere?
There are quite a few benefits to putting this in the DTB itself.
It makes it possible to have a generic bootloader binary which gets
the DTB in an implementation-specific way, it avoids having to
hard-code the data.
On devices that have an EFI which doesn't provide a DTB, a driver can
be installed once on the ESP which installs a stub DT just containing
these properties, so that the OS loader can use them.
It isn't EFI specific, extlinux or other boot methods can make use of this.
This is metadata which belongs with the DTB, it can be inserted at
build time or at runtime, or even augmented to add additional overlays
at runtime should the implementation require that.
All in all, a generic mechanism for bootloaders and OS loaders to load
a dtb and overlays from the ESP (or other arbitrary storage mechanism)
is needed, and there doesn't seem to be another place to put it.
Why not FIT?
The FIT format has it's uses in embedded applications, but the only
way it could be applied here would be to use it as the way to index
/all/ of the available DTBs, in a generic ARM64 Fedora or Debian image
there are thousands of these. In addition, while matching by
compatible property may work for the base DTB, it doesn't work for
overlays.
And of course, using FIT for this would require changing how DTBs are
installed and packaged, this would be hugely disruptive and introduce
a myriad of additional problems.
cc @poettering @apalos
________________________________
You can view, comment on, or merge this pull request online at:
https://github.com/devicetree-org/dt-schema/pull/167
Commit Summary
bb9677f schemas: chosen: document devicetree-path property
File Changes (1 file)
M dtschema/schemas/chosen.yaml (22)
Patch Links:
https://github.com/devicetree-org/dt-schema/pull/167.patchhttps://github.com/devicetree-org/dt-schema/pull/167.diff
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this
thread.Message ID: <devicetree-org/dt-schema/pull/167(a)github.com>
Hi,
We have no agenda for today's EBBR call [1],
therefore I suspect we might end up canceling it.
If you have an urgent topic to discuss today,
please let us know before 11am UTC,
otherwise we will adjourn the call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Hi,
We have no agenda for today's EBBR call [1],
therefore I wonder if we might as well cancel it.
If you have an urgent topic to discuss today,
please let us know before 11am UTC, otherwise we will adjourn the call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Dear EBBR contributors and stakeholders,
We will have an EBBR "birds of a feather" session at the Linaro Connect
in Lisbon. [1]
If you are attending the Linaro Connect, we would be pleased to see you
there!
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://www.kitefor.events/events/linaro-connect-2025/submissions/331
Hi,
We have no agenda for today's EBBR call [1]; shall we cancel it?
If you have an urgent topic to discuss today, please let us know before
11am UTC, otherwise we will adjourn the call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Hi,
We have nothing on today's EBBR call's agenda [1]; I would therefore be
tempted to cancel it.
If you have an urgent topic to discuss today, please let us know before
1pm UTC, otherwise we will adjourn the call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Hi,
I am happy to announce that v2.3.0 of the EBBR specification has now been
released. [1]
Compared to v2.2.0, this release formalizes the Boot Manager requirements,
adds requirements on authenticated FMP capsules for firmware update and
deprecates spin tables for AArch64.
The following people (listed in alphabetical order) have participated to
this EBBR release directly or indirectly, with patches, github issues, pull
requests, reviews, comments, suggestions, or by participating to the
regular calls:
Andrea Della Porta
Ard Biesheuvel
Étienne Carrière
Heinrich Schuchardt
Ilias Apalodimas
Joakim Bech
Jon Humphreys
Michal Simek
Peter Robinson
Ricardo Salveti
Rob Herring
Vincent Stehlé
A big thank you and a merry Christmas to all the EBBR contributors!
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/releases/tag/v2.3.0
Hi,
The EBBR pre-release v2.3.0-pre1 is now available for review. [1]
Pdf comparisons are attached there for convenience. Please, have a look and
report any issue found by e-mail or during our next call on Dec 18 [2]. If
everything looks good and everybody agrees, we will release EBBR v2.3.0 soon
after that. Thank you!
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/releases/tag/v2.3.0-pre1
[2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Hi,
We have nothing on today's EBBR call's agenda [1]; we might therefore
cancel it.
If you have an urgent topic to discuss today, please let us know before
11am UTC, otherwise we will adjourn the call (sorry for the short
notice).
Also, given EBBR current stability, I am starting to think that it might
be ripe for a release.
Here is a summary of the most significant changes since v2.2.0:
chapter2: require authenticated fmp capsules for fw update
Update UEFI version to 2.10 A
chapter2: add boot manager requirements
(More changes omitted here.)
I will post a pull-request to prepare a v2.3.0.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Hi,
We have nothing on today's EBBR call's agenda [1]; we might thus cancel
it.
If you have an urgent topic to discuss today, please let us know before
11am UTC, otherwise we will adjourn the call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Dear EBBR stakeholders,
Thank you for completing the second poll [1]. We have looked at the
results during our call of yesterday [2]. While there is no ideal slot
allowing all people to attend, the Wednesday slots seem to allow more
participants.
We have thus decided to move the EBBR call to Wednesday, 14:00 UTC
(following BST).
Our next call will be on Oct. 23; see you there!
Best regards,
--
Vincent Stehlé
System Architect - Arm
[1] https://framadate.org/Wwf2GCiOsQywWfTg
[2] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.10.07
Dear EBBR stakeholders,
Thank you for having completed the poll, to try to find an even better schedule
for our EBBR call. It appears that people have available slots on the afternoon
of Monday, Wednesday and Friday.
Here is a second (and hopefully last) poll, with 1/2 hour granularity:
https://framadate.org/Wwf2GCiOsQywWfTg
Could you please add your availabilities in there?
Thank you!
Best regards,
Vincent Stehlé
System Architect - Arm
Hi,
We have nothing on today's EBBR call's agenda [1]; we might as well cancel it.
If you have an urgent topic to discuss today, please let us know before 1pm BST
(12pm UTC), otherwise we will adjourn the call.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings