u-boot.git/lib, branch v2026.01 Unnamed repository; edit this file 'description' to name the repository. lib: uuid: add EFI_PARTITION_INFO_PROTOCOL_GUID translation 2025-12-12T11:51:17+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-12-07T11:18:45+00:00 f9f4f8df57996708c5767eda9a2a3fbcbd48a105 Add support for translating the EFI_PARTITION_INFO_PROTOCOL_GUID to a text. Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Add support for translating the EFI_PARTITION_INFO_PROTOCOL_GUID
to a text.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: Fix a memory leak when retrieving device paths from boot vars 2025-12-06T10:43:28+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2025-11-27T12:19:06+00:00 ad53505a4861ad7eec5c6a919ea39692d915e433 get_dp_device() is used to derive the device path from a boot variable. However, if the last efi_get_variable_int() call fails, we return an error without freeing 'buf'. There's no need to call efi_get_variable_int() for variables we don't know the size since we have the efi_get_var() wrapper. Replace that in the two instances we use it. The first one will also fix the memory leak. A nice sideeffect is that the code size is also reduced, since we are re-using functions instead of open coding them $~ bloat-o-meter u-boot u-boot.new add/remove: 0/0 grow/shrink: 1/2 up/down: 6/-196 (-190) Function old new delta version_string 70 76 +6 efi_launch_capsules 2288 2196 -92 get_dp_device 244 140 -104 Total: Before=1222331, After=1222141, chg -0.02% Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
get_dp_device() is used to derive the device path from a boot variable.
However, if the last efi_get_variable_int() call fails, we return an
error without freeing 'buf'.

There's no need to call efi_get_variable_int() for variables we don't
know the size since we have the efi_get_var() wrapper.

Replace that in the two instances we use it. The first one will also
fix the memory leak.
A nice sideeffect is that the code size is also reduced, since we are
re-using functions instead of open coding them

$~ bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 1/2 up/down: 6/-196 (-190)
Function                                     old     new   delta
version_string                                70      76      +6
efi_launch_capsules                         2288    2196     -92
get_dp_device                                244     140    -104
Total: Before=1222331, After=1222141, chg -0.02%

Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
lib: optee: forbid OP-TEE OS loading without adding OP-TEE OS reserved-memory nodes 2025-11-18T21:54:03+00:00 Quentin Schulz quentin.schulz@cherry.de 2025-11-11T11:52:34+00:00 1c13c9bbb54d979737d56544c5dcaec3ef0481d7 I've spent time trying to figure out why my board (Rockchip PX30-based) suddenly boot loops when running a specific program in Linux userspace after working on a U-Boot upgrade. I actually inadvertently had the TEE environment variable set for a device which doesn't actually need to run any TEE OS (so had OPTEE_LIB disabled). It is currently possible to build an image with an OP-TEE OS (via the TEE environment variable) without OPTEE_LIB. U-Boot will happily load the TEE OS and the next OS (e.g. the Linux kernel). This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to the reserved-memory FDT node for the memory regions it just reserved for itself. This updated FDT is then passed to U-Boot proper which should know better not to use memory from there. The actual issue is that without OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy those nodes over to the next OS's FDT before starting it. This results in the next OS's (e.g. Linux kernel) to not be aware of reserved memory, incurring random crashes or device reboots when it tries to access secure reserved memory area. On Rockchip, the U-Boot FIT image which contains both the TEE OS and U-Boot proper is generated by binman. Unfortunately, binman doesn't seem to have access to Kconfig symbols (grep CONFIG_ doesn't return anything meaningful and binman is either configured through FDT nodes or via CLI arguments, c.f. cmd_binman in the root Makefile) so we cannot try to be smart and guide the user to the correct Kconfig option to select if TEE is set. We could add a property based on the presence of OPTEE_LIB in rockchip-u-boot.dtsi for example and have a custom message based on that, the issue is that I assume all FDT-based platforms do actually need to do this dance, and not only Rockchip. Another option could be to add a CLI argument to binman through which we would pass the state of OPTEE_LIB and error out the build in that case, but that feels like opening the door to other various dirty hacks. Another option is to propagate the TEE environment variable to the preprocessor of the FDT (via dtc_cpp_flags) and then we can do #if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB) #error "CONFIG_OPTEE_LIB must be enabled!" #endif but we have the same issue as above, it is then Rockchip-specific and doesn't feel right to me. Yet another option is to remove the @tee-SEQ node from the binman FIT description when OPTEE_LIB isn't set but then we would lose the following nice message when no TEE is provided: Image 'simple-bin' is missing optional external blobs but is still functional: tee-os and even worse, build without any TEE OS even though we could provide one via the TEE environment variable. Finally, another option could be to move this hack under arch/arm/mach-rockchip/Kconfig to make it Rockchip-specific or add a depends on ARCH_ROCKCHIP. However OP-TEE OS on Aarch32 Rockchip boards doesn't actually need any of that if SPL_OPTEE_IMAGE is set because arch/arm/mach-rockchip/sdram.c then marks some hardcoded memory regions in RAM as holes in DRAM, which has the same effect as reserved memory regions I guess. I assume other platforms may use something different, so it may be casting too wide of a net. This commit is what I could come up with as a stopgap measure to avoid building images that simply cannot reliably work and fail randomly. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> 
I've spent time trying to figure out why my board (Rockchip PX30-based)
suddenly boot loops when running a specific program in Linux userspace
after working on a U-Boot upgrade. I actually inadvertently had the TEE
environment variable set for a device which doesn't actually need to run
any TEE OS (so had OPTEE_LIB disabled).

It is currently possible to build an image with an OP-TEE OS (via the
TEE environment variable) without OPTEE_LIB. U-Boot will happily load
the TEE OS and the next OS (e.g. the Linux kernel).

This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to
the reserved-memory FDT node for the memory regions it just reserved for
itself. This updated FDT is then passed to U-Boot proper which should
know better not to use memory from there. The actual issue is that
without OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy
those nodes over to the next OS's FDT before starting it. This results
in the next OS's (e.g. Linux kernel) to not be aware of reserved memory,
incurring random crashes or device reboots when it tries to access
secure reserved memory area.

On Rockchip, the U-Boot FIT image which contains both the TEE OS and
U-Boot proper is generated by binman. Unfortunately, binman doesn't seem
to have access to Kconfig symbols (grep CONFIG_ doesn't return anything
meaningful and binman is either configured through FDT nodes or via CLI
arguments, c.f. cmd_binman in the root Makefile) so we cannot try to be
smart and guide the user to the correct Kconfig option to select if TEE
is set. We could add a property based on the presence of OPTEE_LIB in
rockchip-u-boot.dtsi for example and have a custom message based on
that, the issue is that I assume all FDT-based platforms do actually
need to do this dance, and not only Rockchip.

Another option could be to add a CLI argument to binman through which
we would pass the state of OPTEE_LIB and error out the build in that
case, but that feels like opening the door to other various dirty hacks.

Another option is to propagate the TEE environment variable to the
preprocessor of the FDT (via dtc_cpp_flags) and then we can do

  #if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB)
  #error "CONFIG_OPTEE_LIB must be enabled!"
  #endif

but we have the same issue as above, it is then Rockchip-specific and
doesn't feel right to me.

Yet another option is to remove the @tee-SEQ node from the binman FIT
description when OPTEE_LIB isn't set but then we would lose the
following nice message when no TEE is provided:

Image 'simple-bin' is missing optional external blobs but is still functional: tee-os

and even worse, build without any TEE OS even though we could provide
one via the TEE environment variable.

Finally, another option could be to move this hack under
arch/arm/mach-rockchip/Kconfig to make it Rockchip-specific or add a
depends on ARCH_ROCKCHIP. However OP-TEE OS on Aarch32 Rockchip boards
doesn't actually need any of that if SPL_OPTEE_IMAGE is set because
arch/arm/mach-rockchip/sdram.c then marks some hardcoded memory regions
in RAM as holes in DRAM, which has the same effect as reserved memory
regions I guess. I assume other platforms may use something different,
so it may be casting too wide of a net.

