Re: SoC-specific device tree aliases?

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

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:

/soc-aliases {
	mmc0 = &sdhci1;
	mmc1 = &sdhci2;
	mmc2 = &sdhci3;
};

With the mmc<X> numbers being the instance numbers from the reference
manual. We can then read the instance number from the SoC registers and
get the device node from that number by looking it up in the aliases.

We use this for example to load the kernel from the device barebox
itself has booted from.

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

Other examples include TI Omap/K3, AT91, Rockchip SoCs, STM32MP1.

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 |