[PATCH] Add 'bootsource' /chosen property

[PATCH] Add 'bootsource' /chosen property

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

Bootloaders typically can be loaded from different storage media, such
as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
such as USB (via proprietary protocols loading directly into SRAM, or
fastboot, DFU, etc..), JTAG, ...

This information is usually reported by the SoC-ROM via some proprietary
mechanism (some specific address in registers/DRAM for example).

It would be useful to know which medium was used to load the first stage
of the bootloader. SoC-ROM shall be ignored and not reported in this
property.

This can allow client programs to detect which medium to write to when
updating the boot program, or detect if fallback mechanisms to
unexpected medium were used to reach the client program's execution.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Bootloaders typically can be loaded from different storage media, such
as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
such as USB (via proprietary protocols loading directly into SRAM, or
fastboot, DFU, etc..), JTAG, ...

This information is usually reported by the SoC-ROM via some proprietary
mechanism (some specific address in registers/DRAM for example).

It would be useful to know which medium was used to load the first stage
of the bootloader. SoC-ROM shall be ignored and not reported in this
property.

This can allow client programs to detect which medium to write to when
updating the boot program, or detect if fallback mechanisms to
unexpected medium were used to reach the client program's execution.

Note that this property is already set by Barebox and I'm planning on
adding it to U-Boot as well, specifically for Rockchip SoCs.

I have some doubts about the wording, especially in the case of
hypervisors or chained boot programs. I'm not entirely sure what would
make the most sense to put in the property for those scenario.
---
 source/chapter3-devicenodes.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -456,6 +456,9 @@ time. It shall be a child of the root node.
                                                        the client program. The value could
                                                        potentially be a null string if no boot
                                                        arguments are required.
+   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
+                                                       node representing the device the BootROM used
+                                                       to load the initial boot program.
    ``stdout-path``         O     ``<string>``          A string that specifies the full path to the
                                                        node representing the device to be used for
                                                        boot console output. If the character ":" is

---
base-commit: 5688e1c0b961d2ca5a32e3b624a9f4a9b433184f
change-id: 20250205-bootsource-84df255e9e6c

Best regards,
-- 
Quentin Schulz <quentin.schulz@cherry.de>

Re: [PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Quentin,

On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@cherry.de>
>
> Bootloaders typically can be loaded from different storage media, such
> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> such as USB (via proprietary protocols loading directly into SRAM, or
> fastboot, DFU, etc..), JTAG, ...
>
> This information is usually reported by the SoC-ROM via some proprietary
> mechanism (some specific address in registers/DRAM for example).
>
> It would be useful to know which medium was used to load the first stage
> of the bootloader. SoC-ROM shall be ignored and not reported in this
> property.
>
> This can allow client programs to detect which medium to write to when
> updating the boot program, or detect if fallback mechanisms to
> unexpected medium were used to reach the client program's execution.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> Bootloaders typically can be loaded from different storage media, such
> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> such as USB (via proprietary protocols loading directly into SRAM, or
> fastboot, DFU, etc..), JTAG, ...
>
> This information is usually reported by the SoC-ROM via some proprietary
> mechanism (some specific address in registers/DRAM for example).
>
> It would be useful to know which medium was used to load the first stage
> of the bootloader. SoC-ROM shall be ignored and not reported in this
> property.
>
> This can allow client programs to detect which medium to write to when
> updating the boot program, or detect if fallback mechanisms to
> unexpected medium were used to reach the client program's execution.
>
> Note that this property is already set by Barebox and I'm planning on
> adding it to U-Boot as well, specifically for Rockchip SoCs.
>
> I have some doubts about the wording, especially in the case of
> hypervisors or chained boot programs. I'm not entirely sure what would
> make the most sense to put in the property for those scenario.
> ---
>  source/chapter3-devicenodes.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
> --- a/source/chapter3-devicenodes.rst
> +++ b/source/chapter3-devicenodes.rst
> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
>                                                         the client program. The value could
>                                                         potentially be a null string if no boot
>                                                         arguments are required.
> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
> +                                                       node representing the device the BootROM used
> +                                                       to load the initial boot program.

Could/shoud this be a phandle instead? It might be more efficient.

>     ``stdout-path``         O     ``<string>``          A string that specifies the full path to the
>                                                         node representing the device to be used for
>                                                         boot console output. If the character ":" is
>
> ---
> base-commit: 5688e1c0b961d2ca5a32e3b624a9f4a9b433184f
> change-id: 20250205-bootsource-84df255e9e6c
>
> Best regards,
> --
> Quentin Schulz <quentin.schulz@cherry.de>
>
>

Regards,
SImon

Re: [PATCH] Add 'bootsource' /chosen property

[Quentin Schulz]

Hi Simon,

On 2/6/25 1:33 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
>>
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> Bootloaders typically can be loaded from different storage media, such
>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
>> such as USB (via proprietary protocols loading directly into SRAM, or
>> fastboot, DFU, etc..), JTAG, ...
>>
>> This information is usually reported by the SoC-ROM via some proprietary
>> mechanism (some specific address in registers/DRAM for example).
>>
>> It would be useful to know which medium was used to load the first stage
>> of the bootloader. SoC-ROM shall be ignored and not reported in this
>> property.
>>
>> This can allow client programs to detect which medium to write to when
>> updating the boot program, or detect if fallback mechanisms to
>> unexpected medium were used to reach the client program's execution.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>> ---
>> Bootloaders typically can be loaded from different storage media, such
>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
>> such as USB (via proprietary protocols loading directly into SRAM, or
>> fastboot, DFU, etc..), JTAG, ...
>>
>> This information is usually reported by the SoC-ROM via some proprietary
>> mechanism (some specific address in registers/DRAM for example).
>>
>> It would be useful to know which medium was used to load the first stage
>> of the bootloader. SoC-ROM shall be ignored and not reported in this
>> property.
>>
>> This can allow client programs to detect which medium to write to when
>> updating the boot program, or detect if fallback mechanisms to
>> unexpected medium were used to reach the client program's execution.
>>
>> Note that this property is already set by Barebox and I'm planning on
>> adding it to U-Boot as well, specifically for Rockchip SoCs.
>>
>> I have some doubts about the wording, especially in the case of
>> hypervisors or chained boot programs. I'm not entirely sure what would
>> make the most sense to put in the property for those scenario.
>> ---
>>   source/chapter3-devicenodes.rst | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
>> --- a/source/chapter3-devicenodes.rst
>> +++ b/source/chapter3-devicenodes.rst
>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
>>                                                          the client program. The value could
>>                                                          potentially be a null string if no boot
>>                                                          arguments are required.
>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
>> +                                                       node representing the device the BootROM used
>> +                                                       to load the initial boot program.
> 
> Could/shoud this be a phandle instead? It might be more efficient.
> 

In terms of size in DTB, phandle vs string probably much more efficient yes.

 From user's perspective, I'm not too sure?

/aliases does use full paths for example.

Having a full path allows for easy consumption, just cat 
/proc/device-tree/chosen/bootsource and you'll have the actual path. 
Otherwise, we'd need a special tool for that I guess since it'll return 
the phandle number and then you have to traverse the tree to find which 
node has that phandle number?

Also, I could imagine some scenario where:
- a boot source would not be available in DT yet (though we probably 
shouldn't write it in /chosen/bootsource since we wouldn't know the 
proper path to it), e.g. USB loading, this is usually done via a 
proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for 
Rockchip) but no USB support yet in boot program or kernel (that was the 
case for a long time for RK3588 for example and I still have at least 
one device without the USB node described yet).
- a boot source would be available in EL3 but not EL2, so does not make 
necessarily make sense to have it in kernel DTB for example. If it's not 
there, can't have a phandle.
- a boot source supported only in boot program's DTB and not kernel's 
DTB, we probably still want to provide it to kernel's DTB even if it's 
not a device node in it.
- a boot source doesn't necessarily have a label (though we could use a 
full-path phandle I believe &{/some/path@1f000} probably works). That is 
not uncommon for SPI flashes for example.

And additional argument for full-path: Barebox already uses that.

Cheers,
Quentin

Re: [PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Quentin,

On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Simon,
>
> On 2/6/25 1:33 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
> >>
> >> From: Quentin Schulz <quentin.schulz@cherry.de>
> >>
> >> Bootloaders typically can be loaded from different storage media, such
> >> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> >> such as USB (via proprietary protocols loading directly into SRAM, or
> >> fastboot, DFU, etc..), JTAG, ...
> >>
> >> This information is usually reported by the SoC-ROM via some proprietary
> >> mechanism (some specific address in registers/DRAM for example).
> >>
> >> It would be useful to know which medium was used to load the first stage
> >> of the bootloader. SoC-ROM shall be ignored and not reported in this
> >> property.
> >>
> >> This can allow client programs to detect which medium to write to when
> >> updating the boot program, or detect if fallback mechanisms to
> >> unexpected medium were used to reach the client program's execution.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> >> ---
> >> Bootloaders typically can be loaded from different storage media, such
> >> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> >> such as USB (via proprietary protocols loading directly into SRAM, or
> >> fastboot, DFU, etc..), JTAG, ...
> >>
> >> This information is usually reported by the SoC-ROM via some proprietary
> >> mechanism (some specific address in registers/DRAM for example).
> >>
> >> It would be useful to know which medium was used to load the first stage
> >> of the bootloader. SoC-ROM shall be ignored and not reported in this
> >> property.
> >>
> >> This can allow client programs to detect which medium to write to when
> >> updating the boot program, or detect if fallback mechanisms to
> >> unexpected medium were used to reach the client program's execution.
> >>
> >> Note that this property is already set by Barebox and I'm planning on
> >> adding it to U-Boot as well, specifically for Rockchip SoCs.
> >>
> >> I have some doubts about the wording, especially in the case of
> >> hypervisors or chained boot programs. I'm not entirely sure what would
> >> make the most sense to put in the property for those scenario.
> >> ---
> >>   source/chapter3-devicenodes.rst | 3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> >> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> >> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
> >> --- a/source/chapter3-devicenodes.rst
> >> +++ b/source/chapter3-devicenodes.rst
> >> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
> >>                                                          the client program. The value could
> >>                                                          potentially be a null string if no boot
> >>                                                          arguments are required.
> >> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
> >> +                                                       node representing the device the BootROM used
> >> +                                                       to load the initial boot program.
> >
> > Could/shoud this be a phandle instead? It might be more efficient.
> >
>
> In terms of size in DTB, phandle vs string probably much more efficient yes.
>
>  From user's perspective, I'm not too sure?
>
> /aliases does use full paths for example.
>
> Having a full path allows for easy consumption, just cat
> /proc/device-tree/chosen/bootsource and you'll have the actual path.
> Otherwise, we'd need a special tool for that I guess since it'll return
> the phandle number and then you have to traverse the tree to find which
> node has that phandle number?
>
> Also, I could imagine some scenario where:
> - a boot source would not be available in DT yet (though we probably
> shouldn't write it in /chosen/bootsource since we wouldn't know the
> proper path to it), e.g. USB loading, this is usually done via a
> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
> Rockchip) but no USB support yet in boot program or kernel (that was the
> case for a long time for RK3588 for example and I still have at least
> one device without the USB node described yet).
> - a boot source would be available in EL3 but not EL2, so does not make
> necessarily make sense to have it in kernel DTB for example. If it's not
> there, can't have a phandle.
> - a boot source supported only in boot program's DTB and not kernel's
> DTB, we probably still want to provide it to kernel's DTB even if it's
> not a device node in it.
> - a boot source doesn't necessarily have a label (though we could use a
> full-path phandle I believe &{/some/path@1f000} probably works). That is
> not uncommon for SPI flashes for example.

