Re: [PATCH v4 0/5] Add fastboot to SPL

Hi Stefan,

On 8/20/26 11:50, Stefan Monnier wrote:
> Carlo Caione [2026-08-20 20:08:24] wrote:
>> Some recovery and initial-provisioning flows need a standard host protocol
>> before usable firmware is available in persistent storage. U-Boot already
>> provides fastboot, but the implementation can currently be started only
>> from the U-Boot-proper command line.
> 
> I'm curious.  In my limited exposure to U-Boot, I got the impression that
> the split between SPL and U-Boot proper is mostly a "technical detail",
> usually mostly hidden from those who install it onto a device: you just
> take the combined U-Boot + SPL image and write it at the appropriate
> offset on the relevant device.  And usually if SPL works, U-Boot
> also works.
> 
> So a bit like Jonas in the recent "hotkey in SPL" patch for rockchip
> SoCs, I'm curious why/when we'd want to add to SPL functionality already
> supported from U-Boot.
> 
> 
> === Stefan
> 

The purpose of SPL is to have small codesize so that it may run in SoC
on-die memory in the most permissive operational mode, select for
hardware configuration settings (devicetree model), load U-Boot main app
to more plentiful off-die memory (DRAM), and then either jump execution
to U-Boot main app itself or pass execution to a system supervisor that
would run U-Boot main app in some different operational mode.

This requires that U-Boot main app exists somewhere that may be loaded
from (UART serial, SPI flash, MMC storage...) and further complicates
the use of U-Boot SPL as a fast and efficient recovery tool.

If adding fastboot feature to SPL does not balloon the codesize beyond
hardware limits then it is a very interesting feature to enable, indeed.

Sometimes the SPL is not something we control or have insight into. The
vendor may have provided some proprietary SPL via code obscurity or
cryptographic signing or it will be the functionality of some
proprietary on-die firmware IP block. More typically though the on-die
boot ROM has functionality that may include fastboot-alike
functionality, UART loading, and MMC loading capability for transferring
SPL and jumping code execution to that but without initializing DRAM.

Additionally there may be additional firmware for some SoC cores that
require initializing with e.g. realtime operating system for power
management or DSP functions, and that must be done before changing the
operational mode (so before U-Boot main app).

I'm no expert on this but if I get some detail wrong it is not
intentional, much of this confusion was the same for me when I begin to
look at the situation for RISC-V.

-E