Re: SoC-specific device tree aliases?

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

On Mon, Nov 17, 2025 at 03:57:19PM +0100, Krzysztof Kozlowski wrote:
> On 17/11/2025 15:52, Sascha Hauer wrote:
> > On Mon, Nov 17, 2025 at 02:18:02PM +0100, Krzysztof Kozlowski wrote:
> >> On 17/11/2025 13:56, Marc Kleine-Budde wrote:
> >>> On 17.11.2025 11:41:12, Krzysztof Kozlowski wrote:
> >>>> 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.
> >>>
> >>> Most SoC have 1 or 2 registers where you can read the source where the
> >>> system has booted from.
> >>>
> >>> One register contains the information such as eMMC, NAND, USB, serial
> >>
> >> I know.
> >>
> >>> download, ... the other register contains the information about which
> >>> instance, e.g. 0, 1, 2... The boot loader combines both pieces of
> >>> information and knows the boot source of the system.
> >>>
> >>> The problem we want to solve is the mapping from the SoC specific
> >>> numbering of the registers to the devices in the DT.
> >>
> >> You are both not replying to what I said.
> >>
> >> So to recall, I said your bootloader comes with something read from
> >> register values and uses this to match the alias from DT and that's as
> >> fragile as doing simple unit address based arithmetic after sorting.
> > 
> > I don't get what you mean with "simple unit address based arithmetic
> > after sorting".
> 
> You read from registers booted device MMC 1 (out of MMC 0-2), so instead
> of relying on register value that "1" always means MMC1, not MMC0 for
> example or whatever else changed in hardware, you can just sort the
> nodes by unit address and choose the second device.

The instance numbers do not always match the unit address sorting.

For example K3 SoCs have:

dts/src/arm64/ti/k3-am62-main.dtsi:548: sdhci0: mmc@fa10000 {
dts/src/arm64/ti/k3-am62-main.dtsi:566: sdhci1: mmc@fa00000 {
dts/src/arm64/ti/k3-am62-main.dtsi:589: sdhci2: mmc@fa20000 {

Rockchip:

dts/src/arm64/rockchip/rk356x-base.dtsi:619:    sdmmc2: mmc@fe000000 {
dts/src/arm64/rockchip/rk356x-base.dtsi:994:    sdmmc0: mmc@fe2b0000 {
dts/src/arm64/rockchip/rk356x-base.dtsi:1008:   sdmmc1: mmc@fe2c0000 {

There are some examples for i.MX as well. To my own surprise not with
the mmc nodes, but some SPI instances are not sorted by unit address.

> 
> 
> > 
> > Also I don't get whether you are suggesting
> > 
> > A is as fragile as B, so you could equally well do B
> 
> Both are fragile, so I would be happy to see arguments why A is better
> than B. Why? Because with B you don't need any binding because all the
> information is already in DTS.

What do you consider fragile with it?

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 |