Calling bootefi on an address that was loaded from memory (e.g., cramfs
or SPI flash via "sf read", etc.), currently results in the EFI binary
not being able to access the EFI image device path.
For example, iPXE would fail with an error "EFI could not get loaded
image's device path: Error 0x7f39e082 (https://ipxe.org/7f39e082)".
This is due to an incomplete special-case in efi_binary_run, where a new
device path was created but not used in all required places.
Fix the in-memory special case, set the "bootefi_device_path" to the
generated "file_path".
iPXE will now boot, and report the device path as
"/MemoryMapped(0x0,0xSTART,0xLEN)"
Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The commit cb9ae40a16 ("tools: mkfwumdata: add logic to append vendor
data to the FWU metadata") added support for adding vendor data to mdata
structure but it is not visible anywhere that's why extend fwu command to
dump it.
Tested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Pass a pointer to a memory mapped initrd and its size to
efi_binary_run. The EFI stack will register an EFI_LOAD_FILE2_PROTOCOL
for the next boot stage to access this initrd.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
U-Boot can pass an initrd to subsequent boot stages via the
EFI_LOAD_FILE2_PROTOCOL. The current implementation only supports
this functionality via the efi boot manager: the initrd is taken
from the load options of the BootCurrent variable. This commit adds
support for registering a memory mapped initrd, e.g. loaded from a
FIT image. For now this new method takes precedence over loading the
initrd from the BootCurrent variable (if both are present) because
the BootCurrent variable is not cleared on exiting the boot manager.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
U-Boot currently reserves only 0x3000 bytes when copying the FDT
in copy_fdt(), which may not be sufficient if additional nodes
(such as FMAN firmware) are added later.
This patch uses the exisitng SYS_FDT_PAD to reserve space for FDT fixup
instead of hardcoded value.
This change prevents potential corruption when resizing FDT after
EFI boot, especially when firmware like FMAN requires additional
space.
Signed-off-by: Gabriel Nesteruk <gnesteruk@sii.pl>
Signed-off-by: Pawel Kochanowski <pkochanowski@sii.pl>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When BLOBLIST_TABLES is used, the ACPI tables are not currently added to
the list of EFI tables. While we don't want to create a new memory
region, we do want to tell EFI about the tables.
Fix this by covering this case. At some point the non-bloblist code can
likely be removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 3da59ee9579 ("efi_loader: Avoid mapping the ACPI tables twice")
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Now that capsule update sets the dfu_alt_info environment variable
explicitly, there is no need to support it in the set_dfu_alt_info()
function. Decouple SET_DFU_ALT_INFO from EFI_CAPSULE_FIRMWARE_FIT and
EFI_CAPSULE_FIRMWARE_RAW. For many boards, this was the only use of
set_dfu_alt_info() so remove the function entirely.
Fixes: a9e6f01a94 ("efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled")
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> # for board/libre-computer/*
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de> # for
The current implementation of EFI capsule update uses set_dfu_alt_info() to
set the dfu_alt_info environment variable with the settings it requires.
However, set_dfu_alt_info() is doing this for all DFU operations, even
those unrelated to capsule update.
Thus other uses of DFU, such as DFU boot which sets its own value for the
dfu_alt_info environment variable, will have that setting overwritten with
the capsule update setting. Similarly, any user defined value for the
dfu_alt_info environment variable would get overwritten when any DFU
operation was performed, including simply performing a "dfu 0 list"
command.
The solution is stop using the set_dfu_alt_info() mechanism to set the
dfu_alt_info environment variable and instead explicitly set it to the
capsule update's setting just before performing the capsule update's DFU
operation, and then restore the environment variable back to its original
value.
This patch implements the explicit setting and restoring of the
dfu_alt_info environment variable as part of the EFI capsule update
operation.
The fix is fully implemented in a subsequent patch that removes the capsule
update dfu_alt_info support in set_dfu_alt_info().
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Directly fill update_info.dfu_string to prepare platforms to switch
from using dfu_alt_info variable to dfu_string which contains description
for capsule update when switch is done.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This data was generated using the ksswtool-autogen project with the
followig commit:
eed7492 ("soc: am62ax: Add cpsw_3guss_main_0 id to the dev list")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Don't initialize Ethernet2 in SPL. We cannot boot from that source anyways
and it throws an error during boot.
This will remove following error message during network boot:
Error: ethernet@8000000port@2 No valid MAC address found.ethernet@8000000port@1
Waiting for PHY auto negotiation to complete....... done
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Add support for ethernet boot in the A53 SPL. Increase the SPL Size
limit and update SPL_STACK_R_ADDR.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Provide a defconfig for booting the phycore-am62x via Ethernet.
We need a separate defconfig because the AM62x has not enough internal
SRAM to support all boot sources.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Add bootph-all tag to phy_gmii_sel node. This is needed for booting via
Ethernet. While at it, drop main_pktdma reg redefinitions which are already
provided by the top-level SoC device tree file.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Tested-by: Daniel Schultz <d.schultz@phytec.de>
Caleb Connolly <caleb.connolly@linaro.org> says:
SCSI devices like UFS may maintain their own cache to speed up writes,
however this is lost on board reset (and may be lost on device removal
or reset by OS drivers).
Currently this can be worked around by "waiting for a while" after
writing data to disk, but of course this is not an acceptable solution.
Ideally U-Boot would have a mechanism to flush caches during board
reset, but until that logic is hooked up let's be sure that all writes
are actually propagated to the storage device so that we don't lose data
on board reset.
The same logic was already implemented just for the AHCI backend, this
duplicated logic has been removed and support for the SYNC_CACHE command
is added to AHCI.
This is particularly noticeable during capsule updates, since the update
file is deleted and the board is reset immediately afterwards which
resulted in the same capsule update being applied over and over again.
This specifically fixes Qualcomm SDM845 devices with UFS 2.1, but likely
all UFS devices that use a cache.
Link: https://lore.kernel.org/r/20250326-scsi-sync-on-write-v2-0-12ab05bd464b@linaro.org
The SCSI layer now issues a SYNC_CACHE command after every write to
ensure there is no data loss due to a board reset after write.
Implement support for this command and remove the same logic from the
ATA write path to be consistent with other SCSI backends.
Ranges are not supported and the whole cache will be flushed in all
cases.
This was done per iteration in ata_scsiop_read_write(), but it's not
clear why this was the case, calling it once for the entire write ought
to achieve the same result.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
We don't have a mechanism to safely shutdown block devices prior to a
baord reset or driver removal. Prevent data loss by synchronizing the
SCSI cache after every write.
In particular this solves the issue of capsule updates looping on some
devices because the board resets immediately after deleting the capsule
file and this write wouldn't be flushed in time.
This may impact NAND wear, but should be negligible given the usecases
for disk write in U-Boot.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
This clears the 6th byte of cmd twice rather than setting the 9th byte
to 0. Fix it.
The only other command that sets the 9th byte is the 64-bit read, so
this likely never caused issues in practise.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Since introduction of OF_UPSTREAM flag, U-Boot's dtc must be able
to compile Kernel's device tree.
Since kernel commit 7de129f5389b ("ARM: dts: stm32: stm32mp151a-prtt1l:
Fix QSPI configuration"), label relative path references has been
introduced. These label relative path references is not supported
by current U-Boot dtc version 1.5.0: (see mailing list discussion [1]).
In order to support such label relative patch references
adds following commit from upstream DTC tree:
commit 651410e54cb9 ("util: introduce xstrndup helper")
commit ec7986e682cf ("dtc: introduce label relative path references")
[1] https://lore.kernel.org/all/20250115144428.GZ3476@bill-the-cat/T/
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The symbol "ENV_IS_EMBEDDED" is an environment internal define and not a
real CONFIG symbol. The IS_ENABLED() macro is still valid to use here,
so update the check.
Signed-off-by: Tom Rini <trini@konsulko.com>
The cflags and ldflags of preload_check_sign depend on the openssl
package thus pkg-config is needed to get the location where openssl
is installed.
This fix a potential build failure when openssl is not from the
distro and installed in a varied place.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
When using non-trivial values for parameters for this test it
will cause a spurious failure as the test passes a decimal value
to the mtest command which will interpret it as hexadecimal and
result in failure as below.
test/py/tests/test_memtest.py:66: in test_memtest_ddr
assert expected_response in response
E AssertionError: assert 'Tested 16 iteration(s) with 0 errors.' in 'Refusing to do empty test\r\nmtest - simple RAM read/write test\r\n\r\nUsage:\r\nmtest [start [end [pattern [iterations]]]]'
----------------------------- Captured stdout call -----------------------------
U-Boot> mtest 134217728 0x8001000 90 0x10
Refusing to do empty test
mtest - simple RAM read/write test
Usage:
mtest [start [end [pattern [iterations]]]]
The fix is to ensure that all the parameters to the mtest command are
passed as hexadecimal values.
Fixes: 22efc1cf27 ("test/py: memtest: Add tests for mtest command")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>
If a series is sent without a cover letter, there is no indication of
the base commit. Add support for this, since single patches of small
series may not always have a cover letter.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is helpful to know which commit patches are based on, even if that
commit might not be available to readers. Add a tag for this in the
cover letter.
Also add the local-branch name since that may be useful to the writer.
Signed-off-by: Simon Glass <sjg@chromium.org>
We had previously gotten this package through a chain of dependencies
with guestfs-tools. Now that we no longer install that package, install
fdisk (for sfdisk) directly.
Fixes: eb1b90ec57 ("Dockerfile: Update to drop virt-make-fs packages")
Signed-off-by: Tom Rini <trini@konsulko.com>
There are some reference platforms from Arm which are not found in QEMU
but instead in the FVP tool. As we can make use of this in CI later on,
download and extract it in our Dockerfile today.
Signed-off-by: Tom Rini <trini@konsulko.com>
Outside of changing versions here the other visible change is that we
tell grub that riscv64 does not have "large model" support. Without this
change the resulting mkimage is non-functional. This is known upstream
already.
Link: https://savannah.gnu.org/bugs/?65909
Signed-off-by: Tom Rini <trini@konsulko.com>
u-boot-dfu-20250410
CI:
- https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/25615
Usb gadget:
- Add SAM9X60 support to atmel driver
- Fix memory leaks in f_mass_storage gadget driver
- Fix comment typo in dwc3 gadget driver
Fastboot:
- Lift restrictions on !NET_LWIP for USB
Android:
- Fix possible NULL ptr when AVB is out of memory
In fsg_common_init, we allocate some buffers via memalign().
However, these buffers are never freed.
Because of that, we cannot call => ums command multiple times on boards
with low memory (CONFIG_SYS_MALLOC_LEN=0x81000):
=> ums 0 mmc 2
UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000
|crq->brequest:0x0
CTRL+C - Operation aborted
=> ums 0 mmc 2
UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000
failed to start <NULL>: -12
g_dnl_register: failed!, error: -12
g_dnl_register failed
Make sure the fsg buffers are freed when the gadget is unbound by
calling fsg_common_release() in fsg_unbind().
Reported-by: Zixun LI <admin@hifiphile.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Zixun LI <admin@hifiphile.com> # on SAM9X60
Link: https://lore.kernel.org/r/20250328-ums-gadget-leak-v1-4-3b677db99bde@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Fastboot works either over TCP, UDP or USB. The latter doesn't have
anything to do with networking, thus should work just fine with
regardless which network stack is selected. In practice, header symbols
are used inside common code paths. Add some ifdeffery to guard against
that.
This will make fastboot over USB work with the new LWIP stack.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250312073655.2281377-1-mwalle@kernel.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Currently, this platform is failing in CI due to seemingly platform
specific reasons. For now, remove it from CI until the maintainers have
a chance to look in to it.
Signed-off-by: Tom Rini <trini@konsulko.com>
