| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "lib":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Prepare v2026.07-rc5
|
|
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data")
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]>
|
|
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol [1]
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Barebox has now ported some of the UEFI code. In the process
they found some bugs.
In this case when the variable buffer is too small, efi_var_collect()
returns EFI_BUFFER_TOO_SMALL but doesn't free the allocated 'buf'.
Fixes: 5f7dcf079de8c ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
1. Loaded Image Device Path Protocol GUID
2. Loaded Image Protocol GUID
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Alexander Graf <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Tom Rini <[email protected]> says:
As part of the resync to dtc version v1.7.2-35-g52f07dcca47c from the
Linux Kernel, we missed updating the fdt_check_full function because it
exists in its own file in upstream dtc and the kernel doesn't import it,
as reported by Anton Ivanov. This short series brings in the upstream
fdt_check.c file and then implements our size-saving option, but in the
modern way.
The size-saving portion has been upstreamed.
Link: https://lore.kernel.org/r/[email protected]
|
|
In the upstream project, the function fdt_check_full has been moved from
fdt_ro.c to its own file, fdt_check.c. This file is not included in the
Linux kernel copy and so has not been synced over. As we do need and use
the fdt_check_full function, bring that file over as of the current
upstream we are synced to. Remove our copy of this function from
fdt_ro.c and add fdt_check.o and 1-liner fdt_check.c where needed. Note
that for now, this will increase size in some cases as upstream does not
have a size reduction method here.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Loading EFI parts like a Debian-Installer on Rockchip SoCs creates
interesting results, in that on some boards the Grub bootloader can't
find any partitions on a USB-Stick, or loading a kernel from Grub spews
EHCI fail timeout STS_IAA set
messages before failing and on others the loading something like efivars
from an eMMC creates read errors and making the MMC vanish from U-Boot.
This only affected boards with at least 4GB of RAM.
These boards have at least 256MB of memory placed above the actual 4GB
address space (due to the iomem being in between) and while kernel,
initramfs, dt are generally loaded to predefined addresses, additional
EFI parts (efivars, etc) are likely just loaded "somewhere" and it seems
this always landed in that higher up memory part.
Also in the Linux-kernel peripherals like EMMC, USB, etc already run
with a 32bit dma-mask set.
So far, I've seen this on RK3568 and RK3588, but as the same peripherals
are used on most Rockchip SoCs, it makes sense to limit this on all.
So add ARCH_ROCKCHIP to the default-y list of LMB_LIMIT_DMA_BELOW_RAM_TOP.
Signed-off-by: Heiko Stuebner <[email protected]>
Reviewed-by: Jonas Karlman <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
[email protected] <[email protected]> says:
From: Randolph Sapp <[email protected]>
Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support
[1]. This does a lot of general setup required for the device, but these
modifications themselves aren't device specific. For those specifically
interested in PocketBeagle2 support and don't care about these details, my
development branch is public [2].
That first patch may provoke some opinions, but honestly if that warning was
still present I wouldn't have spent a week poking holes in both the EFI and LMB
allocations systems. Please let me know if there is a specific usecase that it
breaks though.
[1] https://lore.kernel.org/all/[email protected]/
[2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a new global data struct member called initial_relocaddr. This
stores the original value of relocaddr, directly from setup_dest_addr.
This is specifically to avoid any adjustments made by other init
functions.
Reserve the memory from gd->start_addr_sp - CONFIG_STACK_SIZE to
gd->initial_relocaddr instead of gd->ram_top. This allows platform
specific relocation addresses to work without unnecessarily painting
over a large range.
Signed-off-by: Randolph Sapp <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-07-rc5
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/30365
Documentation:
* Update urllib3 version for building
* usb: typos 'requird', 'current'
UEFI
* Improve PE-COFF relocation data validation
Devicetree-to-C generator:
* dtoc: test: add missing escape in help text
|
|
Prepare v2026.07-rc4
|
|
smbios_write_type3() uses SYSID_SM_BASEBOARD_ASSET_TAG (Type 2) instead
of SYSID_SM_ENCLOSURE_ASSET_TAG (Type 3) for the enclosure asset tag.
This causes the enclosure's asset tag to be read from the baseboard
sysinfo field rather than the enclosure-specific one.
Fixes: bcf456dd ("smbios: add detailed smbios information")
Signed-off-by: Frank Böwingloh <[email protected]>
Cc: Raymond Mao <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
Rename LMB_LIMIT_DMA_BELOW_4G to LMB_LIMIT_DMA_BELOW_RAM_TOP
to make the Kconfig option more descriptive. No functional
change.
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When applying base relocations from a PE-COFF binary all data must
be treated as untrusted. Add the following checks to
efi_loader_relocate():
* Reject relocation blocks that don't start on a 32-bit aligned
address.
* Reject relocation blocks whose SizeOfBlock is smaller than the
block header, which would cause an unsigned underflow when computing
the entry count.
* A block with SizeOfBlock == 0 is invalid and does not mark the end of
the relocation table.
* Reject relocation blocks that extend beyond the end of the
relocation section.
* Reject individual relocation entries whose target offset, together
with the access width, exceeds the mapped image size, preventing
out-of-bounds writes.
Pass virt_size to efi_loader_relocate() from efi_load_pe() to enable
the per-entry bounds check.
Reported-by: Anas Cherni <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Some architectures can not DMA above 4 GiB boundary,
limit available memory to memory below 4 GiB boundary.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]> #rpi4 8GiB
|
|
Tom Rini <[email protected]> says:
This series does a few small but important cleanups to how we check for,
and initialize a bloblist. The first thing is that the way things are
done today, our HANDOFF code can only work with a fixed bloblist
location, so express that requirement in Kconfig. Next, we demote the
scary message about "Bloblist at ... not found" to a debug because we
most often see that because the bloblist doesn't (and can't) exist yet.
Finally, we remove bloblist_maybe_init and split this in to an exists
and a real init. This results in practically no growth (between 8 bytes
growth to 12 bytes saved, with some outliers saving much more thanks to
knowing it's impossible to have been passed a bloblist yet). This also
cleans up some of the code around checking for / knowing about a
bloblist existing.
Link: https://lore.kernel.org/r/[email protected]
|
|
With bloblist, we need to both see if one already exists as well as
create one if it does not. However, the current implementation leads to
odd cases where we attempt to create a bloblist before this is possible
and have things be overly complicated when we are given one to work
with.
This reworks things to instead have a bloblist_exists function, which as
the name implies checks for an existing bloblist. This is used in
the case of booting, to see if we have one and in turn if we have a
device tree there as well as in the bloblist_init function to see if we
need to do anything.
In practical details, we move the logic from bloblist_init that was
checking for a bloblist to the new bloblist_exists function and then can
clarify the logic as it is much easier to state when we know we do not
have one rather than all the ways we might have one. Then we have the
locations that set gd->bloblist now also set the GD_FLG_BLOBLIST_READY
flag.
Reviewed-by: Raymond Mao <[email protected]>
Tested-by: Alexander Stein <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Prepare v2026.07-rc3
|
|
The HII database test for keyboard layouts register two package lists with
two keyboard layouts each, but the test verifies only the GUID of the first
keyboard layout.
This does not catch the bugs happening with the keyboard layouts after the
first one in a package.
Verify all the keyboard layout GUIDs in the unit test to prevent this.
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
The EFI_HII_KEYBOARD_LAYOUT field `layout_length' is expressed in bytes,
but we add it to the `layout' pointer with (scaled) pointer arithmetic.
When adding an HII keyboard package with multiple keyboard layouts, this
results in only the first layout being added correctly; fix it.
Fixes: 8d3b77e36e10 ("efi: hii: add keyboard layout package support")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: AKASHI Takahiro <[email protected]>
|
|
Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS overlap
When efi_allocate_pages() is called with EFI_ALLOCATE_ADDRESS, UEFI
expects EFI_NOT_FOUND if the requested address range is already
allocated or unavailable. U-Boot currently returns
EFI_OUT_OF_RESOURCES when efi_update_memory_map() detects an overlap
after a successful lmb_alloc_mem(), which does not match
EFI_ALLOCATE_ADDRESS semantics.
Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS requests that fail due
to an overlapping EFI memory descriptor, while keeping
EFI_OUT_OF_RESOURCES for other allocation types.
The UEFI specification [1] specifies that
EFI_BOOT_SERVICES.AllocatePages must return EFI_NOT_FOUND when the
requested address range is unavailable or already allocated;
EFI_OUT_OF_RESOURCES applies to non‑address‑specific allocation
failures.
[1] https://uefi.org/specs/UEFI/2.10_A/07_Services_Boot_Services.html
Signed-off-by: Harsimran Singh Tungal <[email protected]>
The UEFI specification does not clearly specify the behavior.
But let's follow the EDK II precedent here.
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The smbios_get_val_si() function may get called for a sysinfo
property for which there is no mapping to a devicetree property.
Avoid a NULL pointer dereference in this case by skipping the
read of the mapped property from the device tree.
Fixes: 83b28b55d74f ("smbios: add support for dynamic generation of Type 9 system slot tables")
Signed-off-by: Mark Kettenis <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
There are quite a few places where we allocate X+1 bytes, initialize
the first X bytes via memcpy() and then set the last byte to 0.
The kernel has a helper for that, kmemdup_nul(). Introduce a similar
one, and start making use of it in a few places. Also the existing
memdup() helper can be put to more use.
There are lots more places one could modify. But for code shared with
host tools, one would need to do some refactoring, putting memdup()
and memdup_nul() in their own str-util.c TU which could then also be
included in the tools build.
Link: https://lore.kernel.org/r/[email protected]
|
|
We have memdup_nul() for exactly this pattern of duplicating a block
of memory and ensuring there's a nul byte after the copy.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
With the addition of memdup_nul(), strdup() and strndup() can be
implemented as one-liners.
While not required by POSIX or C, do keep the behaviour of gracefully
accepting a NULL source and simply return NULL.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
This is completely analogous to the linux kernel's kmemdup_nul()
helper, apart from the lack of the gfp_t argument: Allocate a buffer
of size {len}+1, copy {len} bytes from the given buffer, and add a
final nul byte.
This pattern exists in a number of places, so this helper can reduce
some boilerplate code.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
There has never been an arch-specific optimized implementation of
str[n]dup, nor is there likely to ever be one, because unlike their
cousins strlen(), strcpy() and similar that simply read/write the
src/dst, the dup functions by definition involve memory allocation. So
drop this irrelevant cpp guard.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
It doesn't make sense to restrict memdup() to only return char*
pointers, especially when it is already defined to accept void*. This
makes it uglier to use to e.g. duplicate a struct.
Make it return void*, just as kmemdup() does in the kernel (and which
our kmemdup() in fact also does).
While in here, make a small optimization: memcpy() is defined to
return the destination register, so we write this in a way that the
compiler may do a tail call.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Introduce fwu_mdata_get_image_guid() to retrieve a specific image GUID
from the FWU metadata based on the bank index and image type GUID.
This allows identifying the correct partition in multi-bank (A/B)
scenarios, ensuring the correct image is targeted depending on the
current bank.
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The Extended Boot Loader Partition (XBOOTLDR) is a standard defined by
the Discoverable Partitions Specification (DPS) to host boot loader
resources outside of the EFI System Partition ([1], [2]).
Defining this GUID (bc13c2ff-59e6-4262-a352-b275fd6f7172) allows U-Boot
to correctly identify and label these partitions using the "xbootldr"
shorthand.
[1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/#extended-boot-loader-partition:~:text=UEFI%20Specification.-,Extended%20Boot%20Loader%20Partition,-bc13c2ff%2D59e6%2D4262
[2] https://uapi-group.org/specifications/specs/boot_loader_specification/
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When creating the RSDT and the XSDT table they contain no entries.
The table size therefore must equal the header size.
Without this change a NULL deference has been observed in
acpi_find_table() when running `ut dm` on sandbox64_defconfig
executed via `sudo ./u-boot -D`.
Fixes: 94ba15a3f13f ("x86: Move base tables to a writer function")
Fixes: 7e586f69070d ("acpi: Put table-setup code in its own function")
Fixes: ab5efd576c4e ("x86: acpi: Adjust order in acpi_table.c")
Fixes: 867bcb63e79f ("x86: Generate a valid ACPI table")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Update dm_test_acpi_ctx_and_base_tables() in test/dm/acpi.c to expect
sizeof(struct acpi_table_header) for the initial table length (instead
of sizeof(*rsdt) / sizeof(*xsdt)), and to compute the checksum over
header->length bytes rather than the full struct size:
Signed-off-by: Simon Glass <[email protected]>
|
|
Coverity Scan defects are observed in fdtdec_apply_bloblist_dtos(),
since the live FDT taken from the bloblist is passed to libfdt helpers
which consume header size/offset fields:
- fdt_open_into()
- fdt_pack()
Validate the bloblist FDT with fdt_check_full() before calling
fdt_open_into() and again after applying overlays before calling
fdt_pack(). This makes the libfdt consumers operate on a checked FDT
blob while keeping the existing flow unchanged.
Also normalize libfdt return codes from this path to errno values,
including the overlay callback path through bloblist_apply_blobs().
Fixes: b70cbbfbf94f ("fdtdec: apply DT overlays from bloblist")
Addresses-Coverity-ID: CID 645837: (TAINTED_SCALAR)
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
|
|
Use list_for_each_entry_safe and comparisons against the current and
next efi_mem_desc. This reduces the computation required for merging
regions, prevents unnecessary additional iterations of the list, and
requires less temporary values.
Signed-off-by: Randolph Sapp <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Check for duplicate memory mappings before reporting any incorrect
attributes. Could be that second allocation has the correct type while
the first doesn't. Knowing there is a duplicate in this scenario is
more helpful than just reporting the first mismatch.
Signed-off-by: Randolph Sapp <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Use the more straightforward fdtdec_get_bool instead of fdt_getprop and
a return code check.
Signed-off-by: Randolph Sapp <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When using lwIP, efi_dp_from_http() may fail to initialize ip or mask.
Initialize the variables before the call.
Addresses-Coverity-ID: 645840 - Uninitialized variables (UNINIT)
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The fdt_pack() function can return an error code, but its return value
was not being checked. Add proper error handling to propagate any
failure.
Also fix typo in comment: "Shink" -> "Shrink".
Addresses-Coverity-ID: CID 645839: Error handling issues (CHECKED_RETURN)
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
If efi_init_obj_list() fails we cannot use the UEFI sub-system.
* Instead of having messages for this everywhere write an error message
in efi_init_obj_list().
* Always use (ret != EFI_SUCCESS) when checking the return value of
efi_init_obj_list().
* Remove the return code from the error message as it does not help
users to understand which initialization went wrong.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
efi_binary_run_dp() is expected to return an efi_status_t value.
Reported-by: Simon Glass <[email protected]>
Fixes: 6422820ac3e5 ("efi_loader: split unrelated code from efi_bootmgr.c")
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
efi_bootmgr_run() is expected to return an efi_status_t value.
Reported-by: Simon Glass <[email protected]>
Fixes: 0bef4b0123f2 ("cmd: bootefi: move library interfaces under lib/efi_loader")
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
As exposed by "make randconfig", we have an issue with the dependencies
for EFI_HTTP_BOOT. As this is implemented by running commands (as seen
by what it selects) it must depend on CMDLINE as well.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Quentin Schulz <[email protected]> says:
This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.
The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?
No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.
This was tested based on 70fd0c3bb7c2 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.
#!/usr/bin/env bash
set -o pipefail
set -eux
ARGS="-BvelPEWM --reproducible-builds --step 0"
./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $*
./tools/buildman/buildman -o ${O} $ARGS -Ssd $*
O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt
I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.
The summary is the following:
aarch64: (for 537/537 boards) all +0.0 rodata +0.0
uniphier_v8 : all +1 rodata +1
u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
function old new delta
data_gz 10640 10641 +1
arm: (for 733/733 boards) all -0.0 rodata -0.0
uniphier_v7 : all -1 rodata -1
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
function old new delta
data_gz 11919 11918 -1
opos6uldev : all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 18778 18775 -3
uniphier_ld4_sld8: all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 11276 11273 -3
stemmy : all -20 rodata -20
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
function old new delta
data_gz 15783 15763 -20
As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.
Here is the diff for the 5 defconfigs listed above, generated with:
for f in build/*-m; do
diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done
(-m is the build directory for master, and without the suffix, it's the
top commit of this series)
"""
--- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200
+++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200
@@ -970,4 +969,0 @@
-
-#
-# Networking
-#
@@ -975,0 +972 @@
+CONFIG_NET_LEGACY=y
--- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200
+++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200
@@ -733,4 +732,0 @@
-
-#
-# Networking
-#
@@ -738,2 +733,0 @@
-# CONFIG_NET is not set
-# CONFIG_NET_LWIP is not set
--- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200
+++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200
@@ -997,4 +996,0 @@
-
-#
-# Networking
-#
@@ -1002,0 +999 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200
+++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200
@@ -1004,4 +1003,0 @@
-
-#
-# Networking
-#
@@ -1009,0 +1006 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200
+++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200
@@ -875,4 +874,0 @@
-
-#
-# Networking
-#
@@ -880,0 +877 @@
+CONFIG_NET_LEGACY=y
"""
This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
(old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
be part of .config,
GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849
It passes.
Link: https://lore.kernel.org/r/[email protected]
|
|
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n,
when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so
let's simplify the various checks across the codebase.
SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so
the proper symbol is still defined in SPL whenever needed.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Highlight that NET really is the legacy networking stack by renaming the
option to NET_LEGACY.
This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise
CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL.
The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is
using the legacy networking app so this seems fine to do.
This also has the benefit of removing potential confusion on NET being a
specific networking stack instead of "any" network stack.
Signed-off-by: Quentin Schulz <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Raymond Mao <[email protected]> says:
The series include refactoring on bloblist and fdtdec to support handoff
of multiple DT overlays and applying them into the DT base during setup.
All changes are aligned to the spec update for supporting DT overlay
handoff[1].
Notes for testing:
Currently DT overlay is not yet enabled in TF-A, but with the test
patches I provided for TF-A and OP-TEE build, importing a DT overlay
blob file from QEMU to TF-A reserved memory is supported.
Follow below instructions to build and run for test:
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
Replace your local qemu_v8.xml with [2], which contains all necessary
changes in both TF-A and OP-TEE build.
$ repo sync
$ cd build
$ make toolchains
$ make ARM_FIRMWARE_HANDOFF=y all
Copy and rename your DT overlay blob as 'qemu_v8.dtb' into out/bin
$ make ARM_FIRMWARE_HANDOFF=y run-only
[1] Add Transfer Entry for Devicetree Overlay
https://github.com/FirmwareHandoff/firmware_handoff/pull/74
[2] https://github.com/raymo200915/optee_manifest/blob/dt_overlay_handoff/qemu_v8.xml
Link: https://lore.kernel.org/r/[email protected]
|
