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

Re: SoC-specific device tree aliases?

[Ahmad Fatoum]

Hello Krzysztof,

On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> On 17/11/2025 17:06, Rob Herring wrote:
>>> 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.

I can't see how this could work. A number of boards renumber MMC devices
in a different manner than the SoC reference manual:

- Changing the alias numbering is an ABI break, because Linux derives
its /dev/mmcblkX numbering from it

- Leaving them as-is means they are not usable for boot source determination

That's why I am suggesting a separate node that reflects only the SoC
reference manual's numbering. I don't see how a schema for the existing
/aliases would remove the need for this.

Thanks,
Ahmad

> 
> Best regards,
> Krzysztof
> 

-- 
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 03/12/2025 11:16, Ahmad Fatoum wrote:
> Hello Krzysztof,
> 
> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
>> On 17/11/2025 17:06, Rob Herring wrote:
>>>> 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.
> 
> I can't see how this could work. A number of boards renumber MMC devices
> in a different manner than the SoC reference manual:
> 
> - Changing the alias numbering is an ABI break, because Linux derives
> its /dev/mmcblkX numbering from it

First, why the alias would change? Isn't the board following the SoC
numbering in 99.9% cases?

Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
the mmcblkX was changing based on probe ordering. Many people setups got
broken, many people complained and the consensus reply was: please start
finally using UUID/PARTUIID/LABEL for rootfs. Eventually we got back to
mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
then it is your problem.




Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Matthias Schiffer]

On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
> On 03/12/2025 11:16, Ahmad Fatoum wrote:
> > Hello Krzysztof,
> > 
> > On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> > > On 17/11/2025 17:06, Rob Herring wrote:
> > > > > 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.
> > 
> > I can't see how this could work. A number of boards renumber MMC devices
> > in a different manner than the SoC reference manual:
> > 
> > - Changing the alias numbering is an ABI break, because Linux derives
> > its /dev/mmcblkX numbering from it
> 
> First, why the alias would change? Isn't the board following the SoC
> numbering in 99.9% cases?

At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
numbering; that is, we're using the aliases as a form of hardware abstraction
rather than hardware description.

Best,
Matthias


> 
> Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
> the mmcblkX was changing based on probe ordering. Many people setups got
> broken, many people complained and the consensus reply was: please start
> finally using UUID/PARTUIID/LABEL for rootfs. Eventually we got back to
> mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
> then it is your problem.
> 
> 
> 
> 
> Best regards,
> Krzysztof
> 

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/

Re: SoC-specific device tree aliases?

[Krzysztof Kozlowski]

On 03/12/2025 11:36, Matthias Schiffer wrote:
> On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
>>> Hello Krzysztof,
>>>
>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
>>>> On 17/11/2025 17:06, Rob Herring wrote:
>>>>>> 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.
>>>
>>> I can't see how this could work. A number of boards renumber MMC devices
>>> in a different manner than the SoC reference manual:
>>>
>>> - Changing the alias numbering is an ABI break, because Linux derives
>>> its /dev/mmcblkX numbering from it
>>
>> First, why the alias would change? Isn't the board following the SoC
>> numbering in 99.9% cases?
> 
> At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
> eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
> numbering; that is, we're using the aliases as a form of hardware abstraction
> rather than hardware description.

Huh, does it even match numbering on the schematics / board / user-guides?

I would prefer not to create bindings purely because some existing DTS
code is not matching our expectations. However there could be a case
where board numbering is different than soc number and we want to keep
aliases configured for board.

Basically what you propose here is the discouraged instance ID disguised
under one more 'alias' which is not really alias. It's just an instance
ID. There is no other use of soc-aliases beside instance ID.

I see the problem you want to solve, I agree it is worth solving and I
agree that DT is the place for this mapping between register value and
device node. However solution of discouraged instance ID is just...
well, discouraged, so not optimal. I don't have particular advice expect
a dedicated property for each device in such case.

Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Ahmad Fatoum]

Hi,