Well I'm not sure what we are defining here and which programs will use it.

I don't really like the idea of mentioning a boot source that is not
in the device tree. In fact that's one reason why I believe it is
better to use a phandle, since it enforces that. The RK3588 things you
mention sound like things the vendor should fix from day one, if it
matters.

If the boot-source device is not in the 'kernel' DTB, then why have
the boot source there? What use could it be? This seems like having an
alias to something that doesn't exist in the tree. But it could also
be used to just have "my-silly-device" as the value, with a magic
meaning which no one can figure out.

Re not having a label, we can add one. Yes, fdtdump does not have the
schema and doesn't decode phandles, although I suppose we could teach
it some basic things, or add a new tool.

So overall, this seems like a balance between short-term convenience
and long-term confusion.

To me, the strongest argument for paths is that /aliases uses full
paths rather the phandles. I believe that was a mistake (it caused
problems in SPL as it bloats the DT), but I've not looked at what it
would take to change it now.

>
> And additional argument for full-path: Barebox already uses that.

Were there discussions with that, which could be used here?

Anyway, if this is the way you want to go, I think it would be useful
to add some of your notes above into the binding, so there are some
rules around it.

Regards,
Simon

Re: [PATCH] Add 'bootsource' /chosen property

[Quentin Schulz]

Hi Simon,

On 2/9/25 3:28 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>
>> Hi Simon,
>>
>> On 2/6/25 1:33 PM, Simon Glass wrote:
>>> Hi Quentin,
>>>
>>> On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
>>>>
>>>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>>>
>>>> Bootloaders typically can be loaded from different storage media, such
>>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
>>>> such as USB (via proprietary protocols loading directly into SRAM, or
>>>> fastboot, DFU, etc..), JTAG, ...
>>>>
>>>> This information is usually reported by the SoC-ROM via some proprietary
>>>> mechanism (some specific address in registers/DRAM for example).
>>>>
>>>> It would be useful to know which medium was used to load the first stage
>>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
>>>> property.
>>>>
>>>> This can allow client programs to detect which medium to write to when
>>>> updating the boot program, or detect if fallback mechanisms to
>>>> unexpected medium were used to reach the client program's execution.
>>>>
>>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>>>> ---
>>>> Bootloaders typically can be loaded from different storage media, such
>>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
>>>> such as USB (via proprietary protocols loading directly into SRAM, or
>>>> fastboot, DFU, etc..), JTAG, ...
>>>>
>>>> This information is usually reported by the SoC-ROM via some proprietary
>>>> mechanism (some specific address in registers/DRAM for example).
>>>>
>>>> It would be useful to know which medium was used to load the first stage
>>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
>>>> property.
>>>>
>>>> This can allow client programs to detect which medium to write to when
>>>> updating the boot program, or detect if fallback mechanisms to
>>>> unexpected medium were used to reach the client program's execution.
>>>>
>>>> Note that this property is already set by Barebox and I'm planning on
>>>> adding it to U-Boot as well, specifically for Rockchip SoCs.
>>>>
>>>> I have some doubts about the wording, especially in the case of
>>>> hypervisors or chained boot programs. I'm not entirely sure what would
>>>> make the most sense to put in the property for those scenario.
>>>> ---
>>>>    source/chapter3-devicenodes.rst | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
>>>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
>>>> --- a/source/chapter3-devicenodes.rst
>>>> +++ b/source/chapter3-devicenodes.rst
>>>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
>>>>                                                           the client program. The value could
>>>>                                                           potentially be a null string if no boot
>>>>                                                           arguments are required.
>>>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
>>>> +                                                       node representing the device the BootROM used
>>>> +                                                       to load the initial boot program.
>>>
>>> Could/shoud this be a phandle instead? It might be more efficient.
>>>
>>
>> In terms of size in DTB, phandle vs string probably much more efficient yes.
>>
>>   From user's perspective, I'm not too sure?
>>
>> /aliases does use full paths for example.
>>
>> Having a full path allows for easy consumption, just cat
>> /proc/device-tree/chosen/bootsource and you'll have the actual path.
>> Otherwise, we'd need a special tool for that I guess since it'll return
>> the phandle number and then you have to traverse the tree to find which
>> node has that phandle number?
>>
>> Also, I could imagine some scenario where:
>> - a boot source would not be available in DT yet (though we probably
>> shouldn't write it in /chosen/bootsource since we wouldn't know the
>> proper path to it), e.g. USB loading, this is usually done via a
>> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
>> Rockchip) but no USB support yet in boot program or kernel (that was the
>> case for a long time for RK3588 for example and I still have at least
>> one device without the USB node described yet).
>> - a boot source would be available in EL3 but not EL2, so does not make
>> necessarily make sense to have it in kernel DTB for example. If it's not
>> there, can't have a phandle.
>> - a boot source supported only in boot program's DTB and not kernel's
>> DTB, we probably still want to provide it to kernel's DTB even if it's
>> not a device node in it.
>> - a boot source doesn't necessarily have a label (though we could use a
>> full-path phandle I believe &{/some/path@1f000} probably works). That is
>> not uncommon for SPI flashes for example.
> 
> Well I'm not sure what we are defining here and which programs will use it.
> 

I'm not sure to understand where the confusion is wrt "what we are 
defining here"? Can you please clarify?

Used by whatever and whoever wants to have some specific logic based on 
which medium the DUT was booted from, e.g. software updaters, distros or 
CI tools (labgrid in my case)? If your software is assuming the DUT is 
booted from eMMC while it is actually from SPI, you may think you're 
updating (including security fixes) the SW while you're not.

Throwing ideas right now, but this could also probably be used by 
fastboot/DFU to know which medium (e.g. MMC, SPI) to update by default 
instead of using one that defaults from the env/bin. I have no 
experience with either so maybe that's misleading.

> I don't really like the idea of mentioning a boot source that is not
> in the device tree. In fact that's one reason why I believe it is
> better to use a phandle, since it enforces that. The RK3588 things you
> mention sound like things the vendor should fix from day one, if it
> matters.
> 

There is no such "full Device Tree support day one", especially for new 
arm SoCs. We still do not have USB-C support on Radxa Rock-5B (it's on 
the way but still), the introducing commit was made more than two years 
ago already. I don't understand what's being suggested here.

> If the boot-source device is not in the 'kernel' DTB, then why have
> the boot source there? What use could it be? This seems like having an

Informative?

> alias to something that doesn't exist in the tree. But it could also
> be used to just have "my-silly-device" as the value, with a magic
> meaning which no one can figure out.
>

That's fair.

> Re not having a label, we can add one. Yes, fdtdump does not have the
> schema and doesn't decode phandles, although I suppose we could teach
> it some basic things, or add a new tool.
> 

If you don't use the same DT for U-Boot and the kernel (which is the 
case for all Rockchip-based devices as far as I know), a label may be an 
issue, especially if you don't keep the symbols in the DTB. Because then 
you need to guarantee that label X in U-Boot matching node Y in U-Boot 
also matches node Y in the kernel and not node Z, so you need some kind 
of hardcoding/mapping somewhere in U-Boot.

> So overall, this seems like a balance between short-term convenience
> and long-term confusion.
> 
> To me, the strongest argument for paths is that /aliases uses full
> paths rather the phandles. I believe that was a mistake (it caused
> problems in SPL as it bloats the DT), but I've not looked at what it
> would take to change it now.
> 
>>
>> And additional argument for full-path: Barebox already uses that.
> 
> Were there discussions with that, which could be used here?
> 

@Ahmad, any piece of history you'd like to share here maybe?

What I can say from glancing at the code is that for Rockchip they do 
the following:

Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a 
bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The 
mapping between what the ROM says the device is vs what it is in the DT 
is done in their Barebox-specific DT via this custom prop in /chosen:

barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  # 
à-la /aliases

This gets read and resolved and then inserted as

/chosen/bootsource = "/some/path"

into the kernel DT.

> Anyway, if this is the way you want to go, I think it would be useful
> to add some of your notes above into the binding, so there are some
> rules around it.
> 

I'm not sure what classifies as a rule in what I suggested, could you 
elaborate on that maybe?

Cheers,
Quentin

