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

Hi Simon,

On 6/10/25 4:26 PM, Simon Glass wrote:
> On Mon, 5 May 2025 at 09:34, Quentin Schulz <[email protected]> wrote:
>>
>> From: Quentin Schulz <[email protected]>
>>
>> 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.
>>
>> In cases where a boot program is split into multiple stages (like
>> U-Boot), it only represents the device that was used to load the very
>> first stage (in case of U-Boot, VPL/TPL/SPL whichever is executed first)
>> and not any of the later stages (in case of U-Boot, TPL/SPL/proper) or
>> any client program. They may match, but they may not and this property
>> is meant to only represent the device used for loading the very first
>> stage.
>>
>> I have a board running U-Boot which currently has 9 boot scenarios
>> (eMMC/SD/SPI-NOR for the first stage, eMMC/SD/SPI-NOR for the next
>> stages; not counting USB loading yet, which would make it a few more). I
>> cannot force the BootROM of this board to select a specific device aside
>> from erasing the other media.
>> The only way to identify which device was used for the first stage is to
>> parse U-Boot first stage console output or add some custom logic for my
>> board. To validate that a new version of the bootloader works, including
>> the fallback mechanisms, I need to make sure the BootROM loads the first
>> stage from the expected device otherwise I may have false positives.
>> This would be useful for automated testing.
>>
>> I could also very well see this being used to identify where the first
>> stage of the boot program is stored (which may differ from where the
>> later stages are! that's the case for U-Boot proper for example!) to be
>> able to update it from a client program.
>>
>> Note that Barebox has been using this property for a while already, with
>> this very content[1].
>>
>> This is chosen as a string so that it matches other properties in
>> /chosen (e.g. stdout-path) as well as allows for extending it, in case
>> one needs to provide additional information (e.g. HW boot partition for
>> eMMC, a specific disk on an AHCI controller, a specific USB device on
>> a USB bus, etc.).
>>
>> [1] https://lore.kernel.org/u-boot/[email protected]/
>>
>> Signed-off-by: Quentin Schulz <[email protected]>
>> ---
>> 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.
>> ---
>> Changes in v2:
>> - added usecases, non-usecases and increased verbosity of the definition
>>    of the property name as requested by Simon,
>> - Link to v1: https://lore.kernel.org/r/[email protected]
>> ---
>>   source/chapter3-devicenodes.rst | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
> 
> Reviewed-by: Simon Glass <[email protected]>
> 
> Does this need to go into the schema as well?
> 

Considering this should ever only be programmatically set at runtime, 
I'm not sure this is necessary?

But taking into account that u-boot,version is part of the schema, I 
guess this could too :)

Cheers,
Quentin