u-boot.git/scripts, branch v2025.07-rc3 Unnamed repository; edit this file 'description' to name the repository. scripts/Makefile.lib: add PLATFORM_LIBGCC to efi linking 2025-05-11T11:30:31+00:00 Adriano Cordova adrianox@gmail.com 2025-05-08T18:30:32+00:00 43d43241d1c9592bee640227a1c8ed8bc880f255 Link .efi applications using libgcc Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com> 
Link .efi applications using libgcc

Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Makefile: Strip leading spaces when preprocessing generated_defconfig 2025-05-05T20:17:23+00:00 Yao Zi ziyao@disroot.org 2025-04-27T14:50:10+00:00 252cd205300c1b9945079c0ae1fe5980ef9dfa56 Clang's preprocessor may emit extra spaces for lines starting with '#'. Lines with these extra characters cannot be handled by Kconfig and will be ignored with warnings like, unexpected data: # CONFIG_OF_BOARD_FIXUP is not set Those options that is expected to be assigned explicitly with N will be set to the default value, messing up board configurations. Let's sed these spaces away to ensure board configurations could be correctly generated with Clang. Link: https://github.com/llvm/llvm-project/issues/78778 Fixes: 2027e99e61a ("Makefile: Run defconfig files through the C preprocessor") Reported-by: Nathaniel Hourt <I@nathaniel.land> Signed-off-by: Yao Zi <ziyao@disroot.org> 
Clang's preprocessor may emit extra spaces for lines starting with '#'.
Lines with these extra characters cannot be handled by Kconfig and will
be ignored with warnings like,

        unexpected data:  # CONFIG_OF_BOARD_FIXUP is not set

Those options that is expected to be assigned explicitly with N will be
set to the default value, messing up board configurations.

Let's sed these spaces away to ensure board configurations could be
correctly generated with Clang.

Link: https://github.com/llvm/llvm-project/issues/78778
Fixes: 2027e99e61a ("Makefile: Run defconfig files through the C preprocessor")
Reported-by: Nathaniel Hourt <I@nathaniel.land>
Signed-off-by: Yao Zi <ziyao@disroot.org>
tools/make_pip: Use venv when invoking pip 2025-04-24T22:30:37+00:00 Mattijs Korpershoek mkorpershoek@kernel.org 2025-04-16T12:36:28+00:00 9d3f1ebaf8751f0287b5d02158cc706435f8fb19 Recent Ubuntu versions (24.04+) disallow pip by default when installing packages. The recommended approach is to use a virtual environment (venv) instead. Because of this, "make pip" is failing on such versions. To prepare CI container migration to Ubuntu 24.04, use a venv in the make_pip script. Note: This has been reported on [1] [1] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/37 Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> 
Recent Ubuntu versions (24.04+) disallow pip by default when
installing packages. The recommended approach is to use a virtual
environment (venv) instead.
Because of this, "make pip" is failing on such versions.

To prepare CI container migration to Ubuntu 24.04, use a venv in the
make_pip script.

Note: This has been reported on [1]

[1] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/37

Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Merge patch series "Switch to using $(PHASE_) in Makefiles" 2025-04-11T18:16:49+00:00 Tom Rini trini@konsulko.com 2025-04-11T18:16:49+00:00 407d68638fe32418d61681407effba2a303bb9ee Tom Rini <trini@konsulko.com> says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com 
Tom Rini <trini@konsulko.com> says:

This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.

Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
Kbuild: Always use $(PHASE_) 2025-04-11T18:16:44+00:00 Tom Rini trini@konsulko.com 2025-04-01T22:55:23+00:00 302b41d5397e9f821d360a74335e8821d4513970 It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini <trini@konsulko.com> 
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

Signed-off-by: Tom Rini <trini@konsulko.com>
efi_loader: Move public cert for capsules to .rodata 2025-04-11T11:25:31+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2025-04-01T11:27:25+00:00 fd58c275f6ba524101ba0990e53f5a11ac390bd0 commit ddf67daac39d ("efi_capsule: Move signature from DTB to .rodata") was reverted in commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to .rodata"") because that's what U-Boot was usually doing -- using the DT to store configuration and data. Some of the discussions can be found here [0]. (Ab)using the device tree to store random data isn't ideal though. On top of that with new features introduced over the years, keeping the certificates in the DT has proven to be problematic. One of the reasons is that platforms might send U-Boot a DTB from the previous stage loader using a transfer list which won't contain the signatures since other loaders are not aware of internal U-Boot ABIs. On top of that QEMU creates the DTB on the fly, so adding the capsule certificate there does not work and requires users to dump it and re-create it injecting the public keys. Now that we have proper memory permissions for arm64, move the certificate to .rodata and read it from there. [0] https://lore.kernel.org/u-boot/CAPnjgZ2uM=n8Qo-a=DUkx5VW5Bzp5Xy8=Wgmrw8ESqUBK00YJQ@mail.gmail.com/ Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Jonathan Humphreys <j-humphreys@ti.com> # on TI sk-am62p-lp Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-A311D-CC Tested-by: Raymond Mao <raymond.mao@linaro.org> 
commit ddf67daac39d ("efi_capsule: Move signature from DTB to .rodata")
was reverted in
commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to .rodata"")
because that's what U-Boot was usually doing -- using the DT to store
configuration and data. Some of the discussions can be found here [0].

