Re: SoC-specific device tree aliases?

[Sascha Hauer <s.hauer@pengutronix.de>]

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.

On i.MX these used to be the aliases in /aliases/. Nowadays we agree
that the instance numbers in the aliases are board specific, hence Ahmad
is asking for a place to store SoC specific aliases.

The properties do not have to contain a full device path, a phandle
would do it as well.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |