Pull request efi-2025-07-rc1
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/25648
Documentation:
* Update authenticated capsules documentation
UEFI:
* Add support for loading FIT images including initrd
- efi_loader: efi_load_initrd: provide a memory mapped initrd
- efi_loader: binary_run: register an initrd
- bootm: add support for initrd in do_bootm_efi
* efi_selftest: remove un-needed NULL checks
* efi: Fix efiboot for payloads loaded from memory
* Print extra information from the bootmgr
* Move public cert for capsules to .rodata
* Set EFI capsule dfu_alt_info env explicitly
* Make FDT extra space configurable
* Install the ACPI table from the bloblist
* Handle GD_FLG_SKIP_RELOC
* Handle malloc() errors
Others:
* acpi: select CONFIG_BLOBLIST
* smbios: select CONFIG_BLOBLIST
* xilinx: dfu: Fill directly update_info.dfu_string
* cmd: fwu: Dump custom fields from mdata structure
* board: remove capsule update support in set_dfu_alt_info()
Because we've already returned early in the event 'handle' is NULL we
don't need these extra not NULL checks. Remove them
Signed-off-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since commit 53d5a22163 ("emulation: Use bloblist to hold tables")
`make qemu-riscv64_smode_defconfig acpi.config && make` fails with
drivers/misc/qfw_smbios.c:93:(.text.qfw_evt_write_smbios_tables+0xe):
undefined reference to `bloblist_add'
Build with bloblist support.
Fixes: 53d5a22163 ("emulation: Use bloblist to hold tables")
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since commit 53d5a22163 ("emulation: Use bloblist to hold tables")
`make qemu-riscv64_smode_defconfig acpi.config && make` fails with
qfw_acpi.c:146:(.text.evt_write_acpi_tables+0xc):
undefined reference to `bloblist_add'
Build with bloblist support.
Fixes: 53d5a22163 ("emulation: Use bloblist to hold tables")
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Now that we moved out the capsule signature from the DTB, remove the
relevant documentation.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
commit ddf67daac3 ("efi_capsule: Move signature from DTB to .rodata")
was reverted in
commit 47a25e81d3 ("Revert "efi_capsule: Move signature from DTB to .rodata"")
because that's what U-Boot was usually doing -- using the DT to store
configuration and data. Some of the discussions can be found here [0].
(Ab)using the device tree to store random data isn't ideal though.
On top of that with new features introduced over the years, keeping
the certificates in the DT has proven to be problematic.
One of the reasons is that platforms might send U-Boot a DTB
from the previous stage loader using a transfer list which won't contain
the signatures since other loaders are not aware of internal
U-Boot ABIs. On top of that QEMU creates the DTB on the fly, so adding
the capsule certificate there does not work and requires users to dump
it and re-create it injecting the public keys.
Now that we have proper memory permissions for arm64, move the certificate
to .rodata and read it from there.
[0] https://lore.kernel.org/u-boot/CAPnjgZ2uM=n8Qo-a=DUkx5VW5Bzp5Xy8=Wgmrw8ESqUBK00YJQ@mail.gmail.com/
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Jonathan Humphreys <j-humphreys@ti.com> # on TI sk-am62p-lp
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-A311D-CC
Tested-by: Raymond Mao <raymond.mao@linaro.org>
Instead of just printing the label, add information for the Device
path as well so it's easier to see if we are booting from disk, network
etc
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
If the EFI runtime services pointers are relocated even though
relocation is skipped, it corrupts some other data resulting in some
unexpected behaviour.
In this specific case, it overwrote some page table entries resulting in
the device memory address range's mappings getting removed. Eventually,
after the completion of efi_runtime_relocate(), when a driver tries to
access its device's registers it crashes since the mappings are absent.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
Current mmc bootpart-resize command only support Samsung eMMC BOOT/RPMB
hardware partition resizing. Add Sandisk and Micron eMMC BOOT/RPMB hardware
partition resizing support. The commands and parameters for resizing
partitions are different for each manufacturer. Select the corresponding
function according to CID.
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Each MMC device has a child which ihs a block device. At present we call
mmc_deinit() when the block device is removed.
But the MMC struct (i.e. struct mmc) is attached to the MMC's device,
not its child.
So at present, when an MMC device is removed, mmc_deinit() is called
twice, once for the MMC device and once for its block device. This
results in a double call to cyclic_unregister().
Fix this by adding a 'remove' method to the uclass and calling
mmc_deinit() from there.
Also drop the call to device_probe() within the block-device's probe()
method. The device is already in the process of being probed, so this
call does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: c822c1a50b ("mmc: call device_probe() after scanning")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When MMC_SDHCI_SDMA=y or MMC_SDHCI_ADMA=y and PIO mode is used
dma_unmap_single() is called on an unmapped address, 0x0. This may
result in a Synchronous Abort:
## Checking hash(es) for Image atf-1 ... sha256+ OK
CMD_SEND:16
ARG 0x00000200
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:18
ARG 0x00004005
"Synchronous Abort" handler, esr 0x96000147
elr: 00000000400015bc lr : 0000000040012b4c
x 0: 0000000000008000 x 1: 0000000000092600
x 2: 0000000000000040 x 3: 000000000000003f
x 4: 0000000000000030 x 5: 0000000000000001
x 6: 0000000000000001 x 7: 0000000000000000
x 8: 000000000000000a x 9: 0000000000000090
x10: 0000000043dffc68 x11: 0000000043c00440
x12: 0000000043c00440 x13: ffffffffbfe00000
x14: 000000000000031c x15: 0000000240000000
x16: 000000004001145c x17: 0000000000000032
x18: 0000000043dffef0 x19: 0000000043c00000
x20: 0000000043dffbc8 x21: 0000000000000000
x22: 00000000000f3d95 x23: 0000000000000002
x24: 0000000000000493 x25: 0000000000092600
x26: 0000000000000001 x27: 0000000000000001
x28: 0000000000000008 x29: 0000000043dffab0
Code: d2800082 9ac32042 d1000443 8a230000 (d5087620)
Resetting CPU ...
resetting ...
Fix this by only dma_unmap_single() when DMA mode is used and
sdhci_prepare_dma() has been called to map host->start_addr.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Per JESD84-B51 6.6.9 Erase:
The host can erase a contiguous range of Erase Groups. Starting the erase
process is a three steps sequence. First the host defines the start address
of the range using the ERASE_GROUP_START (CMD35) command, next it defines
the last address of the range using the ERASE_GROUP_END (CMD36) command and
finally it starts the erase process by issuing the ERASE (CMD38) command
with argument bits set to zero. See Table 11 for the arguments supported by
CMD38. The address field in the erase commands is an Erase Group address,
in byte units for densities up to 2GB, and in sector units for densities
greater than 2GB. The Device will ignore all LSB's below the Erase Group
size, effectively rounding the address down to the Erase Group boundary.
So choose 2GB bytes as check condition.
If the erase size is larger that 2GB, use 2GB to avoid breaking non high
capacity cards. If erase size is less than 2GB and larger than a grp, use
'grpcnt * mmc->erase_grp_size' to cover all the sectors, else use
the number of sectors.
With test erasing 20GB eMMC
board: Evk_8ulp Evk_8mm Evk_8mn Evk_8mp Mek_8qxpc0 Mek_8qm
kingston sandisk
before: 37.683s 112.738s 129.365s 28.238s 112.605s 500.470s 490.708s
after: 0.093s 0.111s 0.951s 0.080s 0.121s 6.960s 6.915s
Tested-by: Faqiang Zhu <faqiang.zhu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In case mmc_complete_init() returns error, exit from mmc_init()
without possibly calling cyclic_register(), which at that point
would be undesired.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Simplify 90cc07fd78 ("mmc: Poll CD in case cyclic framework is enabled")
according to suggestions by Rasmus. The struct cyclic_info is zero-size in
case CONFIG_CYCLIC is not enabled and does not add any size to struct mmc,
so it can unconditionally be part of that structure. This allows clean up
of all the other conditionals in mmc.c which can now be unconditionally
present, as they also add no extra space.
Suggested-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The option MMC_SDHCI_ADMA_FORCE_32BIT is only tested or used when
MMC_SDHCI_ADMA or SPL_MMC_SDHCI_ADMA is enabled. And for
MMC_SDHCI_ADMA_64BIT the same is true except we also require
MMC_SDHCI_ADMA_FORCE_32BIT to be disabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
UFS devices uses the block and scsi frameworks. Enable UFS erase
support by adding erase support to SCSI.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Allow invoking fit_check_sig without the key parameter, allowing to
validate only checksums and hashes for unsigned images.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Skip signature verification in case no public key was given in order to
allow using fit_check_sign also to validate uImage.FIT images without
signatures. Guarded by USE_HOSTCC macro the behavior on target is
unchanged.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
As current design, only Manager CPU called armv8_setup_psci() before
jump to next stage(such as Linux Kernel), Subordinate CPUs also need
setup psci vector to handle trap request which comes from higher EL
level.
Signed-off-by: Xu Zhang <423756212@qq.com>
[trini: Guard with !CONFIG_XPL_BUILD check]
In console_setfile(), there is some #ifdef'ed code, updating monitor
functions for a U-Boot proper build. This is called inside a switch/case
statement, but the closing "break;" is inside the #ifdef section.
This doesn't look right: we should not fall through to the error case
for an SPL/TPL build.
Move the "break" to be always effective, solving a compiler warning about
an untagged implicit fallthrough.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
