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
When building without DHCP/PXE configurations (NET disabled),
compilation errors may occur due to mismatched bootargs.
Ensure bootargs related to DHCP/PXE are not enabled if the
corresponding commands are disabled.
include/config_distro_bootcmd.h:443:9: error: expected ‘}’ before
‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’
443 | BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Chanho Park <parkch98@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The get_timer function returns an unsigned long which may be calculated
from the ARM system counter. This counter is reset only on a cold reset.
U-boot divides this counter down to a 1000 Hz counter that will cross
the 32bit barrier after a bit more than 49 days. Assigning the value to
an unsigned int will truncate it on 64bit systems.
Passing this truncated value back to the get_timer function will return
a very large value that is certainly larger than the timeout and so will
go down the error path and besides stopping U-Boot will lead to messages
like
"SPI: QSPI is still busy after poll for 5000 ms."
Signed-off-by: Ronald Wahl <ronald.wahl@legrand.com>
Cc: Vignesh R <vigneshr@ti.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
For a sandbox implementation, where code size is no object, it makes sense
to use the full bootstd drivers to load images.
For real boards, running from SRAM, this adds quite a bit of overhead.
Add a way to load the next phase using just the underlying storage
driver, to reduce code size. For now, only MMC is supported.
Change the log_debug() to show the load address and size in a more
neutral way, rather than suggesting that the load has already happened.
Signed-off-by: Simon Glass <sjg@chromium.org>
VBE needs to load different images from a FIT depending on the xPL phase
in use. The IH_PHASE value is used to select the image to load.
Add the required logic to handle this. For compatibility with the
SPL-loader driver, fill out a struct spl_image_info with the details
needed to boot the next phase.
This is good enough for VBE-simple but ABrec will need the full set of
bootstd features. So add a USE_BOOTMETH define to control this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add FDT support so that this can be copied down in memory after loading
and made available to the new image.
Signed-off-by: Simon Glass <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>
This function will be used by the relocating jumper too, so add a
typedef to the header file to avoid mismatches.
Signed-off-by: Simon Glass <sjg@chromium.org>
In many cases the FIT includes a devicetree. Add support for loading
this into a suitable place in memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases only the 'loadable' property is present in the FIT.
Handle this by loading the first such image.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no guarantee that an FIT image starts on a block boundary. When
it doesn't, the image starts part-way through the first block.
Add logic to detect this and copy the image down into place.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the VBE implementation is limited to sandbox only. Adjust the
call to fit_image_load() to remove this limitation.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is convenient to use TEXT_BASE as a place to hold the FIT header, but
this does not work in VPL, since SDRAM is not inited yet.
Allocate the memory instead. Ensure the size is aligned to the media
block-size so that it can be read in directly. Improve the
error-checking for blk_read() and add some more debugging.
Keep the existing TEXT_BASE mechanism in sandbox to avoid an
'Exec format error' when trying to run the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Loading a FIT is useful for other VBE methods, such as ABrec. Create a
new function to handling reading it.
Signed-off-by: Simon Glass <sjg@chromium.org>
VBE is currently quite careful with function arguments because it is
used in VPL which cannot be updated after manufacture. Bugs can cause
security holes.
Unfortunately this adds to code size.
In several cases we are reading values from a devicetree which is part
of U-Boot (or at least VPL) and so known to be good. Also, in several
places, getting bad values does not matter.
So change a few checks to assert() to reduce code size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass the private data instead of the device, to help the compiler
optimise better. This saves 16 bytes of code on pinecube (rk3288)
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass a struct udevice instead of the descriptor structure, since this is
the native argument for blk_read()
Signed-off-by: Simon Glass <sjg@chromium.org>
Move a few things into a new, common header file so that vbe-simple can
share code with the upcoming abrec.
Put struct simple_nvdata in it and rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should not be using the old blk_d...() interface, is only there to
aid migration to driver model.
Move to blk_read() instead.
Changes in v2:
- Split patch into several pieces
Signed-off-by: Simon Glass <sjg@chromium.org>
Replace delay_ns by delay_us which is the field name used into
struct cyclic_info.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
On 32 bits platforms, timer_get_us() returns an unsigned long which
is a 32 bits. timer_get_us() wraps around every 72 minutes
(2 ^ 32 / 1000000 =~ 4295 sec =~ 72 min).
So the test "if time_after_eq64(now, cyclic->next_call)" is no more
true when cyclic->next_call becomes above 32 bits max value (4294967295).
At this point after 72 min, no more cyclic function are
executed included watchdog one.
Instead of using timer_get_us(), use get_timer_us() which returns a
uint64_t, this allows a rollover every 584942 years.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Move differences in DT files between upstream Linux DT and U-Boot DT to
mt7629-rfb-u-boot.dtsi.
Remove old copies of mt7629-related clock bindings, .dts, and .dtsi files.
Update defconfig to switch the whole mt7629 SoC to use OF_UPSTREAM.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The clock definitions in mt7629-clk.h indicate that CLK_PERIBUS_SEL is the
first element in the pericfg clock tree and also serves as a clock mux,
unlike other clocks belonging to the clock gate in pericfg.
This make the clock consumer get a wrong clock gate during request a clock
from <&pericfg>.
Since CLK_PERIBUS_SEL clock is not required in U-Boot, add a clock gate
offset for the pericfg clock tree to resolve this problem.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Enable rudimentary nand read/write capability.
Changes in v2:
- New patch in series added enabling of nand functionality
Signed-off-by: david regan <dregan@broadcom.com>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Anand Gore <anand.gore@broadcom.com>
Update bcmbca dts to current nand node naming convention.
Changes in v2:
- Removed addition of nand-on-flash-bbt parameter
Signed-off-by: david regan <dregan@broadcom.com>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Anand Gore <anand.gore@broadcom.com>
OSPI flash writing was broken on am62x SKs as the OSPI flash device has a
256k sector size but was set to 20k. This breaks OSPI flash writes because
the current implementation of the SF DFU backend requires that the DFU data
buffer size be the same as the sector erase size, and the USB DFU config
fragment (for both A53 and R5) reduced the size of the DFU data buffer,
presumably so that it can fit into SPL's much smaller heap.
Change the SYS_DFU_DATA_BUF_SIZE to the erase sector size, which still fits
within the post-relocation heap size in SPL.
Fixes: dfc2dff5a8 ("configs: am62x_evm_*: Enable USB and DFU support")
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When using the ACPI tables supplied by QEMU, we don't need to build the
FADT and MADT tables in U-Boot.
This patch avoids a build failure
make qemu-riscv64_smode_defconfig acpi.config
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_fadt':
lib/acpi/acpi_table.c:265:(.text.acpi_write_fadt+0x15c):
undefined reference to `acpi_fill_fadt'
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_madt':
lib/acpi/acpi_table.c:294:(.text.acpi_write_madt+0x52):
undefined reference to `acpi_fill_madt'
Fixes: f5f7962091 ("acpi: x86: Write FADT in common code")
Fixes: 4a3fc0f525 ("acpi: x86: Move MADT to common code")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tom Rini <trini@konsulko.com> says:
One problem we have today is how the BLK symbol is set and used in
Kconfig files. Part of the challenge is that we use it as a gating
symbol for "we have a block device" and also for "enable block device
library code". What this series does is move to always use "select BLK"
by block drivers (a few were and a few others had it the inverse) and
then "depends on BLK" for functionality that needs a block device
present. The end result of this series is that a number of platforms
which had disabled EFI_LOADER now don't ask for it (they have no block
device) and espresso7420 has a regression about MMC support fixed. With
v2 of this I've picked up the review tags from v1 and also reworded the
body of the commit in the first patch.
Link: https://lore.kernel.org/r/20250115012322.215243-1-trini@konsulko.com
Now that block drivers are all selecting the BLK symbol, there's no need
for other options to be select'ing BLK so that other required
functionality can be enabled. Remove these places.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
In the case of MTD_BLOCK and UBI_BLOCK they should be select'ing BLK as
they provide block device functionality and not depending on some other
block device already being enabled too (as is the typical case).
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The BLK symbol has a few meanings, one of which is that it controls the
driver model portion of a "block device". Rather than having this hidden
symbol be "default y if ..." it should be select'd by the various block
subsystems. Symbols such as PVBLOCK which already select'd BLK are
unchanged".
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
In reworking the BLK usage in Kconfig, I found there's a few issues with
EFI_LOADER=y and BLK=n. In general, we can easily say that
lib/efi_loader/efi_file.c also should only be built with CONFIG_BLK.
That however leaves the bootmgr code, eficonfig code and then parts of
efi_device_path.c, efi_boottime.c and efi_setup.c which functionally
depend on BLK. While these calls can be if'd out, I'm unsure if the
result is usable. So rather than leave that buildable and imply that it
is, I'm leaving that combination non-buildable and commenting that
EFI_LOADER depends on BLK in the Kconfig currently.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point in time, DM is always enabled. So if MMC is enabled, it
should select DM_MMC. No drivers need to depend on DM_MMC being enabled
now, so remove that from dependency lists. This now means that a number
of platforms which select'd DM_MMC need to select MMC instead. This also
fixes a migration problem with espresso7420 in that MMC is built again
with the platform.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point in time, we know that with the MMC symbol enabled we will
always also have the BLK symbol enabled, so we do not need to list that
as a dependency for MMC drivers.
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Delete tifs DT node as part of fixup.
TISCI API reported msmc_size, does not include 64KB reserved size for
tifs aka MSMC comms memory, see documentation[0].
As part of fixup, original code uses TISCI API reported msmc_size as
size for SRAM DT node.
tifs node is similar to l3-cache, which should hold address above
msmc_size, and should be deleted before passing control to OS.
[0] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html?highlight=msmc#tisci-msg-query-msmc
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Include k3_rproc.env to access rproc boot commands and specify rproc
firmware names for adding remoteproc support in J722S SoCs.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
The default value for the mux to select the parent clock,
AUDIO_REFCLK1_CTRL_CLK_SEL is '11111' (31) but the mux input for 31
is marked as 'Reserved' so the ti-sci-clk call for get-parent fails.
Mark it to a valid value, '11100' (28) for MAIN_PLL4_HSDIV2_CLKOUT
to get rid of the linux failures during boot-time like:
"[ 1.573193] ti-sci-clk 44083000.system-controller:clock-controller:
get-parent failed for dev=157, clk=34, ret=-19"
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Tom Rini
Chanho ParkandTom Rini
Ronald WahlandTom Rini
Simon GlassandTom Rini
Patrice ChotardandStefan Roese
Patrick RudolphandTom Rini
Sam ShihandTom Rini
david reganandTom Rini
Jonathan HumphreysandTom Rini
Heinrich SchuchardtandTom Rini
Udit KumarandTom Rini
Beleswar PadhiandTom Rini
Jayesh ChoudharyandTom Rini