Re: [PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Quentin,

On Mon, 10 Feb 2025 at 09:25, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Simon,
>
> On 2/9/25 3:28 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 2/6/25 1:33 PM, Simon Glass wrote:
> >>> Hi Quentin,
> >>>
> >>> On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
> >>>>
> >>>> From: Quentin Schulz <quentin.schulz@cherry.de>
> >>>>
> >>>> Bootloaders typically can be loaded from different storage media, such
> >>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> >>>> such as USB (via proprietary protocols loading directly into SRAM, or
> >>>> fastboot, DFU, etc..), JTAG, ...
> >>>>
> >>>> This information is usually reported by the SoC-ROM via some proprietary
> >>>> mechanism (some specific address in registers/DRAM for example).
> >>>>
> >>>> It would be useful to know which medium was used to load the first stage
> >>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
> >>>> property.
> >>>>
> >>>> This can allow client programs to detect which medium to write to when
> >>>> updating the boot program, or detect if fallback mechanisms to
> >>>> unexpected medium were used to reach the client program's execution.
> >>>>
> >>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> >>>> ---
> >>>> Bootloaders typically can be loaded from different storage media, such
> >>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> >>>> such as USB (via proprietary protocols loading directly into SRAM, or
> >>>> fastboot, DFU, etc..), JTAG, ...
> >>>>
> >>>> This information is usually reported by the SoC-ROM via some proprietary
> >>>> mechanism (some specific address in registers/DRAM for example).
> >>>>
> >>>> It would be useful to know which medium was used to load the first stage
> >>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
> >>>> property.
> >>>>
> >>>> This can allow client programs to detect which medium to write to when
> >>>> updating the boot program, or detect if fallback mechanisms to
> >>>> unexpected medium were used to reach the client program's execution.
> >>>>
> >>>> Note that this property is already set by Barebox and I'm planning on
> >>>> adding it to U-Boot as well, specifically for Rockchip SoCs.
> >>>>
> >>>> I have some doubts about the wording, especially in the case of
> >>>> hypervisors or chained boot programs. I'm not entirely sure what would
> >>>> make the most sense to put in the property for those scenario.
> >>>> ---
> >>>>    source/chapter3-devicenodes.rst | 3 +++
> >>>>    1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> >>>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
> >>>> --- a/source/chapter3-devicenodes.rst
> >>>> +++ b/source/chapter3-devicenodes.rst
> >>>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
> >>>>                                                           the client program. The value could
> >>>>                                                           potentially be a null string if no boot
> >>>>                                                           arguments are required.
> >>>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
> >>>> +                                                       node representing the device the BootROM used
> >>>> +                                                       to load the initial boot program.
> >>>
> >>> Could/shoud this be a phandle instead? It might be more efficient.
> >>>
> >>
> >> In terms of size in DTB, phandle vs string probably much more efficient yes.
> >>
> >>   From user's perspective, I'm not too sure?
> >>
> >> /aliases does use full paths for example.
> >>
> >> Having a full path allows for easy consumption, just cat
> >> /proc/device-tree/chosen/bootsource and you'll have the actual path.
> >> Otherwise, we'd need a special tool for that I guess since it'll return
> >> the phandle number and then you have to traverse the tree to find which
> >> node has that phandle number?
> >>
> >> Also, I could imagine some scenario where:
> >> - a boot source would not be available in DT yet (though we probably
> >> shouldn't write it in /chosen/bootsource since we wouldn't know the
> >> proper path to it), e.g. USB loading, this is usually done via a
> >> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
> >> Rockchip) but no USB support yet in boot program or kernel (that was the
> >> case for a long time for RK3588 for example and I still have at least
> >> one device without the USB node described yet).
> >> - a boot source would be available in EL3 but not EL2, so does not make
> >> necessarily make sense to have it in kernel DTB for example. If it's not
> >> there, can't have a phandle.
> >> - a boot source supported only in boot program's DTB and not kernel's
> >> DTB, we probably still want to provide it to kernel's DTB even if it's
> >> not a device node in it.
> >> - a boot source doesn't necessarily have a label (though we could use a
> >> full-path phandle I believe &{/some/path@1f000} probably works). That is
> >> not uncommon for SPI flashes for example.
> >
> > Well I'm not sure what we are defining here and which programs will use it.
> >
>
> I'm not sure to understand where the confusion is wrt "what we are
> defining here"? Can you please clarify?
>
> Used by whatever and whoever wants to have some specific logic based on
> which medium the DUT was booted from, e.g. software updaters, distros or
> CI tools (labgrid in my case)? If your software is assuming the DUT is
> booted from eMMC while it is actually from SPI, you may think you're
> updating (including security fixes) the SW while you're not.

So for example, VBE includes a node which tells you which device is
used for firmware updates. If VBE is used, does it supercede this
setting?

>
> Throwing ideas right now, but this could also probably be used by
> fastboot/DFU to know which medium (e.g. MMC, SPI) to update by default
> instead of using one that defaults from the env/bin. I have no
> experience with either so maybe that's misleading.

What are you planning to use this for? Can we scope it to that, initially?

>
> > I don't really like the idea of mentioning a boot source that is not
> > in the device tree. In fact that's one reason why I believe it is
> > better to use a phandle, since it enforces that. The RK3588 things you
> > mention sound like things the vendor should fix from day one, if it
> > matters.
> >
>
> There is no such "full Device Tree support day one", especially for new
> arm SoCs. We still do not have USB-C support on Radxa Rock-5B (it's on
> the way but still), the introducing commit was made more than two years
> ago already. I don't understand what's being suggested here.

You mentioned that we have to use a string because it might refer to a
node not in the devicetree, e.g. we booted from USB but there is no
USB node in the devicetree. My suggestion would be to add that node,
even if it is empty.

>
> > If the boot-source device is not in the 'kernel' DTB, then why have
> > the boot source there? What use could it be? This seems like having an
>
> Informative?

OK, but this is really what I'm getting at. You must be adding this
for a reason, perhaps many. So please can you list the actual uses
your software will make, with this value in place?

>
> > alias to something that doesn't exist in the tree. But it could also
> > be used to just have "my-silly-device" as the value, with a magic
> > meaning which no one can figure out.
> >
>
> That's fair.
>
> > Re not having a label, we can add one. Yes, fdtdump does not have the
> > schema and doesn't decode phandles, although I suppose we could teach
> > it some basic things, or add a new tool.
> >
>
> If you don't use the same DT for U-Boot and the kernel (which is the
> case for all Rockchip-based devices as far as I know), a label may be an
> issue, especially if you don't keep the symbols in the DTB. Because then
> you need to guarantee that label X in U-Boot matching node Y in U-Boot
> also matches node Y in the kernel and not node Z, so you need some kind
> of hardcoding/mapping somewhere in U-Boot.

Wouldn't you set it correctly when you update the /chosen node? There
is no sense in putting this property in either the U-Boot or Linux
devicetree. It needs to be added to the Linux devicetree, in the FDT
fix-ups, just before booting LInux, like we do with other things in
the /chosen node.

>
> > So overall, this seems like a balance between short-term convenience
> > and long-term confusion.
> >
> > To me, the strongest argument for paths is that /aliases uses full
> > paths rather the phandles. I believe that was a mistake (it caused
> > problems in SPL as it bloats the DT), but I've not looked at what it
> > would take to change it now.
> >
> >>
> >> And additional argument for full-path: Barebox already uses that.
> >
> > Were there discussions with that, which could be used here?
> >
>
> @Ahmad, any piece of history you'd like to share here maybe?
>
> What I can say from glancing at the code is that for Rockchip they do
> the following:
>
> Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a
> bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The
> mapping between what the ROM says the device is vs what it is in the DT
> is done in their Barebox-specific DT via this custom prop in /chosen:
>
> barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  #
> à-la /aliases
>
> This gets read and resolved and then inserted as
>
> /chosen/bootsource = "/some/path"
>
> into the kernel DT.
>
> > Anyway, if this is the way you want to go, I think it would be useful
> > to add some of your notes above into the binding, so there are some
> > rules around it.
> >
>
> I'm not sure what classifies as a rule in what I suggested, could you
> elaborate on that maybe?

Let's get the info on what you are actually going to use this (you, or
your company).

But overall, I don't really have a strong opinion on whether this
should be a string or a phandle. If we consistently used phandles
today, I would want that, but we don't, so it seems that ship has
sailed.

Regards,
Simon

Re: [PATCH] Add 'bootsource' /chosen property

[Mark Kettenis]

> From: Simon Glass <sjg@chromium.org>
> Date: Sat, 15 Feb 2025 04:59:06 -0700

Hi Siomon, Quentin,

