Re: [PATCH RFC v3 0/9] dt-bindings: hwinfo: Introduce board-id

From: Michal Simek
Date: Thu May 30 2024 - 10:13:02 EST



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