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

[Michal Simek]

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