> Hi Quentin,
> 
> On Mon, 10 Feb 2025 at 09:25, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >
> > Hi Simon,
> >
> > On 2/9/25 3:28 PM, Simon Glass wrote:
> > > Hi Quentin,
> > >
> > > On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> > >>
> > >> Hi Simon,
> > >>
> > >> On 2/6/25 1:33 PM, Simon Glass wrote:
> > >>> Hi Quentin,
> > >>>
> > >>> On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
> > >>>>
> > >>>> From: Quentin Schulz <quentin.schulz@cherry.de>
> > >>>>
> > >>>> Bootloaders typically can be loaded from different storage media, such
> > >>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> > >>>> such as USB (via proprietary protocols loading directly into SRAM, or
> > >>>> fastboot, DFU, etc..), JTAG, ...
> > >>>>
> > >>>> This information is usually reported by the SoC-ROM via some proprietary
> > >>>> mechanism (some specific address in registers/DRAM for example).
> > >>>>
> > >>>> It would be useful to know which medium was used to load the first stage
> > >>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
> > >>>> property.
> > >>>>
> > >>>> This can allow client programs to detect which medium to write to when
> > >>>> updating the boot program, or detect if fallback mechanisms to
> > >>>> unexpected medium were used to reach the client program's execution.
> > >>>>
> > >>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> > >>>> ---
> > >>>> Bootloaders typically can be loaded from different storage media, such
> > >>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> > >>>> such as USB (via proprietary protocols loading directly into SRAM, or
> > >>>> fastboot, DFU, etc..), JTAG, ...
> > >>>>
> > >>>> This information is usually reported by the SoC-ROM via some proprietary
> > >>>> mechanism (some specific address in registers/DRAM for example).
> > >>>>
> > >>>> It would be useful to know which medium was used to load the first stage
> > >>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
> > >>>> property.
> > >>>>
> > >>>> This can allow client programs to detect which medium to write to when
> > >>>> updating the boot program, or detect if fallback mechanisms to
> > >>>> unexpected medium were used to reach the client program's execution.
> > >>>>
> > >>>> Note that this property is already set by Barebox and I'm planning on
> > >>>> adding it to U-Boot as well, specifically for Rockchip SoCs.
> > >>>>
> > >>>> I have some doubts about the wording, especially in the case of
> > >>>> hypervisors or chained boot programs. I'm not entirely sure what would
> > >>>> make the most sense to put in the property for those scenario.
> > >>>> ---
> > >>>>    source/chapter3-devicenodes.rst | 3 +++
> > >>>>    1 file changed, 3 insertions(+)
> > >>>>
> > >>>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> > >>>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
> > >>>> --- a/source/chapter3-devicenodes.rst
> > >>>> +++ b/source/chapter3-devicenodes.rst
> > >>>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
> > >>>>                                                           the client program. The value could
> > >>>>                                                           potentially be a null string if no boot
> > >>>>                                                           arguments are required.
> > >>>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
> > >>>> +                                                       node representing the device the BootROM used
> > >>>> +                                                       to load the initial boot program.
> > >>>
> > >>> Could/shoud this be a phandle instead? It might be more efficient.
> > >>>
> > >>
> > >> In terms of size in DTB, phandle vs string probably much more efficient yes.
> > >>
> > >>   From user's perspective, I'm not too sure?
> > >>
> > >> /aliases does use full paths for example.
> > >>
> > >> Having a full path allows for easy consumption, just cat
> > >> /proc/device-tree/chosen/bootsource and you'll have the actual path.
> > >> Otherwise, we'd need a special tool for that I guess since it'll return
> > >> the phandle number and then you have to traverse the tree to find which
> > >> node has that phandle number?
> > >>
> > >> Also, I could imagine some scenario where:
> > >> - a boot source would not be available in DT yet (though we probably
> > >> shouldn't write it in /chosen/bootsource since we wouldn't know the
> > >> proper path to it), e.g. USB loading, this is usually done via a
> > >> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
> > >> Rockchip) but no USB support yet in boot program or kernel (that was the
> > >> case for a long time for RK3588 for example and I still have at least
> > >> one device without the USB node described yet).
> > >> - a boot source would be available in EL3 but not EL2, so does not make
> > >> necessarily make sense to have it in kernel DTB for example. If it's not
> > >> there, can't have a phandle.
> > >> - a boot source supported only in boot program's DTB and not kernel's
> > >> DTB, we probably still want to provide it to kernel's DTB even if it's
> > >> not a device node in it.
> > >> - a boot source doesn't necessarily have a label (though we could use a
> > >> full-path phandle I believe &{/some/path@1f000} probably works). That is
> > >> not uncommon for SPI flashes for example.
> > >
> > > Well I'm not sure what we are defining here and which programs will use it.
> > >
> >
> > I'm not sure to understand where the confusion is wrt "what we are
> > defining here"? Can you please clarify?
> >
> > Used by whatever and whoever wants to have some specific logic based on
> > which medium the DUT was booted from, e.g. software updaters, distros or
> > CI tools (labgrid in my case)? If your software is assuming the DUT is
> > booted from eMMC while it is actually from SPI, you may think you're
> > updating (including security fixes) the SW while you're not.
> 
> So for example, VBE includes a node which tells you which device is
> used for firmware updates. If VBE is used, does it supercede this
> setting?
> 
> >
> > Throwing ideas right now, but this could also probably be used by
> > fastboot/DFU to know which medium (e.g. MMC, SPI) to update by default
> > instead of using one that defaults from the env/bin. I have no
> > experience with either so maybe that's misleading.
> 
> What are you planning to use this for? Can we scope it to that, initially?
> 
> >
> > > I don't really like the idea of mentioning a boot source that is not
> > > in the device tree. In fact that's one reason why I believe it is
> > > better to use a phandle, since it enforces that. The RK3588 things you
> > > mention sound like things the vendor should fix from day one, if it
> > > matters.
> > >
> >
> > There is no such "full Device Tree support day one", especially for new
> > arm SoCs. We still do not have USB-C support on Radxa Rock-5B (it's on
> > the way but still), the introducing commit was made more than two years
> > ago already. I don't understand what's being suggested here.
> 
> You mentioned that we have to use a string because it might refer to a
> node not in the devicetree, e.g. we booted from USB but there is no
> USB node in the devicetree. My suggestion would be to add that node,
> even if it is empty.
> 
> >
> > > If the boot-source device is not in the 'kernel' DTB, then why have
> > > the boot source there? What use could it be? This seems like having an
> >
> > Informative?
> 
> OK, but this is really what I'm getting at. You must be adding this
> for a reason, perhaps many. So please can you list the actual uses
> your software will make, with this value in place?
> 
> >
> > > alias to something that doesn't exist in the tree. But it could also
> > > be used to just have "my-silly-device" as the value, with a magic
> > > meaning which no one can figure out.
> > >
> >
> > That's fair.
> >
> > > Re not having a label, we can add one. Yes, fdtdump does not have the
> > > schema and doesn't decode phandles, although I suppose we could teach
> > > it some basic things, or add a new tool.
> > >
> >
> > If you don't use the same DT for U-Boot and the kernel (which is the
> > case for all Rockchip-based devices as far as I know), a label may be an
> > issue, especially if you don't keep the symbols in the DTB. Because then
> > you need to guarantee that label X in U-Boot matching node Y in U-Boot
> > also matches node Y in the kernel and not node Z, so you need some kind
> > of hardcoding/mapping somewhere in U-Boot.
> 
> Wouldn't you set it correctly when you update the /chosen node? There
> is no sense in putting this property in either the U-Boot or Linux
> devicetree. It needs to be added to the Linux devicetree, in the FDT
> fix-ups, just before booting LInux, like we do with other things in
> the /chosen node.
> 
> >
> > > So overall, this seems like a balance between short-term convenience
> > > and long-term confusion.
> > >
> > > To me, the strongest argument for paths is that /aliases uses full
> > > paths rather the phandles. I believe that was a mistake (it caused
> > > problems in SPL as it bloats the DT), but I've not looked at what it
> > > would take to change it now.
> > >
> > >>
> > >> And additional argument for full-path: Barebox already uses that.
> > >
> > > Were there discussions with that, which could be used here?
> > >
> >
> > @Ahmad, any piece of history you'd like to share here maybe?
> >
> > What I can say from glancing at the code is that for Rockchip they do
> > the following:
> >
> > Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a
> > bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The
> > mapping between what the ROM says the device is vs what it is in the DT
> > is done in their Barebox-specific DT via this custom prop in /chosen:
> >
> > barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  #
> > à-la /aliases
> >
> > This gets read and resolved and then inserted as
> >
> > /chosen/bootsource = "/some/path"
> >
> > into the kernel DT.
> >
> > > Anyway, if this is the way you want to go, I think it would be useful
> > > to add some of your notes above into the binding, so there are some
> > > rules around it.
> > >
> >
> > I'm not sure what classifies as a rule in what I suggested, could you
> > elaborate on that maybe?
> 
> Let's get the info on what you are actually going to use this (you, or
> your company).
> 
> But overall, I don't really have a strong opinion on whether this
> should be a string or a phandle. If we consistently used phandles
> today, I would want that, but we don't, so it seems that ship has
> sailed.

It probably should be a string because that allows you to specify some
additional information at the end of the path.  For example if you
boot from a disk on an AHCI controller, there are no nodes for the
individual disks.  So if you use a phandle the best you can do is
point at the AHCI controller.  A string also allows you to specify the
partition on a disk and a file on that partition if necessary.  This
is similar to how "stdout-path" and "stdin-path" can include
additional information about the serial interface (i.e. baud rate,
parity bit, stop bit).

There is prior art for all this in OpenFirmware, which defines a
"bootpath" string under "/chosen".  Not sure why that was dropped in
DTSpec.  Interestingly enough in OpenFirmware there were "stdin" and
"stdout" which were lhandles.  Those are similar to phandles but
reference a node in the tree directly.  So it looks like the DTSpec
authors made a conscious decision to use strings for things like this.