On 12/3/25 12:08 PM, Krzysztof Kozlowski wrote:
> On 03/12/2025 11:36, Matthias Schiffer wrote:
>> On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
>>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
>>>> Hello Krzysztof,
>>>>
>>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
>>>>> On 17/11/2025 17:06, Rob Herring wrote:
>>>>>>> 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.
>>>>
>>>> I can't see how this could work. A number of boards renumber MMC devices
>>>> in a different manner than the SoC reference manual:
>>>>
>>>> - Changing the alias numbering is an ABI break, because Linux derives
>>>> its /dev/mmcblkX numbering from it
>>>
>>> First, why the alias would change? Isn't the board following the SoC
>>> numbering in 99.9% cases?
>>
>> At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
>> eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
>> numbering; that is, we're using the aliases as a form of hardware abstraction
>> rather than hardware description.
> 
> Huh, does it even match numbering on the schematics / board / user-guides?
> 
> I would prefer not to create bindings purely because some existing DTS
> code is not matching our expectations. However there could be a case
> where board numbering is different than soc number and we want to keep
> aliases configured for board.
> 
> Basically what you propose here is the discouraged instance ID disguised
> under one more 'alias' which is not really alias. It's just an instance
> ID. There is no other use of soc-aliases beside instance ID.
> 
> I see the problem you want to solve, I agree it is worth solving and I
> agree that DT is the place for this mapping between register value and
> device node. However solution of discouraged instance ID is just...
> well, discouraged, so not optimal. I don't have particular advice expect
> a dedicated property for each device in such case.

How do we move forward here? I don't think we can change the nature of
/aliases being board-specific now without breaking users.

Does this make the addition of /soc-aliases (or /soc/aliases?) more
palatable?

Cheers,
Ahmad

> 
> Best regards,
> Krzysztof
> 

-- 
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 Wed, Dec 3, 2025 at 5:37 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hi,
>
> On 12/3/25 12:08 PM, Krzysztof Kozlowski wrote:
> > On 03/12/2025 11:36, Matthias Schiffer wrote:
> >> On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
> >>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
> >>>> Hello Krzysztof,
> >>>>
> >>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> >>>>> On 17/11/2025 17:06, Rob Herring wrote:
> >>>>>>> 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.
> >>>>
> >>>> I can't see how this could work. A number of boards renumber MMC devices
> >>>> in a different manner than the SoC reference manual:
> >>>>
> >>>> - Changing the alias numbering is an ABI break, because Linux derives
> >>>> its /dev/mmcblkX numbering from it
> >>>
> >>> First, why the alias would change? Isn't the board following the SoC
> >>> numbering in 99.9% cases?
> >>
> >> At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
> >> eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
> >> numbering; that is, we're using the aliases as a form of hardware abstraction
> >> rather than hardware description.
> >
> > Huh, does it even match numbering on the schematics / board / user-guides?
> >
> > I would prefer not to create bindings purely because some existing DTS
> > code is not matching our expectations. However there could be a case
> > where board numbering is different than soc number and we want to keep
> > aliases configured for board.
> >
> > Basically what you propose here is the discouraged instance ID disguised
> > under one more 'alias' which is not really alias. It's just an instance
> > ID. There is no other use of soc-aliases beside instance ID.
> >
> > I see the problem you want to solve, I agree it is worth solving and I
> > agree that DT is the place for this mapping between register value and
> > device node. However solution of discouraged instance ID is just...
> > well, discouraged, so not optimal. I don't have particular advice expect
> > a dedicated property for each device in such case.
>
> How do we move forward here? I don't think we can change the nature of
> /aliases being board-specific now without breaking users.
>
> Does this make the addition of /soc-aliases (or /soc/aliases?) more
> palatable?

No.

Thinking about this some more, I'm not sure that something aliases
based is even the right approach. Let's back up to the original
problem instead of talking about a problem concerning a possible
solution.

