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

[Tom Rini]

On Tue, Aug 12, 2025 at 04:26:14PM +0200, Quentin Schulz wrote:
> Hi Tom,
> 
> On 8/12/25 4:15 PM, Tom Rini wrote:
> > On Tue, Aug 12, 2025 at 03:15:00PM +0200, Quentin Schulz wrote:
> > > 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?
> > 
> > Ah good, OK. So should this be in v2025.10 or will v2026.01 be OK? It's
> > small enough I'm OK taking it now.
> > 
> 
> I'm fine with v2026.01, there's no hurry for me as I can carry it in my
> downstream forks until it's merged upstream.
> 
> So, up to you!

OK, thanks. I'll put it in -next soon then for v2026.01.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250812/78cb00c1/attachment.sig>