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

[Quentin Schulz <quentin.schulz@cherry.de>]

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