(Ab)using the device tree to store random data isn't ideal though.
On top of that with new features introduced over the years, keeping
the certificates in the DT has proven to be problematic.
One of the reasons is that platforms might send U-Boot a DTB
from the previous stage loader using a transfer list which won't contain
the signatures since other loaders are not  aware of internal
U-Boot ABIs. On top of that QEMU creates the DTB on the fly, so adding
the capsule certificate there does not work and requires users to dump
it and re-create it injecting the public keys.

Now that we have proper memory permissions for arm64, move the certificate
to .rodata and read it from there.

[0] https://lore.kernel.org/u-boot/CAPnjgZ2uM=n8Qo-a=DUkx5VW5Bzp5Xy8=Wgmrw8ESqUBK00YJQ@mail.gmail.com/

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Jonathan Humphreys <j-humphreys@ti.com>  # on TI sk-am62p-lp
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-A311D-CC
Tested-by: Raymond Mao <raymond.mao@linaro.org>
dtc: introduce label relative path references 2025-04-10T17:58:08+00:00 Patrice Chotard patrice.chotard@foss.st.com 2025-03-28T16:31:15+00:00 088bbc1efa8c1efe8e2714b9640055ce984aec93 Since introduction of OF_UPSTREAM flag, U-Boot's dtc must be able to compile Kernel's device tree. Since kernel commit 7de129f5389b ("ARM: dts: stm32: stm32mp151a-prtt1l: Fix QSPI configuration"), label relative path references has been introduced. These label relative path references is not supported by current U-Boot dtc version 1.5.0: (see mailing list discussion [1]). In order to support such label relative patch references adds following commit from upstream DTC tree: commit 651410e54cb9 ("util: introduce xstrndup helper") commit ec7986e682cf ("dtc: introduce label relative path references") [1] https://lore.kernel.org/all/20250115144428.GZ3476@bill-the-cat/T/ Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Since introduction of OF_UPSTREAM flag, U-Boot's dtc must be able
to compile Kernel's device tree.

Since kernel commit 7de129f5389b ("ARM: dts: stm32: stm32mp151a-prtt1l:
Fix QSPI configuration"), label relative path references has been
introduced. These label relative path references is not supported
by current U-Boot dtc version 1.5.0: (see mailing list discussion [1]).

In order to support such label relative patch references
adds following commit from upstream DTC tree:

commit 651410e54cb9 ("util: introduce xstrndup helper")
commit ec7986e682cf ("dtc: introduce label relative path references")

[1] https://lore.kernel.org/all/20250115144428.GZ3476@bill-the-cat/T/

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Merge tag 'v2025.04-rc5' into next 2025-03-25T02:10:55+00:00 Tom Rini trini@konsulko.com 2025-03-25T02:10:55+00:00 647cb87b5ab2ad6469cf42f3272f00688bd26039 Prepare v2025.04-rc5 
Prepare v2025.04-rc5
checkpatch.pl: Report an error for CONFIG_xPL_BUILD in device trees 2025-03-18T14:17:36+00:00 Hendrik Donner hd@os-cillation.de 2025-03-06T20:15:39+00:00 69fb899133b6c374eff11b13482371bec6898a01 The defines for the different build phases shouldn't be used in device trees, currently they aren't even defined for device tree pre processing, resulting in build errors. Link: https://lists.denx.de/pipermail/u-boot/2025-March/582787.html Signed-off-by: Hendrik Donner <hd@os-cillation.de> Reviewed-by: Simon Glass <sjg@chromium.org> 
The defines for the different build phases shouldn't be used in device
trees, currently they aren't even defined for device tree pre processing,
resulting in build errors.

Link: https://lists.denx.de/pipermail/u-boot/2025-March/582787.html
Signed-off-by: Hendrik Donner <hd@os-cillation.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
scripts: typos in event_dump.py 2025-03-18T14:17:27+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-02-20T10:00:13+00:00 2ac91756ad9124a607af81fda1eafc436934ad4a %s/even spies/event spies/ %s/EFL/ELF/ Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
%s/even spies/event spies/
%s/EFL/ELF/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>