devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elliot Berman <quic_eberman@quicinc.com>
To: Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Amrit Anand <quic_amrianan@quicinc.com>,
	Peter Griffin <peter.griffin@linaro.org>,
	Caleb Connolly <caleb.connolly@linaro.org>,
	"Andy Gross" <agross@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	"Doug Anderson" <dianders@chromium.org>,
	Simon Glass <sjg@chromium.org>,
	"Chen-Yu Tsai" <wenst@chromium.org>,
	Julius Werner <jwerner@chromium.org>,
	"Humphreys, Jonathan" <j-humphreys@ti.com>,
	Sumit Garg <sumit.garg@linaro.org>,
	"Jon Hunter" <jonathanh@nvidia.org>,
	Michal Simek <michal.simek@amd.com>,
	<boot-architecture@lists.linaro.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-arm-msm@vger.kernel.org>,
	Elliot Berman <quic_eberman@quicinc.com>
Subject: [PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id
Date: Tue, 21 May 2024 11:37:57 -0700	[thread overview]
Message-ID: <20240521-board-ids-v3-0-e6c71d05f4d2@quicinc.com> (raw)

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/thread/DZCZSOCRH5BN7YOXEL2OQKSDIY7DCW2M/

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@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/#r

---
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>


             reply	other threads:[~2024-05-21 18:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 18:37 Elliot Berman [this message]
2024-05-21 18:37 ` [PATCH RFC v3 1/9] libfdt: board-id: Implement board-id scoring Elliot Berman
2024-05-21 19:28   ` Conor Dooley
2024-05-22 23:57     ` Elliot Berman
2024-05-21 18:37 ` [PATCH RFC v3 2/9] dt-bindings: board: Introduce board-id Elliot Berman
2024-05-21 19:19   ` Rob Herring (Arm)
2024-05-21 19:21   ` Conor Dooley
2024-05-21 19:25     ` Conor Dooley
2024-05-21 21:32       ` Rob Herring
2024-05-21 21:47         ` Conor Dooley
2024-05-22 23:47     ` Elliot Berman
2024-05-22 23:54       ` Elliot Berman
2024-05-23  1:23         ` Rob Herring (Arm)
2024-05-25 16:54         ` Conor Dooley
2024-05-29 15:43           ` Elliot Berman
2024-05-21 18:38 ` [PATCH RFC v3 3/9] fdt-select-board: Add test tool for selecting dtbs based on board-id Elliot Berman
2024-05-21 18:38 ` [PATCH RFC v3 4/9] dt-bindings: arm: qcom: Update Devicetree identifiers Elliot Berman
2024-05-25 17:21   ` Conor Dooley
2024-05-29 15:34     ` Elliot Berman
2024-05-21 18:38 ` [PATCH RFC v3 5/9] dt-bindings: board: Document board-ids for Qualcomm devices Elliot Berman
2024-05-21 19:19   ` Rob Herring (Arm)
2024-05-25 17:08   ` Conor Dooley
2024-05-29 15:09     ` Elliot Berman
2024-05-21 18:38 ` [PATCH RFC v3 6/9] arm64: boot: dts: sm8650: Add board-id Elliot Berman
2024-06-05  8:18   ` Krzysztof Kozlowski
2024-05-21 18:38 ` [PATCH RFC v3 7/9] arm64: boot: dts: qcom: Use phandles for thermal_zones Elliot Berman
2024-05-21 18:38 ` [PATCH RFC v3 8/9] arm64: boot: dts: qcom: sm8550: Split into overlays Elliot Berman
2024-06-05  8:20   ` Krzysztof Kozlowski
2024-05-21 18:38 ` [PATCH RFC v3 9/9] tools: board-id: Add test suite Elliot Berman
2024-05-21 19:00 ` [PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id Dmitry Baryshkov
2024-05-24 15:51   ` Konrad Dybcio
2024-05-27  7:19     ` Michal Simek
2024-05-29 15:32       ` Elliot Berman
2024-05-30 14:12         ` Michal Simek
2024-06-05 13:17 ` Simon Glass
2024-06-05 17:17   ` Elliot Berman
2024-06-06 16:00     ` Simon Glass
2024-06-21 22:40       ` Elliot Berman
2024-06-22  7:18         ` Dmitry Baryshkov
2024-06-28  7:33         ` Simon Glass
2024-06-28  8:04           ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240521-board-ids-v3-0-e6c71d05f4d2@quicinc.com \
    --to=quic_eberman@quicinc.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=boot-architecture@lists.linaro.org \
    --cc=caleb.connolly@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=frowand.list@gmail.com \
    --cc=j-humphreys@ti.com \
    --cc=jonathanh@nvidia.org \
    --cc=jwerner@chromium.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=peter.griffin@linaro.org \
    --cc=quic_amrianan@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=sjg@chromium.org \
    --cc=sumit.garg@linaro.org \
    --cc=wenst@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).