You have a platform specific register with values (or from 1 or
multiple fields) that you need to map to devices in DT. That's it.
That could be solved like this:

bootsource-map =
  <0x2 &mmc0>,
  <0x3 &mmc1>,
  <0x10 &spi0>,
  ...;

Simple. The first value is platform specific. Maybe it is several
fields (e.g. device type, instance) merged together. Doesn't matter.

And where do we put 'bootsource-map'? That could be either in the node
of the device with the boot source register(s) or alongside bootsource
in chosen. In chosen is a bit weird because that's supposed to be
things the bootloader fills in.

Now I'm pretty annoyed because like what happens many times, I
accepted bootsource and you all turn right around want to add on to
it. IOW, it didn't completely solve the problem or give me the whole
picture. Why does that matter? Because now I might say 'bootsource'
can just be the index into 'bootsource-map', but now we're stuck with
it (forever). Anything else needed in this area?

Rob

Re: SoC-specific device tree aliases?

[Sascha Hauer]

On Wed, Dec 03, 2025 at 11:51:28AM -0600, Rob Herring wrote:
> On Wed, Dec 3, 2025 at 5:37 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi,
> >
> > On 12/3/25 12:08 PM, Krzysztof Kozlowski wrote:
> > > On 03/12/2025 11:36, Matthias Schiffer wrote:
> > >> On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
> > >>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
> > >>>> Hello Krzysztof,
> > >>>>
> > >>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> > >>>>> On 17/11/2025 17:06, Rob Herring wrote:
> > >>>>>>> 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.
> > >>>>
> > >>>> I can't see how this could work. A number of boards renumber MMC devices
> > >>>> in a different manner than the SoC reference manual:
> > >>>>
> > >>>> - Changing the alias numbering is an ABI break, because Linux derives
> > >>>> its /dev/mmcblkX numbering from it
> > >>>
> > >>> First, why the alias would change? Isn't the board following the SoC
> > >>> numbering in 99.9% cases?
> > >>
> > >> At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
> > >> eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
> > >> numbering; that is, we're using the aliases as a form of hardware abstraction
> > >> rather than hardware description.
> > >
> > > Huh, does it even match numbering on the schematics / board / user-guides?
> > >
> > > I would prefer not to create bindings purely because some existing DTS
> > > code is not matching our expectations. However there could be a case
> > > where board numbering is different than soc number and we want to keep
> > > aliases configured for board.
> > >
> > > Basically what you propose here is the discouraged instance ID disguised
> > > under one more 'alias' which is not really alias. It's just an instance
> > > ID. There is no other use of soc-aliases beside instance ID.
> > >
> > > I see the problem you want to solve, I agree it is worth solving and I
> > > agree that DT is the place for this mapping between register value and
> > > device node. However solution of discouraged instance ID is just...
> > > well, discouraged, so not optimal. I don't have particular advice expect
> > > a dedicated property for each device in such case.
> >
> > How do we move forward here? I don't think we can change the nature of
> > /aliases being board-specific now without breaking users.
> >
> > Does this make the addition of /soc-aliases (or /soc/aliases?) more
> > palatable?
> 
> No.
> 
> Thinking about this some more, I'm not sure that something aliases
> based is even the right approach. Let's back up to the original
> problem instead of talking about a problem concerning a possible
> solution.
> 
> You have a platform specific register with values (or from 1 or
> multiple fields) that you need to map to devices in DT. That's it.
> That could be solved like this:
> 
> bootsource-map =
>   <0x2 &mmc0>,
>   <0x3 &mmc1>,
>   <0x10 &spi0>,
>   ...;
> 
> Simple. The first value is platform specific. Maybe it is several
> fields (e.g. device type, instance) merged together. Doesn't matter.

That's an interesting approach and I like it.

I am not sure though how the platform specific value could be composed.

