Use this function instead of fit_image_get_emb_data() data, since it
works will FITs that use external data.
Signed-off-by: Simon Glass <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>
We want to encourage people to use an allocated bloblist since it is
more flexible than a fixed one. Make this the default, being sure not to
change existing users.
The unit tests require BLOBLIST_FIXED so add a dependency in the
Makefile to avoid build errors.
All sandbox builds require BLOBLIST_FIXED so make that the default for
sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
Rather than doing autoprobe within the driver model code, move it out to
the board-init code. This makes it clear that it is a separate step from
binding devices.
For now this is always done twice, before and after relocation, but we
should discuss whether it might be possible to drop the post-relocation
probe.
For boards with SPL, the autoprobe is still done there as well.
Note that with this change, autoprobe happens after the
EVT_DM_POST_INIT_R/F events are sent, rather than before.
Link: https://lore.kernel.org/u-boot/20240626235717.272219-1-marex@denx.de/
Signed-off-by: Simon Glass <sjg@chromium.org>
Andrew Goodbody <andrew.goodbody@linaro.org> says:
Picking up a series from Dan Carpenter and applying requested
changes for v2.
I had previously set CONFIG_64BIT for arm64. This patchset does the
same thing for sandbox and x86_64. (Mips and riscv were already
doing it). This CONFIG option is used in the Makefile to determine
if it's a 32 or 64 bit system for the CHECKER.
Makefile
1052 # the checker needs the correct machine size
1053 CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
Link: https://lore.kernel.org/r/20241216180736.1933807-1-andrew.goodbody@linaro.org
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to
static analysis tools.
Introduce CONFIG_SPL_64BIT and select it for architectures other than
x86 with 64 bit builds. Do not select it for x86 builds as x86 uses
a 32 bit SPL.
Ensure that when limits are set they use CONFIG_64BIT for U-Boot
proper and CONFIG_SPL_64BIT for SPL. This is to allow for the 32 bit
SPL build used by x86.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Patch keeps the access to dtb_dt_embedded() within fdtdec API,
by means of new API function introduction. This new function is a
common place for updating appropriate global_data fields for
OF_EMBED case.
Also, the consequence of the patch is movement of '___dtb_dt_*begin'
symbols' declaration from header file, because nobody used symbols
outside the lib/fdtdec.c.
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
fatures are available in VPL.
Link: https://lore.kernel.org/r/20241219182907.2609704-1-sjg@chromium.org
The variable 'ret' is defined twice, which is not intended. This may
have been a local merge error.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 2eefeb6d893 ("spl: Report a loader failure")
U-Boot uses ulong for addresses. It is confusing to use uintptr_t in a
few places, since it makes people wonder if the types are compatible.
Change the few occurences in SPL to use ulong
Signed-off-by: Simon Glass <sjg@chromium.org>
The current check looks only at SPL, but TPL or VPL might have a
different setting. Update the condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current check looks only at SPL, but TPL or VPL might have a
different setting. Update the condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
If a loader returns an error code it is silently ignored. Show a message
to at least provide some feedback to the user.
Signed-off-by: Simon Glass <sjg@chromium.org>
The for() loop ends up being in the code even if the log_debug() does
nothing. Add a condition to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
As the return type is "int" for find_ram_top() function and
returning the "base" which is of phys_addr_t is breaking when the
"base" address is 64-bit. So fix this by updating the return type as
phys_addr_t.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Link: https://lore.kernel.org/r/20241220030742.1745984-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The FIT name in RISC-V Falcon mode should be different from that in
normal boot mode; it is called linux.itb. If the setting is missing
in common/spl, the normal boot file name will be used.
Signed-off-by: Randolph <randolph@andestech.com>
This reverts commit 1fdf53ace13f745fe8ad4d2d4e79eed98088d555, reversing
changes made to e5aef1bbf11412eebd4c242b46adff5301353c30.
I had missed that this caused too much size growth on rcar3_salvator-x.
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
fatures are available in VPL.
Link: https://lore.kernel.org/r/20241207172412.1124558-1-sjg@chromium.org
The variable 'ret' is defined twice, which is not intended. This may
have been a local merge error.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 2eefeb6d893 ("spl: Report a loader failure")
U-Boot uses ulong for addresses. It is confusing to use uintptr_t in a
few places, since it makes people wonder if the types are compatible.
Change the few occurences in SPL to use ulong
Signed-off-by: Simon Glass <sjg@chromium.org>
The current check looks only at SPL, but TPL or VPL might have a
different setting. Update the condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current check looks only at SPL, but TPL or VPL might have a
different setting. Update the condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
If a loader returns an error code it is silently ignored. Show a message
to at least provide some feedback to the user.
Signed-off-by: Simon Glass <sjg@chromium.org>
The for() loop ends up being in the code even if the log_debug() does
nothing. Add a condition to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
As the "peer-hub" property is optional, don't error out just
skip the bind function.
Fixes: 57e30b09fc ("usb: onboard-hub: Bail out if peer hub is already probed")
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patch resolves two kind of bugs, one of which is vulnerability related
to KASLR.
=== Issue briefly ===
Working with FDT (via non-relocated gd::fdt_blob) from inside bootm
command may lead to the reading the garbage instead of FDT nodes. And
this can result in various side-effects depending on DTS nodes, being
parsed during bootm.
But below is my specific story how I faced with this issue due to
MESON_RNG probing failure.
=== Bugs description ===
1) Bug is revealed on:
* configuration below
* U-boot 2024.10 - f919c3a889f ("Prepare v2024.10")
It seems, the following patch is a trigger:
ea955eea4f ("fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled")
Generally, CONFIG_OF_EMBED=y & CONFIG_RNG_MESON=y are the most
valuable ones for reproducing the issue.
```
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
CONFIG_CMD_FDT=y
CONFIG_DEFAULT_FDT_FILE=""
CONFIG_FDT_64BIT=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_CONTROL=y
CONFIG_OF_EMBED=y
CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_OF_LIBFDT=y
CONFIG_OF_LIST="meson-axg-our-device-name"
CONFIG_OF_REAL=y
CONFIG_OF_TRANSLATE=y
CONFIG_SUPPORT_OF_CONTROL=y
CONFIG_SYS_FDT_PAD=0x3000
CONFIG_TOOLS_OF_LIBFDT=y
CONFIG_DM_RNG=y
CONFIG_RNG_MESON=y
```
2) Due to CONFIG_OF_EMBED, the DTS is embedded into U-boot ELF and
accessible via __dtb_dt_begin symbol.
On early boot stage (board_f.c) the fdtdec_setup() is called only
once before U-boot's relocation into top of RAM. fdtdec_setup()
initializes gd::fdt_blob for FDTSRC_EMBED case:
```
gd->fdt_blob = dtb_dt_embedded();
gd->fdt_src = FDTSRC_EMBED;
```
3) Then reloc_fdt() is called in board_f.c
But due to CONFIG_OF_EMBED=y the reloc_fdt() does not update
gd::fdt_blob value (strictly speaking, it is impossible for
CONFIG_OF_EMBED=y, because U-boot ELF has not been relocated yet
at this moment).
As a result after relocation we get fdt_blob, pointing to DTS address
before relocation:
```
# bdinfo
<...>
relocaddr = 0x000000000fedf000
reloc off = 0x000000000eedf000
<...>
fdt_blob = 0x010ce6c0 << points to __dtb_dt_begin before relocation
new_fdt = 0x0000000000000000 << empty erroneously
fdt_size = 0x0000000000000000 << zero erroneously
```
4) During bootm command (according to our ITS-config file) the Linux
is loaded into 0x01080000 (which is very close to fdt_blob addr
0x010ce6c0).
```
## Loading kernel from FIT Image at 04000000 ...
Trying 'kernel' kernel subimage
<...>
Load Address: 0x01080000
```
So Linux image overwrites the gd::fdt_blob memory location
in RAM (0x010ce6c0).
5) Issue:
Hence any manipulation with DTS (say, via FDT API) inside
implementation of bootm command leads to accessing the fdt_blob area
with garbage, that can lead to two situations:
5.1) Abort.
Call to fdt_off_dt_struct() from fdt_next_tag() :: fdt_offset_ptr()::
fdt_offset_ptr_() returns with garbage, that leads to tagp value
being out of RAM top addr (256 Mb in our board), causing the abort:
```
Boot cmd: bootm 0x4000000#boot_evt1
bootm_run_states()
<...>
image_setup_libfdt()
fdt_chosen()
fdt_kaslrseed()
uclass_get_device()
uclass_get_device_tail()
device_probe()
device_of_to_plat()
meson_rng_of_to_plat()
clk_get_by_name_optional()
clk_get_by_name()
clk_get_by_name_nodev()
ofnode_stringlist_search()
fdt_stringlist_search()
fdt_getprop()
fdt_get_property_namelen_()
fdt_first_property_offset()
fdt_check_node_offset_()
fdt_next_tag():
```
tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
```
fdt_next_tag() tagp:0x22890766
fdt_next_tag() ram_top:0x10000000 (tagp OUT of RAM)
"Synchronous Abort" handler, esr 0x96000010, far 0x22890766
elr: 000000000108be24 lr : 000000000108be24 (reloc)
elr: 000000000ff6fe24 lr : 000000000ff6fe24
x0 : 0000000000000041 x1 : 0000000000000000
x2 : 000000000ff3b57c x3 : 0000000000000012
x4 : 000000000ded2ad5 x5 : 0000000000000020
x6 : 00000000ffffffe8 x7 : 000000000ded2f40
x8 : 00000000ffffffd8 x9 : 000000000000000d
x10: 0000000000000006 x11: 000000000001869f
x12: 000000000fffffff x13: 000000000fffffff
x14: 0000000000000000 x15: 000000000ded2abb
x16: 000000000ff3b080 x17: 0000000000000001
x18: 000000000ded3dc0 x19: 0000000022890766
x20: 00000000010cb0f0 x21: 00000000000015e4
x22: 000000000ff8f4d8 x23: 000000000000000b
x24: 000000000ded2fbc x25: 000000000ffe2000
x22: 000000000ff8f4d8 x23: 000000000000000b
x24: 000000000ded2fbc x25: 000000000ffe2000
x26: 000000000ffe2000 x27: 000000000000000b
x28: 000000000ff9cf2d x29: 000000000ded2f40
Code: aa1603e1 91197484 52801742 94004de8 (b9400276)
```
5.2) Vulnerability situation "KASLR is disabled".
Almost the same as in (5.1), but 2 situations happen (depending on
the value of garbage):
* call to fdt_offset_ptr_() :: fdt_off_dt_struct(fdt)
returns not so big garbage, leading to tagp, being inside RAM.
* or calculations of absoffset inside fdt_offset_ptr() leads to
failure of the one of if() conditions with NULL as retval.
Result is fdt_next_tag() interprets the tagp as FDT_END. And we are
returning from our callstack via functions' error paths, leading to
"No RNG device" and "KASLR disabled due to lack of seed":
```
fdt_kaslrseed()
uclass_get_device()
<...>
device_probe()
device_of_to_plat()
meson_rng_of_to_plat()
clk_get_by_name()
clk_get_by_name_nodev()
<...>
fdt_stringlist_search()
fdt_getprop()
fdt_get_property_namelen_()
fdt_first_property_offset()
fdt_check_node_offset_()
fdt_next_tag():
```
tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
```
fdt_next_tag() tagp:0000000001890677
fdt_next_tag() ram_top:0x10000000 (tagp is inside RAM)
uclass_get_device_tail():486 device_probe() ret:-22
No RNG device
Starting kernel ...
[ 0.000000] Linux version 6.9.12
[ 0.000000] KASLR disabled due to lack of seed
```
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>
This breaks chromebook_coral which says:
Video: No video mode configured in FSP!
This reverts commit 2e9313179a846b581c0fc3f6a49e19f3d343efa8.
Signed-off-by: Simon Glass <sjg@chromium.org>
If BIOSEMU is compiled for RISC-V (SiFive Unmatched board) and the function
dm_pci_run_vga_bios() is executed, U-Boot stops with error message saying
that the SPL malloc pool is too small. So increase the default pool size
when both BIOSEMU and RISCV parameters are set.
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
