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
Dear EBBR stakeholders,
I hope you all had a nice summer break.
Our next EBBR call is approaching as it will take place next Monday, Aug 26
at 14h30 BST (13h30 UTC; BST is active).
In the mean time, I would like to remind you that we have a poll[1]
on-going, to try to find an even better schedule for our EBBR call.
Thank you to those who added their availabilities already; for those of
you, who have not yet completed this first poll, could you please do so?
At the time of writing, we have a couple of pull requests on the agenda[2]:
- #131: Update UEFI version to 2.10 A
- #132: Boot Manager requirements
This an attempt at fixing issue #130: Explicitly require boot manager,
from Heinrich
Please have a look, and feel free to add to the agenda, directly on the
wiki page or by e-mail.
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://framadate.org/6jm8P3jHqAzmv8Xo
[2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
[130] https://github.com/ARM-software/ebbr/issues/130
[131] https://github.com/ARM-software/ebbr/pull/131
[132] https://github.com/ARM-software/ebbr/pull/132
>> Could this section be updated in order to reduce the number of different
>> interpretations?
>
> Yes, it can be clarified. As Daniel says, this section is only
> intended for platforms where there is no other place to store
> firmware. If the OS and the firmware need to share a logical block
> device, and there is no way to protect the firmware bits, then this
> section describes how they can co-exist. e.g., you don't want an OS
> deployment to accidentally wipe out firmware.
>
> It is preferred and encouraged to have firmware contained entirely in
> something separate from the main block storage. For example, in eMMC
> boot areas (separate from the primary area), or on a separate device
> entirely (SPI flash). I predict that a future version of EBBR will
> require this and drop the shared storage option entirely because it is
> necessary to protect against attacks against firmware (replacement or
> deletion)
>
> g.
>
Thank you all contributing to this thread!
While most of the points in this thread are self-explanatory and should
not need a summary, I want to extract the main points to avoid
misinterpretations:
1. Chapters '4.1 Partitioning of Shared Storage' and '4.2 Firmware
Partition Filesystem' refer to cases when shared storage is used for OS
and firmware images. In this case, the block device needs to be
partitioned using GPT and the firmware binaries should be stored in a
FAT partition. The folder organization for this partition is described
in the '4.2.1 The firmware directory hierarchy' chapter. Ideally, the
BootROM should be able to load images from a FAT partition. However, a
feature release of the EBBR is likely to drop this option in the future.
2. For scenarios involving dedicated storage, the organization of
the underlying storage for firmware falls outside the scope of the EBBR
and can be arranged according to the SoC vendor's discretion. This can
include options such as offset addressing, without GPT, with MRB, with
or without a partition, based on the platform's requirements or limitations.
Could you please confirm that this understanding is correct?
> If I recall correctly, on the Arm platform, A-BL1 (BootROM) and A-BL2
> are responsible only for
> loading the images. SCP_BL2 is loaded by BL2 into trusted SRAM and then
> transferred to the SCP using the MHU protocol and I believe it is
> followed this
> way for other platforms also (?).
> In summary, A-BL1(BootROM) and A-BL2 need to be aware of their next
> stages to load those
> images properly:
> BootROM -> BL2 -> BL31 -> ...
> |
> v
> SCP
If the above summary points are valid, then in the case of a shared
device, the BL2 should be able to load the next image(s) (either FIP or
BL31) from a FAT partition, I suppose.
Regards,
Ghennadi
Greetings everyone,
I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0
and I would like to clarify my understanding:
Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a
dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem
makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware
for multiple platforms.
Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System
Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore
dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP
Questions:
1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others)
must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT)
disk layout?
2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Regards,
Ghennadi
Hi,
We have nothing on today's EBBR call's agenda [1]; I would thus be inclined 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,
The question of moving the EBBR call 1/2 hour earlier was raised during our last
call [1].
Some people have colliding meetings now and it would make their lives easier.
Also, this seemed practical for all the people present.
Could all the EBBR attendees please tick their available hours on the following
poll?
https://framadate.org/FWI2Ff4Tmyz9yOfR
Thank you in advance!
If possible we will move the EBBR call to 14:30 UTC/BST starting with our next
call on Jul 15.
Best regards,
Vincent Stehlé
System Architect - Arm
[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.07.01
Device manufacturers frequently ship multiple boards or SKUs under a
single software package. These software packages will ship multiple
devicetree blobs and require some mechanism to pick the correct DTB for
the board the software package was deployed. Introduce a common
definition for adding board identifiers to device trees. board-id
provides a mechanism for bootloaders to select the appropriate DTB which
is vendor/OEM-agnostic.
This series is based off a talk I gave at EOSS NA 2024 [1]. There is
some further discussion about how to do devicetree selection in the
boot-architecture mailing list [2].
[1]: https://sched.co/1aBFy
[2]: https://lists.linaro.org/archives/list/boot-architecture@lists.linaro.org/t…
Quick summary
-------------
This series introduces a new subnode in the root:
/ {
board-id {
some-hw-id = <value>;
other-hw-id = <val1>, <val2>;
};
};
Firmware provides a mechanism to fetch the values of "some-hw-id" and
"other-hw-id" based on the property name. I'd like to leave exact
mechanism data out of the scope of this proposal to keep this proposal
flexible because it seems architecture specific, although I think we we
should discuss possible approaches. A DTB matches if firmware can
provide a matching value for every one of the properties under
/board-id. In the above example, val1 and val2 are both valid values and
firmware only provides the one that actually describes the board.
It's expected that devicetree's board-id don't describe all the
properties firmware could provide. For instance, a devicetree overlay
may only care about "other-hw-id" and not "some-hw-id". Thus, it need
only mention "other-hw-id" in its board-id node.
Isn't that what the compatible property is for?
-----------------------------------------------
The compatible property can be used for board matching, but requires
bootloaders and/or firmware to maintain a database of possible strings
to match against or implement complex compatible string matching.
Compatible string matching becomes complicated when there are multiple
versions of board: the device tree selector should recognize a DTB that
cares to distinguish between v1/v2 and a DTB that doesn't make the
distinction. An eeprom either needs to store the compatible strings
that could match against the board or the bootloader needs to have
vendor-specific decoding logic for the compatible string. Neither
increasing eeprom storage nor adding vendor-specific decoding logic is
desirable.
How is this better than Qualcomm's qcom,msm-id/qcom,board-id?
-------------------------------------------------------------
The selection process for devicetrees was Qualcomm-specific and not
useful for other devices and bootloaders that were not developed by
Qualcomm because a complex algorithm was used to implement. Board-ids
provide a matching solution that can be implemented by bootloaders
without introducing vendor-specific code. Qualcomm uses three
devicetree properties: msm-id (interchangeably: soc-id), board-id, and
pmic-id. This does not scale well for use casese which use identifiers,
for example, to distinguish between a display panel. For a display
panel, an approach could be to add a new property: display-id, but now
bootloaders need to be updated to also read this property. We want to
avoid requiring to update bootloaders with new hardware identifiers: a
bootloader need only recognize the identifiers it can handle.
Notes about the patches
-----------------------
In my opinion, most of the patches in this series should be submitted to
libfdt and/or dtschema project. I've made them apply on the kernel tree
to be easier for other folks to pick them up and play with them. As the
patches evolve, I can send them to the appropriate projects.
Signed-off-by: Elliot Berman <quic_eberman(a)quicinc.com>
---
Changes in v3:
- Follow new "/board-id {}" approach, which uses key-value pairs
- Add match algorithm in libfdt and some examples to demo how the
selection could work in tools/board-id
Changes in V2:
- Addressed few comments related to board-id, and DDR type.
- Link to V2: https://lore.kernel.org/all/a930a3d6-0846-a709-8fe9-44335fec92ca@quicinc.co…
---
Amrit Anand (1):
dt-bindings: arm: qcom: Update Devicetree identifiers
Elliot Berman (8):
libfdt: board-id: Implement board-id scoring
dt-bindings: board: Introduce board-id
fdt-select-board: Add test tool for selecting dtbs based on board-id
dt-bindings: board: Document board-ids for Qualcomm devices
arm64: boot: dts: sm8650: Add board-id
arm64: boot: dts: qcom: Use phandles for thermal_zones
arm64: boot: dts: qcom: sm8550: Split into overlays
tools: board-id: Add test suite
.../devicetree/bindings/board/board-id.yaml | 24 ++++
.../devicetree/bindings/board/qcom,board-id.yaml | 144 ++++++++++++++++++++
arch/arm64/boot/dts/qcom/Makefile | 4 +
arch/arm64/boot/dts/qcom/pm8010.dtsi | 62 ++++-----
arch/arm64/boot/dts/qcom/pm8550.dtsi | 32 ++---
arch/arm64/boot/dts/qcom/pm8550b.dtsi | 36 +++--
arch/arm64/boot/dts/qcom/pm8550ve.dtsi | 38 +++---
arch/arm64/boot/dts/qcom/pm8550vs.dtsi | 128 +++++++++--------
arch/arm64/boot/dts/qcom/pmr735d_a.dtsi | 38 +++---
arch/arm64/boot/dts/qcom/pmr735d_b.dtsi | 38 +++---
.../dts/qcom/{sm8550-mtp.dts => sm8550-mtp.dtso} | 24 +++-
.../dts/qcom/{sm8550-qrd.dts => sm8550-qrd.dtso} | 22 ++-
.../boot/dts/qcom/{sm8550.dtsi => sm8550.dts} | 10 +-
arch/arm64/boot/dts/qcom/sm8650-mtp.dts | 6 +
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 6 +
arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +-
include/dt-bindings/arm/qcom,ids.h | 86 ++++++++++--
scripts/dtc/.gitignore | 1 +
scripts/dtc/Makefile | 3 +-
scripts/dtc/fdt-select-board.c | 126 +++++++++++++++++
scripts/dtc/libfdt/fdt_ro.c | 76 +++++++++++
scripts/dtc/libfdt/libfdt.h | 54 ++++++++
tools/board-id/test.py | 151 +++++++++++++++++++++
23 files changed, 901 insertions(+), 210 deletions(-)
---
base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
change-id: 20240112-board-ids-809ff0281ee5
Best regards,
--
Elliot Berman <quic_eberman(a)quicinc.com>