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

Hi all,

On 7/25/25 11:23 AM, Quentin Schulz wrote:
> 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://eur02.safelinks.protection.outlook.com/? 
>>>>> url=https%3A%2F%2Flore.kernel.org%2Fu- 
>>>>> boot%2F0066fcc2-3431-48be-8dc2-00ea7e2550c2%40pengutronix.de%2F&data=05%7C02%7Cquentin.schulz%40cherry.de%7C62bee489a30342bdfe1108dda833a49d%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638851661931307638%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cZXaYVfIc3%2BN6VahJmAtzUzut0VjG9LiUZNeLWKxbHQ%3D&reserved=0
>>>>>
>>>>> 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://eur02.safelinks.protection.outlook.com/? 
>>>>> url=https%3A%2F%2Flore.kernel.org%2Fr%2F20250205-bootsource- 
>>>>> v1-1-95f4ba69ac27%40cherry.de&data=05%7C02%7Cquentin.schulz%40cherry.de%7C62bee489a30342bdfe1108dda833a49d%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638851661931346429%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c3xFGwKD0uapQ4%2B%2Fk15t5Yfu3Dr4JgZGyJGYpountT8%3D&reserved=0
>>>>> ---
>>>>>    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
> 

The above (dt-schema part) was merged August 4th, 2025. Can this patch 
here be merged into the spec please? Or is there additional review to 
share if it isn't ready to merge?

Thanks!
Quentin