2018-09-23 23:41:19 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# Architecture-specific definitions
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2018-09-12 12:22:53 +02:00
|
|
|
# Allow GCC target configuration settings to be optionally
|
|
|
|
|
# overwritten by architecture specific makefiles.
|
|
|
|
|
|
|
|
|
|
# Makefiles must use the GCC_TARGET_* variables below instead
|
|
|
|
|
# of the BR2_GCC_TARGET_* versions.
|
|
|
|
|
GCC_TARGET_ARCH := $(call qstrip,$(BR2_GCC_TARGET_ARCH))
|
|
|
|
|
GCC_TARGET_ABI := $(call qstrip,$(BR2_GCC_TARGET_ABI))
|
|
|
|
|
GCC_TARGET_NAN := $(call qstrip,$(BR2_GCC_TARGET_NAN))
|
|
|
|
|
GCC_TARGET_FP32_MODE := $(call qstrip,$(BR2_GCC_TARGET_FP32_MODE))
|
|
|
|
|
GCC_TARGET_CPU := $(call qstrip,$(BR2_GCC_TARGET_CPU))
|
|
|
|
|
GCC_TARGET_FPU := $(call qstrip,$(BR2_GCC_TARGET_FPU))
|
|
|
|
|
GCC_TARGET_FLOAT_ABI := $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
|
|
|
|
|
GCC_TARGET_MODE := $(call qstrip,$(BR2_GCC_TARGET_MODE))
|
|
|
|
|
|
arch: add support for configurable page size on ARM64
This commit is based on earlier work from Łukasz Stelmach
<l.stelmach@samsung.com> to add support for different page sizes on
ARM64.
In his initial submission, Łukasz took an approach similar to this
one, i.e make it ARM64-specific. Following the feedback on the mailing
list, his second version [1] tried to generalize the logic to
configure the page size between architectures. But the general
consensus during the review process was that there wasn't much to
generalize in the end.
So, this new iteration is back to a simpler approach:
* We have new options in Config.in.arm to configure the page
size. Only 4 KB and 64 KB are supported, because our testing in
Qemu and real hardware has not allowed to get a successful setup
for 16 KB pages. We can always re-add support for 16 KB later if
that is resolved.
* The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is
moved from the ARC-specific file to arch/arch.mk, and extended to
cover ARM64.
* The appropriate logic in uclibc.mk and linux.mk is added to tweak
the relevant configuration options.
* A test case is added in the runtime test infrastructure to test
building and booting under Qemu a 64 KB configuration, with all 3 C
libraries.
For the regular configuration of 4 KB pages, this commit makes one
functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in
the compiler flags of the wrapper.
[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
|
|
|
# Explicitly set LD's "max-page-size" instead of relying on some defaults
|
|
|
|
|
ifeq ($(BR2_ARC_PAGE_SIZE_4K)$(BR2_ARM64_PAGE_SIZE_4K),y)
|
arch: set ld's common-page-size explicitly
On some CPU architecures it's possible to use MMU pages of different
sizes, for example on ARC or ARM. And while for user-space
applications the page size is supposed to be transparent, there's
still some use of that extra information. In particular it's possible
to align data structures or code/data sections on page boundary, etc.
For these tricks to become possible tools which pack data (think of
the linker, like GNU "ld") need to be informed of the page size to
be considered.
Obviously, there're some sane defaults which are being used most of
the time, so we even think about that peculiarity, but when non-default
value needs to be used, GNU "ld" accepts 2 properties related to page
size:
-z common-page-size=XXX
-z max-page-size=YYY
And while in thery those might be different (but always "common" <= "max"),
and that might make sense if we build for some unknown platfrom,
in case of Buildroot when we build entire target's filesystem and so
know exactly the configuration we're targeting to, we may safely assume
"common-page-size"="max-page-size".
See a lengthy discussion in this thread [1].
Fixes:
http://autobuild.buildroot.net/results/c8b2f331c98453670cd982558144c4fd84674a3d/ (uclibc)
http://autobuild.buildroot.net/results/3a22f7aac38145b26c549254b819f87329e7a77e/ (glibc)
And while at it, recover use of "XX-page-size" for ARC, as with [2]
moving page size selection in the generic code we've got unexpected
override for ARC (note "=", but not "+="):
--------------------->8--------------------
ARCH_TOOLCHAIN_WRAPPER_OPTS = -matomic
--------------------->8--------------------
[1] https://lists.buildroot.org/pipermail/buildroot/2022-July/646176.html
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-15 19:17:44 +02:00
|
|
|
ARCH_TOOLCHAIN_WRAPPER_OPTS += -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
|
arch: add support for configurable page size on ARM64
This commit is based on earlier work from Łukasz Stelmach
<l.stelmach@samsung.com> to add support for different page sizes on
ARM64.
In his initial submission, Łukasz took an approach similar to this
one, i.e make it ARM64-specific. Following the feedback on the mailing
list, his second version [1] tried to generalize the logic to
configure the page size between architectures. But the general
consensus during the review process was that there wasn't much to
generalize in the end.
So, this new iteration is back to a simpler approach:
* We have new options in Config.in.arm to configure the page
size. Only 4 KB and 64 KB are supported, because our testing in
Qemu and real hardware has not allowed to get a successful setup
for 16 KB pages. We can always re-add support for 16 KB later if
that is resolved.
* The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is
moved from the ARC-specific file to arch/arch.mk, and extended to
cover ARM64.
* The appropriate logic in uclibc.mk and linux.mk is added to tweak
the relevant configuration options.
* A test case is added in the runtime test infrastructure to test
building and booting under Qemu a 64 KB configuration, with all 3 C
libraries.
For the regular configuration of 4 KB pages, this commit makes one
functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in
the compiler flags of the wrapper.
[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
|
|
|
else ifeq ($(BR2_ARC_PAGE_SIZE_8K),y)
|
arch: set ld's common-page-size explicitly
On some CPU architecures it's possible to use MMU pages of different
sizes, for example on ARC or ARM. And while for user-space
applications the page size is supposed to be transparent, there's
still some use of that extra information. In particular it's possible
to align data structures or code/data sections on page boundary, etc.
For these tricks to become possible tools which pack data (think of
the linker, like GNU "ld") need to be informed of the page size to
be considered.
Obviously, there're some sane defaults which are being used most of
the time, so we even think about that peculiarity, but when non-default
value needs to be used, GNU "ld" accepts 2 properties related to page
size:
-z common-page-size=XXX
-z max-page-size=YYY
And while in thery those might be different (but always "common" <= "max"),
and that might make sense if we build for some unknown platfrom,
in case of Buildroot when we build entire target's filesystem and so
know exactly the configuration we're targeting to, we may safely assume
"common-page-size"="max-page-size".
See a lengthy discussion in this thread [1].
Fixes:
http://autobuild.buildroot.net/results/c8b2f331c98453670cd982558144c4fd84674a3d/ (uclibc)
http://autobuild.buildroot.net/results/3a22f7aac38145b26c549254b819f87329e7a77e/ (glibc)
And while at it, recover use of "XX-page-size" for ARC, as with [2]
moving page size selection in the generic code we've got unexpected
override for ARC (note "=", but not "+="):
--------------------->8--------------------
ARCH_TOOLCHAIN_WRAPPER_OPTS = -matomic
--------------------->8--------------------
[1] https://lists.buildroot.org/pipermail/buildroot/2022-July/646176.html
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-15 19:17:44 +02:00
|
|
|
ARCH_TOOLCHAIN_WRAPPER_OPTS += -Wl,-z,max-page-size=8192 -Wl,-z,common-page-size=8192
|
2023-12-11 16:59:50 +01:00
|
|
|
else ifeq ($(BR2_ARC_PAGE_SIZE_16K)$(BR2_ARM64_PAGE_SIZE_16K),y)
|
arch: set ld's common-page-size explicitly
On some CPU architecures it's possible to use MMU pages of different
sizes, for example on ARC or ARM. And while for user-space
applications the page size is supposed to be transparent, there's
still some use of that extra information. In particular it's possible
to align data structures or code/data sections on page boundary, etc.
For these tricks to become possible tools which pack data (think of
the linker, like GNU "ld") need to be informed of the page size to
be considered.
Obviously, there're some sane defaults which are being used most of
the time, so we even think about that peculiarity, but when non-default
value needs to be used, GNU "ld" accepts 2 properties related to page
size:
-z common-page-size=XXX
-z max-page-size=YYY
And while in thery those might be different (but always "common" <= "max"),
and that might make sense if we build for some unknown platfrom,
in case of Buildroot when we build entire target's filesystem and so
know exactly the configuration we're targeting to, we may safely assume
"common-page-size"="max-page-size".
See a lengthy discussion in this thread [1].
Fixes:
http://autobuild.buildroot.net/results/c8b2f331c98453670cd982558144c4fd84674a3d/ (uclibc)
http://autobuild.buildroot.net/results/3a22f7aac38145b26c549254b819f87329e7a77e/ (glibc)
And while at it, recover use of "XX-page-size" for ARC, as with [2]
moving page size selection in the generic code we've got unexpected
override for ARC (note "=", but not "+="):
--------------------->8--------------------
ARCH_TOOLCHAIN_WRAPPER_OPTS = -matomic
--------------------->8--------------------
[1] https://lists.buildroot.org/pipermail/buildroot/2022-July/646176.html
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-15 19:17:44 +02:00
|
|
|
ARCH_TOOLCHAIN_WRAPPER_OPTS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384
|
arch: add support for configurable page size on ARM64
This commit is based on earlier work from Łukasz Stelmach
<l.stelmach@samsung.com> to add support for different page sizes on
ARM64.
In his initial submission, Łukasz took an approach similar to this
one, i.e make it ARM64-specific. Following the feedback on the mailing
list, his second version [1] tried to generalize the logic to
configure the page size between architectures. But the general
consensus during the review process was that there wasn't much to
generalize in the end.
So, this new iteration is back to a simpler approach:
* We have new options in Config.in.arm to configure the page
size. Only 4 KB and 64 KB are supported, because our testing in
Qemu and real hardware has not allowed to get a successful setup
for 16 KB pages. We can always re-add support for 16 KB later if
that is resolved.
* The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is
moved from the ARC-specific file to arch/arch.mk, and extended to
cover ARM64.
* The appropriate logic in uclibc.mk and linux.mk is added to tweak
the relevant configuration options.
* A test case is added in the runtime test infrastructure to test
building and booting under Qemu a 64 KB configuration, with all 3 C
libraries.
For the regular configuration of 4 KB pages, this commit makes one
functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in
the compiler flags of the wrapper.
[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
|
|
|
else ifeq ($(BR2_ARM64_PAGE_SIZE_64K),y)
|
arch: set ld's common-page-size explicitly
On some CPU architecures it's possible to use MMU pages of different
sizes, for example on ARC or ARM. And while for user-space
applications the page size is supposed to be transparent, there's
still some use of that extra information. In particular it's possible
to align data structures or code/data sections on page boundary, etc.
For these tricks to become possible tools which pack data (think of
the linker, like GNU "ld") need to be informed of the page size to
be considered.
Obviously, there're some sane defaults which are being used most of
the time, so we even think about that peculiarity, but when non-default
value needs to be used, GNU "ld" accepts 2 properties related to page
size:
-z common-page-size=XXX
-z max-page-size=YYY
And while in thery those might be different (but always "common" <= "max"),
and that might make sense if we build for some unknown platfrom,
in case of Buildroot when we build entire target's filesystem and so
know exactly the configuration we're targeting to, we may safely assume
"common-page-size"="max-page-size".
See a lengthy discussion in this thread [1].
Fixes:
http://autobuild.buildroot.net/results/c8b2f331c98453670cd982558144c4fd84674a3d/ (uclibc)
http://autobuild.buildroot.net/results/3a22f7aac38145b26c549254b819f87329e7a77e/ (glibc)
And while at it, recover use of "XX-page-size" for ARC, as with [2]
moving page size selection in the generic code we've got unexpected
override for ARC (note "=", but not "+="):
--------------------->8--------------------
ARCH_TOOLCHAIN_WRAPPER_OPTS = -matomic
--------------------->8--------------------
[1] https://lists.buildroot.org/pipermail/buildroot/2022-July/646176.html
[2] https://git.buildroot.net/buildroot/commit/?id=dcb74db89e74e512e36b32cea6f574a1a1ca84c4
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-15 19:17:44 +02:00
|
|
|
ARCH_TOOLCHAIN_WRAPPER_OPTS += -Wl,-z,max-page-size=65536 -Wl,-z,common-page-size=65536
|
arch: add support for configurable page size on ARM64
This commit is based on earlier work from Łukasz Stelmach
<l.stelmach@samsung.com> to add support for different page sizes on
ARM64.
In his initial submission, Łukasz took an approach similar to this
one, i.e make it ARM64-specific. Following the feedback on the mailing
list, his second version [1] tried to generalize the logic to
configure the page size between architectures. But the general
consensus during the review process was that there wasn't much to
generalize in the end.
So, this new iteration is back to a simpler approach:
* We have new options in Config.in.arm to configure the page
size. Only 4 KB and 64 KB are supported, because our testing in
Qemu and real hardware has not allowed to get a successful setup
for 16 KB pages. We can always re-add support for 16 KB later if
that is resolved.
* The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is
moved from the ARC-specific file to arch/arch.mk, and extended to
cover ARM64.
* The appropriate logic in uclibc.mk and linux.mk is added to tweak
the relevant configuration options.
* A test case is added in the runtime test infrastructure to test
building and booting under Qemu a 64 KB configuration, with all 3 C
libraries.
For the regular configuration of 4 KB pages, this commit makes one
functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in
the compiler flags of the wrapper.
[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
|
|
|
endif
|
|
|
|
|
|
2018-09-12 12:22:53 +02:00
|
|
|
# Include any architecture specific makefiles.
|
|
|
|
|
-include $(sort $(wildcard arch/arch.mk.*))
|
