SoC-specific device tree aliases?

SoC-specific device tree aliases?

[Ahmad Fatoum]

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

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?


Thanks!
Ahmad

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

Re: SoC-specific device tree aliases?

[Rob Herring]

On Thu, Nov 13, 2025 at 2:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> 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.

So bootsource will be populated "mmc0" or "spinor1" for example?

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

But usually the numbering follows the SoC numbering. Sometimes it
follows the PCB numbering, but I think that's mainly serial ports.
I've certainly steered people away from vendor specific instance
numbering properties towards aliases (if the need can't be eliminated
entirely).

The board specific part I think is more that the board defines what
devices are present and not present. It would be weird to have a
serial3 alias when that's not wired up. And board .dts files are going
to forget to remove it. Though I guess it is somewhat harmless.

I think the real change here is it would make aliases required when
currently they aren't really. Though I guess populating bootsource is
entirely optional?

Rob

Re: SoC-specific device tree aliases?

[Doug Anderson]

Hi,

On Thu, Nov 13, 2025 at 10:12 AM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Nov 13, 2025 at 2:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> 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.
>
> So bootsource will be populated "mmc0" or "spinor1" for example?
>
> > 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).
>
> But usually the numbering follows the SoC numbering. Sometimes it
> follows the PCB numbering, but I think that's mainly serial ports.
> I've certainly steered people away from vendor specific instance
> numbering properties towards aliases (if the need can't be eliminated
> entirely).

It's been a long time since I was involved in any discussion about
this, but I remember Arnd Bergmann being strongly against having
numbering aliases in the SoC "dtsi" file. I was always on the opposite
side of this argument, but it seems reasonable to include him in the
conversation.

From my point of view, with the exception of the "serial" alias folks
almost always wanted devices to be numbered as per the SoC numbering,
as long as there was a well-defined SoC numbering. For instance, if
the SoC manual consistently calls a port "i2c12" then it's pretty
confusing if the device doesn't end up as "/dev/i2c12". This always
led me to the argument that aliases like this should be in the SoC
".dtsi" file.

The "serial" alias is a bit of a special case because of historical
assumptions. It's often assumed that serial port "0" is the debug
port. Luckily there aren't usually so many active serial ports so it's
not terribly confusing...


> The board specific part I think is more that the board defines what
> devices are present and not present. It would be weird to have a
> serial3 alias when that's not wired up. And board .dts files are going
> to forget to remove it. Though I guess it is somewhat harmless.

To me it doesn't seem awful to still have the alias pointing to a
"disabled" node. The node is still there, so why can't the alias still
be there?

-Doug

Re: SoC-specific device tree aliases?

[Heiko Stübner]

Am Donnerstag, 13. November 2025, 20:17:40 Mitteleuropäische Normalzeit schrieb Doug Anderson:
> Hi,
> 
> On Thu, Nov 13, 2025 at 10:12 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Thu, Nov 13, 2025 at 2:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> 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.
> >
> > So bootsource will be populated "mmc0" or "spinor1" for example?
> >
> > > 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).
> >
> > But usually the numbering follows the SoC numbering. Sometimes it
> > follows the PCB numbering, but I think that's mainly serial ports.
> > I've certainly steered people away from vendor specific instance
> > numbering properties towards aliases (if the need can't be eliminated
> > entirely).
> 
> It's been a long time since I was involved in any discussion about
> this, but I remember Arnd Bergmann being strongly against having
> numbering aliases in the SoC "dtsi" file. I was always on the opposite
> side of this argument, but it seems reasonable to include him in the
> conversation.
> 
> From my point of view, with the exception of the "serial" alias folks
> almost always wanted devices to be numbered as per the SoC numbering,
> as long as there was a well-defined SoC numbering. For instance, if
> the SoC manual consistently calls a port "i2c12" then it's pretty
> confusing if the device doesn't end up as "/dev/i2c12". This always
> led me to the argument that aliases like this should be in the SoC
> ".dtsi" file.

Yep, especially when everything in the soc documentation _and_ the
board schematics calls i2c4 controller, clocks and data lines ... i2c4-foo.

I do agree that unnumbered controllers (like sdhci, sdmmc, sdio on
recent Rockchip SoCs) should be the responsibility of the boards,
but really don't get the idea of repeating the ever same list of aliases
in each and every board dts.


> The "serial" alias is a bit of a special case because of historical
> assumptions. It's often assumed that serial port "0" is the debug
> port. Luckily there aren't usually so many active serial ports so it's
> not terribly confusing...
> 
> 
> > The board specific part I think is more that the board defines what
> > devices are present and not present. It would be weird to have a
> > serial3 alias when that's not wired up. And board .dts files are going
> > to forget to remove it. Though I guess it is somewhat harmless.
> 
> To me it doesn't seem awful to still have the alias pointing to a
> "disabled" node. The node is still there, so why can't the alias still
> be there?

additionally, one would never ever point "serial3" or "i2c4" to anything
else than the uart3 and i2c4 controllers, because that would be completely
confuse everybody.

Like when the board uses i2c0 and i2c4, those should still have the
aliases i2c0 and i2c4, because when you have "i2c1" as alias for the i2c4
controller on the running system, so many heads will explode ;-)

Re: SoC-specific device tree aliases?

[Ahmad Fatoum]

Hi Rob,

On 11/13/25 7:04 PM, Rob Herring wrote:
> On Thu, Nov 13, 2025 at 2:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> 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.
> 
> So bootsource will be populated "mmc0" or "spinor1" for example?

It will be populated by the full device tree node path:

