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>
Hi all. Several EBBR meetings ago, I introduced the need for allowing OS provided device trees [1]. Please find below the proposal I am delinquent on sending.
Hopefully, we can discuss this in the next meeting.
Thanks
Jon
[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.02.12
Problem statement:
==================
Device trees are in theory a pure description of the hardware, and since the hardware
doesn't change, the device tree describing the hardware likewise never changes.
With this, a device tree could then be burned into the hardware's ROM to be
queried by software for hardware discovery. In practice, though, device trees
evolve over time. They evolve for many reasons, including
- support for previously unsupported hardware
- device driver improvements that require additional hardware information
- bug fixes
Linux's device tree source is maintained with the kernel source, and kernel builds
include building the device trees too. This ensures that the device tree
matching the kernel's usage is always kept in sync. Often, embedded distros will
include the matching device tree blobs.
The EBBR mandates that the device tree blob is provided by the firmware.
Thus it is likely that the device tree provided by the firmware and given to the
operating system is not the matching device tree blob for that kernel. This can
cause hardware to be missing, buggy, or non-functional.
Proposal:
=========
A key goal of the EBBR is to define the contract between the firmware and the OS
so that the OS doesn't need to be built specifically for the hardware, and the
firmware can boot any compliant OS. Thus, any solution that requires the OS to
know specifics about the hardware beyond the EBBR contract would violate the
EBBR goals. This precludes any solution where the OS, having the matching DTBs,
would pick the DTB, because this requires the OS to know what hardware it is
being run on. Likewise, any solution where the firmware is aware of the OS
matching DTBs would require the firmware to be aware of the particular OS it is
booting.
What can be known:
- The firmware knows what board it is running on, and thus knows what device
tree to use. But it doesn't know what version of the device tree to use,
because it doesn't know what OS is being booted.
- The OS knows what version of DTBs matches it's kernel, but does not know which
specific device tree to use.
This proposal then has the firmware choose the device tree by name, or some
other identifier that can be used to match the device tree for the board [1]. It
has the OS-provided OS loader select the location of the matching versions of
DTBs for it.
The firmware would pass the device tree filename/id to the OS loader, instead of
the DTB itself. The OS loader would determine the location of the matching DTBs
based on the chosen OS to boot, load the matching DTB from that location, and
pass to the kernel.
Considerations:
- often a DTB requires fixups. The EFI_DT_FIXUP_PROTOCOL could be utilized.
- device tree overlays could be indicated with a scheme using the device tree ID
passed to the OS loader
- authenticating the DTB would be the responsibility of the OS distribution and
handled in the same way as the kernel itself is authenticated. The OS is the
entity responsible for signing the DTB, as it should be.
This proposal should be in addition to supporting the standard way of passing in
a firmware-provided DT, in cases where the OS doesn't provide or have a need to
provide a matching DT.
[1] Rather than using the device tree source filename, to have more flexibility,
one can conceive an ID or compatible string that the OS could then scan the DTBs
to find a match.
Hi,
I am happy to announce that v2.2.0 of the EBBR specification has now been
released. [1]
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 attending the zoom calls:
Ilias Apalodimas
Joakim Bech
Ard Biesheuvel
Etienne Carrière
Wei Chen
Patrick Delaunay
Samuel Dionne-Riel
Samer El-Haj-Mahmoud
Andreas Färber
Ahmad Fatoum
Sughosh Ganu
Simon Glass
Alexander Graf
Rob Herring
Jon Humphreys
Jan Kiszka
Jan Lübbe
Jose Marinho
Loïc Minier
Weizhao Ouyang
François-Frédéric Ozog
Stephen Paulger
Tom Rini
Peter Robinson
Heinrich Schuchardt
Michal Simek
Vincent Stehlé
Daniel Thompson
Ivan T. Ivanov
Stuart Yoder
A big thank you to all the EBBR contributors!
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/releases/tag/v2.2.0
On Sat, May 25, 2024 at 05:54:52PM +0100, Conor Dooley wrote:
> On Wed, May 22, 2024 at 04:54:23PM -0700, Elliot Berman wrote:
> > Device manufcturers frequently ship multiple boards or SKUs under a
> > single softwre package. These software packages ship multiple devicetree
> > blobs and require some mechanims to pick the correct DTB for the boards
> > that use the software package. This patch introduces a common language
> > for adding board identifiers to devicetrees.
> >
> > Signed-off-by: Elliot Berman <quic_eberman(a)quicinc.com>
> > ---
> > .../devicetree/bindings/board/board-id.yaml | 71 ++++++++++++++++++++++
> > 1 file changed, 71 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/board/board-id.yaml b/Documentation/devicetree/bindings/board/board-id.yaml
> > new file mode 100644
> > index 000000000000..894c1e310cbd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/board/board-id.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/board/board-id.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Board identifiers
> > +description: |
> > + This node contains a list of identifier values for the board(s) supported by
> > + this devicetree. Identifier values are either N-tuples of integers or a
> > + string. The number of items for an N-tuple identifer is determined by the
> > + property name. String identifiers must be suffixed with "-string".
> > +
> > + Every identifier in the devicetree must have a matching value from the board
> > + to be considered a valid devicetree for the board. In other words: if
> > + multiple identifiers are present in the board-id and one identifier doesn't
> > + match against the board, then the devicetree is not applicable. Note this is
> > + not the case where the the board can provide more identifiers than the
> > + devicetree describes: those additional identifers can be ignored.
> > +
> > + Identifiers in the devicetree can describe multiple possible valid values,
> > + such as revision 1 and revision 2.
> > +
> > +maintainers:
> > + - Elliot Berman <quic_eberman(a)quicinc.com>
> > +
> > +properties:
> > + $nodename:
> > + const: '/'
> > + board-id:
>
>
> Does this need to be
> properties:
> $nodename:
> const: board-id
> ? That's the pattern I see for all top level nodes.
>
> > + type: object
> > + patternProperties:
> > + "^.*(?<!-string)$":
>
> At least this regex now actually works :)
>
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > + description: |
> > + List of values that match boards this devicetree applies to.
> > + A bootloader checks whether any of the values in this list
> > + match against the board's value.
> > +
> > + The number of items per tuple is determined by the property name,
> > + see the vendor-specific board-id bindings.
> > + "^.*-string$":
> > + $ref: /schemas/types.yaml#/definitions/string-array
>
> Your description above doesn't match a string-array, just a single
> string. That said I'm far from sold on the "thou shalt have -string"
> edict. If every vendor is expected to go and define their own set of
> properties (and provide their own callback in your libfdt PoC) there's
> little to no reason to inflict property naming on them, AFAICT all that
> is gained is a being able to share
> if (string) {
> return fdt_stringlist_contains(prop->data,
> fdt32_to_cpu(prop->len),
> data);
> } else {
> // exact data comparison. data_len is the size of each entry
> if (fdt32_to_cpu(prop->len) % data_len || data_len % 4)
> return -FDT_ERR_BADVALUE;
>
> for (int i = 0; i < fdt32_to_cpu(prop->len); i += data_len) {
> if (!memcmp(&prop->data[i], data, data_len))
> return 1;
> }
>
> return 0;
> }
> in the libfdt PoC? I'd be expecting that a common mechanism would use
> the same "callback" for boards shipped by both Qualcomm and
> $other_vendor. Every vendor having different properties and only sharing
> the board-id node name seems a wee bit like paying lip-service to a
> common mechanism to me. What am I missing?
One way I thought to get the real board-id values from firmware to OS
loader is via DT itself. A firmware-provided DT provides the real
board-id values. In this case, firmware doesn't have any way to say the
board-id property is a string or a number, so I put that info in the DT
property name.
Another way I thought to get the real board-id values from firmware is
via a UEFI protocol. In that case, we could easily share whether the
value is a string or number and we can drop the "-string" suffix bit.
Thanks,
Elliot
On Sat, May 25, 2024 at 06:21:32PM +0100, Conor Dooley wrote:
> On Tue, May 21, 2024 at 11:38:01AM -0700, Elliot Berman wrote:
> > #define QCOM_BOARD_ID(a, major, minor) \
> > - (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a)
> > + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | ((QCOM_BOARD_ID_##a) & 0xff))
>
> I assume there's no devices that have a >8 bit QCOM_BOARD_ID that would
> end up with a different value in their dtb due to this change?
That's correct.