Re: [PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Mark,

On Sat, 15 Feb 2025 at 05:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Sat, 15 Feb 2025 04:59:06 -0700
>
> Hi Siomon, Quentin,
>
> > Hi Quentin,
> >
> > On Mon, 10 Feb 2025 at 09:25, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> > >
> > > Hi Simon,
> > >
> > > On 2/9/25 3:28 PM, Simon Glass wrote:
> > > > Hi Quentin,
> > > >
> > > > On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> > > >>
> > > >> Hi Simon,
> > > >>
> > > >> On 2/6/25 1:33 PM, Simon Glass wrote:
> > > >>> Hi Quentin,
> > > >>>
> > > >>> On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
> > > >>>>
> > > >>>> From: Quentin Schulz <quentin.schulz@cherry.de>
> > > >>>>
> > > >>>> Bootloaders typically can be loaded from different storage media, such
> > > >>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> > > >>>> such as USB (via proprietary protocols loading directly into SRAM, or
> > > >>>> fastboot, DFU, etc..), JTAG, ...
> > > >>>>
> > > >>>> This information is usually reported by the SoC-ROM via some proprietary
> > > >>>> mechanism (some specific address in registers/DRAM for example).
> > > >>>>
> > > >>>> It would be useful to know which medium was used to load the first stage
> > > >>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
> > > >>>> property.
> > > >>>>
> > > >>>> This can allow client programs to detect which medium to write to when
> > > >>>> updating the boot program, or detect if fallback mechanisms to
> > > >>>> unexpected medium were used to reach the client program's execution.
> > > >>>>
> > > >>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> > > >>>> ---
> > > >>>> Bootloaders typically can be loaded from different storage media, such
> > > >>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
> > > >>>> such as USB (via proprietary protocols loading directly into SRAM, or
> > > >>>> fastboot, DFU, etc..), JTAG, ...
> > > >>>>
> > > >>>> This information is usually reported by the SoC-ROM via some proprietary
> > > >>>> mechanism (some specific address in registers/DRAM for example).
> > > >>>>
> > > >>>> It would be useful to know which medium was used to load the first stage
> > > >>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
> > > >>>> property.
> > > >>>>
> > > >>>> This can allow client programs to detect which medium to write to when
> > > >>>> updating the boot program, or detect if fallback mechanisms to
> > > >>>> unexpected medium were used to reach the client program's execution.
> > > >>>>
> > > >>>> Note that this property is already set by Barebox and I'm planning on
> > > >>>> adding it to U-Boot as well, specifically for Rockchip SoCs.
> > > >>>>
> > > >>>> I have some doubts about the wording, especially in the case of
> > > >>>> hypervisors or chained boot programs. I'm not entirely sure what would
> > > >>>> make the most sense to put in the property for those scenario.
> > > >>>> ---
> > > >>>>    source/chapter3-devicenodes.rst | 3 +++
> > > >>>>    1 file changed, 3 insertions(+)
> > > >>>>
> > > >>>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
> > > >>>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
> > > >>>> --- a/source/chapter3-devicenodes.rst
> > > >>>> +++ b/source/chapter3-devicenodes.rst
> > > >>>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
> > > >>>>                                                           the client program. The value could
> > > >>>>                                                           potentially be a null string if no boot
> > > >>>>                                                           arguments are required.
> > > >>>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
> > > >>>> +                                                       node representing the device the BootROM used
> > > >>>> +                                                       to load the initial boot program.
> > > >>>
> > > >>> Could/shoud this be a phandle instead? It might be more efficient.
> > > >>>
> > > >>
> > > >> In terms of size in DTB, phandle vs string probably much more efficient yes.
> > > >>
> > > >>   From user's perspective, I'm not too sure?
> > > >>
> > > >> /aliases does use full paths for example.
> > > >>
> > > >> Having a full path allows for easy consumption, just cat
> > > >> /proc/device-tree/chosen/bootsource and you'll have the actual path.
> > > >> Otherwise, we'd need a special tool for that I guess since it'll return
> > > >> the phandle number and then you have to traverse the tree to find which
> > > >> node has that phandle number?
> > > >>
> > > >> Also, I could imagine some scenario where:
> > > >> - a boot source would not be available in DT yet (though we probably
> > > >> shouldn't write it in /chosen/bootsource since we wouldn't know the
> > > >> proper path to it), e.g. USB loading, this is usually done via a
> > > >> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
> > > >> Rockchip) but no USB support yet in boot program or kernel (that was the
> > > >> case for a long time for RK3588 for example and I still have at least
> > > >> one device without the USB node described yet).
> > > >> - a boot source would be available in EL3 but not EL2, so does not make
> > > >> necessarily make sense to have it in kernel DTB for example. If it's not
> > > >> there, can't have a phandle.
> > > >> - a boot source supported only in boot program's DTB and not kernel's
> > > >> DTB, we probably still want to provide it to kernel's DTB even if it's
> > > >> not a device node in it.
> > > >> - a boot source doesn't necessarily have a label (though we could use a
> > > >> full-path phandle I believe &{/some/path@1f000} probably works). That is
> > > >> not uncommon for SPI flashes for example.
> > > >
> > > > Well I'm not sure what we are defining here and which programs will use it.
> > > >
> > >
> > > I'm not sure to understand where the confusion is wrt "what we are
> > > defining here"? Can you please clarify?
> > >
> > > Used by whatever and whoever wants to have some specific logic based on
> > > which medium the DUT was booted from, e.g. software updaters, distros or
> > > CI tools (labgrid in my case)? If your software is assuming the DUT is
> > > booted from eMMC while it is actually from SPI, you may think you're
> > > updating (including security fixes) the SW while you're not.
> >
> > So for example, VBE includes a node which tells you which device is
> > used for firmware updates. If VBE is used, does it supercede this
> > setting?
> >
> > >
> > > Throwing ideas right now, but this could also probably be used by
> > > fastboot/DFU to know which medium (e.g. MMC, SPI) to update by default
> > > instead of using one that defaults from the env/bin. I have no
> > > experience with either so maybe that's misleading.
> >
> > What are you planning to use this for? Can we scope it to that, initially?
> >
> > >
> > > > I don't really like the idea of mentioning a boot source that is not
> > > > in the device tree. In fact that's one reason why I believe it is
> > > > better to use a phandle, since it enforces that. The RK3588 things you
> > > > mention sound like things the vendor should fix from day one, if it
> > > > matters.
> > > >
> > >
> > > There is no such "full Device Tree support day one", especially for new
> > > arm SoCs. We still do not have USB-C support on Radxa Rock-5B (it's on
> > > the way but still), the introducing commit was made more than two years
> > > ago already. I don't understand what's being suggested here.
> >
> > You mentioned that we have to use a string because it might refer to a
> > node not in the devicetree, e.g. we booted from USB but there is no
> > USB node in the devicetree. My suggestion would be to add that node,
> > even if it is empty.
> >
> > >
> > > > If the boot-source device is not in the 'kernel' DTB, then why have
> > > > the boot source there? What use could it be? This seems like having an
> > >
> > > Informative?
> >
> > OK, but this is really what I'm getting at. You must be adding this
> > for a reason, perhaps many. So please can you list the actual uses
> > your software will make, with this value in place?
> >
> > >
> > > > alias to something that doesn't exist in the tree. But it could also
> > > > be used to just have "my-silly-device" as the value, with a magic
> > > > meaning which no one can figure out.
> > > >
> > >
> > > That's fair.
> > >
> > > > Re not having a label, we can add one. Yes, fdtdump does not have the
> > > > schema and doesn't decode phandles, although I suppose we could teach
> > > > it some basic things, or add a new tool.
> > > >
> > >
> > > If you don't use the same DT for U-Boot and the kernel (which is the
> > > case for all Rockchip-based devices as far as I know), a label may be an
> > > issue, especially if you don't keep the symbols in the DTB. Because then
> > > you need to guarantee that label X in U-Boot matching node Y in U-Boot
> > > also matches node Y in the kernel and not node Z, so you need some kind
> > > of hardcoding/mapping somewhere in U-Boot.
> >
> > Wouldn't you set it correctly when you update the /chosen node? There
> > is no sense in putting this property in either the U-Boot or Linux
> > devicetree. It needs to be added to the Linux devicetree, in the FDT
> > fix-ups, just before booting LInux, like we do with other things in
> > the /chosen node.
> >
> > >
> > > > So overall, this seems like a balance between short-term convenience
> > > > and long-term confusion.
> > > >
> > > > To me, the strongest argument for paths is that /aliases uses full
> > > > paths rather the phandles. I believe that was a mistake (it caused
> > > > problems in SPL as it bloats the DT), but I've not looked at what it
> > > > would take to change it now.
> > > >
> > > >>
> > > >> And additional argument for full-path: Barebox already uses that.
> > > >
> > > > Were there discussions with that, which could be used here?
> > > >
> > >
> > > @Ahmad, any piece of history you'd like to share here maybe?
> > >
> > > What I can say from glancing at the code is that for Rockchip they do
> > > the following:
> > >
> > > Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a
> > > bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The
> > > mapping between what the ROM says the device is vs what it is in the DT
> > > is done in their Barebox-specific DT via this custom prop in /chosen:
> > >
> > > barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  #
> > > à-la /aliases
> > >
> > > This gets read and resolved and then inserted as
> > >
> > > /chosen/bootsource = "/some/path"
> > >
> > > into the kernel DT.
> > >
> > > > Anyway, if this is the way you want to go, I think it would be useful
> > > > to add some of your notes above into the binding, so there are some
> > > > rules around it.
> > > >
> > >
> > > I'm not sure what classifies as a rule in what I suggested, could you
> > > elaborate on that maybe?
> >
> > Let's get the info on what you are actually going to use this (you, or
> > your company).
> >
> > But overall, I don't really have a strong opinion on whether this
> > should be a string or a phandle. If we consistently used phandles
> > today, I would want that, but we don't, so it seems that ship has
> > sailed.
>
> It probably should be a string because that allows you to specify some
> additional information at the end of the path.  For example if you
> boot from a disk on an AHCI controller, there are no nodes for the
> individual disks.  So if you use a phandle the best you can do is
> point at the AHCI controller.  A string also allows you to specify the
> partition on a disk and a file on that partition if necessary.  This
> is similar to how "stdout-path" and "stdin-path" can include
> additional information about the serial interface (i.e. baud rate,
> parity bit, stop bit).
>
> There is prior art for all this in OpenFirmware, which defines a
> "bootpath" string under "/chosen".  Not sure why that was dropped in
> DTSpec.  Interestingly enough in OpenFirmware there were "stdin" and
> "stdout" which were lhandles.  Those are similar to phandles but
> reference a node in the tree directly.  So it looks like the DTSpec
> authors made a conscious decision to use strings for things like this.

Thanks, that helps a lot. Quentin, can you include some notes like
this in your patch?

Regards,
Simon

Re: [PATCH] Add 'bootsource' /chosen property

[Daniel Golle]

Hi Quentin,

On 10 February 2025 16:25:23 UTC, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> [...]
>What I can say from glancing at the code is that for Rockchip they do the following:
>
>Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The mapping between what the ROM says the device is vs what it is in the DT is done in their Barebox-specific DT via this custom prop in /chosen:
>
>barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  # à-la /aliases
>
>This gets read and resolved and then inserted as
>
>/chosen/bootsource = "/some/path"
>
>into the kernel DT.

We are doing something quite similar downsream at openwrt.org for MediaTek router SoCs, see for example:

https://github.com/openwrt/openwrt/blob/main/package/boot/uboot-mediatek/patches/310-mt7988-select-rootdisk.patch

https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi#L32

https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso#L60


Of course we could use the standard "bootsource" property instead, but having a way to reference the volume or partition used as rootfs instead of just passing a referencd to a physical device is advantagous...

Re: [PATCH] Add 'bootsource' /chosen property

[Quentin Schulz]

Hi Simon, Mark,

On 2/15/25 2:04 PM, Simon Glass wrote:
> Hi Mark,
> 
> On Sat, 15 Feb 2025 at 05:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>
>>> From: Simon Glass <sjg@chromium.org>
>>> Date: Sat, 15 Feb 2025 04:59:06 -0700
>>
>> Hi Siomon, Quentin,
>>
>>> Hi Quentin,
>>>
>>> On Mon, 10 Feb 2025 at 09:25, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On 2/9/25 3:28 PM, Simon Glass wrote:
>>>>> Hi Quentin,
>>>>>
>>>>> On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 2/6/25 1:33 PM, Simon Glass wrote:
>>>>>>> Hi Quentin,
>>>>>>>
>>>>>>> On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@0leil.net> wrote:
>>>>>>>>
>>>>>>>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>>>>>>>
>>>>>>>> Bootloaders typically can be loaded from different storage media, such
>>>>>>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
>>>>>>>> such as USB (via proprietary protocols loading directly into SRAM, or
>>>>>>>> fastboot, DFU, etc..), JTAG, ...
>>>>>>>>
>>>>>>>> This information is usually reported by the SoC-ROM via some proprietary
>>>>>>>> mechanism (some specific address in registers/DRAM for example).
>>>>>>>>
>>>>>>>> It would be useful to know which medium was used to load the first stage
>>>>>>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
>>>>>>>> property.
>>>>>>>>
>>>>>>>> This can allow client programs to detect which medium to write to when
>>>>>>>> updating the boot program, or detect if fallback mechanisms to
>>>>>>>> unexpected medium were used to reach the client program's execution.
>>>>>>>>
>>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>>>>>>>> ---
>>>>>>>> Bootloaders typically can be loaded from different storage media, such
>>>>>>>> as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
>>>>>>>> such as USB (via proprietary protocols loading directly into SRAM, or
>>>>>>>> fastboot, DFU, etc..), JTAG, ...
>>>>>>>>
>>>>>>>> This information is usually reported by the SoC-ROM via some proprietary
>>>>>>>> mechanism (some specific address in registers/DRAM for example).
>>>>>>>>
>>>>>>>> It would be useful to know which medium was used to load the first stage
>>>>>>>> of the bootloader. SoC-ROM shall be ignored and not reported in this
>>>>>>>> property.
>>>>>>>>
>>>>>>>> This can allow client programs to detect which medium to write to when
>>>>>>>> updating the boot program, or detect if fallback mechanisms to
>>>>>>>> unexpected medium were used to reach the client program's execution.
>>>>>>>>
>>>>>>>> Note that this property is already set by Barebox and I'm planning on
>>>>>>>> adding it to U-Boot as well, specifically for Rockchip SoCs.
>>>>>>>>
>>>>>>>> I have some doubts about the wording, especially in the case of
>>>>>>>> hypervisors or chained boot programs. I'm not entirely sure what would
>>>>>>>> make the most sense to put in the property for those scenario.
>>>>>>>> ---
>>>>>>>>     source/chapter3-devicenodes.rst | 3 +++
>>>>>>>>     1 file changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
>>>>>>>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
>>>>>>>> --- a/source/chapter3-devicenodes.rst
>>>>>>>> +++ b/source/chapter3-devicenodes.rst
>>>>>>>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
>>>>>>>>                                                            the client program. The value could
>>>>>>>>                                                            potentially be a null string if no boot
>>>>>>>>                                                            arguments are required.
>>>>>>>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
>>>>>>>> +                                                       node representing the device the BootROM used
>>>>>>>> +                                                       to load the initial boot program.
>>>>>>>
>>>>>>> Could/shoud this be a phandle instead? It might be more efficient.
>>>>>>>
>>>>>>
>>>>>> In terms of size in DTB, phandle vs string probably much more efficient yes.
>>>>>>
>>>>>>    From user's perspective, I'm not too sure?
>>>>>>
>>>>>> /aliases does use full paths for example.
>>>>>>
>>>>>> Having a full path allows for easy consumption, just cat
>>>>>> /proc/device-tree/chosen/bootsource and you'll have the actual path.
>>>>>> Otherwise, we'd need a special tool for that I guess since it'll return
>>>>>> the phandle number and then you have to traverse the tree to find which
>>>>>> node has that phandle number?
>>>>>>
>>>>>> Also, I could imagine some scenario where:
>>>>>> - a boot source would not be available in DT yet (though we probably
>>>>>> shouldn't write it in /chosen/bootsource since we wouldn't know the
>>>>>> proper path to it), e.g. USB loading, this is usually done via a
>>>>>> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
>>>>>> Rockchip) but no USB support yet in boot program or kernel (that was the
>>>>>> case for a long time for RK3588 for example and I still have at least
>>>>>> one device without the USB node described yet).
>>>>>> - a boot source would be available in EL3 but not EL2, so does not make
>>>>>> necessarily make sense to have it in kernel DTB for example. If it's not
>>>>>> there, can't have a phandle.
>>>>>> - a boot source supported only in boot program's DTB and not kernel's
>>>>>> DTB, we probably still want to provide it to kernel's DTB even if it's
>>>>>> not a device node in it.
>>>>>> - a boot source doesn't necessarily have a label (though we could use a
>>>>>> full-path phandle I believe &{/some/path@1f000} probably works). That is
>>>>>> not uncommon for SPI flashes for example.
>>>>>
>>>>> Well I'm not sure what we are defining here and which programs will use it.
>>>>>
>>>>
>>>> I'm not sure to understand where the confusion is wrt "what we are
>>>> defining here"? Can you please clarify?
>>>>
>>>> Used by whatever and whoever wants to have some specific logic based on
>>>> which medium the DUT was booted from, e.g. software updaters, distros or
>>>> CI tools (labgrid in my case)? If your software is assuming the DUT is
>>>> booted from eMMC while it is actually from SPI, you may think you're
>>>> updating (including security fixes) the SW while you're not.
>>>
>>> So for example, VBE includes a node which tells you which device is
>>> used for firmware updates. If VBE is used, does it supercede this
>>> setting?
>>>

