Re: SoC-specific device tree aliases?

On 17/11/2025 09:26, Sascha Hauer wrote:
> On Mon, Nov 17, 2025 at 08:38:48AM +0100, Krzysztof Kozlowski wrote:
>> On 13/11/2025 09:28, Ahmad Fatoum wrote:
>>> Hello,
>>>
>>> With /chosen/bootsource now part of dt-schema, I would like to raise a
>>> related point: The need for SoC-specific device tree aliases.
>>>
>>> For many SoCs, there is a canonical numbering for peripherals; it's used
>>> in the datasheet and BootROMs often makes use of it at runtime to report
>>> the bootsource as a pair:
>>>
>>>   - One value to enumerate type of boot medium (e.g. mmc, spi-nor..)
>>>   - Another value that describes which instance (e.g. SDHC1, SPI3, ...)
>>>
>>> Some examples, where this is the case, are AT91, STM32MP or i.MX.
>>>
>>> barebox has traditionally used /aliases to translate BootROM information
>>> to a device tree node to fixup /chosen/bootsource.
>>>
>>> This doesn't work out for many newer SoC support, because of different
>>> expectations: For upstream, aliases are relevant to a board, while
>>> barebox traditionally expected them to be SoC-specific (because they
>>> used to be on i.MX, probably).
>>
>> Please state exactly the problem - you have aliases in DTS but
>> bootsource in DTSI? Then that's clearly mixup - you need to define them
>> in the same place. Aliases are in DTS (I see here other thread on that),
>> so stdout-path is also in DTS.
>>
>> Or you don't have bootsource in DTSI at all because barebox invents it
>> regardless of actual aliases? Then shouldn't this be an obvious issue?
>> You cannot have barebox as second source of aliases.
>>
>>>
>>> To accommodate this, barebox nowadays extends upstream device trees with
>>> /chosen/barebox,bootsource-${alias} properties, which can be used as
>>> translation table instead of aliases.
>>>
>>> This solves the issue, but there is occasional breakage when upstream
>>> decides to remove aliases from the SoC DTSI and move them into the
>>> boards until barebox is made to add the /chosen/barebox, overrides.
>>>
>>> As described above, I think the data sheet numbering is pretty much an
>>> aspect of the hardware and it has a place in the upstream SoC DTSI.
>>>
>>>
>>> So what are the thoughts on adding /soc/aliases or some other top-level
>>> node to hold this information?
>>> Or would a h"ardware-label" property or similar be more tenable?
>>
>> So you want to map full node path to some alias, so later you can map
>> that alias back to full node path, right? This sounds like quite
>> redundant information in DTS just to avoid impact of node reshuffling
>> (like unit address changes). In DTS-source-code realm, we solved it with
>> phandles. Maybe this would help here?
> 
> We want aliases that map from the hardware numbers of a device as used
> in the reference manuals to the actual device nodes. One reason why we
> need it is to get the device node a SoC has booted from. Many SoCs have
> registers which describe <bootsource> <instance number>. We want to get
> the device node from that information.

Ah, so you don't map from full node path but from some value in register
and you want to store these values as alias. I see i.MX gives here such
information but that might be the only user. Samsung AFAIK only gives
the order of boot device choices, not which one was chosen, for Qcom I
could not find at all.

Aliases could be solution here but it is as fragile as simple arithmetic
of sorting MMC nodes by unit address...


Best regards,
Krzysztof