2012-11-15 04:53:52 +01:00
|
|
|
choice
|
|
|
|
|
prompt "Target Architecture Variant"
|
|
|
|
|
default BR2_xtensa_fsf
|
2018-04-01 07:08:34 +02:00
|
|
|
depends on BR2_xtensa
|
2017-07-09 14:21:55 +02:00
|
|
|
|
2012-11-20 09:31:36 +01:00
|
|
|
config BR2_XTENSA_CUSTOM
|
2012-11-15 04:53:52 +01:00
|
|
|
bool "Custom Xtensa processor configuration"
|
2018-04-01 07:08:34 +02:00
|
|
|
select BR2_ARCH_HAS_MMU_OPTIONAL
|
2017-07-09 14:21:55 +02:00
|
|
|
|
2012-11-15 04:53:52 +01:00
|
|
|
config BR2_xtensa_fsf
|
|
|
|
|
bool "fsf - Default configuration"
|
2018-04-01 07:08:34 +02:00
|
|
|
select BR2_ARCH_HAS_MMU_MANDATORY
|
2017-07-09 14:21:55 +02:00
|
|
|
|
2012-11-15 04:53:52 +01:00
|
|
|
endchoice
|
|
|
|
|
|
arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
- the core name
- the directory containing the overlay tarball
However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.
This has two main drawbacks:
- the overlay file must be named after the core,
- the tarball can not be compressed.
Furthermore, it also makes it extremely complex to implement a download
of that tarball.
So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.
Update the qemu-xtensa defconfig accordingly.
Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 14:21:56 +02:00
|
|
|
config BR2_XTENSA_OVERLAY_FILE
|
|
|
|
|
string "Overlay file for custom configuration"
|
2012-11-20 09:31:36 +01:00
|
|
|
depends on BR2_XTENSA_CUSTOM
|
2012-11-15 04:53:52 +01:00
|
|
|
help
|
arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
- the core name
- the directory containing the overlay tarball
However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.
This has two main drawbacks:
- the overlay file must be named after the core,
- the tarball can not be compressed.
Furthermore, it also makes it extremely complex to implement a download
of that tarball.
So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.
Update the qemu-xtensa defconfig accordingly.
Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 14:21:56 +02:00
|
|
|
Enter the path to the overlay tarball for a custom processor
|
|
|
|
|
configuration.
|
|
|
|
|
|
2018-04-01 07:08:40 +02:00
|
|
|
These overlay files are tar packages with updated
|
|
|
|
|
configuration files for various toolchain packages and Xtensa
|
|
|
|
|
processor configurations. They are provided by the processor
|
|
|
|
|
vendor or directly from Tensilica.
|
2012-11-15 04:53:52 +01:00
|
|
|
|
2018-04-01 07:08:40 +02:00
|
|
|
The path can be either absolute, or relative to the top
|
|
|
|
|
directory of buildroot.
|
arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
- the core name
- the directory containing the overlay tarball
However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.
This has two main drawbacks:
- the overlay file must be named after the core,
- the tarball can not be compressed.
Furthermore, it also makes it extremely complex to implement a download
of that tarball.
So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.
Update the qemu-xtensa defconfig accordingly.
Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 14:21:56 +02:00
|
|
|
|
2015-05-05 18:18:24 +02:00
|
|
|
choice
|
|
|
|
|
prompt "Target Architecture Endianness"
|
|
|
|
|
default BR2_XTENSA_LITTLE_ENDIAN
|
2018-04-01 07:08:34 +02:00
|
|
|
depends on BR2_XTENSA_CUSTOM
|
2015-05-05 18:18:24 +02:00
|
|
|
|
|
|
|
|
config BR2_XTENSA_LITTLE_ENDIAN
|
|
|
|
|
bool "Little endian"
|
|
|
|
|
|
|
|
|
|
config BR2_XTENSA_BIG_ENDIAN
|
|
|
|
|
bool "Big endian"
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config BR2_ENDIAN
|
|
|
|
|
default "LITTLE" if BR2_XTENSA_LITTLE_ENDIAN
|
|
|
|
|
default "BIG" if BR2_xtensa_fsf || BR2_XTENSA_BIG_ENDIAN
|
|
|
|
|
|
2012-11-15 04:53:51 +01:00
|
|
|
config BR2_ARCH
|
|
|
|
|
default "xtensa" if BR2_xtensa
|
2017-03-19 14:07:51 +01:00
|
|
|
|
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH
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>
2022-01-15 21:03:00 +01:00
|
|
|
config BR2_NORMALIZED_ARCH
|
2022-01-15 21:02:59 +01:00
|
|
|
default "xtensa"
|
|
|
|
|
|
2017-03-19 14:07:51 +01:00
|
|
|
config BR2_READELF_ARCH_NAME
|
|
|
|
|
default "Tensilica Xtensa Processor"
|
2019-05-03 15:10:17 +02:00
|
|
|
|
|
|
|
|
# vim: ft=kconfig
|
|
|
|
|
# -*- mode:kconfig; -*-
|
