[PATCH RFC] rockchip: add /chosen/bootsource to U-Boot proper DT

[Quentin Schulz]

Hi Tom,

On 7/30/25 7:24 PM, Tom Rini wrote:
> On Wed, Jul 30, 2025 at 02:03:18PM +0200, Quentin Schulz wrote:
> 
>> From: Quentin Schulz <quentin.schulz at cherry.de>
>>
>> U-Boot typically can be loaded from different storage media, such as
>> eMMC, SD card, SPI flash, 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 BootROM via some proprietary
>> mechanism (some specific address in registers/DRAM for example). For
>> Rockchip, that information is stored in a register
>> (BROM_BOOTSOURCE_ID_ADDR).
>>
>> While we already have the information about which medium was used to
>> load U-Boot proper from SPL (via /chosen/u-boot,spl-boot-device), this
>> new property represents the medium used to load U-Boot first phase
>> (depending on configuration, can be VPL/TPL/SPL) which absolutely may
>> differ from the one used to load U-Boot proper!
>>
>> It would be useful to know which medium was used to load the first phase
>> of U-Boot, for example to check fallback mechanisms (proper loaded from
>> a different medium than first phase) are actually working.
>>
>> For now, this only applies to Rockchip's U-Boot proper DT but could be
>> applied to the kernel's as well and possibly for other architectures or
>> vendors.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
>> ---
>> I have a board (RK3399 Puma) running U-Boot which currently has 9 boot
>> scenarios (eMMC/SD/SPI-NOR for the first phase, eMMC/SD/SPI-NOR for the
>> next phases; 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 phase is to
>> parse U-Boot first phase 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
>> phase from the expected device otherwise I may have false positives.
>> This would be useful for automated testing.
>>
>> Patches pending in the devicetree-spec[1] and dt-schema[2], hence the
>> RFC here.
>>
>> [1] https://lore.kernel.org/devicetree-spec/20250505-bootsource-v2-1-5a315d9bff26@cherry.de/
>> [2] https://github.com/devicetree-org/dt-schema/pull/169
> 
> I am conceptually fine with the changes, but this needs to have the
> schema side approved first, just for the record.
> 

Now merged in the dt-schema (still no news on the spec side though aside 
from a R-b from Simon 2 months ago). Is that good enough or do we need 
to wait on the spec part too?

Cheers,
Quentin