If I remember how VBE is working, they are for different things.

If I recall correctly, VBE will provide which medium/partition/offset 
was used by VPL to load the next stage (SPL IIRC?).

This /chosen/bootsource would be what's reported by the bootrom. I.e. 
where VPL/TPL or whatever the first stage loaded by the BootROM is stored.

E.g. you could very well upload VPL+TPL over USB via rkdeveloptool and 
have it load SPL+Proper from a local storage medium such as eMMC, for 
example if VPL+TPL somehow got corrupted and you need to recover the 
board. In that case /chosen/bootsource would be the USB device, not the 
eMMC.

FWIW, we have /chosen/u-boot,spl-boot-device for storing the boot medium 
that was used by SPL to load U-Boot proper, I assume this would be what 
VPL/VBE would set for the updatable part of U-Boot?

>>>>
>>>> Throwing ideas right now, but this could also probably be used by
>>>> fastboot/DFU to know which medium (e.g. MMC, SPI) to update by default
>>>> instead of using one that defaults from the env/bin. I have no
>>>> experience with either so maybe that's misleading.
>>>
>>> What are you planning to use this for? Can we scope it to that, initially?

I have our RK3399 Puma with 9 possible booting media scenario (SPI-NOR, 
eMMC and SD card for TPL, with the same amount of choices for U-Boot 
proper), not counting USB loading.

Our other products have 4 (eMMC, SD card for TPL, same amount of choices 
for proper), not counting USB loading.

It is possible to have a board I'm trying to test eMMC/SPI boot actually 
boot from SPI/eMMC based on their state and content. I don't want to 
think I actually properly tested eMMC/SPI booting but actually tested 
something else.

So the answer is simply CI for now, for me. I'm pretty sure it isn't the 
only usecase since Barebox added support for it too, long time ago.

This would also help debug customer setups much more easily if we know 
they are updating the wrong storage medium. We also have customers who 
have U-Boot without serial, so just looking at the serial output is not 
an option.

>>>
>>>>
>>>>> I don't really like the idea of mentioning a boot source that is not
>>>>> in the device tree. In fact that's one reason why I believe it is
>>>>> better to use a phandle, since it enforces that. The RK3588 things you
>>>>> mention sound like things the vendor should fix from day one, if it
>>>>> matters.
>>>>>
>>>>
>>>> There is no such "full Device Tree support day one", especially for new
>>>> arm SoCs. We still do not have USB-C support on Radxa Rock-5B (it's on
>>>> the way but still), the introducing commit was made more than two years
>>>> ago already. I don't understand what's being suggested here.
>>>
>>> You mentioned that we have to use a string because it might refer to a
>>> node not in the devicetree, e.g. we booted from USB but there is no
>>> USB node in the devicetree. My suggestion would be to add that node,
>>> even if it is empty.
>>>

Considering that DT people usually advocate for the full dt binding 
picture when adding support for a new controller, PHY, SoC, I'm not sure 
a random empty node is going to fly by them.

But sure, that's an option.

>>>>
>>>>> If the boot-source device is not in the 'kernel' DTB, then why have
>>>>> the boot source there? What use could it be? This seems like having an
>>>>
>>>> Informative?
>>>
>>> OK, but this is really what I'm getting at. You must be adding this
>>> for a reason, perhaps many. So please can you list the actual uses
>>> your software will make, with this value in place?
>>>

I need it for CI of the bootloader, much easier to parse the DT than 
parse some possibly changing bootloader output.

I can think of other scenarios like making sure updates are applied to 
the bootloader that is actually being used, helping debug people's 
setups, allowing userspace to have different logic based on which device 
was used for loading the first stage, starting manufacturing 
provisioning if you boot from USB, go through a full recovery process if 
booting from SD card, ...

>>>>
>>>>> alias to something that doesn't exist in the tree. But it could also
>>>>> be used to just have "my-silly-device" as the value, with a magic
>>>>> meaning which no one can figure out.
>>>>>
>>>>
>>>> That's fair.
>>>>
>>>>> Re not having a label, we can add one. Yes, fdtdump does not have the
>>>>> schema and doesn't decode phandles, although I suppose we could teach
>>>>> it some basic things, or add a new tool.
>>>>>
>>>>
>>>> If you don't use the same DT for U-Boot and the kernel (which is the
>>>> case for all Rockchip-based devices as far as I know), a label may be an
>>>> issue, especially if you don't keep the symbols in the DTB. Because then
>>>> you need to guarantee that label X in U-Boot matching node Y in U-Boot
>>>> also matches node Y in the kernel and not node Z, so you need some kind
>>>> of hardcoding/mapping somewhere in U-Boot.
>>>
>>> Wouldn't you set it correctly when you update the /chosen node? There
>>> is no sense in putting this property in either the U-Boot or Linux
>>> devicetree. It needs to be added to the Linux devicetree, in the FDT
>>> fix-ups, just before booting LInux, like we do with other things in
>>> the /chosen node.
>>>

How do I know I set it up correctly? I don't necessarily have the 
symbols in the kernel DT and the path/phandle value may be different 
between U-Boot DT and kernel DT.

>>>>
>>>>> So overall, this seems like a balance between short-term convenience
>>>>> and long-term confusion.
>>>>>
>>>>> To me, the strongest argument for paths is that /aliases uses full
>>>>> paths rather the phandles. I believe that was a mistake (it caused
>>>>> problems in SPL as it bloats the DT), but I've not looked at what it
>>>>> would take to change it now.
>>>>>
>>>>>>
>>>>>> And additional argument for full-path: Barebox already uses that.
>>>>>
>>>>> Were there discussions with that, which could be used here?
>>>>>
>>>>
>>>> @Ahmad, any piece of history you'd like to share here maybe?
>>>>
>>>> What I can say from glancing at the code is that for Rockchip they do
>>>> the following:
>>>>
>>>> Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a
>>>> bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The
>>>> mapping between what the ROM says the device is vs what it is in the DT
>>>> is done in their Barebox-specific DT via this custom prop in /chosen:
>>>>
>>>> barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  #
>>>> à-la /aliases
>>>>
>>>> This gets read and resolved and then inserted as
>>>>
>>>> /chosen/bootsource = "/some/path"
>>>>
>>>> into the kernel DT.
>>>>
>>>>> Anyway, if this is the way you want to go, I think it would be useful
>>>>> to add some of your notes above into the binding, so there are some
>>>>> rules around it.
>>>>>
>>>>
>>>> I'm not sure what classifies as a rule in what I suggested, could you
>>>> elaborate on that maybe?
>>>
>>> Let's get the info on what you are actually going to use this (you, or
>>> your company).
>>>
>>> But overall, I don't really have a strong opinion on whether this
>>> should be a string or a phandle. If we consistently used phandles
>>> today, I would want that, but we don't, so it seems that ship has
>>> sailed.
>>
>> It probably should be a string because that allows you to specify some
>> additional information at the end of the path.  For example if you
>> boot from a disk on an AHCI controller, there are no nodes for the
>> individual disks.  So if you use a phandle the best you can do is
>> point at the AHCI controller.  A string also allows you to specify the
>> partition on a disk and a file on that partition if necessary.  This
>> is similar to how "stdout-path" and "stdin-path" can include
>> additional information about the serial interface (i.e. baud rate,
>> parity bit, stop bit).
>>

I really really want to reiterate that this property is NOT to be used 
for storing which medium was used to load the kernel, rootfs, or 
whatnot. Only from where the BootROM of the SoC loaded the first 
user-flashable/loadable.

Also not from first stage to second stage, e.g. not for storing from 
where U-Boot SPL loaded U-Boot proper from, this we already use 
/chosen/u-boot,spl-boot-device for that.

I do not know which info all SoC models or vendors are exposing as their 
first boot medium. Rockchip stores that in an undocumented register as 
far as I could tell. c.f. BROM_BOOTSOURCE_ID_ADDR for the register 
(somewhere at the beginning of the SRAM it seems) and 
arch/arm/include/asm/arch-rockchip/bootrom.h for the meaning of its content.

I guess if Rockchip's BootROM could load from eMMC HW boot partitions, 
and they would expose the information, it would make sense to be able to 
specify that in the path. Similarly, Rockchip's BootROM looks for a 
special magic value at different offsets to detect where a first stage 
bootloader is loaded. I do not know if the offset the first stage 
bootloader was found is stored in some undocumented register/RAM 
address, but if it could, it would be helpful to know as well. If we had 
two copies of the bootloader at offsets that can be read by the BootROM, 
we could imagine storing the offset of the bootloader that was properly 
loaded and provide that information to the user. E.g. if we boot from 
the second offset, it means the first one got some bitflip or corruption 
and we should fix it.

I guess we could also imagine a BootROM capable of reading MBR/GPT 
partition tables and reporting which partition it used to load the first 
stage bootloader.

There's just so many possible scenario I could imagine, I am not 
entirely sure it makes sense to try to have all those supported in one 
single string property?

Cheers,
Quentin

Re: [PATCH] Add 'bootsource' /chosen property

[Quentin Schulz]

Hi Daniel,

