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

Hi all,

On 6/10/25 5:29 PM, Rob Herring wrote:
> On Tue, Jun 10, 2025 at 9:52 AM Quentin Schulz <[email protected]> wrote:
>>
>> 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 :)
> 
> Validation can and does run on booted systems, so yes.
> 

See https://github.com/devicetree-org/dt-schema/pull/169

Cheers,
Quentin