Those target configurations marked as "secondary" will be tested with a
lower probability in autobuilders. The intent is to focus the Buildroot
development (and bugfixes) on mainstream configurations, while still
keeping some other, less common, configurations.
This commit marks the following CPU architectures as secondary:
BR2_arcle (ARC little endian)
BR2_armeb (ARM big endian)
BR2_aarch64_be (AArch64 big endian)
BR2_hppa (PA-RISC)
BR2_loongarch64
BR2_m68k
BR2_microblazeel (Microblaze AXI, little endian)
BR2_microblazebe (Microblaze non-AXI, big endian)
BR2_mips (MIPS, big endian)
BR2_mipsel (MIPS, little endian)
BR2_mips64 (MIPS64 big endian)
BR2_or1k (OpenRISC)
BR2_powerpc (PowerPC, big endian)
BR2_powerpc64 (PowerPC64, big endian)
BR2_s390x
BR2_sh (SuperH)
BR2_sparc
BR2_sparc64
BR2_xtensa
In the following CPU architecture, only specific configurations are
marked secondary:
In BR2_armeb (ARM little endian),
- armv4 cores (arm920t, arm922t, fa526/626, strongarm sa110/sa1100)
In BR2_riscv:
- all 32-bit configurations
- 64-bit no-MMU
In BR2_i386 (x86 32-bit),
- i486, i586 and X1000 CPU
There was no strict rule established to build this list of secondary
configurations. This list was built mainly from the observation of
which architecture/CPUs are still widely used in the field
(disregarding its age), the quality of their upstream support and
the general relevance in the Buildroot project.
Signed-off-by: Julien Olivain <ju.o@free.fr>
[Arnout: use !BR2_HIDE_SECONDARY_TARGET_OPTIONS instead of
BR2_SHOW_SECONDARY_TARGET_OPTIONS]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Add support for the Precision Architecture (a.k.a. PA-RISC),
a 32-bit architecture developed by Hewlett Packard.
While at it, add this arch to myself in DEVELOPERS.
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Julien Olivain <ju.o@free.fr>
[Julien: arch "arch/" prefix in commit title]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Alexey Brodkin from Synopsys says in [1]:
I think indeed, we may remove all the big-endian support for ARC.
Reasons are since introduction of ARC HS4x processors we no longer
support big-endian in any new processor IP, and even for older IP
which used to support big-endian it was rarely used... so basically
there's no good justification to spend any cycles on big-endian
support looking forward in this project. I.e. BE support in uClibc
could also be removed if it makes any difference.
Therefore, let's removed support for ARC big-endian.
[1] https://lore.kernel.org/buildroot/SJ2PR12MB818487232470DA4456967C73A1A3A@SJ2PR12MB8184.namprd12.prod.outlook.com/
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: ARC Maintainers <arc-buildroot@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
[Julien:
- move legacy option to 2026.02 section
- add link to mailing list
- remove BR2_arceb from pkg-meson.mk to fix check-symbols error
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Glibc introduced LoongArch64 support in 2.36, it requires kernel
5.19 to build.
Unselect BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT to reflect we can
build the toolchain.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Introduce LoongArch64 at architecture level.
Config.in.loongarch is prepared for possible loongarch32
enablement in future, thus BR2_ARCH_IS_64 is being depended
by some 64bit only options.
Internal toolchain is supported, as our minimal binutils
version is already beyond LoongArch minimal version and
GCC option is limited by BR2_ARCH_NEEDS_GCC_AT_LEAST_12.
BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT is selected temporary
and it's going to be rmoved after we gain libc support.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
[Julien: fix typo in Kconfig BR2_LOONGARCH_ABI_LP64S prompt
replace "lp64d" by "lp64s"]
Signed-off-by: Julien Olivain <ju.o@free.fr>
gcc 15 was introduced in Buildroot in commit [1].
In Buildroot, a user creates a build configuration in Kconfig
menus by selecting the CPU architecture and CPU first, then
a toolchain that support this CPU, then packages and system
configuration.
To make sure those Kconfig menus and choices behave correctly in that
order, we use a logic in which a CPU selects the Kconfig symbol
BR2_ARCH_NEEDS_GCC_AT_LEAST_N (with N being the needed gcc version).
Then, to make sure unsupported gcc version are hidden for a selected
CPU, a gcc version N has in fact a "depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_(N+1)". For example, Cortex-A710 needs
at least gcc 12. See [2] and [3].
This means that when we introduce the latest gcc version with this
logic in place, we already need this BR2_ARCH_NEEDS_GCC_AT_LEAST_(N+1)
symbol defined. Doing so is desirable to avoid forgetting to add it
later. See for example commit [4], adding those missing dependencies
for gcc 13 and 14.
Since in Buildroot we currently keep 3 actively maintained gcc
versions, adding a new gcc version N in Buildroot should:
- add the BR2_ARCH_NEEDS_GCC_AT_LEAST_(N+1) symbol
- add package/gcc N
- switch the default gcc from N-2 to N-1
- drop package/gcc N-3
Then, once this new gcc N is added, new CPUs supported by that version
can be introduced, by selecting BR2_ARCH_NEEDS_GCC_AT_LEAST_N.
All this logic will be ready for future gcc versions. This was also
described in commit log [5].
This commit simply adds the BR2_ARCH_NEEDS_GCC_AT_LEAST_16 symbol.
It is worth mentioning that, at the time of this commit, gcc 16 is not
released yet. This release number 16 is already known, though. See [6].
For reference, this was discussed in [7].
[1] 75891397ab
[2] https://gitlab.com/buildroot.org/buildroot/-/blob/2025.05/arch/Config.in.arm#L514
[3] https://gitlab.com/buildroot.org/buildroot/-/blob/2025.05/package/gcc/Config.in.host#L27
[4] 6f231d3003
[5] eab17d763c
[6] https://gcc.gnu.org/gcc-16/changes.html
[7] https://lore.kernel.org/buildroot/877c0v1sn1.fsf@dell.be.48ers.dk/T/#m45688e25632401029e4c0d989072e1d3e1a59854
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Doing so, we remove nios2 support from the internal toolchain backend.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since we're going to introduce external toolchains that are based on
GCC 14.x, we will need them to "depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_15", so let's introduce this symbol
first.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
With this patch series we again allow building a Buildroot toolchain
for SPARC, because SPARC was fixed in uClibc-ng, so SPARC systems
work fine now.
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since commit
a0d2a5cfec ("support/scripts/gen-bootlin-toolchains:
generate BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard"), the
gen-bootlin-toolchains script will generate references to
BR2_ARCH_NEEDS_GCC_AT_LEAST_X including potentially against the "next"
version of gcc.
Indeed, a toolchain using gcc 13.x should have a "depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_14" so that once some architectures that
require gcc 14.x are added, such toolchains are not made visible.
In order for this to work, we must have the
BR2_ARCH_NEEDS_GCC_AT_LEAST_x symbol ready for the N+1 version of gcc
compared to the latest one we support.
As we're supporting up to gcc 13.x right now, let's introduce the
symbol BR2_ARCH_NEEDS_GCC_AT_LEAST_14 so that gcc 13.x toolchains can
be marked depends on !BR2_ARCH_NEEDS_GCC_AT_LEAST_14.
The other alternative would be to make the gen-bootlin-toolchains a
bit smarter, and not emit this depends on
!BR2_ARCH_NEEDS_GCC_AT_LEAST_14 if BR2_ARCH_NEEDS_GCC_AT_LEAST_14 does
not exist. But this would require re-running the script when
BR2_ARCH_NEEDS_GCC_AT_LEAST_14 which we are unlikely to do. While
today, when the script is invoked, the usual check-symbols complains
and reminds us that BR2_ARCH_NEEDS_GCC_AT_LEAST_14 should be added, so
we remember to do it right away.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since gcc 11 [1] the sparc architecture is disabled since
it produce a non working image. Buildroot now provide gcc
13.x, 12.x and 11.x and we are going to remove gcc 10
that was the last working release (thanks to a local patch).
We have to disable the internal toolchain backend for sparc
before removing gcc 10. While at it, remove !BR2_sparc
dependency for gcc 11.x, 12.x and 13.x.
[1] 2ab88dac29
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We currently have no internal and no external toolchain for csky.
The website is down (no https:// available, and the http:// index
page is 404).
This commit removes the architecture entry; remnants will be dropped in
followup changes.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Right now the "Target options" menu looks like this:
Target architecture (....)
... options related to the binary format selection ...
... options related to the architecture variant selection ...
This doesn't make much sense: the architecture variant selection
should be just below the target architecture selection. With this
commit, things will now be presented this way:
Target architecture (....)
... options related to the architecture variant selection ...
... options related to the binary format selection ...
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The commit [1] removed the Config.in.host file and moved the arm, sh,
sparc, xtensa and riscv-64 architectures dependencies. But this list
doesn't contain all elf2flt supported architectures and this breaks
the host-gcc-initial build for m68k.
Since BR2_BINFMT_FLAT is only available on no MMU case, we can rely on
BR2_USE_MMU option and remove the architecture list.
Note: SH without MMU support has been removed by [2], sparc requires
an MMU since at least [3].
Fixes:
http://autobuild.buildroot.net/results/15d62edfc4b54c0b40b9d3961b797bce4e307919/
[1] 9db5eb258c
[2] 04ea3d38dd
[3] 29563047e0
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no need to have configuration files direbtly set the
BR2_PACKAGE_HOST_ELF2FLT option. The need for the elf2flt utility is
automatically determined by gcc build in package/gcc/gcc.mk according to
the BR2_BINFMT_FLAT option.
Accordingly, we can remove the file package/elf2flt/Config.in.host to
get rid of the BR2_PACKAGE_HOST_ELF2FLT option. BR2_STRIP_strip
dependency on this option is replaced with a dependency on
BR2_BINFMT_ELF.
To stay consistent with the fact that elf2flt supports only the arm, sh,
sparc, xtensa and riscv-64 architectures, a dependency on these
architectures is added to the BR2_BINFMT_FLAT option in arch/Config.in.
Board configuration files setting the BR2_PACKAGE_HOST_ELF2FLT option
are also updated.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The support for this architecture has been removed from the upstream
Linux kernel, as of commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f
Which states:
The nds32 architecture, also known as AndeStar V3, is a custom
32-bit RISC target designed by Andes Technologies. Support was added
to the kernel in 2016 as the replacement RISC-V based V5 processors
were already announced, and maintained by (current or former) Andes
employees.
As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.
There has also been little to no maintenance done in Buildroot for
this architecture in recent times, so let's follow the Linux kernel
community decision and drop support for this CPU architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Selecting BR2_ARCH_HAS_MMU_MANDATORY from BR2_aarch64 and
BR2_aarch64_be doesn't make much sense, because the actual ARM cores
described in arch/Config.in.arm then all select
BR2_ARCH_HAS_MMU_OPTIONAL. So we end up with both
BR2_ARCH_HAS_MMU_OPTIONAL and BR2_ARCH_HAS_MMU_MANDATORY, which
doesn't make any sense.
To prevent this, we remove the selection of BR2_ARCH_HAS_MMU_MANDATORY
from BR2_aarch64 and BR2_aarch64_be, and let arch/Config.in.arm do its
job. What arch/Config.in.arm does is currently incorrect, but it will
be fixed in a separate commit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that all SuperH cores have an MMU, and must use it, move back the
select BR2_ARCH_HAS_MMU_MANDATORY one level up.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The variable 'KERNEL_ARCH' is actually a normalized version of
'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just
as all powerpc variants become 'powerpc'.
It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically
the first place where support for a new architecture is added, and thus is
the entity that defines the normalized name.
However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture
used by the kernel', which need not be exactly the same as 'the normalized
name for a certain arch'. In particular, for cases where a 64-bit
architecture is running a 64-bit kernel but 32-bit userspace. Examples
include:
* aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace
* x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace
In such cases, the 'architecture used by the kernel' needs to refer to the
64-bit name (aarch64, x86_64), whereas all userspace applications need to
refer the, potentially normalized, 32-bit name.
This means that there need to be two different variables:
KERNEL_ARCH: the architecture used by the kernel
NORMALIZED_ARCH: the normalized name for the current userspace architecture
At this moment, both will actually have the same content. But a subsequent
patch will add basic support for situations described above, in which
KERNEL_ARCH may become overwritten to the 64-bit architecture, while
NORMALIZED_ARCH needs to remain the same (32-bit) case.
This commit replaces use of KERNEL_ARCH where actually the userspace arch is
needed. Places that use KERNEL_ARCH in combination with building of kernel
modules are not touched.
There may be cases where a package builds both a kernel module as userspace,
in which case it may need to know about both KERNEL_ARCH and
NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on
a per-need basis.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Similar to other arch-specific strings, the 'KERNEL_ARCH' variable can be
determined from Config.in.<arch> files.
Besides aligning with similar strings, this also means simplification: the
big 'sed' covers several architectures not even supported by Buildroot.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Linux supports No-MMU RISC-V 64-bits since kernel version 5.8. Make
MMU optional to enable building for RISC-V 64-bits boards that do not
have one. MMU use of RISC-V 32-bits builds remains mandatory for now.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
[yann.morin.1998@free.fr: drop supperfluous depends on s390x in choice]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As Guo explained, upstream gcc does not support abi-v1 (only abi-v2), but
ck610 needs abi-v1 [0] [1]
To simplify things, we make the whole C-SKY architecture require gcc-9
or later, and add a single exception in gcc to force the ck610 to use
the C-SKY port.
Note that this does not change the default gcc version to be used for
C-SKY: the C-SKY port is still always the default one; the gcc-9 version
is only proposed as an alternative (except for ck610, of course).
[0] http://lists.busybox.net/pipermail/buildroot/2019-July/254386.html
[1] package/Makefile.in#73
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Guo Ren <guoren@kernel.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Romain Naour <romain.naour@gmail.com>
Acked-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that we have support for C-SKY in gcc, binutils and glibc, we can
use Buildroot to build a C-SKY toolchain.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In commit 325bb37942, support for the
Blackfin architecture was removed. This was our only use of
BR2_GCC_TARGET_CPU_REVISION, and since this config option somewhat
complicates the calculation of the --with-cpu/-mcpu option values,
let's drop it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This enables a riscv64 system to be built with a Buildroot generated
toolchain (gcc >= 7.x, binutils >= 2.30, glibc only).
This configuration has been used to successfully build a qemu-bootable
riscv-linux-4.15 kernel (https://github.com/riscv/riscv-linux.git).
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
[Thomas:
- simplify arch.mk.riscv by directly setting GCC_TARGET_ARCH
- simplify glibc.mk changes by using GLIBC_CONF_ENV.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we dropped support for blackfin, we no longer have any
architecture that supports FDPIC, so BR2_ARCH_HAS_FDPIC_SUPPORT
is never selected, so we can't select BR2_BINFMT_FDPIC.
Drop all of that now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Blackfin architecture has for a long time been complicated to
maintain, with poor support in upstream binutils/gcc. As of April
2018, the Blackfin architecture has been dropped from the upstream
Linux kernel. Also, the Analog Device engineer who used to be in touch
with the Buildroot community also privately said we should drop the
support for this architecture, which Analog Devices is no longer
using, promoting and maintaining.
The BR2_BINFMT_FLAT_SEP_DATA option becomes unselectable, it will be
removed in a future commit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