This commit is what I could come up with as a stopgap measure to avoid
building images that simply cannot reliably work and fail randomly.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
efi_loader: Assure fitImage from capsule is used from 8-byte aligned address 2025-11-15T10:50:42+00:00 Marek Vasut marek.vasut+renesas@mailbox.org 2025-11-13T11:55:49+00:00 8cc144227e13b50cd6d97c36ebb45f31f4d8c9cd The fitImage may be stored in EFI update capsule at address that is not aligned to 8 bytes. Since fitImage is a DT, new version of libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy the fitImage into aligned buffer in case it is not aligned. This does increase overhead for unaligned fitImages in EFI capsules, but tries to keep the overhead low for aligned ones. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_selftest: efi_selftest_snp: Fix warning when building with clang 2025-11-15T10:45:29+00:00 Tom Rini trini@konsulko.com 2025-11-06T23:28:39+00:00 b8f2614ecaca83b381a92af54e5e38eefaf7646f When building with clang, we see a warning: lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within 'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due to 'struct dhcp' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by packing struct dhcp_hdr as well, as the only place it is used also is packed. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> 
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_client: correct memset() return value 2025-11-15T10:36:50+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-11-04T22:14:23+00:00 ea99509b67d92c261e8cc1d293edd8462974bc5a Memset() must return a pointer to the start of the updated memory block. Fixes: 476476e73b14 ("efi: Add support for loading U-Boot through an EFI stub") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Memset() must return a pointer to the start of the updated memory block.

Fixes: 476476e73b14 ("efi: Add support for loading U-Boot through an EFI stub")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_client: don't include asm/global_data.h twice 2025-11-15T10:36:33+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-11-04T22:00:55+00:00 033780768edb2cf3d115099277f50ce90400959f Remove duplicate #include. Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Remove duplicate #include.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: typo 'eventfor' in efi_ipconfig.c 2025-11-15T10:36:22+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-11-04T21:50:25+00:00 479ba0cc4d6ef1dd74889826e0dbad82b29999a7 %s/eventfor/event for/ Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
%s/eventfor/event for/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_selftest: use Sphinx style comments in efi_console.c 2025-11-15T10:36:08+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-11-04T20:56:46+00:00 691eab09df03f3bfcc4e677122b11dad43d3b499 Convert function comments in efi_selftest_console.c to match Sphinx style. Correct function name in print_uuid() comment. Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
Convert function comments in efi_selftest_console.c to match
Sphinx style.

Correct function name in print_uuid() comment.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Merge tag 'efi-2026-01-rc2' of https://source.denx.de/u-boot/custodians/u-boot-efi 2025-11-07T14:26:59+00:00 Tom Rini trini@konsulko.com 2025-11-07T14:26:59+00:00 df786b4c57f582b4f875effe68d3ae22bbb478a9 Pull request efi-2026-01-rc2 CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28208 Documentation: * bootstd: Describe environment variable extension_overlay_addr environment and remove extension support from TODO list EFI: * Correct the detection of the video mode in the EFI payload app: - Use struct efi_gop_mode_info in the definition of struct efi_entry_gopmode. - In function get_mode_from_entry() use the correct type for the video mode structure. * Use a valid error code as return value in efi_store_memory_map(). * Avoid a memory leak for the variable name in efi_bl_create_block_device(). * Correct the code indentation in efi_uc_stop(). * Correct the description of struct efi_priv. * Fix typos in code comments. Other: * qfw: Add more fields and a heading to qfw list * Fix the support for ACPI pass-through on ARM and RISC-V: Avoid zeroing out the XSDT address * test: provide unit test for 'acpi list' command # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmkNj/kACgkQxIHbvCwF # GsS8NQ/6Aj+Z54HJTIEfoXssvElLr5ATactrCxszq42i/yy6dLqa2Ym1afG6w1XS # 1ZbCeU/bCXFke5Tsz+x89gEfckUm83oTwngwcID0WR1qn8mWjwR7tM5MuORq8NxU # 7NwLuFs9O/QZihagKdz6hv1/Y+cBwiAYLY16EYVSuUlbLaKQo3QvxwWkqG3jdKWV # Rm58/PolU+2h04MBwP0SxSduX4OyRF/tMOGjf5RGLyqCyj8kIgdu7PvUAPMM+Gps # KemL59V0Bdv8hlF4JknmPz+idtZg2nHIDdNrBZvoxwzwGQeRZ1YXAMruRxZXqDYL # tiuDp6HMv/GfIIGkz14tJtJMdboaAybAnluPWGalx8JQJqJzEPww0R+9s4KKQeWL # mHgRyl6PxVV9p19f79Qq6q6ETwrFDX0YH3pdrGUk3DBa3lDt0UsEAnuW4FvaJ8tx # 3PMrjKAxpxocT0hglsMVnptnfvDEigMsjwH/TWrau83mY+juxFQLjm+U4vye+qCa # 4zXjjLas18+eRcrv2KxU7teakyi1Jp+WbqHq37L26YcQMaLq/RkBc0bTrsreKKLu # jprYFpvc7EJpH2Fd1XWaZ2EnxXcVSJSvrY/iwRQqb6wbwQ6XGtMvSh3IFY8IzAoh # N2Pj78oaYqyL1q/TftuZWhEHo3a0M/HfM4D+oMSHzJtWCb0wZHE= # =OGcS # -----END PGP SIGNATURE----- # gpg: Signature made Fri 07 Nov 2025 12:21:45 AM CST # gpg: using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4 # gpg: Good signature from "Heinrich Schuchardt <xypron.glpk@gmx.de>" [unknown] # gpg: aka "[jpeg image of size 1389]" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 
Pull request efi-2026-01-rc2

CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28208

Documentation:

* bootstd: Describe environment variable extension_overlay_addr
  environment and remove extension support from TODO list

EFI:

* Correct the detection of the video mode in the EFI payload app:
  - Use struct efi_gop_mode_info in the definition of struct
    efi_entry_gopmode.
  - In function get_mode_from_entry() use the correct type for the video
    mode structure.
* Use a valid error code as return value in efi_store_memory_map().
* Avoid a memory leak for the variable name in efi_bl_create_block_device().
* Correct the code indentation in efi_uc_stop().
* Correct the description of struct efi_priv.
* Fix typos in code comments.

Other:

* qfw: Add more fields and a heading to qfw list
* Fix the support for ACPI pass-through on ARM and RISC-V:
  Avoid zeroing out the XSDT address
* test: provide unit test for 'acpi list' command

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmkNj/kACgkQxIHbvCwF
# GsS8NQ/6Aj+Z54HJTIEfoXssvElLr5ATactrCxszq42i/yy6dLqa2Ym1afG6w1XS
# 1ZbCeU/bCXFke5Tsz+x89gEfckUm83oTwngwcID0WR1qn8mWjwR7tM5MuORq8NxU
# 7NwLuFs9O/QZihagKdz6hv1/Y+cBwiAYLY16EYVSuUlbLaKQo3QvxwWkqG3jdKWV
# Rm58/PolU+2h04MBwP0SxSduX4OyRF/tMOGjf5RGLyqCyj8kIgdu7PvUAPMM+Gps
# KemL59V0Bdv8hlF4JknmPz+idtZg2nHIDdNrBZvoxwzwGQeRZ1YXAMruRxZXqDYL
# tiuDp6HMv/GfIIGkz14tJtJMdboaAybAnluPWGalx8JQJqJzEPww0R+9s4KKQeWL
# mHgRyl6PxVV9p19f79Qq6q6ETwrFDX0YH3pdrGUk3DBa3lDt0UsEAnuW4FvaJ8tx
# 3PMrjKAxpxocT0hglsMVnptnfvDEigMsjwH/TWrau83mY+juxFQLjm+U4vye+qCa
# 4zXjjLas18+eRcrv2KxU7teakyi1Jp+WbqHq37L26YcQMaLq/RkBc0bTrsreKKLu
# jprYFpvc7EJpH2Fd1XWaZ2EnxXcVSJSvrY/iwRQqb6wbwQ6XGtMvSh3IFY8IzAoh
# N2Pj78oaYqyL1q/TftuZWhEHo3a0M/HfM4D+oMSHzJtWCb0wZHE=
# =OGcS
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 07 Nov 2025 12:21:45 AM CST
# gpg:                using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4
# gpg: Good signature from "Heinrich Schuchardt <xypron.glpk@gmx.de>" [unknown]
# gpg:                 aka "[jpeg image of size 1389]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4