Currently U-Boot uses ESP as storage for EFI variables.
Devices with SPI Flash are used for storing environment with this
commit we allow EFI variables to be stored on SPI Flash.
Signed-off-by: Shantur Rathore <i@shantur.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Every SetVariable() call triggers efi_var_mem_ins() followed by
efi_var_to_storage(), even when the variable value is not actually
changing. This is unfriendly to flash-backed stores that suffer
wear from unnecessary erase/write cycles.
Add a change-detection path to efi_var_mem_ins(): when size2 == 0
(i.e. not an append) and the caller passes a non-NULL changep flag,
look up the existing variable and compare attributes, length, time
and data byte-by-byte. If everything matches, set *changep = false
and return EFI_SUCCESS without touching the variable buffer.
Both efi_set_variable_int() and efi_set_variable_runtime() now
check the flag and skip efi_var_mem_del() / efi_var_to_storage()
when nothing changed.
Introduce efi_memcmp_runtime() - a runtime-safe byte-by-byte memory
comparison helper, following the same pattern as the existing
efi_memcpy_runtime(). The standard memcmp() is not available after
ExitBootServices() and calling it from Linux will crash.
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The value of buf->length comes from outside U-Boot and may be incorrect.
We must avoid to overrun our internal buffer for excessive values.
If buf->length is shorter than the variable file header, the variable
file is invalid.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Export the ECPT GUID, to prepare accessing it from more than one location.
The C file containing the GUID is compiled only when CONFIG_EFI_ECPT is
set; gate the export accordingly.
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>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add support for printing the EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID as human
readable text.
This is compiled in only when CONFIG_CMD_EFIDEBUG and CONFIG_EFI_EPCT are
set.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI specification requires at least 128 KiB stack space. Consider this
value as a prerequisite for CONFIG_EFI_LOADER.
Mention the requirement in the CONFIG_STACK_SPACE description and decribe
that the UEFI sub-system uses CONFIG_STACK_SPACE when defining the memory
map.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add NULL check after memalign() call in get_mem() to prevent
potential NULL pointer dereference (CWE-476).
The function memalign() can return NULL on allocation failure.
Dereferencing the returned pointer without checking for NULL
may cause a crash in low-memory conditions.
Changes:
- Add NULL check after memalign() allocation
- Return NULL on failure, consistent with function semantics
This fixes the static analyzer warning:
linux_compat.c:34: dereference of memalign return value without NULL check
Reported-by: static analyzer Svace
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Revert commit eb052cbb896f ("lmb: add and reserve memory above ram_top")
and commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from
same bank"). These are based on incorrect premise of the first commit, that
"U-Boot does not use memory above ram_top". While U-Boot itself indeed does
not and should not use memory above ram_top, user can perfectly well use
that memory from the U-Boot shell, for example to load content in there.
Currently, attempt to use that memory to load large image using TFTP ends
with "TFTP error: trying to overwrite reserved memory...". With this change
in place, the memory can be used again.
Fixes: eb052cbb896f ("lmb: add and reserve memory above ram_top")
Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
Reported-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Pull request net-20260312.
net:
- Move network PHY under NETDEVICES
- s/DM_CLK/CLK/ in HIFEMAC_{ETH,MDIO}
- Add support for Airoha AN8811HB PHY
- airoha: PCS and MDIO support for Airoha AN7581 SoC
net-lwip:
- Fix issue when TFTP blocksize is >8192
- Adjust PBUF_POOL_SIZE/IP_REASS_MAX_PBUFS for better performance and
resource usage.
- Enable mii command for NET_LWIP
TFTP transfers fail when tftpblocksize is set to 8192 or larger due to
insufficient buffer resources for IP fragment reassembly.
Calculate PBUF_POOL_SIZE and IP_REASS_MAX_PBUFS dynamically based on
CONFIG_TFTP_BLOCKSIZE using IP fragmentation boundaries (1480 usable
bytes per fragment at 1500 MTU). The pool size includes headroom for
TX, ARP, and protocol overhead, while ensuring PBUF_POOL_SIZE remains
greater than IP_REASS_MAX_PBUFS as required by lwIP.
Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com>
The PBUF_POOL_BUFSIZE ends up being only 592 bytes, instead of 1514,
when PROT_TCP_LWIP Kconfig option is disabled. This results in a full
Ethernet frame requiring three PBUFs instead of just one.
This happens because the PBUF_POOL_BUFSIZE constant depends on the value
of a TCP_MSS constant, something that defaults to 536 when PROT_TCP_LWIP
is disabled.
PBUF_POOL_BUFSIZE = LWIP_MEM_ALIGN_SIZE(TCP_MSS + 40 + PBUF_LINK_HLEN)
Ensure that a full Ethernet frame fits inside a single PBUF by moving
the define of TCP_MSS outside the PROT_TCP_LWIP ifdef block.
Fixes: 1c41a7afaa15 ("net: lwip: build lwIP")
Acked-by: Jerome Forissier <jerome.forissier@arm.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Add minimal infrastructure to build SPL images with support for UFS
storage devices. This also pulls in SCSI support and charset functions,
which are dependencies of the UFS code.
With this, only a fixed offset is supported for loading the next image,
which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the
number of 4096-byte sectors into the UFS block device.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20260120-rk3576-ufs-v5-1-0edb61b301b7@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Fix a few UEFI function names, as well as a typo.
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>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add a test calling the LoadImage() UEFI function with both its SourceBuffer
and DevicePath input arguments equal to NULL.
This test can be run on the sandbox with the following command:
./u-boot -T -c "setenv efi_selftest load image from file; \
bootefi selftest"
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>
When the LoadImage() UEFI function is called with both its SourceBuffer and
DevicePath input arguments equal to NULL, it must return EFI_NOT_FOUND [1].
However, it does return EFI_INVALID_PARAMETER instead; fix it.
Link: https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html#efi-boot-services-loadimage [1]
Reported-by: Sathisha Shivaramappa <sathisha.shivaramappa@arm.com>
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>
Raymond Mao <raymondmaoca@gmail.com> says:
From: Raymond Mao <raymond.mao@riscstar.com>
This series finish the last missing puzzle of required SMBIOS types by:
1) Fixing duplicated handles when multiple instances exist in one type;
2) Implementing the rest of required types 9/16/17/19;
3) Adding version control when printing properties for all types.
Type 9/16/17/19 are generally DT-based, the idea is to write these tables
using a hybrid approach:
Explicit DT definitions under existing '/smbios/smbios' take precedence,
with fallback to scan and interpret values from the entire DT.
Moreover, all below APIs:
smbios_get_val_si()
smbios_get_u64_si()
smbios_add_prop_si()
are on top of sysinfo, thus allow vendors to get values from other
subsystems by implementing their own sysinfo driver if needed.
Link: https://lore.kernel.org/r/20260213225254.2544596-1-raymondmaoca@gmail.com
This commit implements SMBIOS Type 19 (Memory Array Mapped Address)
generation with a hybrid approach supporting both:
1. Explicit definition via Device Tree 'smbios' node:
Child node under '/smbios/smbios/memory-array-mapped-address' will be
used to populate as individual Type 19 structure directly.
- Properties follow SMBIOS field names with lowercase letters and
hyphen-separated words (e.g., 'starting-address', 'ending-address',
'partition-width', etc.).
- This method supports precise platform-defined overrides and system
descriptions.
2. Fallback to automatic DT-based discovery:
If child node under '/smbios/smbios/memory-array-mapped-address' does
not exist, the implementation will:
- Scan all top-level 'memory@' nodes to populate Type 19 structure with
inferred size and location data.
- Scan nodes named or marked as 'memory-controller' and parse
associated 'dimm@' subnodes (if present) to extract DIMM sizes and
map them accordingly.
This dual-mode support enables flexible firmware SMBIOS reporting while
aligning with spec-compliant naming and runtime-detected memory topology.
Type 19 support is under GENERATE_SMBIOS_TABLE_VERBOSE to avoid
increasing rom size for those platforms which only require basic SMBIOS
support.
Signed-off-by: Raymond Mao <raymondmaoca@gmail.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This commit implements SMBIOS Type 17 (Memory Device) generation with a
hybrid approach supporting both:
1. Explicit definition via Device Tree 'smbios' node:
Child node under '/smbios/smbios/memory-device' will be used to
populate as individual Type 17 structure directly.
- Properties follow SMBIOS field names with lowercase letters and
hyphen-separated words (e.g., 'physical-memory-array-handle',
' memory-error-information-handle', 'configured-memory-speed', etc.).
- This method supports precise platform-defined overrides and system
descriptions.
2. Fallback to automatic DT-based discovery:
If child node under '/smbios/smbios/memory-device' does not exist,
the implementation will:
- Scan all top-level 'memory@' nodes to populate Type 17 structure with
inferred size and location data.
- Scan nodes named or marked as 'memory-controller' and parse
associated 'dimm@' subnodes (if present) to extract DIMM sizes and
map them accordingly.
This dual-mode support enables flexible firmware SMBIOS reporting while
aligning with spec-compliant naming and runtime-detected memory topology.
Type 17 support is under GENERATE_SMBIOS_TABLE_VERBOSE to avoid
increasing rom size for those platforms which only require basic SMBIOS
support.
Signed-off-by: Raymond Mao <raymondmaoca@gmail.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This commit implements SMBIOS Type 16 (Physical Memory Array)
generation with a hybrid approach supporting both:
1. Explicit definition via Device Tree 'smbios' node:
Child node under '/smbios/smbios/memory-array' will be used to
populate as individual Type 16 structure directly.
- Properties follow SMBIOS field names with lowercase letters and
hyphen-separated words (e.g., 'memory-error-correction',
'maximum-capacity', 'extended-maximum-capacity', etc.).
- This method supports precise platform-defined overrides and system
descriptions.
2. Fallback to automatic DT-based discovery:
If child node under '/smbios/smbios/memory-array' does not exist,
the implementation will:
- Scan all top-level 'memory@' nodes to populate Type 16 structure with
inferred size and location data.
- Scan nodes named or marked as 'memory-controller' and parse
associated 'dimm@' subnodes (if present) to extract DIMM sizes and
map them accordingly.
This dual-mode support enables flexible firmware SMBIOS reporting while
aligning with spec-compliant naming and runtime-detected memory topology.
Type 16 support is under GENERATE_SMBIOS_TABLE_VERBOSE to avoid
increasing rom size for those platforms which only require basic SMBIOS
support.
Signed-off-by: Raymond Mao <raymondmaoca@gmail.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This commit introduces support for generating SMBIOS Type 9 (System Slot)
tables using a hybrid approach:
1. Explicit Device Tree definitions:
Child node under '/smbios/smbios/system-slot' will be interpreted as
individual slot definitions.
- Each child represents a slot (e.g., isa, pcmcia, etc.).
- Properties follow the SMBIOS specification using lowercase
hyphen-separated names such as 'slot-type', 'slot-id',
'segment-group-number', 'bus-number', 'slot-information', etc.
- This approach allows full customization of each system slot and is
especially suitable for platforms with well-defined slot topology.
2. Automatic detection fallback:
If child node under '/smbios/smbios/system-slot' does not exist, the
implementation will scan the entire device tree for nodes whose
'device_type' matches known slot-related types ("pci", "isa", "pcmcia",
etc.).
- When a match is found, default values or heuristics are applied to
populate to the System Slot table.
- This mode is useful for platforms that lack explicit SMBIOS nodes
but still expose slot topology via standard DT conventions.
Together, two approaches ensure that SMBIOS Type 9 entries are available
whether explicitly described or automatically derived.
Signed-off-by: Raymond Mao <raymondmaoca@gmail.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Some smbios types can have multiple instances (e.g. Type 7, 9, 16, 17,
19), thus the 'handle' argument should be a pointer so that the value
can be accumulated when writing all the instances.
This also fix the observed duplicated Type 7 handles.
Fixes: bcf456dd369e ("smbios: add detailed smbios information")
Signed-off-by: Raymond Mao <raymondmaoca@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Peng Fan (OSS) <peng.fan@oss.nxp.com> says:
This patch set primarily removes unused DECLARE_GLOBAL_DATA_PTR
instances.
Many files declare DECLARE_GLOBAL_DATA_PTR and include
asm/global_data.h even though gd is never used. In these cases,
asm/global_data.h is effectively treated as a proxy header, which is
not a good practice.
Following the Include What You Use principle, files should include
only the headers they actually depend on, rather than relying on
global_data.h indirectly. This approach is also adopted in Linux kernel
[1].
The first few patches are prepartion to avoid building break after
remove the including of global_data.h.
A script is for filtering the files:
list=`find . -name "*.[ch]"`
for source in ${list}
do
result=`sed -n '/DECLARE_GLOBAL_DATA_PTR/p' ${source}`
if [ "${result}" == "DECLARE_GLOBAL_DATA_PTR;" ]; then
echo "Found in ${source}"
result=`sed -n '/\<gd\>/p' ${source}`
result2=`sed -n '/\<gd_/p' ${source}`
result3=`sed -n '/\<gd->/p' ${source}`
if [ "${result}" == "" ] && [ "${result2}" == "" ] && [ "${result3}" == "" ];then
echo "Cleanup ${source}"
sed -i '/DECLARE_GLOBAL_DATA_PTR/{N;/\n[[:space:]]*$/d;s/.*\n//;}' ${source}
sed -i '/DECLARE_GLOBAL_DATA_PTR/d' ${source}
sed -i '/global_data.h/d' ${source}
git add ${source}
fi
fi
done
[1] https://lpc.events/event/17/contributions/1620/attachments/1228/2520/Linux%20Kernel%20Header%20Optimization.pdf
CI: https://github.com/u-boot/u-boot/pull/865
Link: https://lore.kernel.org/r/20260209-cleanup-v2-0-73a3a84ddbdb@nxp.com
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
EFI_VARIABLE_FILE_STORE is only available when FAT_WRITE is enabled but
that's not valid for all platforms and dependency should be covered.
Also Kconfig behavior is that if default option is not valid then Kconfig
selects the first presented valid option instead hence it is better to
record EFI_VARIABLE_NO_STORE as safe default option.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_var_to/from_file() suggest method where variables are placed. But there
is no reason for it and generic name can be used to wire also different
locations for variables.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently efi_var_file.c has functions to store/read
EFI variables to/from memory buffer. These functions
can be used with other EFI variable stores so move
them out to efi_var_common.c
Signed-off-by: Shantur Rathore <i@shantur.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The EFI_PARTITION_INFO_PROTOCOL test was added before the protocol fully
supported MBR partitions. As a result, it lacked specific checks for the
content of the raw MBR partition record.
Now that MBR support has been implemented, enhance the selftest to provide
coverage for the MBR entries too.
This verifies that the protocol correctly reads and exposes MBR partition
records and prevents this functionality to regress due future changes.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The EFI_PARTITION_INFO_PROTOCOL provides detailed information about
partitions. The UEFI specification mentions that both GPT and MBR
partition schemes are supported, but the U-Boot implementation only
supports the former.
This can cause compatibility issues for platforms whose boot ROM only
supports MBR. This change adds support for MBR partition tables to
the protocol, making U-Boot compatible with systems that require a
legacy MBR table.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
Add get_next_memory_node() function declaration to fdtdec.h to support
iterating through multiple memory nodes in device tree. This function
is used to enumerate memory banks when the system has non-contiguous
or multiple memory regions defined with device_type = "memory".
The function implementation already exists in lib/fdtdec.c (lines
1298-1305) but was missing the public declaration in the header file.
This patch adds the declaration and includes dm/ofnode_decl.h for the
ofnode type definition.
This is needed for platforms that require early memory enumeration
before standard fdtdec_setup_memory_banksize() is called, particularly
for dynamic MMU page table size calculation based on actual DRAM
configuration.
Signed-off-by: Pranav Sanwal <pranav.sanwal@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20260129120021.1328653-2-pranav.sanwal@amd.com
When boot_idx differs from active_idx at boot time, it indicates a
rollback scenario where the firmware update failed and the system
reverted to the previous working bank. In this case, mark the failed
bank (active_idx) as invalid to prevent future boot attempts from that
bank.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Change fwu_state_machine_updates() to accept an enum fwu_bank_states
parameter instead of a boolean. This makes the function interface more
explicit and prepares for adding FWU_BANK_INVALID support to handle
boot failures on the active bank.
Convert the FWU_BANK_* defines to an enum and update all call sites
accordingly.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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
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>
The efi_exit() function frees the loaded image memory by calling
efi_delete_image(). However, when CONFIG_EFI_TCG2_PROTOCOL is enabled, the
image_obj->image_type structure member is accessed after the memory has
been freed.
Fix this by performing the tcg2 measurement before the image deletion.
Fixes: 8fc4e0b4273a ("efi_loader: add boot variable measurement")
Suggested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Masahisa Kojima <kojima.masahisa@socionext.com>
Acked-by: Masahisa Kojima <kojima.masahisa@socionext.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
sprintf will add a trailing \0 so manually adding a trailing \0 will
result in an extra unaccounted for character being written. This
overwrote the first byte of the following allocation block resulting in
unexpected behavior.
This was found by Running 'pxe get' with no available file resulting in
multiple attempts, using the default algorithm, to attempt to find a file.
Eventually there would be a failed assert when free() was called.
Failing the assert would result in a system reset.
Fixes: 27d7ccda94fa ("net: lwip: tftp: add support of blksize option to client")
Reported-by: Michal Simek <michal.simek@amd.com>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Tested-by: Tom Rini <trini@konsulko.com> # Pine64+
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Make crypt_compare() accessible from board-specific code
by removing its dependency on the autoboot feature.
Signed-off-by: Tomas Paukrt <tomaspaukrt@email.cz>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tom Rini <trini@konsulko.com> says:
A long while ago, Darek reported that our copy of the LZMA SDK library
is quite old and so vulnerable to at least one possible security issue
he found that was fixed upstream.
This does a few things. First, we introduce a Kconfig option
to enable LZMA's size reduction option, and enable it on
gardena-smart-gateway-mt7688. This is not critical at the start, but is
as we move forward. Next, we move all the way from version 9.20 of the
LZMA SDK to version 25.01. The few deviations from upstream are the
changes we've already made to the files and are documented in our
history. Finally, we add SPDX tags to the code we've imported from the
LZMA SDK (and upstream has been asked if they're interested in this).
Link: https://lore.kernel.org/u-boot/CAC7rXdTb5u5pzP-mr_+pddCxzfcO8Vm_t-=_+5wxRitMjy6-JA@mail.gmail.com/
Link: https://lore.kernel.org/r/20251218233654.3938385-2-trini@konsulko.com
After consulting https://spdx.org/licenses/ this code should be tagged
with the LZMA-SDK-9.22 identifer, so add them.
Signed-off-by: Tom Rini <trini@konsulko.com>
