Sorry for the spam, earlier mail had some formatting issue.
On 1/24/2024 8:26 PM, Rob Herring wrote:
On Sat, Jan 20, 2024 at 04:50:47PM +0530, Amrit Anand 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.
Show me a 2nd user. Or does vendor/OEM-agnostic just mean vendors of
QCom devices? Multiple SoC families using this would help your case. I'm
not inclined to take it into the DTSpec without that.
Agree; since the DT selection identifiers and algorithm used by various
DT users has been largely undocumented, we were trying to reach a
generic solution based on our known use-cases.
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 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.
You could hash the compatible strings if it was just a size issue.
The solution proposed here is simpler to implement and doesn't require
updating firmware or bootloader for every new board.
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.
So the id list will be always expanding list for every last component
that is 2nd sourced? The ChromeOS folks are also trying to solve that
problem.
Agree, this could be an expanding list as and when any new hardware
identifiers for DT selection become pertinent in future.
There's a similar issue for EFI boot with how to select an OS installed
DTB[1]. You might not care now, but users may later on (like we have
already with QCom devices with fixed bootloaders). If you do this
board-id route, then no doubt that compatible values won't be specific
enough or have suitable fallbacks to be used. Then EFI boot can't use
compatible either and needs to use this QCom specific logic. It may be a
common property name, but all the types you defined are QCom specific
and the matching logic is pretty much undocumented. I'm not saying we
have to use compatible. There wasn't even agreement to use it for EFI
boot case. This does need to work for multiple vendors and multiple boot
scenarios.
Agree, given so many hardware identifiers Qcom uses to find the DT based
on a best and exact match algorithm, it may not work as is for other
vendors/users outside the scope of Qcom.
Since we have none to very limited visibility into complete set of DT
selection identifiers being used by other users or into their selection
algorithms since it is mostly undocumented,
designing a perfectly generic solution (one-size-fits-all) could be
far-fetched. The number of board files in Qcom DT selection software
package often reaches over 100 DT files due to multiple SoCs and
board types being supported out of a single software package and these
multiple hardware identifiers helps to pick the closest best match DT
within a very large pool of DTs.
Not to affect other users/vendors who would be using their own set of
identifiers and an entirely different algorithm for DT selection, would
it make more sense to define these Qcom specific
identifiers within Qcom specific bindings (qcom.yaml), along with
detailed documentation on our DT selection algorithm?
Thanks,
Amrit
Rob
[1] https://lore.kernel.org/u-boot/20231114232012.GD6601@bill-the-cat/#r
