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

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

[Stefan Monnier]

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

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

[E Shattow]

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

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

[Carlo Caione]

On Thu Aug 20, 2026 at 8:50 PM CEST, 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.

Hi Stefan,

Thanks for the question. E Shattow's reply describes the general SPL
constraints well. The detail specific to this series is that "if SPL
works, U-Boot proper also works" assumes that U-Boot proper is already
available from storage that SPL can read and this is not always true.

More specifically the use case we are trying to tackle here is initial
provisioning or recovery of blank or corrupted persistent storage:

Boot ROM -> host-loaded bootstrap -> fastboot -> provision storage

At that point U-Boot proper may not exist on the device yet; it may be
one of the images that fastboot is expected to write on the storage
(through SPL indeed).

It is possible to include U-Boot proper in the host-loaded bootstrap and
use its existing fastboot implementation. That is a valid approach and
is preferable where the Boot ROM download limit and memory budget allow
it. But it is not always possible: some platforms (like the one we
are enabling) impose a strict size limit on the bootstrap, or only
provide enough early memory for the DDR initialization code and (small)
SPL-sized payload.

Fastboot in SPL provides the smaller alternative for those platforms.
It is intended as a provisioning endpoint, not as part of the normal
installed boot path. Once storage has been provisioned, the usual SPL-
to-U-Boot-proper flow remains unchanged.

Hope this clarify the background of this work,

Cheers!

--
Carlo Caione

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

[Stefan Monnier]

Carlo Caione [2026-08-21 09:05:37] wrote:
> It is possible to include U-Boot proper in the host-loaded bootstrap
> and use its existing fastboot implementation. That is a valid approach
> and is preferable where the Boot ROM download limit and memory budget
> allow it.

Right, that's the situation I'm familiar with.

> But it is not always possible: some platforms (like the one we are
> enabling) impose a strict size limit on the bootstrap, or only provide
> enough early memory for the DDR initialization code and (small)
> SPL-sized payload.

I associate "fastboot" with the Android nebula, so I find it hard to
imagine a machine with enough resources to run Android yet with a small
enough boot memory for U-Boot not to fit into it.  I assume the SPL is
pre-installed in some dedicated boot memory (SPI NOR?) whereas the main
storage is left uninitialized during production.  And the NOR flash is
so small that it can't even accommodate a proper U-Boot?

I wonder how many cents it saves the manufacturer (e.g. compared to
having a slightly bigger NOR, or not having the NOR at all and
pre-installing U-Boot on the main storage) 🙁

Anyway, this is clearly getting offtopic.  Thanks for the answer.


=== Stefan

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

[Carlo Caione]

On Fri Aug 21, 2026 at 2:21 PM CEST, Stefan Monnier wrote:
> Carlo Caione [2026-08-21 09:05:37] wrote:
>> It is possible to include U-Boot proper in the host-loaded bootstrap
>> and use its existing fastboot implementation. That is a valid approach
>> and is preferable where the Boot ROM download limit and memory budget
>> allow it.
>
> Right, that's the situation I'm familiar with.
>
>> But it is not always possible: some platforms (like the one we are
>> enabling) impose a strict size limit on the bootstrap, or only provide
>> enough early memory for the DDR initialization code and (small)
>> SPL-sized payload.
>
> I associate "fastboot" with the Android nebula, so I find it hard to
> imagine a machine with enough resources to run Android yet with a small
> enough boot memory for U-Boot not to fit into it.  I assume the SPL is
> pre-installed in some dedicated boot memory (SPI NOR?) whereas the main
> storage is left uninitialized during production.  And the NOR flash is
> so small that it can't even accommodate a proper U-Boot?
>
> I wonder how many cents it saves the manufacturer (e.g. compared to
> having a slightly bigger NOR, or not having the NOR at all and
> pre-installing U-Boot on the main storage) 🙁

Hi Stefan,

Just one clarification: SPL is not pre-installed in NOR here. The
Boot ROM downloads a transient bootstrap over USB into a fixed-size
on-chip memory window. That downloaded bootstrap then contains the DDR
initialization code and SPL, while the eMMC may be completely blank.