The easiest way would be if it maps to some register values. This works
well when there's a bitfield with only a few bits which specifies the
bootsource, but not so when there are many bits. On TI AM62x for example
we have 4 bits specifying the primary bootsource, 3 bits specifying the
backup bootsource and 1 bit specifying if we are booting from the
primary or from the backup bootsource. This means we have an array with
potentially 256 entries with many holes and many different values
pointing to the same bootsource. We could reduce the number of array
entries by specifying a mask for each value. I am worried also that the
initial contributor might for example forget about the backup bootsource
and only upstreams primary bootsource, so we would have to modify
existing values for the primary bootsource when adding the backup
bootsource.

How about only adding the phandles to bootsource-map, like

bootsource-map = <&mmc0>, <&mmc2>, <&spi0>, ...;

New entries must then only be added at the end, existing entries must
never be changed.

But anyway, as with your approach the bootsource would become just
another driver specific binding SoC contributors would be free to choose
whatever suits best for them.

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?

[Rob Herring]

On Thu, Dec 4, 2025 at 1:59 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> On Wed, Dec 03, 2025 at 11:51:28AM -0600, Rob Herring wrote:
> > On Wed, Dec 3, 2025 at 5:37 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > >
> > > Hi,
> > >
> > > On 12/3/25 12:08 PM, Krzysztof Kozlowski wrote:
> > > > On 03/12/2025 11:36, Matthias Schiffer wrote:
> > > >> On Wed, 2025-12-03 at 11:25 +0100, Krzysztof Kozlowski wrote:
> > > >>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
> > > >>>> Hello Krzysztof,
> > > >>>>
> > > >>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> > > >>>>> On 17/11/2025 17:06, Rob Herring wrote:
> > > >>>>>>> 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.
> > > >>>>
> > > >>>> I can't see how this could work. A number of boards renumber MMC devices
> > > >>>> in a different manner than the SoC reference manual:
> > > >>>>
> > > >>>> - Changing the alias numbering is an ABI break, because Linux derives
> > > >>>> its /dev/mmcblkX numbering from it
> > > >>>
> > > >>> First, why the alias would change? Isn't the board following the SoC
> > > >>> numbering in 99.9% cases?
> > > >>
> > > >> At least for our TQ-Systems boards, we have a convention based on usage (mmc0:
> > > >> eMMC, mmc1: SD card; serial0 is often the console) rather than following the SoC
> > > >> numbering; that is, we're using the aliases as a form of hardware abstraction
> > > >> rather than hardware description.
> > > >
> > > > Huh, does it even match numbering on the schematics / board / user-guides?
> > > >
> > > > I would prefer not to create bindings purely because some existing DTS
> > > > code is not matching our expectations. However there could be a case
> > > > where board numbering is different than soc number and we want to keep
> > > > aliases configured for board.
> > > >
> > > > Basically what you propose here is the discouraged instance ID disguised
> > > > under one more 'alias' which is not really alias. It's just an instance
> > > > ID. There is no other use of soc-aliases beside instance ID.
> > > >
> > > > I see the problem you want to solve, I agree it is worth solving and I
> > > > agree that DT is the place for this mapping between register value and
> > > > device node. However solution of discouraged instance ID is just...
> > > > well, discouraged, so not optimal. I don't have particular advice expect
> > > > a dedicated property for each device in such case.
> > >
> > > How do we move forward here? I don't think we can change the nature of
> > > /aliases being board-specific now without breaking users.
> > >
> > > Does this make the addition of /soc-aliases (or /soc/aliases?) more
> > > palatable?
> >
> > No.
> >
> > Thinking about this some more, I'm not sure that something aliases
> > based is even the right approach. Let's back up to the original
> > problem instead of talking about a problem concerning a possible
> > solution.
> >
> > You have a platform specific register with values (or from 1 or
> > multiple fields) that you need to map to devices in DT. That's it.
> > That could be solved like this:
> >
> > bootsource-map =
> >   <0x2 &mmc0>,
> >   <0x3 &mmc1>,
> >   <0x10 &spi0>,
> >   ...;
> >
> > Simple. The first value is platform specific. Maybe it is several
> > fields (e.g. device type, instance) merged together. Doesn't matter.
>
> That's an interesting approach and I like it.
>
> I am not sure though how the platform specific value could be composed.

