Re: SoC-specific device tree aliases?

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?

Best regards,
Krzysztof