Also fastboot is used only as the provisioning protocol; it does not
imply Android.

For more info about the SPL on this kind of platforms you can also look
at [0], there is some documentation about this in there.

> Anyway, this is clearly getting offtopic.  Thanks for the answer.

Thanks for the discussion :)

Cheers,

[0] https://lore.kernel.org/all/20260814-ccaione-upstream-mt8390-spl-v4-0-f4f92978a79e@baylibre.com/

--
Carlo Caione

[PATCH v4 0/5] Add fastboot to SPL

[Carlo Caione]

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.

This series makes USB fastboot available as an opt-in SPL service,
including MMC partition flashing and Android sparse images. The interface
is kept deliberately narrower in SPL: it does not support the boot command
or filesystem probing, and reboot support remains platform-dependent.

The first four patches separate the generic preparation from SPL
enablement. They factor out the USB session runner, route USB reboot
through the common handler, make shared fastboot configuration phase-aware,
and add phase-aware sparse-image support. The final patch then contains the
SPL-specific Kconfig, gadget behavior, and documentation.

No fastboot code or supporting library is added to SPL when SPL_FASTBOOT is
disabled, so the feature has no size cost for existing SPL builds.

---
Changes in v4:
- Drop RFC status.
- Make the USB fastboot helper and gadget build rules phase-aware.
- Use a separate command table for the SPL-supported command subset.
- Document the commands available in SPL.
- Apply the requested Makefile, annotation and preprocessor cleanups.
- Link to v3: https://patch.msgid.link/20260731-ccaione-upstream-spl-fastboot-v3-0-dbea3ff4529e@baylibre.com

Changes in v3:
- Rename the USB session helper to fastboot_usb_run().
- Initialize UDP and TCP sessions in their transport helpers.
- Remove a redundant USB session return assignment.
- Collect the Reviewed-by tag.
- Link to v2: https://patch.msgid.link/20260722-ccaione-upstream-spl-fastboot-v2-0-2ba3f71c42bc@baylibre.com

Changes in v2:
- Split the common USB session runner into a prerequisite patch.
- Route USB reboot through the common fastboot handler separately.
- Split phase-aware fastboot configuration and build rules.
- Split phase-aware Android sparse-image support.
- Keep SPL-specific behavior in the final patch.
- No functional change from v1.
- Link to v1: https://patch.msgid.link/20260719-ccaione-upstream-spl-fastboot-v1-1-c9bab5b0ba72@baylibre.com

---
Carlo Caione (5):
      fastboot: factor out the USB session runner
      fastboot: use the common handler for USB reboot
      fastboot: make shared configuration checks phase-aware
      image: sparse: add phase-aware SPL support
      fastboot: add SPL support

 cmd/fastboot.c                  | 53 +++-------------------
 doc/android/fastboot.rst        | 31 +++++++++++++
 drivers/Makefile                |  2 +-
 drivers/fastboot/Kconfig        | 92 +++++++++++++++++++++++++++++++++++++-
 drivers/fastboot/Makefile       |  9 ++--
 drivers/fastboot/fb_block.c     |  9 ++--
 drivers/fastboot/fb_command.c   | 97 ++++++++++++++++++++++++++++++++---------
 drivers/fastboot/fb_common.c    | 23 +++++++++-
 drivers/fastboot/fb_getvar.c    | 19 +++++---
 drivers/fastboot/fb_mmc.c       | 36 +++++++--------
 drivers/fastboot/fb_usb.c       | 66 ++++++++++++++++++++++++++++
 drivers/usb/gadget/Makefile     |  2 +-
 drivers/usb/gadget/f_fastboot.c |  6 ++-
 include/fastboot.h              | 10 +++++
 lib/Kconfig                     | 11 +++++
 lib/Makefile                    |  3 +-
 lib/image-sparse.c              |  2 +-
 17 files changed, 360 insertions(+), 111 deletions(-)
---
base-commit: 527115ef6783cec49e5610c523c124b399011361
change-id: 20260718-ccaione-upstream-spl-fastboot-14fa2b6b2b64

Best regards,
--  
Carlo Caione <ccaione@baylibre.com>