It's platform specific, so however it wants and not my problem.

> The easiest way would be if it maps to some register values. This works
> well when there's a bitfield with only a few bits which specifies the
> bootsource, but not so when there are many bits. On TI AM62x for example
> we have 4 bits specifying the primary bootsource, 3 bits specifying the
> backup bootsource and 1 bit specifying if we are booting from the
> primary or from the backup bootsource. This means we have an array with
> potentially 256 entries with many holes and many different values
> pointing to the same bootsource. We could reduce the number of array
> entries by specifying a mask for each value. I am worried also that the
> initial contributor might for example forget about the backup bootsource
> and only upstreams primary bootsource, so we would have to modify
> existing values for the primary bootsource when adding the backup
> bootsource.

It's a map, not an array so there should be no holes. The entry index
is not significant. In this example, the platform just defines the
cell as:

<primary_or_sec:16><sec_source:15:8><primary_source:7:0>

You could fit it all in 8-bits, but I spaced it out in case the next
SoC needs another bit.

A mask value would be okay until you have 2 different registers and
then you need a variable number of cells. And then I could imagine
someone will want to define the register address for each cell in the
name of a 'generic binding'. That's not what I want to see.

> How about only adding the phandles to bootsource-map, like
>
> bootsource-map = <&mmc0>, <&mmc2>, <&spi0>, ...;
>
> New entries must then only be added at the end, existing entries must
> never be changed.

That would work too. Then you just have the index to register value
lookup in code. Doesn't matter to me too much. The only downside I see
is having to enforce that people don't try to insert entries in the
middle.

Rob

Re: SoC-specific device tree aliases?

[Marc Kleine-Budde]

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

On 03.12.2025 11:25:11, Krzysztof Kozlowski wrote:
> On 03/12/2025 11:16, Ahmad Fatoum wrote:
> > Hello Krzysztof,
> >
> > On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> >> On 17/11/2025 17:06, Rob Herring wrote:
> >>>> 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.
> >
> > I can't see how this could work. A number of boards renumber MMC devices
> > in a different manner than the SoC reference manual:
> >
> > - Changing the alias numbering is an ABI break, because Linux derives
> > its /dev/mmcblkX numbering from it
>
> First, why the alias would change? Isn't the board following the SoC
> numbering in 99.9% cases?
>
> Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
> the mmcblkX was changing based on probe ordering. Many people setups got
> broken, many people complained and the consensus reply was: please start
> finally using UUID/PARTUIID/LABEL for rootfs. Eventually we got back to
> mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
> then it is your problem.

In order to use UUID/PARTUIID/LABEL in the kernel command line, the
firmware/bootloader/... has to map from the register value to the
instance to read the UUID/PARTUIID/LABEL from the media.

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 03/12/2025 12:20, Marc Kleine-Budde wrote:
> On 03.12.2025 11:25:11, Krzysztof Kozlowski wrote:
>> On 03/12/2025 11:16, Ahmad Fatoum wrote:
>>> Hello Krzysztof,
>>>
>>> On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
>>>> On 17/11/2025 17:06, Rob Herring wrote:
>>>>>> 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.
>>>
>>> I can't see how this could work. A number of boards renumber MMC devices
>>> in a different manner than the SoC reference manual:
>>>
>>> - Changing the alias numbering is an ABI break, because Linux derives
>>> its /dev/mmcblkX numbering from it
>>
>> First, why the alias would change? Isn't the board following the SoC
>> numbering in 99.9% cases?
>>
>> Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
>> the mmcblkX was changing based on probe ordering. Many people setups got
>> broken, many people complained and the consensus reply was: please start
>> finally using UUID/PARTUIID/LABEL for rootfs. Eventually we got back to
>> mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
>> then it is your problem.
> 
> In order to use UUID/PARTUIID/LABEL in the kernel command line, the
> firmware/bootloader/... has to map from the register value to the
> instance to read the UUID/PARTUIID/LABEL from the media.

