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>
For the HS48 processor, BR currently builds with -mcpu=hs4x_rel31 which
generates suboptimal code as it inhibits delay slot and back-back ST and so on.
Enable a new variant to build with -mcpu=hs4x for normal codegen.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
[yann.morin.1998@free.fr:
- simplify dependencies on MMU page size
- wrap long lines
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier)
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch introduces a recently released significant update to ARC HS
family: ARC HS48.
One of the major ARC HS48 features is dual-issue pipeline which requires a
little bit modified instruction scheduling compared to single-issue cores
(HS38), thus new "-mcpu/--with-cpu=hs4x".
Also to address some peculiarities of early designs based on HS48 we
introduced yet another "-mcpu/--with-cpu=hs4x_rel31" which we're going to use
as well on some of our development boards.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
[Peter: fixup check-package warnings]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We used to build everything for pretty much baseline ARC HS capable
of runnig Linux kernel, which was ARC HS38/48 with MMU and caches.
But there's a fully featured ARC HS with additional support for
- Dual & quad integer multiply and MAC operations
- Double-precision floating-point unit
It corresponds to the following ARC HS templates in ARChitect: hs38_slc_full.
In fact existing HSDK board uses exactly this configuration in its SoC
and this is recommended configuration for Linux use-cases.
To make life simpler we have corresponding "-mcpu" and "--with-cpu"
options in ARC GCC port so we're going to use it and get binaries
built accordingly optimized.
And while at it added help message so users may better understand
what they are dealing with.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
It is too sad when an editor picks up the wrong syntax...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
... to follow the convention: type, default, depends on, select, help.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Whitespaces were searched using the following regex:
[ ]{1,}\t
and then manually removed in most of the cases. For
xserver_xorg-server.mk, tabs before backslashes were removed.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This config option corresponds to the string returned by readelf for
the "Machine" field of the ELF header. It will be used to check if the
architecture of binaries built by Buildroot match the target
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can
remove it from arch/Config.in*, as well as from the documentation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Modern ARC cores (those sporting MMU of version 3 and 4) allow selection
of different page sizes (4, 8 or 16 kB) during ASIC design creation.
And it's important to build a toolchain with page size setting that matches
hardware.
Otherwise user-space applications will fail on execution due to
unexpected data layout/alignment etc.
[Thomas: slightly improve help text, fix indentation of help text.]
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Synopsys has recently announced its new ARC HS38 core that is capable of
running Linux -
http://www.synopsys.com/dw/ipdir.php?ds=arc-hs38-processor
ARC HS38 is based on ARCv2 ISA and requires special settings of gcc and
libc.
Also in case of HS38 atomic extensions (LLOCK/SCOND instructions) are
built-in by default, so enabling atomic extensions in Buildroot as well.
This commit adds support of the core in buildroot.
[Peter: string type, so must be in quotes as noted by Yann]
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <anton.kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This separation allows to specify unique options and features for each
CPU.
For example ARC 770D has LLOCK/SCOND instructions built-in by default.
Also this new scheme simplifies selection of proper configuration for
users - preconfigured options now match templates for ARC CPUs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Due to a kconfig limitation, we can't select a no-prompt symbol that
gets its dependencies by being conditionally re-defined in one or more
if-blocks, like we currently do for BR2_ARCH_HAS_ATOMICS.
As a workaround to this issue, we just redefine that symbol in the arc
if-block, like we do for all other architectures, except that in the arc
case, the default value is conditional.
Reported-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
[yann.morin.1998@free.fr: indepently re-done a patch similar to the one
Thomas made on his own]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The fact that atomic operations are available is not really a
specificity of the toolchain, but rather of the architecture.
So, add a new option that architectures that have atomic operations
can select. This in turn selects the current toolchain atomic option,
until all packages have been converted, at which point the old
toolchain option can be removed.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GCC has several builtin functions that implement atomic operations. Those
functions are architecture specific and may not be implemented by the
specific toolchain. In case of GCC for ARC those functions rely on
LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't
support those instructions but software tries to use them, then application
will be aborted with Illegal instruction exception. To avoid confusion user
should first specify that their CPU supports atomic extension, which will
allow selection of packages that use builtin atomic functions.
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
All packages use github now.
This reverts commit 1445b7fd2e.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As ARC support is not yet in all upstream packages, a different location is
required to download the packages from. This adds an option to specify a
site for ARC-specific versions of packages such as binutils, gcc.
When ARC support has been upstreamed for all packages, this option can be
removed again.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Synopsys' DesignWare ARC Processor Cores are a family of 32-bit CPUs that
can be used from deeply embedded to high performance host applications.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