barebox$ of_diff /mnt/nfs/boot/imx8mp-tqma8mpql-mba8mpxl.dtb +  # to show fixups
chosen {
+         bootsource = "/soc@0/bus@30800000/mmc@30b50000";
+         reset-source = "POR";
+         reset-source-device = "/soc@0/bus@30800000/i2c@30a20000/pmic@25";
};
[...]

>> 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).
> 
> But usually the numbering follows the SoC numbering. Sometimes it
> follows the PCB numbering, but I think that's mainly serial ports.
> I've certainly steered people away from vendor specific instance
> numbering properties towards aliases (if the need can't be eliminated
> entirely).
> 
> The board specific part I think is more that the board defines what
> devices are present and not present. It would be weird to have a
> serial3 alias when that's not wired up. And board .dts files are going
> to forget to remove it. Though I guess it is somewhat harmless.

I think differing from the established numbering in SoC datasheet and as
Heiko correctly notes most schematics is weirder.

> I think the real change here is it would make aliases required when
> currently they aren't really. Though I guess populating bootsource is
> entirely optional?

Yes, of course. If the bootloader doesn't have enough information to
resolve the bootsource, then it will just be missing.

I looked at the first 10 matches for of_alias_get_id in drivers/ and
6 from them used the alias as more than just ID, so renumbering would
actually break them.

Such driver could also benefit if we had a mechanism to unambiguously
represent SoC numbering in the device tree.

Cheers,
Ahmad

> 
> Rob
> 

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

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

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

Re: SoC-specific device tree aliases?

[Sascha Hauer]

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 |

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

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

Aliases could be solution here but it is as fragile as simple arithmetic
of sorting MMC nodes by unit address...


Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Sascha Hauer]

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 |

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

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

Re: SoC-specific device tree aliases?

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 4624 bytes --]

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

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Sascha Hauer]

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

Also I don't get whether you are suggesting

A is as fragile as B, so you could equally well do B

or

A is as fragile as B, forget both of them.


I could imagine that you think that we want to create aliases in the
bootloader, but we don't want to do this.

We are suggesting that the (upstream-, Linux-) dtsi files get an
optional additional set of aliases named "mmc0", mmc1",...

In the bootloader we would read the boot source instance from SoC
registers and look up the alias "mmc%d", boot_source_instance
to get the node corresponding to a boot source.

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 |

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

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.


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

> 
> or
> 
> A is as fragile as B, forget both of them.
> 
> 
> I could imagine that you think that we want to create aliases in the
> bootloader, but we don't want to do this.

You already have them because you need to create mapping between
register value and DT aliases.

> 
> We are suggesting that the (upstream-, Linux-) dtsi files get an
> optional additional set of aliases named "mmc0", mmc1",...
> 
> In the bootloader we would read the boot source instance from SoC
> registers and look up the alias "mmc%d", boot_source_instance
> to get the node corresponding to a boot source.

Exactly, that's your mapping. register value into %d.


Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Sascha Hauer]

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 |

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

On 17/11/2025 16:23, Sascha Hauer wrote:
>>
>> 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 {

That's label which is not yet proof that boot source registers have the
same... I can git grep as well, but wanted actual confirmation, because
people put to DTS many wonderful mistakes.


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

Only that you rely on a specific register values and their meaning.

Anyway, I would just go with standard aliases, but add a schema for each
of such cases (SoCs or vendors), so you will define this as an ABI.

One of the reasons why Barebox was affected by all node renames and
alias reshuffling was that it was never documented that anyone treats
this as an ABI.

So you want it to be an ABI for barebox, sure, just make it a binding.

Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Rob Herring]

On Mon, Nov 17, 2025 at 9:44 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 17/11/2025 16:23, Sascha Hauer wrote:
> >>
> >> 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 {
>
> That's label which is not yet proof that boot source registers have the
> same... I can git grep as well, but wanted actual confirmation, because
> people put to DTS many wonderful mistakes.
>
>
> >
> > 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?
>
> Only that you rely on a specific register values and their meaning.
>
> Anyway, I would just go with standard aliases, but add a schema for each
> of such cases (SoCs or vendors), so you will define this as an ABI.
>
> One of the reasons why Barebox was affected by all node renames and
> alias reshuffling was that it was never documented that anyone treats
> this as an ABI.
>
> So you want it to be an ABI for barebox, sure, just make it a binding.

What do you have in mind? Other than standard names for the aliases,
what can we check here? That a specific alias points to a specific
path? That would be a bit too much IMO. That would be equivalent to
specifying possible values in 'reg' for all devices.

Documenting standard names was something I started but gave up on with
the mess we had already. And that was several years ago, so it
probably only got worse.

Rob

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

On 17/11/2025 17:06, Rob Herring wrote:
>>>>
>>>>>
>>>>> 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?
>>
>> Only that you rely on a specific register values and their meaning.
>>
>> Anyway, I would just go with standard aliases, but add a schema for each
>> of such cases (SoCs or vendors), so you will define this as an ABI.
>>
>> One of the reasons why Barebox was affected by all node renames and
>> alias reshuffling was that it was never documented that anyone treats
>> this as an ABI.
>>
>> So you want it to be an ABI for barebox, sure, just make it a binding.
> 
> What do you have in mind? Other than standard names for the aliases,
> what can we check here? That a specific alias points to a specific
> path? That would be a bit too much IMO. That would be equivalent to
> specifying possible values in 'reg' for all devices.

Binding with pattern or list of needed alias names, referenced by given
soc-platform top-level schema.

One of the points is to make it explicit and obvious (e.g. to Arnd or to
me if I forget, because I follow the same logic of aliases per board)
that these aliases are used outside of kernel.

Just because ufs/mmc/spi can be used that way, does not mean we should
accept any possible alias into soc.dtsi.

Best regards,
Krzysztof