With the new cpu dependencies included in the xilinx-prebuilt package,
BR2_TARGET_XILINX_PREBUILT_VERSAL is now default when BR2_cortex_a72 is
selected. This means that BR2_TARGET_XILINX_PREBUILT_VERSAL is not needed
in the versal_*_defconfig files anymore.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add an architecture cpu dependency to each family to make sure that users can
only install prebuilt firmware which is applicable to their target device
family.
The versal family is based on BR2_cortex_a72.
The kria and zynqmp families are based on BR2_cortex_a53.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add an architecture cpu dependency to each application to make sure that users
can only build applications which are applicable to their target device
family.
The versal_plm and versal_psmfw applications are specific to versal devices
which are based on BR2_cortex_a72.
The zynqmp_pmufw application is specific to zynqmp devices which are based on
BR2_cortex_a53.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Currently, the xilinx-embeddedsw and xilinx-prebuilt packages are appearing
for any aarch64 processor. As all Xilinx processors that need these packages
are ARM Cortex-A53 or ARM Cortex-A72, this means that these packages are
often appearing as options for non-Xilinx platforms.
To reduce this occurrence, this patch creates a new symbol
BR2_TARGET_XILINX_FIRMWARE_ARCH_SUPPORTS to limit the appearance of the
xilinx-embeddedsw and xilinx-prebuilt boot packages to only platforms based
on the BR2_cortex_a53 or BR2_cortex_a72 CPU and aarch64 architecture.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a defconfig to build an AArch64 disk image with a U-Boot based
firmware implementing the subset of UEFI defined by EBBR[1], as well as
a Linux OS booting with UEFI, to run on the IOT-GATE-iMX8 from Compulab.
The generated firmware binary can also be used to install or run another
OS supporting the EBBR specification.
This configuration is based on the work of Paul Liu[2] and is not related
with the official BSP from Compulab.
This has been tested on actual hardware.
While at it, add this defconfig to myself in DEVELOPERS.
[1] https://github.com/ARM-software/ebbr
[2] https://git.linaro.org/plugins/gitiles/people/paul.liu/systemready/build-scripts
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ying-Chun Liu (Paul Liu) <paul.liu@linaro.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Also set BuiltForPackageManager=buildroot so that cloudflared's update
command informs the user to update cloudflared via buildroot.
Without BuiltForPackageManager set:
cloudflared update
INF cloudflared is up to date version=
With BuiltForPackageManager set:
cloudflared update
ERR cloudflared was installed by buildroot. Please update using the same method.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
For relase notes, see:
https://go.dev/doc/devel/release#go1.25.0
Building Go 1.24 and later requires Go 1.22.6 or later for bootstrap.
To support this we use our previous Go version 1.23.12 as the version
for go-bootstrap-stage4 and have the build for Go 1.25.1 depend on
go-bootstrap-stage4.
Go version 1.23.12 is the latest go version we can build using
go-bootstrap-stage3.
The package build for go-bootstrap-stage4 if effectively identical to
go-bootstrap-stage3 with only the Go version and stage number changed.
Note: go version 1.25.1 release note mention a security fix
which is for CVE-2025-47910. This commit is not marked as security
bump, because the issue was introduced in version 1.25.0 which
was not included in Buildroot. See:
https://pkg.go.dev/vuln/GO-2025-3955
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Tested-by: Christian Stewart <christian@aperture.us>
[Julien: add link to release notes and
comment about CVE in commit log.
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Patches submitted to update these packages have gone ignored for
months without comment, and I no longer wish to recieve daily
emails about them being out of date.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since the Xilinx Zynq SoC family is always based on ARM Cortex-A9 CPUs, the
BR2_TARGET_UBOOT_ZYNQ option should only be available when the BR2_cortex_a9
option is selected.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
On Zynq, the booloader is responsible for some basic initializations, such as
enabling peripherals, DDR and configuring pinmuxes. The ps7_init_gpl.c file
(and optionally, ps7_init_gpl.h) contains the code for such initializations.
Although U-Boot contains ps7_init_gpl.c files for some boards, each of them
describes only one specific configuration. Users of a different board, or
needing a different configuration, can generate custom files using the Xilinx
Vivado development tools.
This patch adds Buildroot support for custom zynq ps7_init_gpl.c files in the
same way that is already done for zynqmp when working with custom hardware
that is not already supported by u-boot.
To test this feature, the following configs can be added to any zynq_defconfig:
BR2_TARGET_UBOOT_ZYNQ=y
BR2_TARGET_UBOOT_ZYNQ_PS7_INIT_FILE=<path to custom board ps7_init_gpl.c>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch bumps the binutils-bare-metal package to version 2.45. In the
process, it also decouples binutils-bare-metal from the binutils package
since the binutils package does not yet have support for version 2.45.
With the decoupling, the 3 downstream binutils 2.44 patches were evaluated.
Patches not needed for binutils-bare-metal:
0001-sh-conf.patch
0002-poison-system-directories.patch
Patches already included with binutils version 2.45:
0003-objdump-memleak.patch
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ba6ad3a18cb26b79e0e3b84c39f707535bbc344d
Since none of these patches need to be applied to binutils-bare-metal 2.45,
the link to the binutils patch directory is deleted.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch decouples the gcc-bare-metal package from the gcc package to avoid
potential build issues when bumping the version of one package before the
other.
Such as the build issue example here:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11026775160
Since the gcc-bare-metal package does not currently require the gcc 15.2.0
downstream patches, this patch simply deletes the link for patching
gcc-bare-metal 15.2.0 with patches that are not needed for bare-metal apps.
As for the hash link, this patch creates a new file called gcc-bare-metal.hash
which has the same hashes in the gcc.hash file. But by having its own hash
file, hashes from the gcc package can be removed when version bumping without
causing build errors for the gcc-bare-metal package.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Sometimes the default GCC and newlib libraries built for a given
architecture tuple are not based on the desired ABI. Since ABI definitions are
different between architectures, the simplest solution is to allow users to
build bare-metal toolchains with --enable-multilib. This way, the libraries
for every available ABI will be built and users will be able to select the
desired library for their user applications.
This patch adds the option BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_MULTILIB to give
users the choice to enable multilib, if desired.
Please note that when using a string of architecture tuples, this option will
apply to all architectures in the string, so it can significantly increase
build time.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Jesse Taube <Mr.Bossman075@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This removes a warning reported by shellcheck: "Double quote to prevent
globbing and word splitting". As a result, the file can be removed from
.checkpackageignore.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y and
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_GLIBC_STABLE=y in the
defconfig, bumps kernel to 6.16.7, and adds custom hash files and
removes the exception entry in .checkpackageignore.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[Julien:
- mention kernel bump in commit title
- move BR2_DOWNLOAD_FORCE_CHECK_HASHES=y down in defconfig
- remove linux-headers hash file
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Increase again the partition size to accommodate latest kernel.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y and
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV6_EABIHF_GLIBC_STABLE=y in the
defconfig, bumps kernel to 6.16.7, and adds custom hash files and
removes the exception entry in .checkpackageignore.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[Julien:
- mention kernel bump in commit title
- move BR2_DOWNLOAD_FORCE_CHECK_HASHES=y down in defconfig
- remove linux-headers hash file
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The elfutils package provides libdw, which is required by sysprof.
It is not an optional dependency.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This fixes building sysprof when elfutils is also selected (which is
a common setup). The debuginfod client support relies in elfutils
being built with the libdebuginfod option enabled; but Buildroot
unconditionally disables it in the elfutils package. See commit [1].
[1] 52c5c6050c
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Julien: add link to commit disabling debuginfod]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Some links are still pointing to git.buildroot.org, which is the old URL
for the official Buildroot git repository. The repository is now hosted
at gitlab.com. Update those old links accordingly.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Many links pointing to buildroot.org are still prefixed with HTTP.
Update those to HTTPS.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
See the release notes:
- https://github.com/OpenPrinting/cups/releases/tag/v2.4.13
- https://github.com/OpenPrinting/cups/releases/tag/v2.4.14
This fixes the following vulnerabilities:
- CVE-2025-58060:
OpenPrinting CUPS is an open source printing system for Linux and
other Unix-like operating systems. In versions 2.4.12 and earlier,
when the `AuthType` is set to anything but `Basic`, if the request
contains an `Authorization: Basic ...` header, the password is not
checked. This results in authentication bypass. Any configuration that
allows an `AuthType` that is not `Basic` is affected. Version 2.4.13
fixes the issue.
https://www.cve.org/CVERecord?id=CVE-2025-58060
- CVE-2025-58364:
OpenPrinting CUPS is an open source printing system for Linux and
other Unix-like operating systems. In versions 2.4.12 and earlier, an
unsafe deserialization and validation of printer attributes causes
null dereference in the libcups library. This is a remote DoS
vulnerability available in local subnet in default configurations. It
can cause the cups & cups-browsed to crash, on all the machines in
local network who are listening for printers (so by default for all
regular linux machines). On systems where the vulnerability
CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was
not fixed, and the firewall on the machine does not reject incoming
communication to IPP port, and the machine is set to be available to
public internet, attack vector "Network" is possible. The current
versions of CUPS and cups-browsed projects have the attack vector
"Adjacent" in their default configurations. Version 2.4.13 contains a
patch for CVE-2025-58364.
https://www.cve.org/CVERecord?id=CVE-2025-58364
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds BR2_DOWNLOAD_FORCE_CHECK_HASHES=y in the defconfig
and adds custom hash files. The exception entry in .checkpackageignore
is also removed.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
[Julien: change linux.hash comment to reuse hash from upstream]
Signed-off-by: Julien Olivain <ju.o@free.fr>
When searching for the official git repository in the documentation,
readers are forwarded to the buildroot website Download page with a link
pointing to buildroot.org/download, which returns a 404.
Fix the dead link by adding the missing .html suffix.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The CMake build system has logic to detect the git repo info and include it
in the version output. This unfortunately gets confused and adds the git
info of the Buildroot repository when building inside the repo:
-- Found Git version: refs/heads/rtl_433-25.02 commit a367362af0 from 2025-09-21T20:07:58+0200
-- Using Git version tag: 2025.08-283-ga367362af0 on rtl_433-25.02 at 202509212007
rtl_433 -V
rtl_433 version 2025.08-283-ga367362af0 branch rtl_433-25.02 at 202509212007 inputs file rtl_tcp RTL-SDR
Pass GIT_DIR=. to the configure step similar to how it is already done for
the build step to disable this.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Update icu to 77.1.
The LICENSE file contains a lot of changes, so no diff
is presented.
Patch 0002-workaround-toolchain-bugs.patch is no longer required.
Reorder the other patches accordingly.
Update patch 0003-fix-static-linking-with-icu-uc.patch so that
it applies cleanly.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
TestGitHash and TestGitRefs are failing on Gitlab-CI since 2025-08-18
(first runtime-test failures report for master) [1] due a new Gitlab-CI
security settings that prevents the any use of localhost (127.0.0.1) on
the Gitlab-CI runner [2]:
"To prevent exploitation of insecure internal web services, all webhook
and integration requests to the following local network addresses are
not allowed:
Private network addresses, including 127.0.0.1, ::1, 0.0.0.0,
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and IPv6 site-local
(ffc0::/10) addresses."
Gitlab suggest using a second container as a Services [3] since each
containers have access to one another and can communicate when running
the job. But this is really not practical to run git daemon since the
service is started before the Buildroot git tree is fetched and git
daemon needs git-remote directory content.
See [4]:
"If you have your service that tries to write to CI_PROJECT_DIR
immediately after it's started - it will not work and fail with an
error like '/builds/nknapp/gitlab-ci-test/': No such file or directory
error. Because that directory is most probably not there yet, as the
job step that creates it is yet to be executed!"
Also, using Gitlab-CI services requires to handle GitTestBase setUp
differently on Gitlab-CI than local use of run-tests.
So Gitlab-CI services is not an option.
We could move support/testing/tests/download/git-remote to our Gitlab
group (https://gitlab.com/buildroot.org) but since it's only intended
for testing the git download backend, we don't really want to do that.
So the only remaining choice to clone the repository from the Buildroot
git tree (local machine).
To do so, we have to do the following changes:
- Replace all "git://localhost:$(GITREMOTE_PORT_NUMBER)" by
"$(GITREMOTE_DIR)". GITREMOTE_DIR will contain the absolute path to
tests/download/git-remote directory.
- Force to use git download backend using "SITE_METHOD = git" otherwise
the download infra will fall back using wget download backend.
- Cloning a git repository with submodules using the "file://" protocol
needs to be allowed from git config. It's disabled by default:
"fatal: transport 'file' not allowed"
Use a local gitconfig file generated by GitTestBase before starting
TestGitHash and TestGitRefs with:
[protocol "file"]
allow = always
This is considered safe since we are using a git repository from the
Buildroot git tree.
- Running TestGitHash and TestGitRefs on Gitlab-CI requires additional
git config settings to disable ownership check of the git tree [5].
Thanks to Arnout for advices about GIT_CONFIG_GLOBAL.
Runtime tested:
https://gitlab.com/kubu93/buildroot/-/jobs/11428504450 (TestGitHash)
https://gitlab.com/kubu93/buildroot/-/jobs/11428490035 (TestGitRefs)
[1] https://lore.kernel.org/buildroot/68a3ee65.500a0220.397724.30db@mx.google.com/
[2] https://docs.gitlab.com/security/webhooks/#allow-requests-to-the-local-network-from-webhooks-and-integrations
[3] https://docs.gitlab.com/ci/services/
[4] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25982#note_2139685797
[5] a016b693f7
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124174 (TestGitHash)
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124173 (TestGitRefs)
Cc: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
