Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski <krzk@kernel.org>]

On 17/11/2025 11:34, Sascha Hauer wrote:
> On Mon, Nov 17, 2025 at 10:52:49AM +0100, Krzysztof Kozlowski wrote:
>> 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.
> 
> Not sure if we mean the same when you say "store these values as alias".
> 
> What we want to do is a SoC dtsi providing something like:

I meant how your bootloader/barebox generates this information.


Best regards,
Krzysztof