Use OPTIMIZATIONS parameter to pass -marm to fix the following build
failure in Thumb mode:
/tmp/ccEjPM4h.s:941: Error: selected processor does not support `mrc p15,0,r2,c9,c13,0' in Thumb mode
CFLAGS can't be overridden as it is defined as:
CFLAGS = $(FEATUREFLAGS) \
$(OPTIMIZATIONS) \
$(WARNFLAGS) \
$(if $(findstring clang,$(CC)),$(CLANG_WARNINGS)) \
$(ARCH_CFLAGS) \
$(WERRFLAGS) \
$(INCLUDES) \
$(DEFINES)
Fixes:
- http://autobuild.buildroot.org/results/580156f89cfd72122fef07aa2fe37b4fdd4c316b
- http://autobuild.buildroot.org/results/8980c0f422516c7263d8d0c9cc6123f30c4b7ee4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When selecting barebox in menuconfig, BR2_TARGET_BAREBOX_IMAGE_FILE will
be empty by default, which causes Buildroot to install whatever the
barebox-flash-image symlink points at for barebox versions >= v2012.10.0.
This is an outdated fallback, because barebox-flash-image is only valid
when the barebox build produces a single binary. Virtually all new
defconfigs added in the last couple of years are multiconfig
(CONFIG_PBL_IMAGE=y) however, meaning that a single imx_v7_defconfig
or multi_v8_defconfig will produce many images that support different
boards or even platforms.
As there is no single valid target for barebox-flash-image to point at
in this case, this symlink will point at a non-existing
'multi-image-build' to alert the user to this fact.
As replacement for barebox-flash-image, barebox commit 550cf79c216a
("Make list of flash images and fix link all single image cases") first
released with v2015.12.0 creates a barebox-flash-images file with a list
of all images built by barebox.
Have buildroot use that file as a fallback before trying
barebox-flash-image to have a fallback that works for any recent barebox
defconfig as well.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
CVE-2023-40546 mok: fix LogError() invocation
CVE-2023-40547 - avoid incorrectly trusting HTTP headers
CVE-2023-40548 Fix integer overflow on SBAT section size on 32-bit system
CVE-2023-40549 Authenticode: verify that the signature header is in bounds.
CVE-2023-40550 pe: Fix an out-of-bound read in verify_buffer_sbat()
CVE-2023-40551: pe-relocate: Fix bounds check for MZ binaries
https://github.com/rhboot/shim/tree/15.8
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit
c6ab9328e1 ("boot/arm-trusted-firmware:
change BR_NO_CHECK_HASH_FOR logic") was written too hastily, and is
actually broken as it does the reverse of what it should do. It really
should disable the check when we're using a custom version/git/tarball
of TF-A, not the opposite.
Thanks to Romain for pointing out the problem, and providing an IRL
patch to solve the issue.
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Patch 0001-feat-build-add-support-for-new-binutils-versions.patch as
found in v2.8 patch dir has already been applied in lts-v2.8.13
Patch 0002-build-tools-avoid-unnecessary-link.patch from v2.8 has
been included as 0001-build-tools-avoid-unnecessary-link.patch for
lts-v2.8.13
Signed-off-by: Marleen Vos <marleen.vos@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, arm-trusted-firmware checks the hash only if
BR2_TARGET_ARM_TRUSTED_FIRMWARE_LATEST_VERSION=y. As we're about to
introduce other version options for which the hash checking is needed,
let's reverse the logic, and instead ignore hash checking if we're
using a custom version or custom git or custom tarball.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Patch 0001-build-tools-avoid-unnecessary-link.patch that was applied to
v2.9 is already in v2.10, so no new patch dir for v2.10 is added
Signed-off-by: Marleen Vos <marleen.vos@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
From a report on the syslinux mailing list [0]:
The GNU linker now writes two segments of type PT_LOAD into the
program header. However, this is not supported by the wrapper
script that converts the shared object to an .efi executable.
As per comment in that file:
(...) Although there may be several LOAD program headers,
only one is currently copied.
A simple workaround I've found to work is to ask the linker to put
everything into one PT_LOAD program header.
The issue is ackowledged in the syslinux wiki page about building
syslinux [1]. This page refers to various resources, of which a Debian
patch [2].
This information is also referenced in #11861.
Fixes: #11861
[0] https://www.syslinux.org/archives/2018-August/026167.html
[1] https://wiki.syslinux.org/wiki/index.php?title=Building
[2] https://salsa.debian.org/images-team/syslinux/-/blob/debian/master/debian/patches/0017-single-load-segment.patch
Reported-by: Sam Lancia <sam@gpsm.co.uk>
Reported-by: Meliodas <meliodasren01@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
All in-tree configs with the uboot bootloader use a custom version,
so this patch is mostly for the menuconfig default uboot version
Signed-off-by: Flávio Tapajós <flavio.tapajos@newtesc.com.br>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issue:
CVE-2022-28737: There's a possible overflow in handle_image() when shim
tries to load and execute crafted EFI executables
https://github.com/advisories/GHSA-hmxr-46w2-jjwh
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/5834758777
Commit e7d16c35a (boot/arm-trusted-firmware: fix the RPATH of fiptool) tried
to fix the build of host-fiptool, but forgot to pass HOST_CFLAGS.
On hosts without (compatible) openssl development headers, this breaks
the build when it cannot find the openssl headers:
fiptool_platform.h:19:11: fatal error: openssl/sha.h: No such file or directory
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Yann reported in [1] that edk2 build could sometimes fail. The issue
can be reproduced when per-package directories is enabled, or also
when building on a system with GNU Make >= 4.4 using the
"--shuffle=reverse" option (such as Fedora 39). Those are pointing
toward a Makefile dependency issue.
The issue can be reproduced with commands:
cat > .config <<EOF
BR2_riscv=y
BR2_RISCV_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TARGET_EDK2=y
EOF
make olddefconfig
Then, building either with:
make --shuffle=reverse
Or:
utils/config -e BR2_PER_PACKAGE_DIRECTORIES
make olddefconfig
make -j$(nproc)
It is interesting to mention that when using "make --shuffle=reverse"
to build, the build can be completed if restarted only with "make". It
will not pull any other Buildroot package. This fact hints toward a
Makefile dependency issue internal to the EDK2 build system, rather
than in the Buildroot recipe.
The EDK2 build system is quite unique. See [2]. It generates files,
makefiles and internally uses GNU Make to compile code. This system is
likely not tested as being a sub-Make process in a complex Makefile
such as Buildroot.
In order to prevent Buildroot to pass unexpected Make flags to the
EDK2 sub-Make, this commit unset the MAKEFLAGS variable in the EDK2
build environment. This will put the EDK2 build script in a more
common and tested state. See GNU Make documentation about recursive use
of Make, more specifically [3].
Note: as mentioned, the build failure is likely due to an internal
issue of the EDK2 build system. The failure points to a missing
dependency in the EDK2 generator itself. This commit does not fix this
issue, but rather put the EDK2 build system in a normalized
environment, avoiding Buildroot flags being passed to the internal
EDK2 sub-Make invocation. The upstream EDK2 build system most likely
need a fix too.
Fixes:
make[2]: *** No rule to make target '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.efi', needed by '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/FV/Ffs/462CAA21-7614-4503-836E-8AB6F4662331UiApp/UiApp.offset'. Stop.
build.py...
: error 7000: Failed to execute command
make tbuild [/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp]
build.py...
: error F002: Failed to build module
/buildroot/output/build/edk2-edk2-stable202308/MdeModulePkg/Application/UiApp/UiApp.inf [RISCV64, GCC5, RELEASE]
[1] https://lists.buildroot.org/pipermail/buildroot/2023-December/681507.html
[2] https://tianocore-docs.github.io/edk2-BuildSpecification/draft/4_edk_ii_build_process_overview/42_build_process_overview.html
[3] https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
Reported-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
grub2 build is failing, when compiled on host system not including
gawk and host-gawk is not built by another package before. This can
be the the case on current Buildroot Docker image, based on Debian,
which includes mawk.
grub2 was updated in commit 5baf1ffe7e "boot/grub2: bump to version
2.12". This version includes the commit [1], which introduced the use
of the asorti() awk function. This function is a specific gawk
builtin extension. See [2].
This commit fixes this issue by adding host-gawk as a dependency.
Fixes:
mawk: ../../grub-core/genmoddep.awk: line 110: function asorti never defined
make[4]: *** [Makefile:49030: moddep.lst] Error 1
make[4]: Leaving directory '/buildroot/output/build/grub2-2.12/build-i386-pc/grub-core'
make[3]: *** [Makefile:28116: all] Error 2
make[3]: Leaving directory '/buildroot/output/build/grub2-2.12/build-i386-pc/grub-core'
make[2]: *** [Makefile:11714: all-recursive] Error 1
make[2]: Leaving directory '/buildroot/output/build/grub2-2.12/build-i386-pc'
make[1]: *** [Makefile:3547: all] Error 2
make[1]: Leaving directory '/buildroot/output/build/grub2-2.12/build-i386-pc'
make: *** [package/pkg-generic.mk:283: /buildroot/output/build/grub2-2.12/.stamp_built] Error 2
[1] https://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=87648e9c12a32bddb005b899edc44c2c9c63df82
[2] https://www.gnu.org/software/gawk/manual/gawk.html#Sorting-Array-Values-and-Indices-with-gawk
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
RISC-V 64bit qemu virt machine support has been added in edk2
version "stable202302". See [1].
Since edk2-stable202308, introduced in buildroot in commit 5c9f310
"boot/edk2: bump to version edk2-stable202308", it is now possible
to boot the edk2 UEFI shell in qemu.
This commit adds this early RISC-V support to edk2.
The RISC-V edk2 UEFI shell can be booted in Buildroot with the
following commands:
# Build EDK2 images
cat > .config <<EOF
BR2_riscv=y
BR2_RISCV_64=y
BR2_PACKAGE_HOST_QEMU=y
BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
BR2_TARGET_EDK2=y
EOF
make olddefconfig
make
# edk2 image size should fit the 32MB of qemu pflash memories
truncate -s 32M output/images/RISCV_VIRT_CODE.fd
truncate -s 32M output/images/RISCV_VIRT_VARS.fd
# Start qemu:
output/host/usr/bin/qemu-system-riscv64 \
-M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
-nographic \
-blockdev node-name=pflash0,driver=file,read-only=on,filename=output/images/RISCV_VIRT_CODE.fd \
-blockdev node-name=pflash1,driver=file,filename=output/images/RISCV_VIRT_VARS.fd
Note: a Qemu version >= 8.0.0 is needed to properly start edk2. A qemu
version on the host system might not be sufficient. This is why the
Buildroot host-qemu is built in this config example.
[1] https://github.com/tianocore/edk2/releases/tag/edk2-stable202302
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For release announce on mailing list, see [1].
For release general news, see [2].
This commit removes all package patches, as they are all included in
this version.
The .checkpackageignore file is updated accordingly (the entry for
patch 0001 is removed).
This commit also removes GRUB2_AVOID_AUTORECONF hooks, since patch
0001 is removed.
This commit also removes the GRUB2_IGNORE_CVES entries associated to
the removed patches. The version bump should now explicitly exclude
those CVEs. For patches 8 and 9, the upstream commit IDs were
incorrectly recorded:
- patch 8 mentioned d5caac8ab79d068ad9a41030c772d03a4d4fbd7b while
the actual commit is 5bff31cdb6b93d738f850834e6291df1d0b136fa
- patch 9 mentioned 166a4d61448f74745afe1dac2f2cfb85d04909bf while
the actual commit is 347880a13c239b4c2811c94c9a7cf78b607332e3
Finally, this commit introduces a new patch, adding a missing file in
the release tarball.
[1] https://lists.gnu.org/archive/html/grub-devel/2023-12/msg00052.html
[2] https://git.savannah.gnu.org/gitweb/?p=grub.git;a=blob;f=NEWS;hb=refs/tags/grub-2.12
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The arm-trusted-firmware package builds a host tool called "fiptool",
which is used during the build process of arm-trusted-firmware
itself. This tool links against the OpenSSL host library, and
therefore needs to be built with the correct RPATH pointing to
$HOST_DIR/lib.
This is why commit a957d9a90a
("boot/arm-trusted-firmware: build fiptool separately with dependency
o n host-openssl") added the ARM_TRUSTED_FIRMWARE_BUILD_FIPTOOL
variable, which builds the fiptool tool first, with the right
variables set, before invoking the full build of TF-A. This ensured
that fiptool was built with the correct RPATH.
However, more recent versions of TF-A have modified their Makefile
machinery, and fiptool is being rebuilt even if it was built
before. Unfortunately, this rebuild is no longer done with the right
flags, so we end up with a fiptool binary that no longer has the right
RPATH, and fiptool fails to find the OpenSSL libraries from
$HOST_DIR/lib.
In order to fix this, we take a different approach: we do not build
fiptool separately first, but we inject the necessary flags through
the HOSTCC variable. Indeed, there's no HOST_LDFLAGS or HOST_LDLIBS
variable or similar that would allow us to pass the -Wl,-rpath flag
that is needed. Shoe-horning this flag into HOSTCC gets the job done,
and actually simplifies our arm-trusted-firmware.mk.
This patch break the compatibility with version prior to 1.4 (upstream
commit 72610c4102990 ("build: Introduce HOSTCC flag")). v1.4 is very old
(July 2017), not used anymore in-tree and probably not used anymore
outside the tree.
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Co-authored-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
TF-A prints a version string at boot which includes the version number as
specified in the Makefile and additional "build" information, specified by
the BUILD_STRING parameter:
https://trustedfirmware-a.readthedocs.io/en/v2.9/getting_started/build-options.html
BUILD_STRING: Input string for VERSION_STRING, which allows the TF-A build
to be uniquely identified. Defaults to the current git commit id.
This is implemented as:
# Default build string (git branch and commit)
ifeq (${BUILD_STRING},)
BUILD_STRING := $(shell git describe --always --dirty --tags 2> /dev/null)
endif
https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile#L225-L228
Which is never correct in the context of Buildroot, as the TF-A build
directory is never a git repo, and git will move up the directory tree and
possibly and (possibly) pick up the git version of Buildroot instead.
To fix that, explicitly set BUILD_STRING to the version of the package.
Pass it before BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES so it
can still be overridden by the user if needed.
strings images/tf-a-* | egrep '^v2\.'
v2.9(debug):2023.08-859-g99d78b52a0
v2.9(debug):v2.9
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bumps OP-TEE OS package version to OP-TEE release 4.0.0.
Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The toolchain wrapper automatically adds Position Independent
Execution and stack protector flags in the build process when selected
in the configuration. at91bootstrap being freestanding code, it
doesn't support these, so we have to disable them.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With bump of package/e2fsprogs to 1.47.0 [1] a freshly generated
ext4 fs has unfortunately different default features enabled
(e.g. metadata_csum_seed). This and some other newer fs features
(e.g. large_dir) are however not supported by our grub2.
Thus, newly generated ext-based rootfs won't be recognized by grub2
and are therefore not bootable/usable from grub2 anymore. This is
an issue already known to other Linux derivates [2],[3],[4].
This commit introduces two additional upstream patches to
package/grub2 which adds EXT4_FEATURE_INCOMPAT_CSUM_SEED and
EXT4_FEATURE_INCOMPAT_LARGEDIR to the EXT2_DRIVER_IGNORED_INCOMPAT
list of ignored incompatible ext features, allowing grub2 to
use ext filesystems with these newer default feature sets.
[1] https://git.buildroot.net/buildroot/commit/?id=6a21733f839478d902f3eab287a82b456e55f708
[2] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1844012
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031325
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030939
Signed-off-by: Jens Maus <mail@jens-maus.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For change log since version edk2-stable202305, see:
- https://github.com/tianocore/edk2/releases/tag/edk2-stable202308
The main motivations of this bump are the RISC-V QEMU Virt support
improvements (not yet supported in Buildroot).
Cc: Dick Olsson <hi@senzilla.io>
Cc: Vincent Stehlé <vincent.stehle@arm.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Grub 2.06 is affected by a number of CVEs, which have been fixed in
the master branch of Grub, but are not yet part of any release (there
is a 2.12-rc1 release, but nothing else between 2.06 and 2.12-rc1).
So this patch backports the relevant fixes for CVE-2022-28736,
CVE-2022-28735, CVE-2021-3695, CVE-2021-3696, CVE-2021-3697,
CVE-2022-28733, CVE-2022-28734, CVE-2022-2601 and CVE-2022-3775.
It should be noted that CVE-2021-3695, CVE-2021-3696, CVE-2021-3697
are not reported as affecting Grub by our CVE matching logic because
the NVD database uses an incorrect CPE ID in those CVEs: it uses
"grub" as the product instead of "grub2" like all other CVEs for
grub. This issue has been reported to the NVD maintainers.
This requires backporting a lot of patches, but jumping from 2.06 to
2.12-rc1 implies getting 592 commits, which is quite a lot.
All Grub test cases are working fine:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/984500585https://gitlab.com/tpetazzoni/buildroot/-/pipelines/984500679
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Arnout: fix check-package warning in patch 0002]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Certain TI K3 devices such as AM62x and AM62Ax require a Device Manager
(DM) firmnware to be made available to the U-Boot build, which will get
packaged into the "tispl.bin" image tree blob during A53 SPL build.
Without that DM firmware U-Boot will not be functional. To support this,
add a config option called BR2_TARGET_UBOOT_NEEDS_TI_K3_DM to enable
this feature, and another option BR2_TARGET_UBOOT_TI_K3_DM_SOC to allow
setting the name of the SOC which needs to match the corresponding
folder name in the ti-linux-firmware Git repository.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the image generator that builds the initial boot binary,
tiboot3.bin, for the R5 core on TI's K3 family of devices.
This requires the R5 SPL output from the ti-k3-r5-loader package as
well as some boot firmware from ti-k3-boot-firmware.
Signed-off-by: Xuanhao Shi <x-shi@ti.com>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Acked-by: Andrew Davis <afd@ti.com>
Tested-by: Bryan Brattlof <bb@ti.com>
Cc: Romain Naour <romain.naour@gmail.com>
Reviewed-by: Francois Perrad <francois.perrad@gadz.org>
Reviewed-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The TI K3 R5 loader package essentially is a wrapper to build a special
version of U-boot SPL used as part of a multi-stage boot flow on TI K3
devices, and as such needs full flexibility as to specifying the U-Boot
sources used for the build. To accomodate this, add the same options as
already available in the regular U-Boot package. For most use cases, the
same source settings (repo URL, versions, etc.) should be used for both
ti-k3-r5-loader and uboot packages.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We now have 3 different options to select an image as the BL33 stage
of TF-A: Barebox, U-Boot or EDK2. Technically speaking, they are
mutually exclusive: they all specify a BL33= variable to the TF-A
build, and TF-A can only support a single BL33 stage.
However, as pointed out by Vincent Fazio in [0] there is nothing that
prevents selecting Barebox, U-Boot and EDK2 together, even though it
doesn't make sense.
To address this, this commit introduces a choice...endchoice block,
into which the Barebox, U-Boot and EDK2 options are moved. An
additional "none" option is added, which is the default, and
corresponds to not having any BL33 image.
Since we keep the same name for the options, no legacy handling is
necessary.
[0] https://lore.kernel.org/buildroot/PH1P110MB1603A4AA1638838DA56BAA069FDA9@PH1P110MB1603.NAMP110.PROD.OUTLOOK.COM/
Reported-by: Vincent Fazio <vfazio@xes-inc.com>
Cc: Vincent Fazio <vfazio@xes-inc.com>
Cc: Casey Reeves <casey@xogium.me>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
gcc 12 added a warning that triggers on access to low addresses. Add a
patch to allow access since this is normal for low level code.
Rebase our existing patch on top. While at it, add also a proper
Upstream tag.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4795673785
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This package has dubious licensing conditions (not even documented in
the .mk file), and is a bootloader for very old platforms. The
defconfigs making use of it have been removed in Buildroot in 2014, in
commit c6a410964b ("configs: remove
lpc32xx defconfigs"), so let's get rid of the package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
[yann.morin.1998@free.fr: remove reference in test]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The at91dataflashboot code contains some hand-written ARM assembly
that uses ARM classic instructions, and will not build in Thumb-1
mode.
This issue has always existed in Buildroot, but it's only since we
started testing random configurations, including Thumb-1
configurations, that this issue popped up.
Fixes:
http://autobuild.buildroot.net/results/68bf2291201ef1882d8e8d3eca2b1a5ad731e4b0/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some barebox targets need to build host tools (for example rockchip64
uses scripts/rkimage) that require some host libraries, such as
host-openssl or host-libusb. These are detected by the Barebox build
system using pkg-config.
In order to allow supporting such Barebox configurations, we add two
new options: BR2_TARGET_BAREBOX_NEEDS_OPENSSL and
BR2_TARGET_BAREBOX_NEEDS_LIBUSB that respectively allow to ensure that
host-openssl and/or host-libusb are built before Barebox.
Additionally, $(1)_MAKE_ENV is adjusted to ensure that when pkg-config
is run by the Barebox build system, it finds host libraries. This is
similar to what is done in U-Boot.
This allows to fix the following build failure:
HOSTCC scripts/rkimage
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'virtual:world', not found
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccN8Xyaj.o: in function `main':
rkimage.c:(.text.startup+0x218): undefined reference to `SHA256_Init'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: rkimage.c:(.text.startup+0x22b): undefined reference to `SHA256_Update'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: rkimage.c:(.text.startup+0x23e): undefined reference to `SHA256_Final'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: rkimage.c:(.text.startup+0x253): undefined reference to `SHA256_Init'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: rkimage.c:(.text.startup+0x265): undefined reference to `SHA256_Update'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: rkimage.c:(.text.startup+0x275): undefined reference to `SHA256_Final'
collect2: error: ld returned 1 exit status
make[2]: *** [scripts/Makefile.host:107: scripts/rkimage] Error 1
make[1]: *** [Makefile:976: scripts] Error 2
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently for some Rockchip SoCs binary blobs are needed, e.g., for
the RK3588 bl31 and tpl. These blobs are provided by Rockchip. This
patch adds U-Boot package options to use theses binaries, provided
by the rockchip-rkbin package, which is also introduced in this
patch series. The U-Boot package is modified so that it takes the
chosen binaries and automatically uses them during build.
Signed-off-by: Kilian Zinnecker <kilian.zinnecker@mail.de>
[yann.morin.1998@free.fr:
- use already-qstripped variables from rockchip-rkbin
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As reported in commit [1] of the U-Boot project, the config.mk file has
been suppressed in order to use binman to manage FIT
generation. Therefore, the "u-boot.stm32" make target should no longer
be used with recent versions of U-Boot.
The configuration option added by this comit allows the creation of
the u-boot.stm32 image for both recent versions of U-Boot, which use
binman, and older versions.
Legacy handling would have suggested that this new option should
"default y" to preserve existing behavior, but as moving forward all
U-Boot new versions will no longer need this u-boot.stm32 target, it
probably makes sense here to not comply with this backward
compatibility rule, as an exception.
[1] 5564b4cd4d5c69 ("stm32mp: add binman support for STM32MP15x")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Tested-by: David Reaver <me@davidreaver.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When building a fip firmware (BR2_TARGET_ARM_TRUSTED_FIRMWARE_FIP=y), the
TF-A build recipe starts by building the host program fiptool with the
proper build environment variables. Then the main TF-A target firmware
build step takes place, with the expectation that the fiptool program will
be used under the hood if necessary.
In TF-A, the build recipe for the host program fiptool has subtly changed
after v2.7, in commit cf2dd17ddda2 ("refactor(security): add OpenSSL 1.x
compatibility"). This change has the effect to force re-linking fiptool
each time.
If we try to build with Buildroot a fip firmware with a TF-A version after
v2.7 comprising the aforementioned change, the fiptool program is forcibly
re-linked during the main firmware build step. This happens without the
proper build environment variables and consequently, if openssl is not
installed on the host, the libcrypto shared library will not be found by
the linker and the link will fail with the following error:
/usr/bin/ld: cannot find -lcrypto: No such file or directory
A patch has been integrated into TF-A to avoid re-linking fiptool when not
necessary, which should solve the problem starting with version v2.10. Add
that patch in Buildroot for versions v2.8 and v2.9, to repair the build in
the cases described above.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4664845767
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Dick Olsson <hi@senzilla.io>
Cc: Sergey Matyukevich <geomatsi@gmail.com>
[yann.morin.1998@free.fr:
- don't use symlink in v2.9, just copy patch
- fix numbering in v2.8 which now has two patches
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When EDK2 OVMF is built with debug, messages are printed to
IO port 0x402. Those messages are not shown in the normal
Qemu emulated serial port. Enabling this option will print
debug messages on the emulated serial port, potentially
mixing messages with UEFI serial console output.
See OVMF README:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
This option has been useful to debug problems such as [1], in which the
emulator was hanging at startup without any log. Enabling this option
show the debug message on the console, before hanging:
...
PlatformCpuCountBugCheck: Present=0 Possible=1
PlatformCpuCountBugCheck: Broken CPU hotplug register block found. Update QEMU to version 8+, or
PlatformCpuCountBugCheck: to a stable release with commit dab30fbef389 backported. Refer to
PlatformCpuCountBugCheck: <https://bugzilla.tianocore.org/show_bug.cgi?id=4250>.
...
[1] http://lists.busybox.net/pipermail/buildroot/2023-July/670807.html
Signed-off-by: Julien Olivain <ju.o@free.fr>
Tested-by: Romain Naour <romain.naour@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In order for host-dtc to get picked up properly we need to set
the DTC path passed to the build explicitly.
See:
https://github.com/u-boot/u-boot/blob/v2023.07.02/Makefile#L420
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The new version of binutils introduces a new warning when linking. The
new warninng is enabled by default. To fix the issue this warning is
disabled by adding the patches to the arm-trusted-firmware package
v{2.2..2.8}. This is a backport of an upstream commit [1]
Since there are too many defconfigs that use the arm-trusted-firmware
package, it is not practical to create a global-patch-dir for all of them.
Therefore the patches are only in the package directory.
[1] 1f49db5f25
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4603996186https://gitlab.com/buildroot.org/buildroot/-/jobs/4603996189
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Cc: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Tested-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr: add proper Upstream: tags]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This feature was added in commit d07e6b7071 ("boot/uboot/uboot.mk: add
pmufw.elf support"), document it in kconfig.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Bumps OP-TEE OS package version to OP-TEE release 3.21.0.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
