When VBE operates within VPL it does not want the FDT to be changed.
Provide a way to disable this feature.

Move the FIT_IMAGE_TINY condition out of spl_fit_record_loadable() so
that both conditions are together. This makes the code easier to
understand.

Replace the existing fit_loaded member, which is no-longer used.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add support for moving from TPL->VPL->SPL so that the VPL build can fit
properly into the boot flow.

Use #ifdefs to avoid creating unwanted symbols which Binman would then
try (and perhaps fail) to provide.

Add debugging to indicate the next phase.

Signed-off-by: Simon Glass <sjg@chromium.org>

Allow a linker script to be provided for VPL as it is for other U-Boot
phases.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present the simple FIT-loader always loads images, ignoring whether
they are intended for the next phase or not.

VBE packages up several images in the same FIT, some destined for VPL
and some for SPL. Add logic to check the phase before loading the
image. Return -EPERM in that case and handle it gracefully.

Fix a unnecessary re-computation of read_offset while here.

Signed-off-by: Simon Glass <sjg@chromium.org>

The size of some malloc() fields has reduced on 64-bit machines, but
the spl_reloc code was not updated. Fix this to avoid a compiler
warning.

Also update for the new xPL naming.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Simon Glass <sjg@chromium.org> says:

The current UPL spec[1] has been tidied up and improved over the last
year, since U-Boot's original UPL support was written.

This series includes some prerequisite patches needed for the real UPL
patches. It is split from [2]

[1] https://github.com/UniversalPayload/spec/tree/3f1450d
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=*

Link: https://lore.kernel.org/r/20250111000029.245022-1-sjg@chromium.org

This function can only be used with FITs that use embedded data. Rename
it so this is clear.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Simon Glass <sjg@chromium.org> says:

This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on introducing a relocating
SPL-loader so that VBE can run in the limited amount of SRAM available
on many devices.

Another minor new feature is support in VBE for specifying the image
phase when loading from a FIT. This allows a single FIT to include
images for several boot phases, thus simplifying image-creation.

One lingering niggle in this series is that it has a different code path
for sandbox, since it does not support the relocating jump. It should be
possible to resolve this with additional work, but I have not attempted
this so far.

For v2, I have split the first patch into 5 pieces, to make it easier to
see the code-size impact, plus added a few tweaks to reduce code size.

Again, only MMC is supported so far.

Looking ahead, series G will have some more plumbing and H some rk3399
pieces. That should be enough to complete these feature.

Here is a run in my lab, with the VBE ABrec bootmeth. You can see that
VPL runs before memory is set up. SPL sets up memory and can be upgraded
in the field reliably.

$ ub-int vbe
Building U-Boot in sourcedir for rk3399-generic
Bootstrapping U-Boot from dir /tmp/b/rk3399-generic
Writing U-Boot using method rockchip

U-Boot TPL 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58)
Trying to boot from vbe_abrec
load: Firefly-RK3399 Board
   Using 'config-3' configuration
   Trying 'image-vpl' firmware subimage
   Using 'config-3' configuration
   Trying 'fdt-3' fdt subimage

U-Boot VPL 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58)
Trying to boot from vbe_abrec
load: Firefly-RK3399 Board
Starting with empty state
VBE: Firmware pick A at 800000
   Using 'config-3' configuration
   Trying 'spl' firmware subimage
   Using 'config-3' configuration
   Trying 'fdt-3' fdt subimage
Channel 0: DDR3, 800MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: DDR3, 800MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride

U-Boot SPL 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58 -0700)
Trying to boot from vbe_abrec
load: Firefly-RK3399 Board
VBE: Firmware pick A at 900000
load_simple_fit: Skip load 'atf-5': image size is 0!
Relocating bloblist ff8eff00 to 100000: done
ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

U-Boot 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58 -0700)

SoC: Rockchip rk3399
Reset cause: POR
Model: Firefly-RK3399 Board
DRAM:  4 GiB (effective 3.9 GiB)
Core:  314 devices, 33 uclasses, devicetree: separate
MMC:   mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Model: Firefly-RK3399 Board
Net:   PMIC:  RK808
eth0: ethernet@fe300000

starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus usb@fe900000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 1 USB Device(s) found
scanning bus usb@fe900000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0

Link: https://lore.kernel.org/r/20250116012723.2820301-1-sjg@chromium.org

This is fairly easy to use. The SPL loader sets up some fields in the
spl_image_info struct and calls spl_reloc_prepare(). When SPL is ready
to do the jump it must call spl_reloc_jump() instead of jump_to_image().

Add this logic.

Signed-off-by: Simon Glass <sjg@chromium.org>

When one xPL phase wants to jump to the next, the next phase must be
loaded into its required address. This means that the TEXT_BASE for the
two phases must be different and there cannot be any memory overlap
between the code used by the two phases. It also can mean that phases
need to be moved around to accommodate any size growth.

Having two xPL phases in SRAM at the same time can be tricky if SRAM
is limited, which it often is. It would be better if the second phase
could be loaded somewhere else, then decompressed into place over the
top of the first phase.

Introduce a relocating jump for xPL to support this. This selects a
suitable place to load the (typically compressed) next phase, copies
some decompression code out of the first phase, then jumps to this code
to decompress and start the next phase.

This feature makes it much easier to support Verified Boot for Embedded
(VBE) on RK3399 boards, which have 192KB of SRAM.

Signed-off-by: Simon Glass <sjg@chromium.org>