[v2,0/2] Add board-id support for multiple DT selection

Message

Amrit Anand March 14, 2024, 12:11 p.m. UTC

The software packages are shipped with multiple device tree blobs supporting
multiple boards. For instance, suppose we have 3 SoC, each with 4 boards supported,
along with 2 PMIC support for each case which would lead to total of 24 DTB files.
Along with these configurations, OEMs may also add certain additional board variants.
Hence, a mechanism is required to pick the correct DTB for the board on which the
software package is deployed. Introduce a unique property for adding board identifiers
to device trees. Here, board-id property provides a mechanism for Qualcomm based
bootloaders to select the appropriate DTB.

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 have complex compatible string parsing and matching.
Compatible string matching becomes complicated when there are multiple
versions of the same board. It becomes difficult for the device tree
selection mechanism to recognize the right DTB to pick, with minor
differences in compatible strings.

The solution proposed here is simpler to implement and doesn't require the need
to update bootloader for every new board.

How is this better than Qualcomm's qcom,msm-id/qcom,board-id?
-------------------------------------------------------------
Qualcomm's qcom,msm-id/qcom,board-id are not scalable for other distinguishing
features as we need to add a new property every time. Board-id property provide
a solution that the bootloader can use to select appropriate device tree. Board-id
encapsulates soc, board, pmic and oem identifiers. Qualcomm based bootloader can use
these key-value pairs to uniquely identify the device tree. This solution scales well
for cases where additional identifiers would be needed for device tree selection
criteria. Adding a new tuple in "board-id" along with "board-id-type" will help support it.
				      
Changes in V2:
 - Based on comment on V1 related to challenges on designing common bootloader for all
   the vendors, where different vendors can have different representation of board-id
   and the best and exact match logic can also be different for different vendors, moving
   the board-id definition in qcom specific binding.
 - Adding support for board IDs for all the boards that are in kernel.org.
 - Adding Qualcomm bootloader best/exact match logic for multi DT selection. 
 - Keeping list of other vendors in CC for comment/awareness related to this requirement 
 - Link to V1: https://lore.kernel.org/all/[e-mail]/

Amrit Anand (2):
  dt-bindings: arm: qcom: Update Devicetree identifiers
  dt-bindings: qcom: Update DT bindings for multiple DT

 Documentation/devicetree/bindings/arm/qcom.yaml | 90 +++++++++++++++++++++++++
 include/dt-bindings/arm/qcom,ids.h              | 86 ++++++++++++++++++++---
 2 files changed, 167 insertions(+), 9 deletions(-)

Comments

Krzysztof Kozlowski March 28, 2024, 8:50 a.m. UTC | #1

On 14/03/2024 13:11, Amrit Anand wrote:
> The software packages are shipped with multiple device tree blobs supporting
> multiple boards. For instance, suppose we have 3 SoC, each with 4 boards supported,
> along with 2 PMIC support for each case which would lead to total of 24 DTB files.
> Along with these configurations, OEMs may also add certain additional board variants.
> Hence, a mechanism is required to pick the correct DTB for the board on which the
> software package is deployed. Introduce a unique property for adding board identifiers
> to device trees. Here, board-id property provides a mechanism for Qualcomm based
> bootloaders to select the appropriate DTB.
> 
> 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 have complex compatible string parsing and matching.
> Compatible string matching becomes complicated when there are multiple
> versions of the same board. It becomes difficult for the device tree
> selection mechanism to recognize the right DTB to pick, with minor
> differences in compatible strings.
> 
> The solution proposed here is simpler to implement and doesn't require the need
> to update bootloader for every new board.

One of the concerns you got in v1 was: show us second user, so I believe
in your interest is to Cc other platform maintainers which could support
this idea.

Best regards,
Krzysztof