| Message ID | 20240521-board-ids-v3-0-e6c71d05f4d2@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | dt-bindings: hwinfo: Introduce board-id | expand |
Hi Elliot, On Tue, 21 May 2024 at 21:41, 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 is a v3 of the RFC, however it is still a qcom-only series. Might I suggest gaining an actual interest from any other hardware vendor (in the form of the patches) before posting v4? Otherwise it might still end up being a Qualcomm solution which is not supported and/or used by other hardware vendors. > > 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/ >
On 21.05.2024 9:00 PM, Dmitry Baryshkov wrote: > Hi Elliot, > > On Tue, 21 May 2024 at 21:41, 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 is a v3 of the RFC, however it is still a qcom-only series. Might > I suggest gaining an actual interest from any other hardware vendor > (in the form of the patches) before posting v4? Otherwise it might > still end up being a Qualcomm solution which is not supported and/or > used by other hardware vendors. AMD should be onboard [1]. Konrad [1] https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3
Hi, thanks for CCing me. On 5/24/24 17:51, Konrad Dybcio wrote: > On 21.05.2024 9:00 PM, Dmitry Baryshkov wrote: >> Hi Elliot, >> >> On Tue, 21 May 2024 at 21:41, 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 is a v3 of the RFC, however it is still a qcom-only series. Might >> I suggest gaining an actual interest from any other hardware vendor >> (in the form of the patches) before posting v4? Otherwise it might >> still end up being a Qualcomm solution which is not supported and/or >> used by other hardware vendors. > > AMD should be onboard [1]. > > Konrad > > [1] https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3 I am trying to wrap my head around this and I have also looked at that EOSS presentation. I don't think I fully understand your case. There are multiple components which you need to detect. SOC - I expect reading by some regs, board - I expect you have any eeprom, OTP, adc, gpio, etc way how to detect board ID and revision. And then you mentioned displays - how do you detect them? In our Kria platform we have eeproms on SOM and CC cards (or FMC/extension cards) which we read and decode and based on information from it we are composing "unique" string. And then we are having DTBs in FIT image where description of configuration it taken as regular expression. That's why it is up to you how you want to combine them. Currently we are merging them offline and we are not applying any DT overlay at run time but can be done (we are missing one missing piece in U-Boot for it). In presentation you mentioned also that applying overlay can fail but not sure how you can reach it. Because Linux kernel has the whole infrastructure to cover all combinations with base DT + overlays. It means if you cover all working combinations there you should see if they don't apply properly. Also do you really need to detect everything from firmware side? Or isn't it enough to have just "some" devices and then load the rest where you are in OS? I think that's pretty much another way to go to have bare minimum functionality provided by firmware and deal with the rest in OS. Thanks, Michal
On Mon, May 27, 2024 at 09:19:59AM +0200, Michal Simek wrote: > Hi, > > thanks for CCing me. > > On 5/24/24 17:51, Konrad Dybcio wrote: > > On 21.05.2024 9:00 PM, Dmitry Baryshkov wrote: > > > Hi Elliot, > > > > > > On Tue, 21 May 2024 at 21:41, 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 is a v3 of the RFC, however it is still a qcom-only series. Might > > > I suggest gaining an actual interest from any other hardware vendor > > > (in the form of the patches) before posting v4? Otherwise it might > > > still end up being a Qualcomm solution which is not supported and/or > > > used by other hardware vendors. > > > > AMD should be onboard [1]. > > > > Konrad > > > > [1] https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3 > > I am trying to wrap my head around this and I have also looked at that EOSS > presentation. > I don't think I fully understand your case. > There are multiple components which you need to detect. SOC - I expect > reading by some regs, board - I expect you have any eeprom, OTP, adc, gpio, > etc way how to detect board ID and revision. > And then you mentioned displays - how do you detect them? We have a similar mechanism to what you mention below: we have a ROM which encodes information about the platform and that can be read by firmware/bootloader/OS. > > In our Kria platform we have eeproms on SOM and CC cards (or FMC/extension > cards) which we read and decode and based on information from it we are > composing "unique" string. And then we are having DTBs in FIT image where > description of configuration it taken as regular expression. That's why it > is up to you how you want to combine them. I don't think this is a fundamentally different approach from my proposal. Instead of composing a "unique" string and using regex to match, I'm proposing that the information (bytes) that are in your eeprom can be matched without going through regex/string conversion. Instead of firmware/bootloader doing a conversion to the strings, it provides the values via board-id. I have concerns about having bootloaders to contain a regex library -- probably easily addressed by standardizing what terms the regex processor needs to support. I'm also not sure if regex strings are an appropriate use of compatible strings. Using strings limits the usefulness of comaptible strings to the consumers of DTB, since the compatible string has to describe only the boards the DTB is applicable to, you can't mention compatible strings "this board is like" such as some generic SoC compatible. > Currently we are merging them offline and we are not applying any DT overlay > at run time but can be done (we are missing one missing piece in U-Boot for > it). > > In presentation you mentioned also that applying overlay can fail but not > sure how you can reach it. Because Linux kernel has the whole infrastructure > to cover all combinations with base DT + overlays. It means if you cover all > working combinations there you should see if they don't apply properly. Mostly, I was referring to a situation where firmware provides an overlay. Firmware doesn't know the DTB that OS has and I don't see any way to gaurantee that firmware knows how to fix up the OS DTB. > > Also do you really need to detect everything from firmware side? Or isn't it > enough to have just "some" devices and then load the rest where you are in > OS? > I think that's pretty much another way to go to have bare minimum > functionality provided by firmware and deal with the rest in OS. Agreed, although not all devices can be loaded once you are in the OS. All nondiscoverable devices would need to be desribed in the DT. Thanks, Elliot
On 5/29/24 17:32, Elliot Berman wrote: > On Mon, May 27, 2024 at 09:19:59AM +0200, Michal Simek wrote: >> Hi, >> >> thanks for CCing me. >> >> On 5/24/24 17:51, Konrad Dybcio wrote: >>> On 21.05.2024 9:00 PM, Dmitry Baryshkov wrote: >>>> Hi Elliot, >>>> >>>> On Tue, 21 May 2024 at 21:41, 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 is a v3 of the RFC, however it is still a qcom-only series. Might >>>> I suggest gaining an actual interest from any other hardware vendor >>>> (in the form of the patches) before posting v4? Otherwise it might >>>> still end up being a Qualcomm solution which is not supported and/or >>>> used by other hardware vendors. >>> >>> AMD should be onboard [1]. >>> >>> Konrad >>> >>> [1] https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3 >> >> I am trying to wrap my head around this and I have also looked at that EOSS >> presentation. >> I don't think I fully understand your case. >> There are multiple components which you need to detect. SOC - I expect >> reading by some regs, board - I expect you have any eeprom, OTP, adc, gpio, >> etc way how to detect board ID and revision. >> And then you mentioned displays - how do you detect them? > > We have a similar mechanism to what you mention below: we have a ROM > which encodes information about the platform and that can be read by > firmware/bootloader/OS. > >> >> In our Kria platform we have eeproms on SOM and CC cards (or FMC/extension >> cards) which we read and decode and based on information from it we are >> composing "unique" string. And then we are having DTBs in FIT image where >> description of configuration it taken as regular expression. That's why it >> is up to you how you want to combine them. > > I don't think this is a fundamentally different approach from my > proposal. Instead of composing a "unique" string and using regex to > match, I'm proposing that the information (bytes) that are in your > eeprom can be matched without going through regex/string conversion. > Instead of firmware/bootloader doing a conversion to the strings, it > provides the values via board-id. I have concerns about having > bootloaders to contain a regex library -- probably easily addressed by > standardizing what terms the regex processor needs to support. I'm also > not sure if regex strings are an appropriate use of compatible strings. > Using strings limits the usefulness of comaptible strings to the > consumers of DTB, since the compatible string has to describe only the > boards the DTB is applicable to, you can't mention compatible strings > "this board is like" such as some generic SoC compatible. We use regular expression to match fit images configuration description not actual DT itself. And because we have base DT for SOM and overlays for CC we are just using compatible string which is coming from CC only. That's because fdtoverlay works like that (pretty much when compose them together compatible and model are rewritten based on information from overlay). In past when we used applying DT overlay at run time via OS origin compatible/model strings were used. I don't think we have any need to try to look for DTs provided by generic distributions (generated mostly via make dtbs_install) and we tend to provide DT directly by firmware as is required by SR IR. And DTs for programmable logic are coupled with bitstream itself and for it at least on SOM OS is fully aware about base board and it's revision and chip size that user space loader know exactly where it runs and which bitstreams are compatible with that combination. > >> Currently we are merging them offline and we are not applying any DT overlay >> at run time but can be done (we are missing one missing piece in U-Boot for >> it). >> >> In presentation you mentioned also that applying overlay can fail but not >> sure how you can reach it. Because Linux kernel has the whole infrastructure >> to cover all combinations with base DT + overlays. It means if you cover all >> working combinations there you should see if they don't apply properly. > > Mostly, I was referring to a situation where firmware provides an > overlay. Firmware doesn't know the DTB that OS has and I don't see any > way to gaurantee that firmware knows how to fix up the OS DTB. In our case firmware is providing DTB to OS (own or via bootstript). 99% of our DTSes are generated via our Device Tree Generator with connection to HW design which is used. And it is pretty much unique based on used configuration that's why I don't think we get to situation that OS will provide correct DT for us. That also means that we are not doing fixups in firmware because that fixups are coming to device tree generator aligned with particular releases. > >> >> Also do you really need to detect everything from firmware side? Or isn't it >> enough to have just "some" devices and then load the rest where you are in >> OS? >> I think that's pretty much another way to go to have bare minimum >> functionality provided by firmware and deal with the rest in OS. > > Agreed, although not all devices can be loaded once you are in the OS. > All nondiscoverable devices would need to be desribed in the DT. From my perspective IDs you are talking about can be find via different channels then just reading it via DT. They can be passed but we simply just read our EEPROMs again and also chipid via nvmem in OS and used that information for dealing with DT overlays. I don't think that we have the same need as you have but it is pretty much because our programmable logic needs to be handled differently. Thanks, Michal
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]. > > [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. 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/#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> > 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/chapter3-usage.rst
On Wed, Jun 05, 2024 at 07:17:35AM -0600, Simon Glass wrote: > Hi Elliot, > > 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? -rev and -sku don't fit the versioning scheme for QTI devices, so this isn't a generic enough approach. Patch 5 in this series describes the versioning scheme for us. In the other thread, we had talked about using some regex based approach for matching the root node compatible. I haven't had chance to work on that proposal and will try to get to it in the next couple weeks. Thanks, Elliot
Hi Elliot, On Wed, 5 Jun 2024 at 11:17, Elliot Berman <quic_eberman@quicinc.com> wrote: > > On Wed, Jun 05, 2024 at 07:17:35AM -0600, Simon Glass wrote: > > Hi Elliot, > > > > 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? > > -rev and -sku don't fit the versioning scheme for QTI devices, so this > isn't a generic enough approach. Patch 5 in this series describes the > versioning scheme for us. > > In the other thread, we had talked about using some regex based approach > for matching the root node compatible. I haven't had chance to work on > that proposal and will try to get to it in the next couple weeks. OK, I look forward to it. Please do check the FIT best match approach and see how it might be extended to handle your requirements. So far I have not seen a need for regexes, but it is certainly a possibility. Regards, Simon
Hi Simon, On Thu, Jun 06, 2024 at 10:00:54AM -0600, Simon Glass wrote: > On Wed, 5 Jun 2024 at 11:17, Elliot Berman <quic_eberman@quicinc.com> wrote: > > On Wed, Jun 05, 2024 at 07:17:35AM -0600, Simon Glass wrote: > > > Hi Elliot, > > > > > > 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? > > > > -rev and -sku don't fit the versioning scheme for QTI devices, so this > > isn't a generic enough approach. Patch 5 in this series describes the > > versioning scheme for us. > > > > In the other thread, we had talked about using some regex based approach > > for matching the root node compatible. I haven't had chance to work on > > that proposal and will try to get to it in the next couple weeks. > > OK, I look forward to it. Please do check the FIT best match approach > and see how it might be extended to handle your requirements. So far I > have not seen a need for regexes, but it is certainly a possibility. > I spent some time collecting feedback from the team on using compatible strings + regex-style approach and we're not able to add a regex library into firmware, so this approach unfortunately won't work for us. Because we have more axes of board identification than chromebook, using FIT's compatible strings isn't a scalable solution for us. I don't think we have incompatible problems, we only have more than 2-3 axes of information. Thanks, Elliot
On Fri, Jun 21, 2024 at 03:40:20PM GMT, Elliot Berman wrote: > Hi Simon, > > On Thu, Jun 06, 2024 at 10:00:54AM -0600, Simon Glass wrote: > > On Wed, 5 Jun 2024 at 11:17, Elliot Berman <quic_eberman@quicinc.com> wrote: > > > On Wed, Jun 05, 2024 at 07:17:35AM -0600, Simon Glass wrote: > > > > Hi Elliot, > > > > > > > > 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? > > > > > > -rev and -sku don't fit the versioning scheme for QTI devices, so this > > > isn't a generic enough approach. Patch 5 in this series describes the > > > versioning scheme for us. > > > > > > In the other thread, we had talked about using some regex based approach > > > for matching the root node compatible. I haven't had chance to work on > > > that proposal and will try to get to it in the next couple weeks. > > > > OK, I look forward to it. Please do check the FIT best match approach > > and see how it might be extended to handle your requirements. So far I > > have not seen a need for regexes, but it is certainly a possibility. > > > > I spent some time collecting feedback from the team on using compatible > strings + regex-style approach and we're not able to add a regex library > into firmware, so this approach unfortunately won't work for us. Why? What is the size growth caused by the RegularExpressionDxe ? > Because we have more axes of board identification than chromebook, using > FIT's compatible strings isn't a scalable solution for us. I don't think > we have incompatible problems, we only have more than 2-3 axes of > information. Well, not using compatibles / strings results in most of the phone vendors having just the 'MTP' as their platform id. It makes then impossible to have an image with several DTB files targeting different phone families from several vendors. What looks like a nice feature for MTP vs QRD vs HDK becomes useless with the end-user devices.
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,