Or have it stored when flashing/configuring the board as part of
firmware configuration like U-Boot env.

Best regards,
Krzysztof

Re: SoC-specific device tree aliases?

[Ahmad Fatoum]

Hello Krzysztof,

On 12/3/25 11:25 AM, Krzysztof Kozlowski wrote:
> On 03/12/2025 11:16, Ahmad Fatoum wrote:
>>> Just because ufs/mmc/spi can be used that way, does not mean we should
>>> accept any possible alias into soc.dtsi.
>>
>> I can't see how this could work. A number of boards renumber MMC devices
>> in a different manner than the SoC reference manual:
>>
>> - Changing the alias numbering is an ABI break, because Linux derives
>> its /dev/mmcblkX numbering from it
> 
> First, why the alias would change? Isn't the board following the SoC
> numbering in 99.9% cases?

For 32-bit i.MX, the figure is more like 80% with 20% of the boards
going out of their way to override the numbering in the SoC dtsi.

I can only assume the figure may be higher for other platforms, where
there is no numbering in the DTSI. See below[1] for calculation.

> Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
> the mmcblkX was changing based on probe ordering. Many people setups got
> broken, many people complained and the consensus reply was: please start
> finally using UUID/PARTUIID/LABEL for rootfs.

On the other hand, I have seen people flashing the same image to both an
eMMC and a SD-Card and wondering why the bootloader picks a different
rootfs than the kernel.

> Eventually we got back to
> mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
> then it is your problem.

Device tree aliases are the only way to identify the same MMC device
in bootloader and kernel over different boots and for my part, I can
only encourage their use.

[1]: I checked out Linux v6.18, used imx_v6_v7_defconfig and built the
dtb target.

arch/arm/boot/dts/nxp/imx/.*.dtb.dts.tmp in the build directory are the
preprocessed device tree source files.

I deleted arch/arm/boot/dts/nxp/imx/.imx7ulp*.dtb.dts.tmp, because
it's the only SoC apparently that numbers MMC peripherals stating with 0.

Now let's find all instances of mmcX = somethingY, where X is not Y - 1:

perl -ne '/mmc(\d+)\s*=\s*&\w+?(\d+)/ && $1 != $2 - 1 and \
	print($ARGV, $_) && close ARGV' \
		arch/arm/boot/dts/nxp/imx/.*.dtb.dts.tmp

This returns 76 matches out of a total 381, so that's 19.95% of all i.MX
device trees that went out of their way to override the numbering in the
SoC dtsi.

Cheers,
Ahmad

> 
> 
> 
> 
> Best regards,
> Krzysztof
> 

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

[Tom Rini]

On Wed, Dec 03, 2025 at 11:25:11AM +0100, Krzysztof Kozlowski wrote:
> On 03/12/2025 11:16, Ahmad Fatoum wrote:
> > Hello Krzysztof,
> > 
> > On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> >> On 17/11/2025 17:06, Rob Herring wrote:
> >>>> 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.
> > 
> > I can't see how this could work. A number of boards renumber MMC devices
> > in a different manner than the SoC reference manual:
> > 
> > - Changing the alias numbering is an ABI break, because Linux derives
> > its /dev/mmcblkX numbering from it
> 
> First, why the alias would change? Isn't the board following the SoC
> numbering in 99.9% cases?

I swear historically and probably still today at least one major SoC
vendor manuals/etc start numbering from 1 and not 0. And it's not just
iMX where "which one was wired for an SD cage and which is wired for
eMMC" vary from ref (or hobbyist) platform to ref platform. And then, oh
goodness, custom designs. So no, there's no consistency and then "store
UUID/etc in env during install" falls down on other cases starting with
"is there an env to store them to?" and so a common case is "we know
mmcX is ... so read the UUID, pass that to the kernel".

-- 
Tom