The size of the memory allocated for the EFI Conformance Profiles Table is
computed with `num_entries' always equal to zero, which is incorrect when
CONFIG_EFI_EBBR_2_1_CONFORMANCE is enabled.

This can be verified by allocating the ECPT memory with malloc() instead of
efi_allocate_pool(), building u-boot with sandbox_defconfig and
CONFIG_VALGRIND=y, and by finally running the following command:

  valgrind --suppressions=scripts/u-boot.supp \
    ./u-boot -T -c 'efidebug tables'

Fix this by using an array of the supported profiles GUIDs instead, which
should also be easier to extend in the future as U-Boot should publish the
GUIDs for all supported EBBR revisions.

Fixes: 6b92c1735205 ("efi: Create ECPT table")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jose Marinho <jose.marinho@arm.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The read_blocks() function from the Block IO protocol is a UEFI function;
make sure to call it from within U-Boot using the EFI_CALL() macro.

To demonstrate the issue on an AArch64 machine, define the DEBUG macro in
include/efi_loader.h and build u-boot with sandbox_defconfig, then download
and uncompress the ACS-DT image [1], and finally execute the following
command:

  $ ./u-boot -T -c " \
      host bind 0 systemready-dt_acs_live_image.wic; \
      setenv loadaddr 0x10000; \
      load host 0 \${loadaddr} EFI/BOOT/Shell.efi; \
      bootefi \${loadaddr} \${fdtcontroladdr}"

The following assertion should fail:

  lib/efi_loader/efi_net.c:858: efi_network_timer_notify: Assertion `__efi_entry_check()' failed.

This happens due to the following EFIAPI functions call chain:

  efi_start_image()
    efi_disk_read_blocks()
      (due to the missing EFI_CALL, entry_count == 2)
      efi_network_timer_notify()

Link: https://github.com/ARM-software/arm-systemready/releases/download/v25.12_DT_3.1.1/systemready-dt_acs_live_image.wic.xz [1]
Fixes: ce3dbc5d080d ("efi_loader: add UEFI GPT measurement")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Masahisa Kojima <kojima.masahisa@socionext.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Masahisa Kojima <kojima.masahisa@socionext.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Coverity scan reported:

CID 449815:         Memory - illegal accesses  (OVERRUN)
Overrunning array of 64 bytes at byte offset 64 by dereferencing pointer
"sctx->buffer + partial". [Note: The source code implementation of the
function has been overridden by a builtin model.]

In line: 252
   memset(sctx->buffer + partial, 0, SM3_BLOCK_SIZE - partial);

The respective line should be:

memset(sctx->buffer + partial, 0, SM3_BLOCK_SIZE - partial - 1);

as partial gets incremented by one before.

Signed-off-by: Heiko Schocher <hs@nabladev.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Pull request net-20260209.

net:
- airoha: mdio support for the switch
- phy: mscc: allow RGMII with internal delay for the VSC8541
- dwc_eth_qos: Update tail pointer handling

net-legacy:
- Stop conflating return value with file size in net_loop()

net-lwip:
- wget: rework the '#' printing
- tftp: add support of tsize option to client

Pull request efi-2026-04-rc2

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

Documentation:

* Remove pip from requirements.txt
* develop/process: Clarify name usage in the Signed-off-by line

UEFI:

* Improve EFI variable load message
* Fix use after free in efi_exit() with tcg2
* Fix efi_debug_image_info_normal allocation
* Add missing EFI_CALL in efi_net

The TFTP server can report the size of the entire file that is about to
be received in the Transfer Size Option, this is described in RFC 2349.
This functionality is optional and the server may not report tsize in
case it is not supported.

Always send tsize request to the server to query the transfer size,
and in case the server does respond, cache that information locally
in tftp_state.tsize, otherwise cache size 0. Introduce new function
tftp_client_get_tsize() which returns the cached tftp_state.tsize so
clients can determine the transfer size and use it.

Update net/lwip/tftp.c to make use of tftp_client_get_tsize() and
avoid excessive printing of '#' during TFTP transfers in case the
transfer size is reported by the server.

Submitted upstream: https://savannah.nongnu.org/patch/index.php?item_id=10557

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>

The only call site of gzwrite() is cmd/unzip.c do_gzwrite(), where
the 'len' parameter passed to gzwrite(..., len, ...) function is of
type unsigned long. This usage is correct, the 'len' parameter is
an unsigned integer, and the gzwrite() function currently supports
input data 'len' of up to 4 GiB - 1 .

The function signature of gzwrite() function in both include/gzip.h
and lib/gunzip.c does however list 'len' as signed integer, which
is not correct, and ultimatelly limits the implementation to only
2 GiB input data 'len' .

Fix this, update gzwrite() function parameter 'len' data type to
size_t consistently in include/gzip.h and lib/gunzip.c .

Furthermore, update gzwrite() function 'szwritebuf' parameter in
lib/gunzip.c from 'unsigned long' to 'size_t' to be synchronized
with include/gzip.h . Rewrite the other parameters to size_t and
off_t and propagate the change too.

Since the gzwrite() function currently surely only supports input
data size of 4 GiB - 1, add input data size check. The limitation
comes from the current use of zlib z_stream .avail_in parameter,
to which the gzwrite() function sets the entire input data size,
and which is of unsigned int type, which cannot accept any number
beyond 4 GiB - 1. This limitation will be removed in future commit.

Reported-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

The efi_reinstall_protocol_interface() function is a UEFI function;
make sure to call it from within U-Boot using the EFI_CALL() macro.

This fixes the following assertion:

  lib/efi_loader/efi_boottime.c:3752: efi_reinstall_protocol_interface: Assertion `__efi_entry_check()' failed.

To reproduce the issue, define LOG_DEBUG in lib/efi_loader/efi_boottime.c
and build u-boot for your platform. Then, boot the U-Boot helloworld.efi
application over the network. Example commands (adjust the URL and boot
entry number):

  => efidebug boot add -u 0 net http://10.0.2.2:8000/helloworld.efi
  => efidebug boot order 0
  => bootefi bootmgr

Fixes: dd5d82a59995 ("efi_loader: efi_net: Add device path cache")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Adriano Cordova <adrianox@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

When adding a new EFI Debug Image Info entry, we allocate memory for a new
EFI Debug Image Info Normal structure and we add a new entry into the EFI
Debug Image Info Table, which is in fact just a pointer to the allocated
structure.

However, when allocating memory for the new structure we allocate memory
for the wrong type, leading to allocating memory for just a pointer instead
of the desired structure.

Fix the type used during allocation.

Fixes: 146546138af5 ("efi: add EFI_DEBUG_IMAGE_INFO for debug")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Change the EFI variable load message from log_err() to log_info() with
neutral wording. The previous "Failed to load" message caused customer
confusion as it appeared to indicate an error condition.

The efi_var_from_file() function deliberately returns EFI_SUCCESS in
this case to allow the boot process to continue normally. This is
documented in the function's comment block but was not reflected in
the log message level or content.

The message now uses informational wording to reflect that this is
normal behavior when the ubootefi.var file does not yet exist.

Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>