On Wed, Jul 30, 2025 at 02:03:18PM +0200, Quentin Schulz wrote: > From: Quentin Schulz <quentin.sch...@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.sch...@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-5a315d9bf...@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. -- Tom
signature.asc
Description: PGP signature
