Adds a new user-configurable string to arch/Config.in.riscv, and in
arch/arch.mk.riscv appends it to GCC_TARGET_ARCH.
This enables custom extensions/combinations to be easily configured.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Jesse Taube <Mr.Bossman075@gmail.com>
[Arnout:
- fix check-package warnings
- introduce ARCH_RISV_ISA_EXTRA to simplify stripping of quotes
]
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>
Toolchain failed to bootstrap with LP64F and LP64S ABIs.
As reported by Julien in [1]:
Testing the "lp64f" ABI with commands:
cat >.config <<EOF
BR2_loongarch64=y
BR2_LOONGARCH_FPU_32=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
EOF
make olddefconfig
make
fails in host-gcc-initial with output:
Assembler messages:
/tmp/ccEkwSsD.s:28: Error: register save offset not a multiple of 8
/tmp/ccEkwSsD.s:30: Error: register save offset not a multiple of 8
/tmp/ccEkwSsD.s:50: Error: register save offset not a multiple of 8
See also autobuilder failures such as [2].
Testing the "lp46s" ABI with commands:
cat >.config <<EOF
BR2_loongarch64=y
BR2_LOONGARCH_FPU_NONE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
EOF
make olddefconfig
make
fails in host-gcc-final with output:
/buildroot/output/host/loongarch64-buildroot-linux-gnusf/bin/ld: cannot find crti.o: No such file or directory
/buildroot/output/host/loongarch64-buildroot-linux-gnusf/bin/ld: cannot find -lc: No such file or directory
/buildroot/output/host/loongarch64-buildroot-linux-gnusf/bin/ld: cannot find crtn.o: No such file or directory
See also autobuilder failures with as [3].
This commit marks those ABIs as broken at the moment to allow time
for investigation. Also, since gcc defaults to the "lp64d" ABI which
requires a 64bit FPU is present, the BR2_LOONGARCH_FPU_32 and
BR2_LOONGARCH_FPU_NONE options also needs to be marked as broken
as well. See [4].
[1] https://lore.kernel.org/buildroot/e17da108d1fb4e6abda26445dc053b35@free.fr/
[2] https://autobuild.buildroot.org/results/f98570293823867e6c43a1672e1a4b43ca1e4be5
[3] https://autobuild.buildroot.org/results/cf56c37fabcae964dbf4f96eb43a7e4d964452b6
[4] https://lore.kernel.org/buildroot/7b0f1cb629fce8a57d9b644b8beb8b2a@free.fr/
Cc: Mingcong Bai <jeffbai@aosc.io>
Cc: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
[Julien:
- add link to mailing list discussion
- add configuration to reproduce issues to help future investigations
- add links to autobuilder failures in commit log
- mark BR2_LOONGARCH_FPU_{32,NONE} as broken
]
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
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>
This commit adds the Neoverse N2 core, which is an implementation of
the armv9.0a ISA. See: [1] [2].
This CPU support was added in GCC 11. See [3].
The Neoverse N2 CPU is included in the Arm sbsa-ref platform in Qemu.
The Armv9.0-A Buildroot support will be needed to update those SBSA
related components. See the note in commit log [4].
This commit introduces the BR2_ARM_CPU_ARMV9A Kconfig symbol, which just
selects BR2_ARM_CPU_ARMV8A. This is because Armv9.0-A is a superset of
Armv8.5-A. This symbol can help package recipes to detect this new base
architecture.
Neoverse-N2 support has been added in QEmu in commit [5], first
included in v8.2.0.
This CPU supports Aarch32 only in EL0 (user-space). This means it's
technically possible to compile Aarch32 code targeting it. GCC has
the support to do so. Since Buildroot recompiles a full system (ATF,
Kernel, user-space) this support has limited value. This is why this
CPU is limited to 64bit builds only.
[1] https://developer.arm.com/Processors/Neoverse%20N2
[2] https://developer.arm.com/documentation/102099/0003/The-Neoverse-N2--core/Neoverse-N2--core-features
[3] https://gcc.gnu.org/gcc-11/changes.html
[4] c58a2a9687
[5] dfff1000fe
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Linux on ARM supports FDPIC binaries intended for use on no-MMU
systems. This patch enables support for building a toolchain that
produces FDPIC binaries, only for ARMv7-M platforms, for which FDPIC
binaries are relevant.
The target name for a FDPIC toolchain must be
arm-<vendor>-uclinuxfdpiceabi, which doesn't follow the standard
format and requires a special case.
Signed-off-by: Ben Wolsieffer <Ben.Wolsieffer@hefring.com>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot is probably the only thing lightweight enough to run on
68030 machines in the current day.
Add a CPU option for the 68030.
Tested on a Motorola MVME147.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
According to the GCC 14.x release notes at
https://gcc.gnu.org/gcc-14/changes.html:
Xeon Phi CPUs support (a.k.a. Knight Landing and Knight Mill) are
marked as deprecated. GCC will emit a warning when using the
-mavx5124fmaps, -mavx5124vnniw, -mavx512er, -mavx512pf,
-mprefetchwt1, -march=knl, -march=knm, -mtune=knl or -mtune=knm
compiler switches. Support will be removed in GCC 15.
Using those architectures already emits warnings, which when treated
as errors cause build failures, such as:
cc1: error: '-march=knm' support will be removed in GCC 15 [-Werror=deprecated]
cc1: all warnings being treated as errors
Therefore, let's drop support for those two architectures, which are
anyway not common at all, especially in the embedded space.
Fixes:
http://autobuild.buildroot.net/results/ce98c41b22212f52bf7b53d84871b8e03409dbca/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Pentium M does support SSE2 so it would make sense to enable it.
Signed-off-by: Stefan Ott <stefan@ott.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
The BCM2712 of the RaspberryPi 5 supports for 16KB page size.
This adds support for 16 KB on ARM64.
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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 it was introduced in 5a6087d62e (toolchain: add powerpc SPE ABI
support), the CLASSIC vs. SPE choice for the ABI was never really a
choice: CPU without SPE could only use the CLASSIC ABI, while CPUs with
SPE could only use the SPE ABI.
Commit b4c824562b (powerpc: add BR2_POWERPC_CPU_HAS_SPE to replace
adhoc deps/checks) added a blind option that CPUs with SPE would select
rather than duplicate the ad-hoc dependencies in both CLASSIC and SPE
ABI options. Since then, it was even more obvious that the ABI choice
was really not a choice, as the two options have mutually exclusive
conditions.
Drop the useless choice, and directly use the blind option as selected
by the specific CPUs.
We don't need legacy handling, because the situation fixes itself.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The generic extension set 'G' is realy a base with the minimal set of
extensions needed to be comfortable (but not required) to run a
linux-bassed system. Similarly, we consider the custom to be about the
custom set of features (not about a custom core implementing such a
set).
As such, we allow that a core with the G set can have futher extensions
without requiring it to be configured as a custom set.
We drop the intermediate symbols with the prompts, and move the prompts
to the previously hidden symbols, and add a prompt for the I set.
This alows one to clearly see what the generic set is about, without
having to delve into the help and hunt the list of selected symbol.
Note however that the G set implies Zicsr and Zifencei, but we have no
prompt for thos two, because in Buildroot, we assume that they are
mandatory and always present, like the I set (which they previously were
part of).
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
[yann.morin.1998@free.fr:
- drop the intermediate symbols
- move prompt to previously hidden symbols
- add symbol for I
- update defconfigs
- reword the commit log accordingly
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Support for MIPS IV was dropped in commit
dd45fe0efb ("arch/mips: remove
deprecated mips1/2/3/4 support"). However, even though it is an older
ISA than R1, it is still useful to support older MIPS-based
systems (e.g.: Cobalt Qube).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since its introduction in 7d8a59b40, the BR2_x86_geode CPU target has
pointed to GCC -march=geode which targets AMD Geode processors [0].
This arch tuning enables MMX and 3DNow! extensions in GCC but these are
not currently reflected in the selected flags by BR2_x86_geode.
This is likely due to the confusing naming and history of "Geode".
The AMD Geode can trace its origins back to the Cyrix MediaGXm [1] and
then to the NSC Geode GXm/GXLV/GX1/GX2 [2]. All of these processors have
MMX instruction support listed in their datasheets. The NSC GX2 was the
first in the series to enable 3DNow!.
When 7fed07d3a4 introduced BR2_X86_CPU_HAS_MMX, Geode was skipped
presumably because it wasn't clear that the target is AMD Geode and
because the Wikipedia documentation for Geode is incomplete [2] with
regards to supported instructions as they all support MMX.
When f6cd56b9ce introduced BR2_X86_CPU_HAS_3DNOW, Geode was skipped
presumably for similar reasons.
Note: the in-tree olpc_xo1_defconfig uses BR2_x86_geode which is fine
as this hardware uses the AMD Geode [3].
Make it more clear that the target is AMD Geode by renaming the Kconfig
menu option and add both MMX and 3DNow! flags to BR2_x86_geode.
This also means that BR2_x86_geode_mmx is no longer needed, and can be
removed. No legacy handling is needed since BR2_x86_geode_mmx has
never been part of any release.
[0]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/geode.md;;hb=HEAD
[1]: https://en.wikipedia.org/wiki/MediaGX#MediaGXm
[2]: https://en.wikipedia.org/wiki/Geode_%28processor%29
[3]: https://wiki.laptop.org/go/Hardware_specification
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Currently, there is no MMX support for modern GEODE processors in Buildroot.
Yet, some packages like ffmpeg can leverage it when the package is built.
Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commits adds support for building a RISC-V toolchain with the
vector extension, available since gcc 12.
Signed-off-by: Tianrui Wei <tianrui@tianruiwei.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_riscv_custom should only contain the basic I extension. The A
extension should be optional and selected by board configs.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 4cbf733691 ("arch/xtensa: custom
configuration requires an overlay") added a check in
arch/arch.mk.xtensa to bail out if a custom Xtensa core is selected
but not overlay file is provided. While this is indeed a perfectly
valid check to make when building an internal toolchain, with an
external toolchain it's entirely possible to build with no overlay
file: the toolchain already exists, and there's no overlay to be
applied in the context of the Buildroot build.
And indeed commit 4cbf733691 broke some
of the runtime test cases that use a custom Xtensa core configuration,
with no overlay, to test the toolchains.bootlin.com Xtensa external
toolchain. By relaxing the check to only apply to internal toolchain
configurations, we fix those test cases.
It is to be noted that this still allows a configuration where gdb gets
built for a custom core, but with no overlay, so basically that means
the fsf variant, which can lead to build or run failures that
4cbf733691 attempted to fix to begin with. This still covers the
most common cases.
Finally, it also means being able to build a kernel with no overlay, but
this is offset by the fact that the kernel may be already patched with
an overlay (as it is possible to specify a custom kernel), which is most
probably what people using a custom core would have.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/3282261966https://gitlab.com/buildroot.org/buildroot/-/jobs/3282261963
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: extend commit log with last two paragraphs]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This architecture variant is broken in GCC, causing build failures:
../../../libgcc/config/arm/unwind-arm.c:467:1: error: unrecognizable insn:
467 | }
| ^
(insn 2 4 3 2 (set (reg/v/f:SI 118 [ p ])
(reg:SI 0 r0 [ p ])) "../../../libgcc/config/arm/unwind-arm.c":456:1 -1
(nil))
during RTL pass: vregs
../../../libgcc/config/arm/unwind-arm.c:467:1: internal compiler error: in extract_insn, at recog.c:2770
Reported to the GCC developers, the feedback was "iwmmxt support is
definitely bitrotten and most likely should be removed from GCC.".
See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972#c1
So this commit simply drops support for iwmmxt, which anyway is
probably barely used nowadays: it's for old Marvell PXA cores that
implemented a special SIMD instruction set. The BR2_xscale option can
be used instead, it's just that it won't use this SIMD instruction
set.
Fixes:
http://autobuild.buildroot.net/results/8e4c4512902c34d8ec0c6f8dfff92b7a198e4b4a/
and the numerous other build failures at:
http://autobuild.buildroot.net/?reason=host-gcc-initial%&subarch=iwmmxt
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The conditions in the target CPU choice mostly use negative logic, i.e.
"depends on !<something>". This makes it more difficult to understand
exactly on which ARCH variants the CPU _is_ supported. Therefore, change
all of the conditions to positive logic.
Since there is no little-endian variant of the 32-bit PowerPC, the
conditions are:
!BR2_ARCH_IS_64 <==> BR2_powerpc
!BR2_powerpc64le <==> BR2_powerpc || BR2_powerpc64
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The Power9 CPU was released by IBM in 2016. It is a 64-bit CPU
implementing ISA v3.0. It runs in big and little endian modes, and
supports VSX and AltiVec.
Power9 is supported as of GCC 6.1 and Binutils 2.26.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout: remove 64-bit constraint]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Invalid configurations lead to build failures, such as trying to enable
ppc64le for the ppc970:
http://autobuild.buildroot.net/results/fda886768fce25ccd9b52b635ff5b13da7ba2d0c/
In order to run a ppc64le userspace a kernel that runs in this mode is
required. The only CPU supported in buildroot that can boot a ppc64le
kernel is Power8, so mark all of the other 64-bit capable CPUs as not
supporting ppc64le. For Power7, the situation is not so clear, but there
are anyway no commercially available CPUs for that architecture so it
doesn't matter much either way. Let's be safe and disable LE on that one
as well.
This drops the comment about libc, which is true but doesn't tell the
whole story.
Note that we use positive logic for the new conditions, while the rest
of the file uses negative logic. We'll fix that for the rest of the file
in a follow-up patch.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
[Arnout: don't remove 32-bit support for POWER5+]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
