The exported sub_make_done variable leaks into the environment of all
child processes. When make targets like tcheck spawn independent
make-invocations with O=, those child-makes inherit sub_make_done=1,
skip the KBUILD_OUTPUT setup and try to build in the source tree.
A global 'unexport sub_make_done' cannot be used because the build
system itself re-invokes the top-level Makefile for syncconfig (via
'$(MAKE) -f $(srctree)/Makefile syncconfig'). Without sub_make_done,
that child make re-enters the KBUILD_OUTPUT block and recomputes
abs_objtree. With a relative O= path this resolves to a nested
directory (e.g. build/build/) where .config does not exist.
Instead, use 'env -u sub_make_done' in the test-target recipes so only
the test scripts see a clean environment. This allows their child make
invocations to process O= correctly without affecting internal kbuild
recursion.
This is not strictly a bugfix, but compare with:
commit 27529f1cb02d ("kbuild: skip parsing pre sub-make code for recursion")
Signed-off-by: Simon Glass <sjg@chromium.org>
On Xilinx MB-V there is a need to use ELF file for SPL which is placed
in BRAM (Block RAM) because tools for placing code to bitstream requires to
use ELF. That's why introduce SPL_REMAKE_ELF similar to REMAKE_ELF option
as was originally done by commit f4dc714aaa2d ("arm64: Turn u-boot.bin back
into an ELF file after relocate-rela").
There is already generic and simple linker script (arch/u-boot-elf.lds)
which can be also used without any modification.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Convert a duplicate dtbs recipe into a dependency in the main Makefile.
Another recipe is already defined on line 2369, so we are getting
spurious warnings like:
Makefile:2369: warning: overriding recipe for target 'dtbs'
Makefile:1425: warning: ignoring old recipe for target 'dtbs'
The removed recipe was a no-op anyway so can be safely removed.
Signed-off-by: David Lechner <dlechner@baylibre.com>
The exported sub_make_done variable leaks into the environment of all
child processes. When make targets like tcheck spawn independent make
invocations with O=, those child makes inherit sub_make_done=1, skip
the KBUILD_OUTPUT setup and try to build in the source tree.
There is a workaround that resets sub_make_done to 0 for specific test
targets, but this isn't great since it has tolist every target that
spawns independent make invocations.
Instead, unexport sub_make_done once we are in the final make
invocation. The direct sub-make already has the value in its
environment from the export, and no further propagation is needed.
This also allows the per-target workaround to be removed.
Fixes: 27529f1cb02d ("kbuild: skip parsing pre sub-make code for recursion")
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Some boards use CONFIG_DEFAULT_FDT_FILE to specify the value of
fdtfile, althugh the quotes get embedded in the value.
Provide DEFAULT_FDT_FILE with the quotes stripped.
This is a similar work-around to the one provided in commit
d085e692c98d0d7b57cc577ed9befda159cd4a40 for
CONFIG_DEFAULT_DEVICE_TREE.
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
If we have ASSERT macros that validate the position of
_image_binary_end, our awk expression will report a string that causes
the rest of our check to fail with garbage values. Have it exit after
the first match to fix this.
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <sughosh.ganu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>a #rebased on -next
Since commit 5f520875bdf0 ("kbuild: Bump the build system to 5.1")
CONFIG_CC_OPTIMIZE_FOR_DEBUG has no effect on the non-host code.
This patch reestablishes the prior logic to add
-Og -Wno-maybe-uninitialized
to KBUILD_CFLAGS.
Fixes: 5f520875bdf0 ("kbuild: Bump the build system to 5.1")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The current implementation of flash.bin generation with
CONFIG_SPL_LOAD_IMX_CONTAINER=y requires build of u-boot.cnt
which is i.MX8 specific. Reinstate the i.MX8 check to avoid
this dependency for i.MX9 .
Fill in flash.bin target for i.MX9 into imx specific Makefile.
Fixes: c3587197c0c9 ("Makefile: Make flash.bin target available for all platforms")
Signed-off-by: Marek Vasut <marex@nabladev.com>
Add initial changes to support Renesas R-Car Gen5 SoC.
Introduce Kconfig entries, architecture headers and PRR IDs for Renesas
R-Car Gen5 and R-Car X5H R8A78000 SoC. Add Makefile change to produce
u-boot-elf.srec with correct offset for installation tooling. Update
MAINTAINERS entry to cover both r8a77nnn and r8a78nnn .
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Dmitrii Sharshakov <d3dx12.xx@gmail.com> says:
Initially fix the inconsistency reported in reply to the previous
series and also make sure AArch64 images can be built with latest
Clang versions by guarding AArch32-specific options behind extra
config checks.
Tested qemu_arm_defconfig and qemu_arm64_defconfig with Clang 21,
mainline (to be 22) ce7f9f9c and also Clang 18 (for AArch64 only, as I
have not managed to build an AArch32 image with clang-18).
Link: https://lore.kernel.org/r/20251108-clang-cross-fixes-v1-0-ea6c4282844a@gmail.com
Clang cross-compilation worked when cross binutils were available
in PATH. However, when binutils are not in the PATH clang failed to
discover the assembler, falling back to host one.
Make --prefix always absolute, Clang supports this and will search for
e.g. $(prefix)-as for assembler. This makes sure user does not have to
add cross binutils to PATH for Clang build.
Fixes build for these examples (with qemu_arm(64)_defconfig):
make CC=clang-21 CROSS_COMPILE=/.../bin/arm-none-eabi-
make CC=clang-20 CROSS_COMPILE=/.../bin/aarch64-linux-gnu-
Also validated for the case when provided with cross toolchain on PATH:
PATH=/.../bin:$PATH make CC=clang-21 CROSS_COMPILE=arm-none-eabi- -j20
This patch does not affect GCC builds, and they have _not_ been
validated against regressions.
Reported-by: Tom Rini <trini@konsulko.com>
Closes: https://lore.kernel.org/u-boot/20251106221355.GZ6688@bill-the-cat/
Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>
The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Remove a Makefile reference that was missed in v1]
Signed-off-by: Tom Rini <trini@konsulko.com>
This patch adds creation of tifalcon.bin for the AM62a, 62p and 62x.
The contents are the same as the existing tispl.bin but A53's SPL and
the FDT have been removed as they are not needed in R5 falcon mode.
This reduces boot time since the payload size is smaller compared to the
regular tispl.bin.
tispl.bin = TFA + TEE + TIFS-STUB + A53 SPL + FDT
tifalcon.bin = TFA + TEE + TIFS-STUB
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Make sure to pass Clang flags to the KBUILD_CPPFLAGS as well, as this
variable is used for flags during compiling for target
Skipping this leads to Clang being invoked with args for target, but
without target indication, thus defaulting to host arch:
LDS u-boot.lds
clang: error: ... '-mabi=' for target 'x86_64-suse-linux'
clang: error: ... '-mno-thumb' for target 'x86_64-suse-linux'
clang: error: ... '-mno-unaligned-access' for target 'x86_64-suse-linux'
clang: error: ... '-ffixed-r9' for target 'x86_64-suse-linux'
clang: error: ... '-mno-movt' for target 'x86_64-suse-linux'
make: *** [Makefile:2345: u-boot.lds] Fehler 1
Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>
Since the Kbuild bump to 5.1 and specifically
commit af1a9935708a ("kbuild: make -r/-R effective in top Makefile for old Make versions")
the recursion rules have changed.
'make O=/output/dir/' as well as './test/py/test.py --bd sandbox --build'
is working fine but anything that recursively called the makefile was
failing e.g 'make tests', 'make qcheck' etc, which calls a bash script
that ends up calling the makefile again.
The reason is that the internal 'sub_make_done' variable of the makefile
was set after the first pass and the output dir was never evaluated
properly. Reset the variable value if we are executing any of these
tests.
Fixes: af1a9935708a ("kbuild: make -r/-R effective in top Makefile for old Make versions")
Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Test-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This patch is used to restore support for i.MX95 A0 silicon. To avoid
duplicating defconfig, imx95.config is added and can be shared between
imx95_a0_19x19_evk_defconfig and imx95_19x19_evk_defconfig.
container.cfg and imximage.cfg are used to created .cfgout files that
are be passed to mkimage with -n to build flash.bin. Now they have been
deleted and replaced by adding their content to properties of node which
type is nxp-imx9image under binman node.
Fixes: 9936724aa9b ("imx95_evk: Add i.MX95 B0 support")
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Tested-By: Tim Harvey <tharvey@gateworks.com> # imx95-19x19-evk (rA0)
The U-Boot environment was previously stored in the boot loader stream
using ldr, but it has been replaced by the default environment built
into the U-Boot executable or an environment on external storage
Fixes: ea3310e8aafa ("Blackfin: Remove")
Signed-off-by: Philip Molloy <philip.molloy@analog.com>
Reviewed-by: Greg Malysa <malysagreg@gmail.com>
Top level Makefile starts separate "make" processes for each each
subdirectory. lib/efi_loader apps now depend on lib.a from
arch/$(ARCH)/lib if CONFIG_USE_PRIVATE_LIBGCC is enabled which creates
a race conditions since dependency from lib/efi_loader EFI apps to
arch/$(ARCH)/lib/lib.a is not explicit:
arm-poky-linux-gnueabi-ld.bfd: cannot find arch/arm/lib/lib.a: No such file or directory
make[3]: *** [scripts/Makefile.lib:512: lib/efi_loader/testapp_efi.so] Error 1
This error was seen on yocto/OE-core CI builds after u-boot 2025.07 update:
https://lists.openembedded.org/g/openembedded-core/message/220004https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/2914600/raw_inline
| rm -f lib/efi_loader/built-in.o; arm-poky-linux-gnueabi-ar cDPrsT lib/efi_loader/built-in.o lib/efi_loader/efi_bootmgr.o lib/efi_loader/efi_bootbin.o lib/efi_loader
/efi_boottime.o lib/efi_loader/efi_helper.o lib/efi_loader/efi_console.o lib/efi_loader/efi_device_path.o lib/efi_loader/efi_device_path_to_text.o lib/efi_loader/efi_device_
path_utilities.o lib/efi_loader/efi_dt_fixup.o lib/efi_loader/efi_fdt.o lib/efi_loader/efi_file.o lib/efi_loader/efi_hii.o lib/efi_loader/efi_hii_config.o lib/efi_loader/efi
_image_loader.o lib/efi_loader/efi_load_options.o lib/efi_loader/efi_memory.o lib/efi_loader/efi_root_node.o lib/efi_loader/efi_runtime.o lib/efi_loader/efi_setup.o lib/efi_
loader/efi_string.o lib/efi_loader/efi_unicode_collation.o lib/efi_loader/efi_var_common.o lib/efi_loader/efi_var_mem.o lib/efi_loader/efi_variable.o lib/efi_loader/efi_var_
file.o lib/efi_loader/efi_watchdog.o lib/efi_loader/efi_disk.o lib/efi_loader/efi_net.o lib/efi_loader/efi_smbios.o lib/efi_loader/efi_load_initrd.o lib/efi_loader/efi_confo
rmance.o
| arm-poky-linux-gnueabi-ld.bfd -nostdlib -zexecstack -znocombreloc -znorelro --no-warn-rwx-segments -L /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-
3119200/tmp/work/beaglebone_yocto-poky-linux-gnueabi/u-boot/2025.07/sources/u-boot-2025.07 -T arch/arm/lib/elf_arm_efi.lds -shared -Bsymbolic -s lib/efi_loader/helloworld.o
lib/efi_loader/efi_crt0.o lib/efi_loader/efi_reloc.o lib/efi_loader/efi_freestanding.o arch/arm/lib/lib.a -o lib/efi_loader/helloworld_efi.so
| arm-poky-linux-gnueabi-ld.bfd: cannot find arch/arm/lib/lib.a: No such file or directory
| make[3]: *** [scripts/Makefile.lib:512: lib/efi_loader/helloworld_efi.so] Error 1
The different "make" processes share common scripts/Makefile.build
and scripts/Makefile.libs but since they are separate processes
the Makefile rules can't add a dependency from lib/uefi_loader targets
to arch/$(ARCH)/lib/lib.a. Or the file level dependency can be added but
then "make" produces a too sparse error message which does not mention
that one of the dependencies like arch/$(ARCH)/lib/lib.a was not found:
make[3]: *** No rule to make target 'lib/efi_loader/helloworld.efi', needed by '__build'. Stop.
Fix this dependency problem by building arch/$(ARCH)/lib before lib
if CONFIG_USE_PRIVATE_LIBGCC was enabled.
To reproduce the race condition more reliably, add a "sleep 10" delay
before linker command cmd_link_l_target with 2025.07
or to $(lib-target): target in scripts/Makefile.build with master branch
after Kbuild update.
Fixes: 43d43241d1c9 ("scripts/Makefile.lib: add PLATFORM_LIBGCC to efi linking")
Cc: Adriano Cordova <adrianox@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
This directory was created when U-Boot gained the ability to run as an
EFI app in 2015. Since then the EFI-loader feature has been added.
The code in lib/efi is not actually used by the loader, so the name is
confusing.
Rename the directory to efi_client to indicate that it includes files
just for U-Boot being a client of EFI, i.e. the EFI app and stub.
Signed-off-by: Simon Glass <sjg@chromium.org>
Systems that use clang may not have gcc installed. Set
HOSTCC to cc and HOSTCXX to c++ like we did before to make those
systems work again.
Fixes: 5f520875bdf0 ("kbuild: Bump the build system to 5.1")
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Stranges errors are observed when building U-Boot master for almost any
RISC-V board, the messages are in two types, one is about duplicated
symbols,
u-boot/arch/riscv/cpu//mtrap.S:32: multiple definition of `trap_entry';
arch/riscv/cpu/mtrap.o: u-boot/arch/riscv/cpu//mtrap.S:32: first defined here
and the other is fixdep's complaint about missing dependency files,
fixdep: error opening file: arch/riscv/cpu/.mtrap.o.d: No such file or directory
fixdep: error opening file: arch/riscv/cpu//.start.o.d: No such file or directory
where the latter could only be reproduced when building parallelly.
Both the two types of errors are about files in arch/riscv/cpu, and
there's a suspicious slash character in the reported path. Looking
through RISC-V-specific Makefiles, there's only one place that may
expand to such a path,
libs-y += arch/riscv/cpu/$(CPU)/
The right hand expands to "arch/riscv/cpu//" if $(CPU) isn't defined at
the time of including. With some debug statement added to
arch/riscv/Makefile, the output proves that arch/riscv/Makefile is
included twice, once with $(CPU) undefined and once defined correctly
according to CONFIG_SYS_CPU.
Futher bisecting shows an extra include statement against
arch/$(SRCARCH)/Makefile is added in earlier bump of Kbuild system. But
the statement is evaluated before config.mk is included and definition
of $(CPU), causing objects in arch/riscv/cpu/ are built and linked twice
(once as "arch/riscv/cpu/*", and once as "arch/riscv/cpu//*"), resulting
in the error.
Let's simply remove the extra include to fix these nasty errors. For
config targets, bumping Kbuild also introduced a new include to
arch/$(SRCARCH)/Makefile, which is removed as well for consistency.
Fixes: 5f520875bdf ("kbuild: Bump the build system to 5.1")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Bryan Brattlof <bb@ti.com>
Sometimes when building a platform such as imx28_btt3 we can get an
error such as:
gzip: fit-dtb.blob: warning: file timestamp out of range for gzip format
make[1]: *** [Makefile:1219: fit-dtb.blob.gz] Error 2
make[1]: *** Deleting file 'fit-dtb.blob.gz'
make: *** [Makefile:186: sub-make] Error 2
This is typically resolved by telling gzip to ignore the timestamp.
Signed-off-by: Tom Rini <trini@konsulko.com>
EXT_DTB overrides the of_list_dirs that is passed to binman during
builds. This causes binman to not find the normal DTB paths and instead
it just is able to use the path for EXT_DTB only.
Add the default of_list_dirs that is used for normal binman builds to
EXT_DTB usecase as well.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>
Our last sync with the kernel was 5.1. Even that was a partial one
as some patches from 4.x kernels were already missing making the
transition to a modern kbuild infeasible.
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 Makefile[.lib/.kbuild].
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call.
One of the biggest changes is get rid of partial linking entirely and
build .a archives isntead of .o.
We diaviate from the kernel on that. Instead of calling a custom script
to create the archive symbol table, we call ar with rcTP (isntead of
rcSTP) since we want a resulting archive that's sauble with the linker.
The only affected platforms are PPC ones. Unfortunately I don't have any
of them around to test, but the objdump of the resulting files --
arch/powerpc/lib/built-in.[oa] looks identical.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
