| Age | Commit message (Collapse) | Author |
|---|
|
https://source.denx.de/u-boot/custodians/u-boot-ufs into next
- ufs_hba_ops callbacks cleanup
- Rockchip UFS reset support
- UFS support in SPL
|
|
https://source.denx.de/u-boot/custodians/u-boot-net into next
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Alexey Charkov <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Prepare v2026.04-rc4
|
|
Fix a few UEFI function names, as well as a typo.
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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é <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
Prepare v2026.04-rc3
|
|
tooling"
Raymond Mao <[email protected]> says:
From: Raymond Mao <[email protected]>
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/[email protected]
|
|
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 <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
Peng Fan (OSS) <[email protected]> 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/[email protected]
|
|
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 <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <[email protected]> #TI boards
Acked-by: Yao Zi <[email protected]> #TH1520
Signed-off-by: Peng Fan <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
AMD/Xilinx/FPGA changes for v2026.07-rc1
gpio:
- Add gpio delay driver
zynqmp:
- Wire gpio usb delay
- Enable SPL pinctrl per pin
xilinx:
- Enable NFS support
versal2:
- Extend DDR initialization
zynqmp-rtc:
- Use clock framework for calibration value
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on AML-S905D3-CC
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on AML-S905D3-CC
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Jose Marinho <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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é <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Masahisa Kojima <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Acked-by: Masahisa Kojima <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
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
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
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 <[email protected]>
Acked-by: Jerome Forissier <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
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é <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Adriano Cordova <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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é <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Ying-Chun Liu (PaulLiu) <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Masahisa Kojima <[email protected]>
Acked-by: Masahisa Kojima <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Tested-by: Michal Simek <[email protected]>
Signed-off-by: Andrew Goodbody <[email protected]>
Tested-by: Tom Rini <[email protected]> # Pine64+
Reviewed-by: Jerome Forissier <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Make crypt_compare() accessible from board-specific code
by removing its dependency on the autoboot feature.
Signed-off-by: Tomas Paukrt <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Tom Rini <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
|
|
Currently, we have a copy of the LZMA SDK code, version 9.20, with small
updates. The original import of the LZMA SDK included a script to update the
library. This is no longer possible, due to important local changes, so
remove it. We also remove a number of extra text files that should be
unchanged from upstream, but provide no direct value to the project.
Instead, have the help text for LZMA note that this comes from the LZMA
SDK.
Next, we move our code up to the current release, 25.01. There are a
number of new header files, and some performance improvements made to
the code, at the cost of between 2 to 3 kilobytes in binary size. As
there is now a Kconfig option to disable this and retain similar speed
to what we have currently, the default option is to make this trade-off.
Our changes to the code around calling schedule() to avoid the watchdog
being triggered are kept. We add __UBOOT__ guards in two places to
prevent conflict with our own usage of these words on MIPS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Currently, our LZMA library has an option for optimizing for size,
rather than speed. It is a minimal savings today, and has not been worth
enabling. As this will change in the near future, add options now to
allow disabling it in full U-Boot or in SPL, and enable these on
gardena-smart-gateway-mt7688 which is very close to the size limit
today.
Reviewed-by: Stefan Roese <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Our last sync with the kernel was 5.1.
We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.
This is an attempt to sync up Makefiles to 6.1.
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call for the bump to 5.1,
so we are following the same guidelines here.
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>a #rebased on -next
|
|
Assigning a single variable to section __efi_runtime_date while the rest of
the test is in the boottime section does not make much sense.
As we do not set a virtual address map here, we don't need a runtime
section.
Update the variables at runtime test.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The EFI spec in §8.5.5 says
"The directory \EFI\UpdateCapsule is checked for capsules only within
the EFI system partition on the device specified in the active boot
option determine by reference to BootNext variable or BootOrder variable
processing."
Automatically generated boot options don't point to the ESP, they point to
the disk itself and find_handle() won't match when searching for an ESP
during a capsule update.
This happens because find_handle() only matches device paths that are
shorter or equal to the device path passed as an argument.
Since the EFI spec allows it we want to allow capsule updates, when the
boot option points to a disk, but that disk contains an ESP with a
\EFI\UpdateCapsule directory.
So, let's change device_is_present_and_system_part() and check if the
supplied device path contains an ESP. If it does return the handle of
the device. Otherwise, iterate over child devices and return the handle
of the first child that contains an ESP.
The returned handle can then be reused later. Rather than calling
efi_fs_from_path(), we can simply look up the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
on the discovered handle, avoiding the need to re-parse device paths.
Reported-by: Balaji Selvanathan <[email protected]>
Reported-by: John Toomey <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Check that only a file system installed on a handle for the
device-path node immediately preceding the file path node is
used for LoadImage().
LoadImage() ends up invoking efi_dp_find_obj(). This test helped to
demonstrate an issue in a suggested patch to change that function.
The test can be run with:
setenv efi_selftest load image from file
bootefi selftest
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
|
|
constants"
Quentin Schulz <[email protected]> says:
This does a bit of "cleanup" by reusing constants for some FIT
properties instead of having the same string in multiple places.
Additionally, this adds a new constant for the compatible property in
FIT configuration nodes[1] which is useful for FIT images with multiple
FIT configuration nodes to support multiple devices in the same blob.
U-Boot will try to figure out which node to select based on that
compatible[2].
However, if this property is missing (and the first blob in the fdt
property of the configuration node is uncompressed), the compatible from
the root node of the associated kernel FDT will be used for the
autoselection mechanism. For now, I only print the property if it
exists, but maybe it'd make sense to expose the fallback one if it's
missing. I guess we can implement that later on if desired.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Link: https://lore.kernel.org/r/[email protected]
|
