Hi Elliot,
On Tue, 21 May 2024 at 12:38, Elliot Berman quic_eberman@quicinc.com wrote:
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].
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.
That is not necessary, though. The compatible string should be enough.
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@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.com...
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@quicinc.com
I am just picking up the discussion here, which was started on another thread.
I can't see why this new feature is needed. We should be able to use compatible strings, as we do now. I added a 'usage' section to the FIT spec [1] which might help. I also incorporated the board revision and variant information and some notes on how to add to the available suffixes.
Does that handle your use case?
Regards, Simon
[1] https://github.com/open-source-firmware/flat-image-tree/blob/main/source/cha...