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.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.
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
