u-boot.git/Makefile, branch main

Prepare v2026.10-rc3

2026-08-25T00:46:24Z

Signed-off-by: Tom Rini

Prepare v2026.10-rc2

2026-08-10T22:43:34Z

Signed-off-by: Tom Rini

Makefile: depend on OF_LIST dts sources for fit-dtb.blob

2026-08-10T20:48:11Z

When CONFIG_MULTI_DTB_FIT is enabled, fit-dtb.blob is produced by mkimage with one "-b " argument for every entry in CONFIG_OF_LIST. The make rule, however, only listed dts/dt.dtb (i.e. the CONFIG_DEFAULT_DEVICE_TREE blob) as a prerequisite: fit-dtb.blob: dts/dt.dtb FORCE $(call if_changed,mkimage) Because FORCE is PHONY, if_changed ignores it and rebuilds only when any-prereq or arg-check is non-empty. Editing a non-default dts in OF_LIST rebuilds its .dtb (tracked correctly via fixdep), but that .dtb was not a prerequisite of fit-dtb.blob, so $? stayed empty; the mkimage command line was unchanged too, so arg-check was empty as well. if_changed therefore skipped mkimage and fit-dtb.blob kept the stale dtbs. u-boot.bin, which appends fit-dtb.blob, then shipped the old device tree and the dts change did not take effect. A previous attempt to fix this added every OF_LIST .dtb *output* as a prerequisite. That is wrong on two counts: - Clean build regression: the OF_LIST .dtb files are produced only by the recursive dts/dt.dtb -> arch-dtbs sub-make descent and have no rule at the top make level, so listing them as prerequisites makes them rule-less/intermediate. After a from-scratch rebuild (e.g. wiping an out-of-tree build directory) it fails: make[1]: *** No rule to make target 'arch/arm/dts/.dtb', needed by 'fit-dtb.blob'. Stop. - Incremental two-build race still present: the .dtb outputs are written by a child sub-make descent while the parent make level checks prerequisites, so under `make -j` an edit can still need two make invocations to take effect. List the .dts *sources* instead, which the top make level can see via VPATH in both objtree and srctree. Use $(dt_dir), as MKIMAGEFLAGS_fit-dtb.blob already does just below, so that CONFIG_OF_UPSTREAM boards (whose sources live under dts/upstream/src/) are handled too; a helper variable keeps the rule under 80 columns. Limitation: this only catches edits to the top-level .dts files in OF_LIST. An edit to an included .dtsi (including the *-u-boot.dtsi files) rebuilds the .dtb but leaves fit-dtb.blob stale, so the two-build problem remains in that case. Fixing that fully would need the .dtb outputs (rather than the .dts sources) as prerequisites, which reintroduces the clean-build problem above; covering top-level .dts edits is already a worthwhile improvement. Signed-off-by: Lianghong Liu Reviewed-by: Simon Glass

x86: add support for CONFIG_REMAKE_ELF

2026-07-29T20:45:03Z

x86 builds with CONFIG_REMAKE_ELF fail as the following: ... u-boot-elf.o: file not recognized: file format not recognized ... Fix objcopy/ld parameters for x86 to enable CONFIG_REMAKE_ELF configurations in both SPL and U-Boot proper builds. Add a new 'PLATFORM_ELFLDFLAGS' make variable for injecting proper linker arguments when u-boot.elf is requested. Signed-off-by: Denis Mukhin Reviewed-by: Simon Glass

tools: binman: pass KEYDIR to FIT entries

2026-07-28T18:30:55Z

U-Boot's Makefile passes KEYDIR to direct mkimage invocations, but internal binman FIT builds only receive the generic BINMAN_INDIRS search path. Adding KEYDIR to BINMAN_INDIRS treats it as one more input-file search path: FIT entries still auto-detect a key directory from all include directories, so an explicit KEYDIR may not be the directory that gets passed to mkimage. It also makes a key-only directory part of the generic blob lookup path. Forward KEYDIR as a binman entry argument named keydir, matching the existing entry-argument mechanism used for BL31, TEE, of-list and other U-Boot build inputs. FIT entries use that directory directly for mkimage -k when fit,sign or fit,encrypt is enabled, falling back to the include-directory autodetection when keydir is not provided. Signed-off-by: James Hilliard

Prepare v2026.10-rc1

2026-07-27T22:47:10Z

Signed-off-by: Tom Rini

Merge branch 'next'

2026-07-07T00:26:12Z

Prepare v2026.07

2026-07-06T23:50:43Z

Signed-off-by: Tom Rini

tools: Stop packaging patman as a pip module

2026-07-06T14:28:50Z

patman is no longer shipped from the U-Boot tree, so drop it from the 'make pip' target and from make_pip.sh, and remove its packaging files (setup.py, pyproject.toml, requirements.txt). Nothing else refers to them by this point in the series, so they can go. Also fix binman's pyproject.toml, which declares package-data for a 'patman' package (a copy-paste leftover); use 'binman' instead. Signed-off-by: Simon Glass

Merge tag 'v2026.07-rc5' into next

2026-06-22T22:42:41Z

Prepare v2026.07-rc5