On 2/15/25 4:13 PM, Daniel Golle wrote:
> Hi Quentin,
> 
> On 10 February 2025 16:25:23 UTC, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>> [...]
>> What I can say from glancing at the code is that for Rockchip they do the following:
>>
>> Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The mapping between what the ROM says the device is vs what it is in the DT is done in their Barebox-specific DT via this custom prop in /chosen:
>>
>> barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  # à-la /aliases
>>
>> This gets read and resolved and then inserted as
>>
>> /chosen/bootsource = "/some/path"
>>
>> into the kernel DT.
> 
> We are doing something quite similar downsream at openwrt.org for MediaTek router SoCs, see for example:
> 
> https://github.com/openwrt/openwrt/blob/main/package/boot/uboot-mediatek/patches/310-mt7988-select-rootdisk.patch
> 
> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi#L32
> 
> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso#L60
> 
> 
> Of course we could use the standard "bootsource" property instead, but having a way to reference the volume or partition used as rootfs instead of just passing a referencd to a physical device is advantagous...
> 

If I understood correctly, your prebuilt DT would have

/ {
     chosen {
         rootdisk-emmc = <&rootfs_in_emmc>;
         rootdisk-nor = <&rootfs_in_nor>;
         rootdisk-sd = <&rootfs_in_sd>;
         rootdisk-spim-nand = <&rootfs_in_ubi>;
     };
};

and then at runtime you would populate /chosen/rootdisk property with 
the "rootdisk-<medium>" string with <medium> matching whatever the 
BootROM reports. I assume the goal is to somehow make sure that the 
rootfs is loaded from the same storage medium as the one used by the 
BootROM to load the first stage bootloader?

Can you confirm I did get that right?

I was specifically NOT aiming /chosen/bootsource to represent the 
storage medium used to load the kernel or rootfs, but rather the medium 
that was used by the BootROM to load the first stage of the bootloader 
that is user-flashable/uploadable.

You could very well decide to load/mount your rootfs from SD even if the 
BootROM loaded the first stage bootloader from SPI-NOR. This property is 
about representing the latter, not the former and not merging the 
meaning of both into one.

However, I could see a BootROM being able to report from which partition 
and controller it loaded the first stage bootloader, and then it'd make 
sense to have that in /chosen, either as part of /chosen/bootsource or 
an additional property like /chosen/bootsource-partition.

Cheers,
Quentin

Re: [PATCH] Add 'bootsource' /chosen property

[Daniel Golle]

On Thu, Feb 20, 2025 at 04:04:27PM +0100, Quentin Schulz wrote:
> Hi Daniel,
> 
> On 2/15/25 4:13 PM, Daniel Golle wrote:
> > Hi Quentin,
> > 
> > On 10 February 2025 16:25:23 UTC, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> > > [...]
> > > What I can say from glancing at the code is that for Rockchip they do the following:
> > > 
> > > Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The mapping between what the ROM says the device is vs what it is in the DT is done in their Barebox-specific DT via this custom prop in /chosen:
> > > 
> > > barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  # à-la /aliases
> > > 
> > > This gets read and resolved and then inserted as
> > > 
> > > /chosen/bootsource = "/some/path"
> > > 
> > > into the kernel DT.
> > 
> > We are doing something quite similar downsream at openwrt.org for MediaTek router SoCs, see for example:
> > 
> > https://github.com/openwrt/openwrt/blob/main/package/boot/uboot-mediatek/patches/310-mt7988-select-rootdisk.patch
> > 
> > https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi#L32
> > 
> > https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso#L60
> > 
> > 
> > Of course we could use the standard "bootsource" property instead, but having a way to reference the volume or partition used as rootfs instead of just passing a referencd to a physical device is advantagous...
> > 
> 
> If I understood correctly, your prebuilt DT would have
> 
> / {
>     chosen {
>         rootdisk-emmc = <&rootfs_in_emmc>;
>         rootdisk-nor = <&rootfs_in_nor>;
>         rootdisk-sd = <&rootfs_in_sd>;
>         rootdisk-spim-nand = <&rootfs_in_ubi>;
>     };
> };
> 
> and then at runtime you would populate /chosen/rootdisk property with the
> "rootdisk-<medium>" string with <medium> matching whatever the BootROM
> reports. I assume the goal is to somehow make sure that the rootfs is loaded
> from the same storage medium as the one used by the BootROM to load the
> first stage bootloader?
> 
> Can you confirm I did get that right?

Yes, that's more or less correct. It's to point Linux to the device or
partition of the uImage from which U-Boot has loaded the Linux kernel.

Note that for OpenWrt we prefer to store the uImage.FIT inside a raw
block or flash partition, or UBI volume, rather than as a file inside a
filesystem.

This information is then used for two things:

 - Mount the root filesystem
   We use a read-only squashfs which is part of the uImage.FIT, it essentially
   has the same purpose of an initramfs on other distributions, but mounting
   squashfs is much faster then decompressing the whole initramfs at once, and
   it doesn't need to remain in RAM permanently.

 - Know where an updated uImage.FIT should be written to.

> 
> I was specifically NOT aiming /chosen/bootsource to represent the storage
> medium used to load the kernel or rootfs, but rather the medium that was
> used by the BootROM to load the first stage of the bootloader that is
> user-flashable/uploadable.
> 
> You could very well decide to load/mount your rootfs from SD even if the
> BootROM loaded the first stage bootloader from SPI-NOR. This property is
> about representing the latter, not the former and not merging the meaning of
> both into one.

Of course, especially for general purpose Linux which would not fit into
NOR flash that's the only option.

In case of OpenWrt we usually do want to load kernel (and rootfs) from
the same device also used by the BootROM for booting. OpenWrt can easily
fit onto 16 MiB of NOR flash, including bootloader, EEPROM for MAC
addresses and WiFi calibration as well as some megabytes for user data.

To satisfy both needs, I reckon we would need to formally introduce an
OpenWrt boot-method to U-Boot, and then U-Boot could leave a mark in
/chosen where the uImage.FIT was loaded from, independently of the
BootROM which may differ?

> 
> However, I could see a BootROM being able to report from which partition and
> controller it loaded the first stage bootloader, and then it'd make sense to
> have that in /chosen, either as part of /chosen/bootsource or an additional
> property like /chosen/bootsource-partition.

That definitely makes sense too.

Re: [PATCH] Add 'bootsource' /chosen property

[Ahmad Fatoum]

Hello,

Quentin, thanks for starting this discussion.

On 10.02.25 17:25, Quentin Schulz wrote:
> On 2/9/25 3:28 PM, Simon Glass wrote:
>> On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
>>>>> index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
>>>>> --- a/source/chapter3-devicenodes.rst
>>>>> +++ b/source/chapter3-devicenodes.rst
>>>>> @@ -456,6 +456,9 @@ time. It shall be a child of the root node.
>>>>>                                                           the client program. The value could
>>>>>                                                           potentially be a null string if no boot
>>>>>                                                           arguments are required.
>>>>> +   ``bootsource``          O     ``<string>``          A string that specifies the full path to the
>>>>> +                                                       node representing the device the BootROM used
>>>>> +                                                       to load the initial boot program.
>>>>
>>>> Could/shoud this be a phandle instead? It might be more efficient.

AFAIK, all other properties in /chosen (e.g. stdout-path) are strings
Having this one be a phandle would be confusing IMO.

>>> - a boot source would not be available in DT yet (though we probably
>>> shouldn't write it in /chosen/bootsource since we wouldn't know the
>>> proper path to it), e.g. USB loading, this is usually done via a
>>> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
>>> Rockchip) but no USB support yet in boot program or kernel (that was the
>>> case for a long time for RK3588 for example and I still have at least
>>> one device without the USB node described yet).

I don't think we want to go there. /chosen/bootsource should always point at
an existing node. If there is no node, the property shouldn't be there at all
until an actual hardware device tree node is created first.

>>> And additional argument for full-path: Barebox already uses that.
>>
>> Were there discussions with that, which could be used here?
>>
> 
> @Ahmad, any piece of history you'd like to share here maybe?

I can't share history, as the addition in 2018 predates my involvement
with the project. I can share some thoughts and experiences though:

- Inside barebox, the bootsource is most often used for

  - loading the correct environment:
    For modern boards, barebox automatically looks up a GPT partition with the
    barebox environment type UUID and loads it. As there can be multiple such partitions,
    it prefers the partition that is located on the original boot medium as indicated
    by the bootsource.

  - setting a barebox update handler as the default:
    barebox_update /mnt/tftp/my-barebox-image without further arguments will by default
    update the barebox binary on the original boot medium

  - inside scripts. A common stanza is an init script that has:
    if [ $bootsource = serial ]; then global.autoboot_timeout=30; fi
    So the boot is delayed a little.

- If standardized, /chosen/bootsource could be useful to pass information from
  first to second stage bootloader. E.g. on Rockchip, the information where the
  system is booted from is in RAM that's only available early on in EL3.
  Currently, barebox running as first stage copies that information to a place
  where it's not clobbered by BL31, but we could in theory also have the barebox
  prebootloader parse it and fix it up into the device tree it already passes
  along to barebox proper.

- /chosen/bootsource can be used in userspace to detect if the system was
  booted in recovery mode and to adapt accordingly.

- /chosen/bootsource can be used to load boot state from the correct boot
  medium. This is useful when the exact same image is flashed to e.g. a SD
  and an eMMC.

As Quentin mentions this is only about the first external boot medium.
This doesn't reduce usefulness much though, because systems increasingly
have a single boot medium anyway (e.g. eMMC boot partition + user area).

Cheers,
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: [PATCH] Add 'bootsource' /chosen property

[Quentin Schulz]

On 2/20/25 4:22 PM, Daniel Golle wrote:
> On Thu, Feb 20, 2025 at 04:04:27PM +0100, Quentin Schulz wrote:
>> Hi Daniel,
>>
>> On 2/15/25 4:13 PM, Daniel Golle wrote:
>>> Hi Quentin,
>>>
>>> On 10 February 2025 16:25:23 UTC, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>> [...]
>>>> What I can say from glancing at the code is that for Rockchip they do the following:
>>>>
>>>> Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The mapping between what the ROM says the device is vs what it is in the DT is done in their Barebox-specific DT via this custom prop in /chosen:
>>>>
>>>> barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  # à-la /aliases
>>>>
>>>> This gets read and resolved and then inserted as
>>>>
>>>> /chosen/bootsource = "/some/path"
>>>>
>>>> into the kernel DT.
>>>
>>> We are doing something quite similar downsream at openwrt.org for MediaTek router SoCs, see for example:
>>>
>>> https://github.com/openwrt/openwrt/blob/main/package/boot/uboot-mediatek/patches/310-mt7988-select-rootdisk.patch
>>>
>>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi#L32
>>>
>>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso#L60
>>>
>>>
>>> Of course we could use the standard "bootsource" property instead, but having a way to reference the volume or partition used as rootfs instead of just passing a referencd to a physical device is advantagous...
>>>
>>
>> If I understood correctly, your prebuilt DT would have
>>
>> / {
>>      chosen {
>>          rootdisk-emmc = <&rootfs_in_emmc>;
>>          rootdisk-nor = <&rootfs_in_nor>;
>>          rootdisk-sd = <&rootfs_in_sd>;
>>          rootdisk-spim-nand = <&rootfs_in_ubi>;
>>      };
>> };
>>
>> and then at runtime you would populate /chosen/rootdisk property with the
>> "rootdisk-<medium>" string with <medium> matching whatever the BootROM
>> reports. I assume the goal is to somehow make sure that the rootfs is loaded
>> from the same storage medium as the one used by the BootROM to load the
>> first stage bootloader?
>>
>> Can you confirm I did get that right?
> 
> Yes, that's more or less correct. It's to point Linux to the device or
> partition of the uImage from which U-Boot has loaded the Linux kernel.
> 
> Note that for OpenWrt we prefer to store the uImage.FIT inside a raw
> block or flash partition, or UBI volume, rather than as a file inside a
> filesystem.
> 
> This information is then used for two things:
> 
>   - Mount the root filesystem
>     We use a read-only squashfs which is part of the uImage.FIT, it essentially
>     has the same purpose of an initramfs on other distributions, but mounting
>     squashfs is much faster then decompressing the whole initramfs at once, and
>     it doesn't need to remain in RAM permanently.
> 
>   - Know where an updated uImage.FIT should be written to.
> 

OK, so everything in a FIT image and you store the location and storage 
medium where it was loaded from so that you can update it. Makes sense.

I guess we could have bootstd/bootmeths populate another property that 
specifies which medium and partition was used to load the kernel/FDT and 
initramfs. I don't have much experience with that aside from 
extlinux.conf and that wouldn't be appropriate I believe especially if 
you used root=PARTLABEL= or a UUID in your kernel command line as there 
could be multiple ones with the same there (e.g. we have the exact same 
image you can flash on SD card and eMMC and the probe order isn't 
deterministic in the kernel I believe).

Don't want to get sidetracked too far though, I don't think it is 
incompatible with or related to /chosen/bootsource usage?

>>
>> I was specifically NOT aiming /chosen/bootsource to represent the storage
>> medium used to load the kernel or rootfs, but rather the medium that was
>> used by the BootROM to load the first stage of the bootloader that is
>> user-flashable/uploadable.
>>
>> You could very well decide to load/mount your rootfs from SD even if the
>> BootROM loaded the first stage bootloader from SPI-NOR. This property is
>> about representing the latter, not the former and not merging the meaning of
>> both into one.
> 
> Of course, especially for general purpose Linux which would not fit into
> NOR flash that's the only option.
> 
> In case of OpenWrt we usually do want to load kernel (and rootfs) from
> the same device also used by the BootROM for booting. OpenWrt can easily
> fit onto 16 MiB of NOR flash, including bootloader, EEPROM for MAC
> addresses and WiFi calibration as well as some megabytes for user data.
> 

We (Cherry/Theobroma) have some modified behavior for bootstd to favor 
booting from the same storage medium as U-Boot proper (so NOT 
necessarily what is reported by /chosen/bootsource) instead of 
defaulting to boot from SD card first and then eMMC. See 
https://elixir.bootlin.com/u-boot/v2025.01/source/board/theobroma-systems/common/common.c#L11. 
So I very much understand your usecase :)

FYI, U-Boot SPL favors for loading U-Boot proper the same storage medium 
as was used by the BootROM (so that would be the same as reported by 
/chosen/bootsource here!) and this is modeled with the "same-as-spl" 
string in /chosen/u-boot,spl-boot-order property. I was thinking of 
adding a "same-as-proper" boot target for bootstd so I can remove my 
custom setup_boottargets. This was also somehow asked by at least one 
person over IRC some months ago, so maybe I'm not the only one with this 
usecase :) Haven't spent time looking into it and I may never have time 
to do so, take this as a brain dump here :)


> To satisfy both needs, I reckon we would need to formally introduce an
> OpenWrt boot-method to U-Boot, and then U-Boot could leave a mark in
> /chosen where the uImage.FIT was loaded from, independently of the
> BootROM which may differ?
> 

Yes, I don't think both could or should be represented by the same property.

To sum up, specifically for U-Boot:

BootROM loading VPL/TPL/SPL -> /chosen/bootsource (what this patch is 
suggesting)
VPL loading SPL -> don't know, haven't checked the VBE series yet :( 
maybe Simon has something in mind?
SPL loading U-Boot proper -> /chosen/u-boot,spl-boot-device
U-Boot proper loading kernel/fit/... -> nothing at the moment

Forgot to thank you for sharing what OpenWRT does :)

Cheers,
Quentin

Re: [PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Quentin,

On Thu, 20 Feb 2025 at 08:55, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> On 2/20/25 4:22 PM, Daniel Golle wrote:
> > On Thu, Feb 20, 2025 at 04:04:27PM +0100, Quentin Schulz wrote:
> >> Hi Daniel,
> >>
> >> On 2/15/25 4:13 PM, Daniel Golle wrote:
> >>> Hi Quentin,
> >>>
> >>> On 10 February 2025 16:25:23 UTC, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >>>> [...]
> >>>> What I can say from glancing at the code is that for Rockchip they do the following:
> >>>>
> >>>> Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The mapping between what the ROM says the device is vs what it is in the DT is done in their Barebox-specific DT via this custom prop in /chosen:
> >>>>
> >>>> barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  # à-la /aliases
> >>>>
> >>>> This gets read and resolved and then inserted as
> >>>>
> >>>> /chosen/bootsource = "/some/path"
> >>>>
> >>>> into the kernel DT.
> >>>
> >>> We are doing something quite similar downsream at openwrt.org for MediaTek router SoCs, see for example:
> >>>
> >>> https://github.com/openwrt/openwrt/blob/main/package/boot/uboot-mediatek/patches/310-mt7988-select-rootdisk.patch
> >>>
> >>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi#L32
> >>>
> >>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso#L60
> >>>
> >>>
> >>> Of course we could use the standard "bootsource" property instead, but having a way to reference the volume or partition used as rootfs instead of just passing a referencd to a physical device is advantagous...
> >>>
> >>
> >> If I understood correctly, your prebuilt DT would have
> >>
> >> / {
> >>      chosen {
> >>          rootdisk-emmc = <&rootfs_in_emmc>;
> >>          rootdisk-nor = <&rootfs_in_nor>;
> >>          rootdisk-sd = <&rootfs_in_sd>;
> >>          rootdisk-spim-nand = <&rootfs_in_ubi>;
> >>      };
> >> };
> >>
> >> and then at runtime you would populate /chosen/rootdisk property with the
> >> "rootdisk-<medium>" string with <medium> matching whatever the BootROM
> >> reports. I assume the goal is to somehow make sure that the rootfs is loaded
> >> from the same storage medium as the one used by the BootROM to load the
> >> first stage bootloader?
> >>
> >> Can you confirm I did get that right?
> >
> > Yes, that's more or less correct. It's to point Linux to the device or
> > partition of the uImage from which U-Boot has loaded the Linux kernel.
> >
> > Note that for OpenWrt we prefer to store the uImage.FIT inside a raw
> > block or flash partition, or UBI volume, rather than as a file inside a
> > filesystem.
> >
> > This information is then used for two things:
> >
> >   - Mount the root filesystem
> >     We use a read-only squashfs which is part of the uImage.FIT, it essentially
> >     has the same purpose of an initramfs on other distributions, but mounting
> >     squashfs is much faster then decompressing the whole initramfs at once, and
> >     it doesn't need to remain in RAM permanently.
> >
> >   - Know where an updated uImage.FIT should be written to.
> >
>
> OK, so everything in a FIT image and you store the location and storage
> medium where it was loaded from so that you can update it. Makes sense.
>
> I guess we could have bootstd/bootmeths populate another property that
> specifies which medium and partition was used to load the kernel/FDT and
> initramfs. I don't have much experience with that aside from
> extlinux.conf and that wouldn't be appropriate I believe especially if
> you used root=PARTLABEL= or a UUID in your kernel command line as there
> could be multiple ones with the same there (e.g. we have the exact same
> image you can flash on SD card and eMMC and the probe order isn't
> deterministic in the kernel I believe).
>
> Don't want to get sidetracked too far though, I don't think it is
> incompatible with or related to /chosen/bootsource usage?
>
> >>
> >> I was specifically NOT aiming /chosen/bootsource to represent the storage
> >> medium used to load the kernel or rootfs, but rather the medium that was
> >> used by the BootROM to load the first stage of the bootloader that is
> >> user-flashable/uploadable.
> >>
> >> You could very well decide to load/mount your rootfs from SD even if the
> >> BootROM loaded the first stage bootloader from SPI-NOR. This property is
> >> about representing the latter, not the former and not merging the meaning of
> >> both into one.
> >
> > Of course, especially for general purpose Linux which would not fit into
> > NOR flash that's the only option.
> >
> > In case of OpenWrt we usually do want to load kernel (and rootfs) from
> > the same device also used by the BootROM for booting. OpenWrt can easily
> > fit onto 16 MiB of NOR flash, including bootloader, EEPROM for MAC
> > addresses and WiFi calibration as well as some megabytes for user data.
> >
>
> We (Cherry/Theobroma) have some modified behavior for bootstd to favor
> booting from the same storage medium as U-Boot proper (so NOT
> necessarily what is reported by /chosen/bootsource) instead of
> defaulting to boot from SD card first and then eMMC. See
> https://elixir.bootlin.com/u-boot/v2025.01/source/board/theobroma-systems/common/common.c#L11.
> So I very much understand your usecase :)
>
> FYI, U-Boot SPL favors for loading U-Boot proper the same storage medium
> as was used by the BootROM (so that would be the same as reported by
> /chosen/bootsource here!) and this is modeled with the "same-as-spl"
> string in /chosen/u-boot,spl-boot-order property. I was thinking of
> adding a "same-as-proper" boot target for bootstd so I can remove my
> custom setup_boottargets. This was also somehow asked by at least one
> person over IRC some months ago, so maybe I'm not the only one with this
> usecase :) Haven't spent time looking into it and I may never have time
> to do so, take this as a brain dump here :)
>
>
> > To satisfy both needs, I reckon we would need to formally introduce an
> > OpenWrt boot-method to U-Boot, and then U-Boot could leave a mark in
> > /chosen where the uImage.FIT was loaded from, independently of the
> > BootROM which may differ?
> >
>
> Yes, I don't think both could or should be represented by the same property.
>
> To sum up, specifically for U-Boot:
>
> BootROM loading VPL/TPL/SPL -> /chosen/bootsource (what this patch is
> suggesting)
> VPL loading SPL -> don't know, haven't checked the VBE series yet :(
> maybe Simon has something in mind?
> SPL loading U-Boot proper -> /chosen/u-boot,spl-boot-device
> U-Boot proper loading kernel/fit/... -> nothing at the moment
>
> Forgot to thank you for sharing what OpenWRT does :)

Thanks for all the details. It seems fine to me. Perhaps you could
copy some of the text above into your binding so there is more detail?

Regards,
Simon