iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5adedd4224
linux/arch/arm/Makefile

329 lines
11 KiB
Makefile
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
#
# arch/arm/Makefile
#
kbuild: change kbuild to not rely on incorrect GNU make behavior The kbuild system takes advantage of an incorrect behavior in GNU make. Once this behavior is fixed, all files in the kernel rebuild every time, even if nothing has changed. This patch ensures kbuild works with both the incorrect and correct behaviors of GNU make. For more details on the incorrect behavior, see: http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html Changes in this patch: - Keep all targets that are to be marked .PHONY in a variable, PHONY. - Add .PHONY: $(PHONY) to mark them properly. - Remove any $(PHONY) files from the $? list when determining whether targets are up-to-date or not. Signed-off-by: Paul Smith <psmith@gnu.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-03-06 01:14:10 +03:00
# This file is included by the global makefile so that you can add your own
# architecture-specific flags and dependencies.
#
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# This file is subject to the terms and conditions of the GNU General Public
# License. See the file "COPYING" in the main directory of this archive
# for more details.
#
# Copyright (C) 1995-2001 by Russell King
ARM: 9038/1: Link with '-z norelro' When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with LD=ld.lld, the following error occurs: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage ld.lld: error: section: .exit.data is not contiguous with other relro sections LLD defaults to '-z relro', which is unneeded for the kernel because program headers are not used nor is there any position independent code generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to avoid this error. Link: https://github.com/ClangBuiltLinux/linux/issues/1189 Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-08 03:34:16 +03:00
LDFLAGS_vmlinux := --no-undefined -X --pic-veneer -z norelro
Add core support for ARMv6/v7 big-endian Starting with ARMv6, the CPUs support the BE-8 variant of big-endian (byte-invariant). This patch adds the core support: - setting of the BE-8 mode via the CPSR.E register for both kernel and user threads - big-endian page table walking - REV used to rotate instructions read from memory during fault processing as they are still little-endian format - Kconfig and Makefile support for BE-8. The --be8 option must be passed to the final linking stage to convert the instructions to little-endian Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-05-30 17:00:18 +04:00
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux += --be8
arm/kbuild: replace {C, LD}FLAGS_MODULE with KBUILD_{C, LD}FLAGS_MODULE As kbuild document & commit 6588169d51 says: KBUILD_{C,LD}FLAGS_MODULE are used to add arch-specific options for $(CC) and $(LD). From commandline, {C,LD}FLAGS_MODULE shall be used. Doesn't have any functional change, but just follow kbuild rules. Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> CC: Russell King <linux@armlinux.org.uk> CC: linux-arm-kernel@lists.infradead.org Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-09 10:11:45 +03:00
KBUILD_LDFLAGS_MODULE += --be8
Add core support for ARMv6/v7 big-endian Starting with ARMv6, the CPUs support the BE-8 variant of big-endian (byte-invariant). This patch adds the core support: - setting of the BE-8 mode via the CPSR.E register for both kernel and user threads - big-endian page table walking - REV used to rotate instructions read from memory during fault processing as they are still little-endian format - Kconfig and Makefile support for BE-8. The --be8 option must be passed to the final linking stage to convert the instructions to little-endian Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-05-30 17:00:18 +04:00
endif
arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0 Albin Tonnerre <albin.tonnerre@free-electrons.com> reported: Bash 4 filters out variables which contain a dot in them. This happends to be the case of CPPFLAGS_vmlinux.lds. This is rather unfortunate, as it now causes build failures when using SHELL=/bin/bash to compile, or when bash happens to be used by make (eg when it's /bin/sh) Remove the common definition of CPPFLAGS_vmlinux.lds by pushing relevant stuff to either Makefile.build or the arch specific kernel/Makefile where we build the linker script. This is also nice cleanup as we move the information out where it is used. Notes for the different architectures touched: arm - we use an already exported symbol cris - we use a config symbol aleady available [Not build tested] mips - the jiffies complexity has moved to vmlinux.lds.S where we need it. Added a few variables to CPPFLAGS - they are only used by the linker script. [Not build tested] powerpc - removed assignment that is not needed [not build tested] sparc - simplified it using $(BITS) um - introduced a few new exported variables to deal with this xtensa - added options to CPP invocation [not build tested] Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2009-09-20 14:28:22 +04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
GZFLAGS :=-9
kbuild: enable 'make CFLAGS=...' to add additional options to CC The variable CFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of CFLAGS with KBUILD_CFLAGS all over the tree and enabling one to use: make CFLAGS=... to specify additional gcc commandline options. One usecase is when trying to find gcc bugs but other use cases has been requested too. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k Test was simple to do a defconfig build, apply the patch and check that nothing got rebuild. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-15 00:21:35 +04:00
#KBUILD_CFLAGS +=-pipe
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ARM: 6328/1: Build with -fno-dwarf2-cfi-asm Commit d0679c7 restricted this workaround to powerpc only, but it turns out that ARM needs it as well. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=16310 . Reported-and-Tested-by: Robert Nelson <robertcnelson@gmail.com> Acked-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-15 02:56:21 +04:00
# Never generate .eh_frame
KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
ARM: 9226/1: disable FDPIC ABI When building with an arm-*-uclinuxfdpiceabi toolchain, the FDPIC ABI is enabled by default but should not be used to build the kernel. Therefore, pass -mno-fdpic if supported by the compiler. Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-08-13 00:24:25 +03:00
# Disable FDPIC ABI
KBUILD_CFLAGS += $(call cc-option,-mno-fdpic)
ARM: default to multi_v7_defconfig versatile_defconfig has not been a reasonable default for a very long time, there is very little work happening on this platform and it's based on an old ARM926 CPU core. This changes the default to multi_v7_defconfig, which is much more relevant to anyone doing a build test on ARM, as it covers a wide range of platforms. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2015-12-19 01:44:23 +03:00
# This should work on most of the modern platforms
KBUILD_DEFCONFIG := multi_v7_defconfig
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
trivial: fix typos "man[ae]g?ment" -> "management" Signed-off-by: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-07-23 10:31:31 +04:00
# defines filename extension depending memory management type.
[ARM] nommu: add nommu specific Kconfig and MMUEXT variable in Makefile This patch adds Kconfig-nommu for noMMU specific configurations and MMUEXT variable into Makefile. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-03-27 18:14:19 +04:00
ifeq ($(CONFIG_MMU),)
MMUEXT := -nommu
ARM: 7592/1: nommu: prevent generation of kernel unaligned memory accesses Recent ARMv7 toolchains assume that unaligned memory accesses will not fault and will instead be handled by the processor. For the nommu case (without an MPU), memory will be treated as strongly-ordered and therefore unaligned accesses may fault regardless of the SCTLR.A setting. This patch passes -mno-unaligned-access to GCC when compiling for nommu targets, preventing the generation of unaligned memory access in the kernel. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Jonathan Austin <jonathan.austin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-04 15:56:44 +04:00
KBUILD_CFLAGS += $(call cc-option,-mno-unaligned-access)
[ARM] nommu: add nommu specific Kconfig and MMUEXT variable in Makefile This patch adds Kconfig-nommu for noMMU specific configurations and MMUEXT variable into Makefile. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-03-27 18:14:19 +04:00
endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ifeq ($(CONFIG_FRAME_POINTER),y)
ARM: 8900/1: UNWINDER_FRAME_POINTER implementation for Clang The stackframe setup when compiled with clang is different. Since the stack unwinder expects the gcc stackframe setup it fails to print backtraces. This patch adds support for the clang stackframe setup. Link: https://github.com/ClangBuiltLinux/linux/issues/35 Cc: clang-built-linux@googlegroups.com Suggested-by: Tri Vo <trong@google.com> Signed-off-by: Nathan Huckleberry <nhuck@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-22 23:26:53 +03:00
KBUILD_CFLAGS +=-fno-omit-frame-pointer
ifeq ($(CONFIG_CC_IS_GCC),y)
KBUILD_CFLAGS += -mapcs -mno-sched-prolog
endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
endif
ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP The variable CPPFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the tree and enabling one to use: make CPPFLAGS=... to specify additional CPP commandline options. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-16 00:17:25 +04:00
KBUILD_CPPFLAGS += -mbig-endian
ARM: 8716/1: pass endianness info to sparse ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined or not to correctly select or define endian-specific macros, structures or pieces of code. These macros are predefined by the compiler but sparse knows nothing about them and thus may pre-process files differently from what gcc would. Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse, depending on the endianness of the kernel, like defined by GCC. Note: In most case it won't change anything since most ARMs use little-endian (but an allyesconfig would use big-endian!). To: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-31 20:19:15 +03:00
CHECKFLAGS += -D__ARMEB__
kbuild: rename LDFLAGS to KBUILD_LDFLAGS Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS. Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS. Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS. For some reason, LDFLAGS was not renamed. Using a well-known variable like LDFLAGS may result in accidental override of the variable. Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention. I did not touch Makefiles under tools/ since the tools build system is a different world. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
2018-08-24 02:20:39 +03:00
KBUILD_LDFLAGS += -EB
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
else
kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP The variable CPPFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the tree and enabling one to use: make CPPFLAGS=... to specify additional CPP commandline options. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-16 00:17:25 +04:00
KBUILD_CPPFLAGS += -mlittle-endian
ARM: 8716/1: pass endianness info to sparse ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined or not to correctly select or define endian-specific macros, structures or pieces of code. These macros are predefined by the compiler but sparse knows nothing about them and thus may pre-process files differently from what gcc would. Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse, depending on the endianness of the kernel, like defined by GCC. Note: In most case it won't change anything since most ARMs use little-endian (but an allyesconfig would use big-endian!). To: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-31 20:19:15 +03:00
CHECKFLAGS += -D__ARMEL__
kbuild: rename LDFLAGS to KBUILD_LDFLAGS Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS. Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS. Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS. For some reason, LDFLAGS was not renamed. Using a well-known variable like LDFLAGS may result in accidental override of the variable. Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention. I did not touch Makefiles under tools/ since the tools build system is a different world. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
2018-08-24 02:20:39 +03:00
KBUILD_LDFLAGS += -EL
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
endif
ARM: 8429/1: disable GCC SRA optimization While working on the 32-bit ARM port of UEFI, I noticed a strange corruption in the kernel log. The following snprintf() statement (in drivers/firmware/efi/efi.c:efi_md_typeattr_format()) snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]", was producing the following output in the log: | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | | | | |UC] |RUN| | | | | | | |UC] As it turns out, this is caused by incorrect code being emitted for the string() function in lib/vsprintf.c. The following code if (!(spec.flags & LEFT)) { while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } } for (i = 0; i < len; ++i) { if (buf < end) *buf = *s; ++buf; ++s; } while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } when called with len == 0, triggers an issue in the GCC SRA optimization pass (Scalar Replacement of Aggregates), which handles promotion of signed struct members incorrectly. This is a known but as yet unresolved issue. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular case, it is causing the second while loop to be executed erroneously a single time, causing the additional space characters to be printed. So disable the optimization by passing -fno-ipa-sra. Cc: <stable@vger.kernel.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-09-03 15:24:40 +03:00
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
# char struct members incorrectly. So disable it.
# (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932)
#
KBUILD_CFLAGS += $(call cc-option,-fno-ipa-sra)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# This selects which instruction set is used.
# Note that GCC does not numerically define an architecture version
# macro, but instead defines a whole series of macros which makes
# testing for a specific architecture or later rather impossible.
ARM: 9156/1: drop cc-option fallbacks for architecture selection Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works. The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'. The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those. This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Reported-by: Antonio Terceiro <antonio.terceiro@linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Cc: Matthias Klose <doko@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-06 21:42:29 +03:00
arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m
arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a
arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 -march=armv6
[ARM] armv7: add Makefile and Kconfig entries This patch adds the necessary lines to the Makefile and Kconfig files for enabling the compilation of the ARMv7 CPU support. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-09 01:45:26 +04:00
# Only override the compiler option if ARMv6. The ARMv6K extensions are
# always available in ARMv7
ifeq ($(CONFIG_CPU_32v6),y)
ARM: 9156/1: drop cc-option fallbacks for architecture selection Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works. The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'. The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those. This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Reported-by: Antonio Terceiro <antonio.terceiro@linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Cc: Matthias Klose <doko@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-06 21:42:29 +03:00
arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 -march=armv6k
[ARM] armv7: add Makefile and Kconfig entries This patch adds the necessary lines to the Makefile and Kconfig files for enabling the compilation of the ARMv7 CPU support. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-09 01:45:26 +04:00
endif
ARM: 9156/1: drop cc-option fallbacks for architecture selection Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works. The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'. The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those. This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Reported-by: Antonio Terceiro <antonio.terceiro@linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Cc: Matthias Klose <doko@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-06 21:42:29 +03:00
arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 -march=armv5te
ARM: 7777/1: Avoid extra calls to the C compiler Starting up the C compiler can be a slow operation on some systems. Though these calls don't individually take a lot of time, they add up. Rearrange the ARM Makefile a bit to avoid extra calls to the compiler when they can be easily avoided. When running with the Chrome OS ARM cross compiler "armv7a-cros-linux-gnueabi-", this shaved .55 seconds (from 5.31 seconds to 4.76 seconds) off an incremental build of the kernel: time make -j32 ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi- Thanks to Mike Frysinger for the clean trick to make this work. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-27 07:32:06 +04:00
arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4
ARM: 8801/1: makefile: use ARMv3M mode for RiscPC The purpose of CONFIG_CPU_32v3 is to avoid ldrh/strh on the RiscPC, which is pretty much an ARMv4 device, except its bus will choke on the half-words. The way to make the C compiler not output ldrh/strh is with -march=armv3, which doesn't support them in the ISA. However, this prevents certain cryptography code from working that uses instructions like umull. Fortunately there's also -march=armv3m that does support those, making it possible to continue assembling optimized cryptography routines for our beloved RiscPC. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-10-02 17:01:24 +03:00
arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3m
ARM: 7777/1: Avoid extra calls to the C compiler Starting up the C compiler can be a slow operation on some systems. Though these calls don't individually take a lot of time, they add up. Rearrange the ARM Makefile a bit to avoid extra calls to the compiler when they can be easily avoided. When running with the Chrome OS ARM cross compiler "armv7a-cros-linux-gnueabi-", this shaved .55 seconds (from 5.31 seconds to 4.76 seconds) off an incremental build of the kernel: time make -j32 ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi- Thanks to Mike Frysinger for the clean trick to make this work. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-27 07:32:06 +04:00
# Evaluate arch cc-option calls now
arch-y := $(arch-y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# This selects how we optimise for the processor.
ARM: 7777/1: Avoid extra calls to the C compiler Starting up the C compiler can be a slow operation on some systems. Though these calls don't individually take a lot of time, they add up. Rearrange the ARM Makefile a bit to avoid extra calls to the compiler when they can be easily avoided. When running with the Chrome OS ARM cross compiler "armv7a-cros-linux-gnueabi-", this shaved .55 seconds (from 5.31 seconds to 4.76 seconds) off an incremental build of the kernel: time make -j32 ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi- Thanks to Mike Frysinger for the clean trick to make this work. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-27 07:32:06 +04:00
tune-$(CONFIG_CPU_ARM7TDMI) =-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM740T) =-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM9TDMI) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM940T) =-mtune=arm9tdmi
ARM: 9156/1: drop cc-option fallbacks for architecture selection Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works. The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'. The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those. This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Reported-by: Antonio Terceiro <antonio.terceiro@linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Cc: Matthias Klose <doko@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-06 21:42:29 +03:00
tune-$(CONFIG_CPU_ARM946E) =-mtune=arm9e
ARM: 7777/1: Avoid extra calls to the C compiler Starting up the C compiler can be a slow operation on some systems. Though these calls don't individually take a lot of time, they add up. Rearrange the ARM Makefile a bit to avoid extra calls to the compiler when they can be easily avoided. When running with the Chrome OS ARM cross compiler "armv7a-cros-linux-gnueabi-", this shaved .55 seconds (from 5.31 seconds to 4.76 seconds) off an incremental build of the kernel: time make -j32 ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi- Thanks to Mike Frysinger for the clean trick to make this work. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-27 07:32:06 +04:00
tune-$(CONFIG_CPU_ARM920T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM926T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_FA526) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_SA110) =-mtune=strongarm110
tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100
ARM: 9156/1: drop cc-option fallbacks for architecture selection Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works. The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'. The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those. This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Reported-by: Antonio Terceiro <antonio.terceiro@linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Cc: Matthias Klose <doko@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-06 21:42:29 +03:00
tune-$(CONFIG_CPU_XSCALE) =-mtune=xscale
tune-$(CONFIG_CPU_XSC3) =-mtune=xscale
tune-$(CONFIG_CPU_FEROCEON) =-mtune=xscale
tune-$(CONFIG_CPU_V6) =-mtune=arm1136j-s
tune-$(CONFIG_CPU_V6K) =-mtune=arm1136j-s
ARM: 7777/1: Avoid extra calls to the C compiler Starting up the C compiler can be a slow operation on some systems. Though these calls don't individually take a lot of time, they add up. Rearrange the ARM Makefile a bit to avoid extra calls to the compiler when they can be easily avoided. When running with the Chrome OS ARM cross compiler "armv7a-cros-linux-gnueabi-", this shaved .55 seconds (from 5.31 seconds to 4.76 seconds) off an incremental build of the kernel: time make -j32 ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi- Thanks to Mike Frysinger for the clean trick to make this work. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-06-27 07:32:06 +04:00
# Evaluate tune cc-option calls now
tune-y := $(tune-y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
[ARM] 3107/3: ARM EABI: last bits to configure it Patch from Nicolas Pitre This adds the configuration option, and disables any FPA floating point emulators which are not EABI compatible. It also disables Acorn RISC OS/Arthur binary support when CONFIG_EABI=y since it is incompatible with an EABI kernel. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14 19:33:50 +03:00
ifeq ($(CONFIG_AEABI),y)
ARM: 8766/1: drop no-thumb-interwork in EABI mode According to GCC documentation -m(no-)thumb-interwork is meaningless in AAPCS configurations. Also clang does not support the flag: clang-5.0: error: unknown argument: '-mno-thumb-interwork' Just drop -mno-thumb-interwork in AEABI configuration. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-05-09 00:49:49 +03:00
CFLAGS_ABI :=-mabi=aapcs-linux -mfpu=vfp
[ARM] 3107/3: ARM EABI: last bits to configure it Patch from Nicolas Pitre This adds the configuration option, and disables any FPA floating point emulators which are not EABI compatible. It also disables Acorn RISC OS/Arthur binary support when CONFIG_EABI=y since it is incompatible with an EABI kernel. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14 19:33:50 +03:00
else
[PATCH] ARM: 2778/1: Add -mno-thumb-interwork to CFLAGS_ABI Patch from Catalin Marinas The new EABI gcc adds -mthumb-interwork by default, even if -mabi=apcs-gnu is passed. This causes a warning for every compiled C file when -march=armv4 is used. The patch adds -mno-thumb-interwork if the option is supported. This is also useful since we don't need any ARM/Thumb interworking in the kernel Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-30 20:04:14 +04:00
CFLAGS_ABI :=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) $(call cc-option,-mno-thumb-interwork,)
[ARM] 3107/3: ARM EABI: last bits to configure it Patch from Nicolas Pitre This adds the configuration option, and disables any FPA floating point emulators which are not EABI compatible. It also disables Acorn RISC OS/Arthur binary support when CONFIG_EABI=y since it is incompatible with an EABI kernel. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14 19:33:50 +03:00
endif
[ARM] 5386/2: unwind: Add Makefile and Kconfig entries for ARM stack unwinding This patch also makes the frame pointer default to y only if !ARM_UNWIND. LOCKDEP no longer selects FRAME_POINTER if ARM_UNWIND is enabled. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-12 15:56:34 +03:00
ifeq ($(CONFIG_ARM_UNWIND),y)
CFLAGS_ABI +=-funwind-tables
endif
ARM: 8905/1: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build with clang: arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable': softirq.c:(.text+0x504): undefined reference to `mcount' arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip': softirq.c:(.text+0x58c): undefined reference to `mcount' arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq': softirq.c:(.text+0x6c8): undefined reference to `mcount' arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter': softirq.c:(.text+0x75c): undefined reference to `mcount' arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit': softirq.c:(.text+0x840): undefined reference to `mcount' arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow clang can emit a working mcount symbol, __gnu_mcount_nc, when '-meabi gnu' is passed to it. Until r369147 in LLVM, this was broken and caused the kernel not to boot with '-pg' because the calling convention was not correct. Always build with '-meabi gnu' when using clang but ensure that '-pg' (which is added with CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER) cannot be added with it unless this is fixed (which means using clang 10.0.0 and newer). Link: https://github.com/ClangBuiltLinux/linux/issues/35 Link: https://bugs.llvm.org/show_bug.cgi?id=33845 Link: https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60 Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-09-04 03:13:15 +03:00
ifeq ($(CONFIG_CC_IS_CLANG),y)
CFLAGS_ABI += -meabi gnu
endif
ARM: smp: Store current pointer in TPIDRURO register if available Now that the user space TLS register is assigned on every return to user space, we can use it to keep the 'current' pointer while running in the kernel. This removes the need to access it via thread_info, which is located at the base of the stack, but will be moved out of there in a subsequent patch. Use the __builtin_thread_pointer() helper when available - this will help GCC understand that reloading the value within the same function is not necessary, even when using the per-task stack protector (which also generates accesses via the TLS register). For example, the generated code below loads TPIDRURO only once, and uses it to access both the stack canary and the preempt_count fields. <do_one_initcall>: e92d 41f0 stmdb sp!, {r4, r5, r6, r7, r8, lr} ee1d 4f70 mrc 15, 0, r4, cr13, cr0, {3} 4606 mov r6, r0 b094 sub sp, #80 ; 0x50 f8d4 34e8 ldr.w r3, [r4, #1256] ; 0x4e8 <- stack canary 9313 str r3, [sp, #76] ; 0x4c f8d4 8004 ldr.w r8, [r4, #4] <- preempt count Co-developed-by: Keith Packard <keithpac@amazon.com> Signed-off-by: Keith Packard <keithpac@amazon.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
2021-09-18 11:44:37 +03:00
ifeq ($(CONFIG_CURRENT_POINTER_IN_TPIDRURO),y)
CFLAGS_ABI += -mtp=cp15
endif
ARM: 8723/2: always assume the "unified" syntax for assembly code The GNU assembler has implemented the "unified syntax" parsing since 2005. This "unified" syntax is required when the kernel is built in Thumb2 mode. However the "unified" syntax is a mixed bag of features, including not requiring a `#' prefix with immediate operands. This leads to situations where some code builds just fine in Thumb2 mode and fails to build in ARM mode if that prefix is missing. This behavior discrepancy makes build tests less valuable, forcing both ARM and Thumb2 builds for proper coverage. Let's "fix" this issue by always using the "unified" syntax for both ARM and Thumb2 mode. Given that the documented minimum binutils version that properly builds the kernel is version 2.20 released in 2010, we can assume that any toolchain capable of building the latest kernel is also "unified syntax" capable. Whith this, a bunch of macros used to mask some differences between both syntaxes can be removed, with the side effect of making LTO easier. Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-11-29 09:52:52 +03:00
# Accept old syntax despite ".syntax unified"
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
Thumb-2: Add Thumb-2 support to the build files This patch adds the necessary entries to the Makefile and Kconfig files for building the Thumb-2 kernel. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-07-24 15:33:02 +04:00
ifeq ($(CONFIG_THUMB2_KERNEL),y)
Revert "ARM: 8846/1: warn if divided syntax assembler is used" This reverts commit e8c24bbda7d5eba6df5ca45e5462fd3f96b8f217. GCC 4.7, which is still permitted, emits code using the original syntax. This means we end up with lots of assembler warnings when building with a currently-supported version of gcc. Revert the commit (with fixups to keep the follow-on -mauto-it change) to avoid these warnings. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-05-16 01:17:17 +03:00
CFLAGS_ISA :=-mthumb -Wa,-mimplicit-it=always $(AFLAGS_NOWARN)
ARM: pass -marm to gcc by default for both C and assembler The Linaro cross toolchain and probably others nowadays default to building in THUMB2 mode. When building a kernel for a CPU that does not support THUMB2, the compiler complains about incorrect flags. We can work around this by setting -marm for all non-T2 builds. -marm was passed unconditionally for C files previously, but nothing was passed to the gcc frontend when processing .S files, resulting in a warning. The assembler never defaults to ARM unless -Wa,-mthumb is supplied explicitly, so the files were still assembled correctly. This patch makes sure that -marm is passed for .S files too, and also avoids the redundant gcc -marm -mthumb in Thumb kernels. Without this patch, building assabet_defconfig results in: usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] (and many more) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Dave Martin <dave.martin@linaro.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-10 15:12:20 +04:00
AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
else
ARM: 8723/2: always assume the "unified" syntax for assembly code The GNU assembler has implemented the "unified syntax" parsing since 2005. This "unified" syntax is required when the kernel is built in Thumb2 mode. However the "unified" syntax is a mixed bag of features, including not requiring a `#' prefix with immediate operands. This leads to situations where some code builds just fine in Thumb2 mode and fails to build in ARM mode if that prefix is missing. This behavior discrepancy makes build tests less valuable, forcing both ARM and Thumb2 builds for proper coverage. Let's "fix" this issue by always using the "unified" syntax for both ARM and Thumb2 mode. Given that the documented minimum binutils version that properly builds the kernel is version 2.20 released in 2010, we can assume that any toolchain capable of building the latest kernel is also "unified syntax" capable. Whith this, a bunch of macros used to mask some differences between both syntaxes can be removed, with the side effect of making LTO easier. Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-11-29 09:52:52 +03:00
CFLAGS_ISA :=$(call cc-option,-marm,) $(AFLAGS_NOWARN)
ARM: pass -marm to gcc by default for both C and assembler The Linaro cross toolchain and probably others nowadays default to building in THUMB2 mode. When building a kernel for a CPU that does not support THUMB2, the compiler complains about incorrect flags. We can work around this by setting -marm for all non-T2 builds. -marm was passed unconditionally for C files previously, but nothing was passed to the gcc frontend when processing .S files, resulting in a warning. The assembler never defaults to ARM unless -Wa,-mthumb is supplied explicitly, so the files were still assembled correctly. This patch makes sure that -marm is passed for .S files too, and also avoids the redundant gcc -marm -mthumb in Thumb kernels. Without this patch, building assabet_defconfig results in: usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] (and many more) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Dave Martin <dave.martin@linaro.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-10 15:12:20 +04:00
AFLAGS_ISA :=$(CFLAGS_ISA)
Thumb-2: Add Thumb-2 support to the build files This patch adds the necessary entries to the Makefile and Kconfig files for building the Thumb-2 kernel. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-07-24 15:33:02 +04:00
endif
[ARM] 3107/3: ARM EABI: last bits to configure it Patch from Nicolas Pitre This adds the configuration option, and disables any FPA floating point emulators which are not EABI compatible. It also disables Acorn RISC OS/Arthur binary support when CONFIG_EABI=y since it is incompatible with an EABI kernel. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-14 19:33:50 +03:00
# Need -Uarm for gcc < 3.x
ARM: pass -marm to gcc by default for both C and assembler The Linaro cross toolchain and probably others nowadays default to building in THUMB2 mode. When building a kernel for a CPU that does not support THUMB2, the compiler complains about incorrect flags. We can work around this by setting -marm for all non-T2 builds. -marm was passed unconditionally for C files previously, but nothing was passed to the gcc frontend when processing .S files, resulting in a warning. The assembler never defaults to ARM unless -Wa,-mthumb is supplied explicitly, so the files were still assembled correctly. This patch makes sure that -marm is passed for .S files too, and also avoids the redundant gcc -marm -mthumb in Thumb kernels. Without this patch, building assabet_defconfig results in: usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] (and many more) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Dave Martin <dave.martin@linaro.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-10 15:12:20 +04:00
KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
kbuild: add machine size to CHECKFLAGS By default, sparse assumes a 64bit machine when compiled on x86-64 and 32bit when compiled on anything else. This can of course create all sort of problems for the other archs, like issuing false warnings ('shift too big (32) for type unsigned long'), or worse, failing to emit legitimate warnings. Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT, to CHECKFLAGS in the main Makefile (and so for all archs). Also, remove the now unneeded -m32/-m64 in arch specific Makefiles. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-30 23:48:38 +03:00
CHECKFLAGS += -D__arm__
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ARM: 8096/1: Describe required sort order for textofs-y (TEXT_OFFSET) The section of the makefile that determines the TEXT_OFFSET is sorted by address so that, in multi-arch kernel builds, the architecture with the most stringent requirements for the kernel base address gets to define TEXT_OFFSET. The comment should reflect that. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-07-08 16:50:50 +04:00
# Text offset. This list is sorted numerically by address in order to
# provide a means to avoid/resolve conflicts in multi-arch kernels.
ARM: add TEXT_OFFSET to decompressor kexec image structure Add the TEXT_OFFSET to the decompressor's kexec image structure to kexec knows what offset to use. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-04-03 14:02:28 +03:00
# Note: the 32kB below this value is reserved for use by the kernel
# during boot, and this offset is critical to the functioning of
# kexec-tools.
[ARM] Make kernel link address depend on PAGE_OFFSET We are coding the kernel link address into the makefiles, which is invisibly dependent on PAGE_OFFSET. If PAGE_OFFSET is changed, the makefiles also need to be changed. Make adjustments such that the makefiles encode just the offset from PAGE_OFFSET for the kernel link address, and use PAGE_OFFSET in the linker scripts directly. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-03 20:28:33 +03:00
textofs-y := 0x00008000
ARM: S3C24XX: Locate kernel at 0x30108000 if PM_H1940 is enabled If PM_H1940 is enabled, kernel _must_ be located upper then 0x30008000, because this area (0x30000000-0x30100000) can be used by bootloader. If kernel is located at 0x30008000, bootloader will corrupt kernel's code during resume. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
2010-05-11 10:55:09 +04:00
# We don't want the htc bootloader to corrupt kernel during resume
textofs-$(CONFIG_PM_H1940) := 0x00108000
ARM: Prepare Realtek RTD1195 Introduce ARCH_REALTEK Kconfig option also for 32-bit Arm. Override the text offset to cope with boot ROM occupying first 0xa800 bytes and further reservations up to 0xf4000 (compare Device Tree). Add a custom machine_desc to enforce memory carveout for I/O registers. Signed-off-by: Andreas Färber <afaerber@suse.de>
2017-10-05 04:59:15 +03:00
# RTD1195 has Boot ROM at start of address space
textofs-$(CONFIG_ARCH_REALTEK) := 0x00108000
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
[ARM] sort machine- and plat- by CONFIG* name Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-04-26 17:22:29 +04:00
ifeq ($(CONFIG_ARCH_SA1100),y)
textofs-$(CONFIG_SA1111) := 0x00208000
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
endif
ARM: qcom: Add support for IPQ40xx Add support for the Qualcomm IPQ40xx SoC in Kconfig. Also add its appropriate textofs. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: John Crispin <john@phrozen.org> Tested-by: Robert Marko <robert.marko@sartura.hr> Cc: Luka Perkov <luka.perkov@sartura.hr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-01-06 16:57:15 +03:00
textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs MSMs post 8x50 have 2Mb at the beginning of RAM reserved for shared memory. Since the kernel hasn't typically been told this RAM exists, PHYS_OFFSET has been set to 0xN0200000 and the memory atags passed to the kernel have matched. This doesn't play nicely with things such as AUTO_ZRELADDR, which doesn't work at all, and dynamic phys to virt, which requires an MSM specific workaround. Work around these issues by telling the kernel RAM starts at 0xN0000000 (it actually does) and fixup the atags from the bootloader (if necessary) to say the same. In addition, make sure to set TEXT_OFFSET at least 2Mb beyond the start of RAM so that the kernel doesn't end up being decompressed into shared memory. After doing this, AUTO_ZRELADDR should work on MSM with no problems and ARM_PATCH_PHYS_VIRT_16BIT should no longer be necessary. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by: David Brown <davidb@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-08-12 03:14:28 +04:00
textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
ARM: meson: Add SMP bringup code for Meson8 and Meson8b This adds the necessary SMP-operations and startup code to use the additional cores on the Amlogic Meson8/Meson8m2 (both are using the same sequence) and Meson8b (using a slightly difference sequence) SoCs. Signed-off-by: Carlo Caione <carlo@endlessm.com> [add Meson8/Meson8m2 support and allow taking CPU cores offline as well] Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-17 19:45:21 +03:00
textofs-$(CONFIG_ARCH_MESON) := 0x00208000
ARM: Add platform support for LSI AXM55xx SoC The AXM55xx family consists of devices that may contain up to 16 ARM Cortex-A15 cores (in a 4x4 cluster configuration). The cores within each cluster share an L2 cache, and the clusters are connected to each other via a CCN-504 cache coherent interconnect. This machine requires CONFIG_ARM_LPAE enabled as all peripherals are located above 4GB in the memory map. Signed-off-by: Anders Berg <anders.berg@lsi.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-05-23 13:08:35 +04:00
textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
[ARM] sort machine- and plat- by CONFIG* name Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-04-26 17:22:29 +04:00
# Machine directory name. This list is sorted alphanumerically
# by CONFIG_* macro name.
ARM: Prepare Actions Semi S500 Add ARCH_ACTIONS and mach-actions/owl.c for "actions,s500". Signed-off-by: Andreas Färber <afaerber@suse.de>
2017-02-15 13:03:22 +03:00
machine-$(CONFIG_ARCH_ACTIONS) += actions
ARM: Add basic support for Airoha EN7523 SoC EN7523 is an armv8 based silicon used inside broadband access type devices such as xPON and xDSL. It shares various silicon blocks with MediaTek silicon such as the MT7622. Add basic support for Airoha EN7523, enough for booting to console. The UART is basically 8250-compatible, except for the clock selection. A clock-frequency value is synthesized to get this to run at 115200 bps. Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Bert Vermeulen <bert@biot.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20220130145116.88406-4-nbd@nbd.name Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2022-01-30 17:51:06 +03:00
machine-$(CONFIG_ARCH_AIROHA) += airoha
ARM: Alpine: Initial support for Alpine platform This patch introduces initial architecture and device-tree support. Signed-off-by: Saeed Bishara <saeed@annapurnalabs.com> Signed-off-by: Tsahee Zidenberg <tsahee@annapurnalabs.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-03-12 14:53:00 +03:00
machine-$(CONFIG_ARCH_ALPINE) += alpine
arm: initial machine port for artpec-6 SoC Basic machine port for the Artpec-6 SoC from Axis Communications. Signed-off-by: Lars Persson <larper@axis.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-02-11 19:06:19 +03:00
machine-$(CONFIG_ARCH_ARTPEC) += artpec
ARM: aspeed: Enable SMP boot This brings the secondary CPU into Linux. It depends on the setup performed by ASPEED's u-boot. Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-21 08:55:27 +03:00
machine-$(CONFIG_ARCH_ASPEED) += aspeed
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_AT91) += at91
ARM: Add platform support for LSI AXM55xx SoC The AXM55xx family consists of devices that may contain up to 16 ARM Cortex-A15 cores (in a 4x4 cluster configuration). The cores within each cluster share an L2 cache, and the clusters are connected to each other via a CCN-504 cache coherent interconnect. This machine requires CONFIG_ARM_LPAE enabled as all peripherals are located above 4GB in the memory map. Signed-off-by: Anders Berg <anders.berg@lsi.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-05-23 13:08:35 +04:00
machine-$(CONFIG_ARCH_AXXIA) += axxia
Add support for generic BCM SoC chipsets In order to start upstreaming Broadcom SoC support, create a starting hierarchy, arch and dts files. The first support SoC family that is planned is the BCM281XX (BCM11130/11140/11351/28145/28155) family of dual A9 mobile SoC cores. This code is just the skeleton code for get the machine upstreamed. It has been made MULTIPLATFORM compatible. Next steps ---------- Upstream a basic set of drivers - sufficient for a console boot to ramdisk. These will includer timer, gpio, i2c drivers. After this basic set, we will proceed with a more comprehensive set of drivers for the 281XX SoC family. v2 patch mods -------- - Remove l2x0_of_init call as there were problems with the code. A separate patch will be submitted with cache init code - Rename capri files and refs to bcm281xx-based names - Add bcm281xx binding doc - various misc cleanups v3 patch mods ------------- - Remove extra #include lines - Remove remaining references to capri - dt uart chipset string added - cleaned up chip # references v4 patch mods ------------- - swap order of compatible definitions for uart - fix typo v5 patch mods ------------- - Rename bcm281xx to bcm11351 in dts+code, leaving references to bcm281xx only in help+comments. v6 patch mods ------------- - fix typo in uart 'compatible' string Signed-off-by: Christian Daudt <csd@broadcom.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-11-19 21:46:10 +04:00
machine-$(CONFIG_ARCH_BCM) += bcm
ARM: add initial support for Marvell Berlin SoCs This adds initial support for the Marvell Berlin SoC family with Armada 1500 (88DE3100) and Armada 1500-mini (88DE3005) SoCs. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Reviewed-by: Jason Cooper <jason@lakedaemon.net> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2013-09-09 16:36:19 +04:00
machine-$(CONFIG_ARCH_BERLIN) += berlin
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_CLPS711X) += clps711x
machine-$(CONFIG_ARCH_CNS3XXX) += cns3xxx
machine-$(CONFIG_ARCH_DAVINCI) += davinci
ARM: digicolor: add the machine directory to Makefile Make the digicolor specific DT_MACHINE_START entry visible. Fixes: df8d742e929 (ARM: initial support for Conexant Digicolor CX92755 SoC) Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-03-09 12:05:14 +03:00
machine-$(CONFIG_ARCH_DIGICOLOR) += digicolor
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_DOVE) += dove
machine-$(CONFIG_ARCH_EP93XX) += ep93xx
ARM: Fix sorting of machine- initializers So, there's a comment I put at the top of this, which people seem to fail to read. So let's fix it for them instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-27 03:45:45 +04:00
machine-$(CONFIG_ARCH_EXYNOS) += exynos
ARM: 8161/1: footbridge: select machine dir based on ARCH_FOOTBRIDGE Syntactically FOOTBRIDGE and ARCH_FOOTBRIDGE are identical (the former is defined in an if ARCH_FOOTBRIDGE block and the latter selects the former). Sematically FOOTBRIDGE means "we have a DC21285 (aka footbridge) device in the system" and ARCH_FOOTBRIDGE is the support for boards with a footbridge device, so ARCH_FOOTBRIDGE is the better symbol here. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-09-24 12:01:19 +04:00
machine-$(CONFIG_ARCH_FOOTBRIDGE) += footbridge
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_GEMINI) += gemini
machine-$(CONFIG_ARCH_HIGHBANK) += highbank
ARM: hisi: add ARCH_HISI Since multiple ARCH configuration will be appended into mach-hisi directory, add ARCH_HISI as common configuration for different platforms in mach-hisi. Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org> Acked-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2014-04-01 07:01:09 +04:00
machine-$(CONFIG_ARCH_HISI) += hisi
ARM: hpe: Introduce the HPE GXP architecture The GXP is the HPE BMC SoC that is used in the majority of current generation HPE servers. Traditionally the asic will last multiple generations of server before being replaced. Info about SoC: HPE GXP is the name of the HPE Soc. This SoC is used to implement many BMC features at HPE. It supports ARMv7 architecture based on the Cortex A9 core. It is capable of using an AXI bus to whicha memory controller is attached. It has multiple SPI interfaces to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC for network connectivity. It has multiple i2c engines to drive connectivity with a host infrastructure. There currently are no public specifications but this process is being worked. Previously there was a requirement to reset the EHCI controller for the asic to boot. This functionality has been moved to the u-boot bootloader. Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-05-16 19:33:39 +03:00
machine-$(CONFIG_ARCH_HPE) += hpe
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_IOP32X) += iop32x
machine-$(CONFIG_ARCH_IXP4XX) += ixp4xx
ARM: Fix sorting of machine- initializers So, there's a comment I put at the top of this, which people seem to fail to read. So let's fix it for them instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-27 03:45:45 +04:00
machine-$(CONFIG_ARCH_KEYSTONE) += keystone
ARM: lpc18xx: add basic support for NXP LPC18xx/43xx SoCs Add support for NXP's LPC18xx (Cortex-M3) and LPC43xx (Cortex-M4) SoCs. These SoCs are NXP's high preformance MCU line and can run at clock speeds up to 180 MHz for LPC18xx and 204 MHz for LPC43xx. LPC43xx is more or less a LPC18xx with a Cortex-M4F core and a few extra peripherals. The LPC43xx series also features one or two Cortex-M0 cores that can be used to offload the main M4 core. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-05-12 01:00:47 +03:00
machine-$(CONFIG_ARCH_LPC18XX) += lpc18xx
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx
ARM: meson: add basic support for MesonX SoCs This patch adds the basic machine file for the MesonX SoCs. Only Meson6 is populated. Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-09-11 00:16:59 +04:00
machine-$(CONFIG_ARCH_MESON) += meson
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_MMP) += mmp
ARM: moxart: add MOXA ART SoC platform files The MOXA ART SoC is based on Faraday's FA526. This is a ARMv4 32-bit 192 MHz CPU with MMU and 16KB/8KB D/I-cache. Add platform support for this SoC. Also add UC-7112-LX as a machine. Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2013-12-18 16:58:45 +04:00
machine-$(CONFIG_ARCH_MOXART) += moxart
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0
ARM: Fix sorting of machine- initializers So, there's a comment I put at the top of this, which people seem to fail to read. So let's fix it for them instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-27 03:45:45 +04:00
machine-$(CONFIG_ARCH_MVEBU) += mvebu
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_MXC) += imx
arm: add basic support for Mediatek MT6589 boards This adds a generic devicetree board file and a dtsi for boards based on MT6589 SoCs from Mediatek. Apart from the generic parts (gic, clocks) the only component currently supported are the timers. Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2014-05-13 03:06:13 +04:00
machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
ARM: milbeaut: Add basic support for Milbeaut m10v SoC This adds the basic M10V SoC support under arch/arm. Since all cores are activated in the custom bootloader before booting linux, it is necessary to wait for the secondary-cores using cpu-enable- method and special sram. Signed-off-by: Sugaya Taichi <sugaya.taichi@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-27 07:52:33 +03:00
machine-$(CONFIG_ARCH_MILBEAUT) += milbeaut
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_MXS) += mxs
ARM: mstar: Add machine for MStar/Sigmastar Armv7 SoCs Initial support for the MStar/Sigmastar Armv7 based IP camera and dashcam SoCs. These chips are interesting in that they contain a Cortex-A7, peripherals and system memory in a single tiny QFN package that can be hand soldered allowing almost anyone to embed Linux in their projects. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-07-10 12:45:38 +03:00
machine-$(CONFIG_ARCH_MSTARV7) += mstar
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
arm: npcm: add basic support for Nuvoton BMCs Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com> Reviewed-by: Avi Fishman <avifishman70@gmail.com> Tested-by: Tomer Maimon <tmaimon77@gmail.com> Tested-by: Avi Fishman <avifishman70@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-08-16 22:18:39 +03:00
machine-$(CONFIG_ARCH_NPCM) += npcm
arm: Add Initial TI-Nspire support This patch adds support for the TI-Nspire platform. Changes between v1 and v2: * Added GENERIC_IRQ_CHIP to platform Kconfig Signed-off-by: Daniel Tang <dt.tangr@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-06-11 12:40:17 +04:00
machine-$(CONFIG_ARCH_NSPIRE) += nspire
ARM: oxnas: Add OX820 config and makefile entry Refactor the oxnas Kconfig entries among the OX810SE and OX820 configs, and add the files to support the OX820 SMP feature. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2016-09-09 13:23:45 +03:00
machine-$(CONFIG_ARCH_OXNAS) += oxnas
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_OMAP1) += omap1
machine-$(CONFIG_ARCH_OMAP2PLUS) += omap2
machine-$(CONFIG_ARCH_ORION5X) += orion5x
machine-$(CONFIG_ARCH_PXA) += pxa
ARM: qcom: Split Qualcomm support into legacy and multiplatform Introduce a new mach-qcom that will support SoCs that intend to be multiplatform compatible while keeping mach-msm to legacy SoC/board support that will not transition over to multiplatform. As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over to mach-qcom. Signed-off-by: Kumar Gala <galak@codeaurora.org>
2014-01-22 03:14:10 +04:00
machine-$(CONFIG_ARCH_QCOM) += qcom
ARM: Prepare RDA8810PL SoC Introduce ARCH_RDA and mach-rda for RDA Micro SoCs. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2018-12-18 18:02:30 +03:00
machine-$(CONFIG_ARCH_RDA) += rda
ARM: Prepare Realtek RTD1195 Introduce ARCH_REALTEK Kconfig option also for 32-bit Arm. Override the text offset to cope with boot ROM occupying first 0xa800 bytes and further reservations up to 0xf4000 (compare Device Tree). Add a custom machine_desc to enforce memory carveout for I/O registers. Signed-off-by: Andreas Färber <afaerber@suse.de>
2017-10-05 04:59:15 +03:00
machine-$(CONFIG_ARCH_REALTEK) += realtek
arm: add basic support for Rockchip RK3066a boards This adds a generic devicetree board file and a dtsi for boards based on the RK3066a SoCs from Rockchip. Apart from the generic parts (gic, clocks, pinctrl) the only components currently supported are the timers, uarts and mmc ports (all DesignWare- based). Signed-off-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Olof Johansson <olof@lixom.net>
2013-06-03 01:09:41 +04:00
machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_RPC) += rpc
ARM: s3c: move into a common directory s3c24xx and s3c64xx have a lot in common, but are split across three separate directories, which makes the interaction of the header files more complicated than necessary. Move all three directories into a new mach-s3c, with a minimal set of changes to each file. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [krzk: Rebase, add s3c24xx and s3c64xx suffix to several files, add SPDX headers to new files, remove plat-samsung from MAINTAINERS] Co-developed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> https://lore.kernel.org/r/20200806182059.2431-39-krzk@kernel.org
2019-09-02 18:47:55 +03:00
machine-$(CONFIG_PLAT_SAMSUNG) += s3c
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_S5PV210) += s5pv210
machine-$(CONFIG_ARCH_SA1100) += sa1100
arm: shmobile: Change platform dependency to ARCH_RENESAS Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") ARCH_RENESAS is a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use the former. This will allow to drop ARCH_SHMOBILE on ARM in the near future. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2018-04-20 16:28:27 +03:00
machine-$(CONFIG_ARCH_RENESAS) += shmobile
ARM: socfpga: introduce common ARCH_INTEL_SOCFPGA Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-11 18:25:32 +03:00
machine-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga
ARM: Fix sorting of machine- initializers So, there's a comment I put at the top of this, which people seem to fail to read. So let's fix it for them instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-27 03:45:45 +04:00
machine-$(CONFIG_ARCH_STI) += sti
ARM: Add STM32 family machine STMicrolectronics's STM32 series is a family of Cortex-M microcontrollers. It is used in various applications, and proposes a wide range of peripherals. Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-05-09 10:53:54 +03:00
machine-$(CONFIG_ARCH_STM32) += stm32
ARM: sunplus: Add initial support for Sunplus SP7021 SoC This patch aims to add an initial support for Sunplus SP7021 SoC. Signed-off-by: Qin Jian <qinjian@cqplus1.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-06-28 09:26:49 +03:00
machine-$(CONFIG_ARCH_SUNPLUS) += sunplus
ARM: Fix sorting of machine- initializers So, there's a comment I put at the top of this, which people seem to fail to read. So let's fix it for them instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-27 03:45:45 +04:00
machine-$(CONFIG_ARCH_SUNXI) += sunxi
ARM: initial multiplatform support This lets us build a multiplatform kernel for experimental purposes. However, it will not be useful for any real work, because it relies on a number of useful things to be disabled for now: * SMP support must be turned off because of conflicting symbols. Marc Zyngier has proposed a solution by adding a new SOC operations structure to hold indirect function pointers for these, but that work is currently stalled * We turn on SPARSE_IRQ unconditionally, which is not supported on most platforms. Each of them is currently in a different state, but most are being worked on. * A common clock framework is in place since v3.4 but not yet being used. Work on this is on its way. * DEBUG_LL for early debugging is currently disabled. * THUMB2_KERNEL does not work with allyesconfig because the kernel gets too big [Rob Herring]: Rebased to not be dependent on the mass mach header rename. As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank, picoxcell, mvebu, and socfpga are converted. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Dinh Nguyen <dinguyen@altera.com>
2012-09-06 22:41:12 +04:00
machine-$(CONFIG_ARCH_TEGRA) += tegra
machine-$(CONFIG_ARCH_U8500) += ux500
machine-$(CONFIG_ARCH_VT8500) += vt8500
ARM: Fix sorting of machine- initializers So, there's a comment I put at the top of this, which people seem to fail to read. So let's fix it for them instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-07-27 03:45:45 +04:00
machine-$(CONFIG_ARCH_ZYNQ) += zynq
ARM: versatile: move integrator/realview/vexpress to versatile These are all fairly small platforms by now, and they are closely related. Just move them all into a single directory. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-01 15:35:42 +03:00
machine-$(CONFIG_PLAT_VERSATILE) += versatile
ARM: spear: move all files to mach-spear There are no conflicting files between the three mach-spear* directories and plat-spear any more, so we can now move all file to a common mach-spear directory. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2012-12-02 18:12:47 +04:00
machine-$(CONFIG_PLAT_SPEAR) += spear
[ARM] sort machine- and plat- by CONFIG* name Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-04-26 17:22:29 +04:00
ARM: simplify machdirs/platdirs handling There is only one plat-* directory left, and the MACHINE variable is only used for the mach/*.h header path. Simplify this by removing the checks for ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, and just adding the include directories for the remaining three platforms manually. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-27 12:53:02 +03:00
# legacy platforms provide their own mach/*.h headers globally,
# these three are mutually exclusive
machdirs-$(CONFIG_ARCH_FOOTBRIDGE) += arch/arm/mach-footbridge
machdirs-$(CONFIG_ARCH_RPC) += arch/arm/mach-rpc
machdirs-$(CONFIG_ARCH_SA1100) += arch/arm/mach-sa1100
KBUILD_CPPFLAGS += $(patsubst %,-I$(srctree)/%/include,$(machdirs-y))
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
[ARM] Make kernel link address depend on PAGE_OFFSET We are coding the kernel link address into the makefiles, which is invisibly dependent on PAGE_OFFSET. If PAGE_OFFSET is changed, the makefiles also need to be changed. Make adjustments such that the makefiles encode just the offset from PAGE_OFFSET for the kernel link address, and use PAGE_OFFSET in the linker scripts directly. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-03 20:28:33 +03:00
# The byte offset of the kernel image in RAM from the start of RAM.
TEXT_OFFSET := $(textofs-y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
[ARM] nommu: add nommu specific Kconfig and MMUEXT variable in Makefile This patch adds Kconfig-nommu for noMMU specific configurations and MMUEXT variable into Makefile. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-03-27 18:14:19 +04:00
export TEXT_OFFSET GZFLAGS MMUEXT
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ARM: link board specific files after core files This allows for board specific issues to override decisions made in generic code that might not be suitable due to some errata or the like, by making the initcall hooks from those board specific files run after the core ones, therefore avoiding ugly #ifdef's in core code. Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Tested-by: Dave Martin <dave.martin@linaro.org> Tested-by: Jason Hui <jason.hui@linaro.org>
2010-09-01 17:37:05 +04:00
# If we have a machine-specific directory, then include it in the build.
ARM: simplify machdirs/platdirs handling There is only one plat-* directory left, and the MACHINE variable is only used for the mach/*.h header path. Simplify this by removing the checks for ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, and just adding the include directories for the remaining three platforms manually. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-27 12:53:02 +03:00
core-y += $(patsubst %,arch/arm/mach-%/,$(machine-y))
ARM: 8895/1: visit mach-* and plat-* directories when cleaning When you run "make clean" for arm, it never visits mach-* or plat-* directories because machine-y and plat-y are just empty. When cleaning, all machine, plat directories are accumulated to machine-, plat-, respectively. So, let's pass them to core- to clean up those directories. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-07-18 19:35:23 +03:00
# For cleaning
ARM: simplify machdirs/platdirs handling There is only one plat-* directory left, and the MACHINE variable is only used for the mach/*.h header path. Simplify this by removing the checks for ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, and just adding the include directories for the remaining three platforms manually. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-27 12:53:02 +03:00
core- += $(patsubst %,arch/arm/mach-%/,$(machine-))
core-$(CONFIG_PLAT_ORION) += arch/arm/plat-orion/
ARM: 8895/1: visit mach-* and plat-* directories when cleaning When you run "make clean" for arm, it never visits mach-* or plat-* directories because machine-y and plat-y are just empty. When cleaning, all machine, plat directories are accumulated to machine-, plat-, respectively. So, let's pass them to core- to clean up those directories. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-07-18 19:35:23 +03:00
[ARM] 3097/1: change library link ordering Patch from Nicolas Pitre We have an optimized sha1 routine (arch/arm/lib/sha1.S) meant to override the generic one in lib/sha1.c. Unfortunately lib/lib.a is listed _before_ arch/arm/lib/lib.a in the link argument list and therefore the architecture specific lib functions are not picked up before the generic versions. This patch is a quick fix to change that ordering for ARM. Here's what the kbuild maintainer had to say about it (was also CC'd on lkml): On Wed, 2 Nov 2005, Sam Ravnborg wrote: > This looks like an obvious way to achive correct ordering. > We could change it so arch defines always took precedence but > the above is so simple that it is not worth the effort. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-11-04 20:17:30 +03:00
libs-y := arch/arm/lib/ $(libs-y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# Default target when executing plain make
arm: Use full path in KBUILD_IMAGE definition The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which expect it to point to the image file in the build directory. The builddeb script has a workaround for architectures which only provide the basename, but let's provide a clean interface for packaging tools. Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-11-23 00:34:30 +03:00
boot := arch/arm/boot
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ifeq ($(CONFIG_XIP_KERNEL),y)
arm: Use full path in KBUILD_IMAGE definition The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which expect it to point to the image file in the build directory. The builddeb script has a workaround for architectures which only provide the basename, but let's provide a clean interface for packaging tools. Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-11-23 00:34:30 +03:00
KBUILD_IMAGE := $(boot)/xipImage
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
else
arm: Use full path in KBUILD_IMAGE definition The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which expect it to point to the image file in the build directory. The builddeb script has a workaround for architectures which only provide the basename, but let's provide a clean interface for packaging tools. Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-11-23 00:34:30 +03:00
KBUILD_IMAGE := $(boot)/zImage
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
endif
ARM: smp: add support for per-task stack canaries On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 11:32:57 +03:00
ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
prepare: stack_protector_prepare
ARM: stackprotector: prefer compiler for TLS based per-task protector Currently, we implement the per-task stack protector for ARM using a GCC plugin, due to lack of native compiler support. However, work is underway to get this implemented in the compiler, which means we will be able to deprecate the GCC plugin at some point. In the meantime, we will need to support both, where the native compiler implementation is obviously preferred. So let's wire this up in Kconfig and the Makefile. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-21 17:16:47 +03:00
ifeq ($(CONFIG_CC_HAVE_STACKPROTECTOR_TLS),y)
stack_protector_prepare: prepare0
$(eval KBUILD_CFLAGS += \
-mstack-protector-guard=tls \
-mstack-protector-guard-offset=$(shell \
awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}'\
include/generated/asm-offsets.h))
else
ARM: smp: add support for per-task stack canaries On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 11:32:57 +03:00
stack_protector_prepare: prepare0
ARM: 8961/2: Fix Kbuild issue caused by per-task stack protector GCC plugin When using plugins, GCC requires that the -fplugin= options precedes any of its plugin arguments appearing on the command line as well. This is usually not a concern, but as it turns out, this requirement is causing some issues with ARM's per-task stack protector plugin and Kbuild's implementation of $(cc-option). When the per-task stack protector plugin is enabled, and we tweak the implementation of cc-option not to pipe the stderr output of GCC to /dev/null, the following output is generated when GCC is executed in the context of cc-option: cc1: error: plugin arm_ssp_per_task_plugin should be specified before \ -fplugin-arg-arm_ssp_per_task_plugin-tso=1 in the command line cc1: error: plugin arm_ssp_per_task_plugin should be specified before \ -fplugin-arg-arm_ssp_per_task_plugin-offset=24 in the command line These errors will cause any option passed to cc-option to be treated as unsupported, which is obviously incorrect. The cause of this issue is the fact that the -fplugin= argument is added to GCC_PLUGINS_CFLAGS, whereas the arguments above are added to KBUILD_CFLAGS, and the contents of the former get filtered out of the latter before being passed to the GCC running the cc-option test, and so the -fplugin= option does not appear at all on the GCC command line. Adding the arguments to GCC_PLUGINS_CFLAGS instead of KBUILD_CFLAGS would be the correct approach here, if it weren't for the fact that we are using $(eval) to defer the moment that they are added until after asm-offsets.h is generated, which is after the point where the contents of GCC_PLUGINS_CFLAGS are added to KBUILD_CFLAGS. So instead, we have to add our plugin arguments to both. For similar reasons, we cannot append DISABLE_ARM_SSP_PER_TASK_PLUGIN to KBUILD_CFLAGS, as it will be passed to GCC when executing in the context of cc-option, whereas the other plugin arguments will have been filtered out, resulting in a similar error and false negative result as above. So add it to ccflags-y instead. Fixes: 189af4657186da08 ("ARM: smp: add support for per-task stack canaries") Reported-by: Merlijn Wajer <merlijn@wizzup.org> Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-02-18 11:15:34 +03:00
$(eval SSP_PLUGIN_CFLAGS := \
ARM: smp: add support for per-task stack canaries On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 11:32:57 +03:00
-fplugin-arg-arm_ssp_per_task_plugin-offset=$(shell \
gcc-plugins: arm-ssp: Prepare for THREAD_INFO_IN_TASK support We will be enabling THREAD_INFO_IN_TASK support for ARM, which means that we can no longer load the stack canary value by masking the stack pointer and taking the copy that lives in thread_info. Instead, we will be able to load it from the task_struct directly, by using the TPIDRURO register which will hold the current task pointer when THREAD_INFO_IN_TASK is in effect. This is much more straight-forward, and allows us to declutter this code a bit while at it. Note that this means that ARMv6 (non-v6K) SMP systems can no longer use this feature, but those are quite rare to begin with, so this is a reasonable trade off. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
2021-09-18 11:44:34 +03:00
awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}'\
ARM: smp: add support for per-task stack canaries On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 11:32:57 +03:00
include/generated/asm-offsets.h))
ARM: 8961/2: Fix Kbuild issue caused by per-task stack protector GCC plugin When using plugins, GCC requires that the -fplugin= options precedes any of its plugin arguments appearing on the command line as well. This is usually not a concern, but as it turns out, this requirement is causing some issues with ARM's per-task stack protector plugin and Kbuild's implementation of $(cc-option). When the per-task stack protector plugin is enabled, and we tweak the implementation of cc-option not to pipe the stderr output of GCC to /dev/null, the following output is generated when GCC is executed in the context of cc-option: cc1: error: plugin arm_ssp_per_task_plugin should be specified before \ -fplugin-arg-arm_ssp_per_task_plugin-tso=1 in the command line cc1: error: plugin arm_ssp_per_task_plugin should be specified before \ -fplugin-arg-arm_ssp_per_task_plugin-offset=24 in the command line These errors will cause any option passed to cc-option to be treated as unsupported, which is obviously incorrect. The cause of this issue is the fact that the -fplugin= argument is added to GCC_PLUGINS_CFLAGS, whereas the arguments above are added to KBUILD_CFLAGS, and the contents of the former get filtered out of the latter before being passed to the GCC running the cc-option test, and so the -fplugin= option does not appear at all on the GCC command line. Adding the arguments to GCC_PLUGINS_CFLAGS instead of KBUILD_CFLAGS would be the correct approach here, if it weren't for the fact that we are using $(eval) to defer the moment that they are added until after asm-offsets.h is generated, which is after the point where the contents of GCC_PLUGINS_CFLAGS are added to KBUILD_CFLAGS. So instead, we have to add our plugin arguments to both. For similar reasons, we cannot append DISABLE_ARM_SSP_PER_TASK_PLUGIN to KBUILD_CFLAGS, as it will be passed to GCC when executing in the context of cc-option, whereas the other plugin arguments will have been filtered out, resulting in a similar error and false negative result as above. So add it to ccflags-y instead. Fixes: 189af4657186da08 ("ARM: smp: add support for per-task stack canaries") Reported-by: Merlijn Wajer <merlijn@wizzup.org> Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-02-18 11:15:34 +03:00
$(eval KBUILD_CFLAGS += $(SSP_PLUGIN_CFLAGS))
$(eval GCC_PLUGINS_CFLAGS += $(SSP_PLUGIN_CFLAGS))
ARM: smp: add support for per-task stack canaries On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 11:32:57 +03:00
endif
ARM: stackprotector: prefer compiler for TLS based per-task protector Currently, we implement the per-task stack protector for ARM using a GCC plugin, due to lack of native compiler support. However, work is underway to get this implemented in the compiler, which means we will be able to deprecate the GCC plugin at some point. In the meantime, we will need to support both, where the native compiler implementation is obviously preferred. So let's wire this up in Kconfig and the Makefile. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-21 17:16:47 +03:00
endif
ARM: smp: add support for per-task stack canaries On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06 11:32:57 +03:00
kbuild: consolidate Devicetree dtb build rules There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Paul Burton <paul.burton@mips.com> Acked-by: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-kbuild@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: uclinux-h8-devel@lists.sourceforge.jp Cc: linux-mips@linux-mips.org Cc: nios2-dev@lists.rocketboards.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Rob Herring <robh@kernel.org>
2018-01-11 00:19:37 +03:00
all: $(notdir $(KBUILD_IMAGE))
[ARM] Add KBUILD_IMAGE target support Add support for KBUILD_IMAGE on ARM. This takes the usual target specifiers (zImage/Image/etc) in the same way that powerpc does (iow, without the arch/arm/boot prefix). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-10-29 15:51:05 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ARM: convert to generated system call tables Convert ARM to use a similar mechanism to x86 to generate the unistd.h system call numbers and the various kernel system call tables. This means that rather than having to edit three places (asm/unistd.h for the total number of system calls, uapi/asm/unistd.h for the system call numbers, and arch/arm/kernel/calls.S for the call table) we have only one place to edit, making the process much more simple. The scripts have knowledge of the table padding requirements, so there's no need to worry about __NR_syscalls not fitting within the immediate constant field of ALU instructions anymore. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2016-10-18 21:57:01 +03:00
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
arm: move mach-types to include/generated Simplified arch/arm/Makefile by dropping the maketools target It was undocumented and not needed Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-04-20 21:59:58 +04:00
archprepare:
ARM: remove indirection of asm/mach-types.h Arrange for mach-types.h to be directly generated in the relevant path, so we don't need a one-liner file in arch/arm/include/asm/. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2016-10-18 22:11:23 +03:00
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# Convert bzImage to zImage
bzImage: zImage
arm, kbuild: make "make install" not depend on vmlinux Install targets (install, zinstall, uinstall) on arm have a dependency to vmlinux. This may cause parts of the kernel to be rebuilt during installation. We must avoid this since this may run as root. Install targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus emphasized this in: http://lkml.org/lkml/2013/7/10/600 So on arm and maybe other archs we need the same as for x86: 1648e4f8 x86, kbuild: make "make install" not depend on vmlinux This patch fixes this for arm. Dependencies are removed and instead a check to install.sh is added for the files that are needed. This issue was uncovered by this build error where the -j option is used in conjunction with install targets: $ make <makeflags> $ make <makeflags> zinstall ... DEPMOD Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease> (INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms required in this case.) The problem is that zinstall on arm due to its dependency to vmlinux does a prepare/prepare3 and finally does a forced rewrite of kernel.release even if it exists already. Rebuilding kernel.release removes it first and then recreates it. This might race with another parallel make job running depmod. So this patch should fix this one too. Also quoting $(KERNELRELEASE) arg for install.sh as this messes argument order in case it is empty (which is the case if the kernel was not built yet). Signed-off-by: Robert Richter <robert.richter@linaro.org> Signed-off-by: Robert Richter <rric@kernel.org> Acked-by: Michal Marek <mmarek@suse.cz>. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Michal Marek <mmarek@suse.cz>
2013-07-17 20:05:06 +04:00
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
ARM: 8418/1: add boot image dependencies to not generate invalid images U-Boot is often used to boot the kernel on ARM boards, but uImage is not built by "make all", so we are often inclined to do "make all uImage" to generate DTBs, modules and uImage in a single command, but we should notice a pitfall behind it. In fact, "make all uImage" could generate an invalid uImage if it is run with the parallel option (-j). You can reproduce this problem with the following procedure: [1] First, build "all" and "uImage" separately. You will get a valid uImage $ git clean -f -x -d $ export CROSS_COMPILE=<your-tools-prefix> $ make -s -j8 ARCH=arm multi_v7_defconfig $ make -s -j8 ARCH=arm all $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:21:35 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6138648 Bytes = 5994.77 kB = 5.85 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:20 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 6138712 Aug 8 23:21 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:20 arch/arm/boot/zImage [2] Update some source file(s) $ touch init/main.c [3] Then, re-build "all" and "uImage" simultaneously. You will get an invalid uImage at random. $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CC init/main.o CHK include/generated/compile.h LD init/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map OBJCOPY arch/arm/boot/Image Building modules, stage 2. Kernel: arch/arm/boot/Image is ready GZIP arch/arm/boot/compressed/piggy.gzip AS arch/arm/boot/compressed/piggy.gzip.o Kernel: arch/arm/boot/Image is ready LD arch/arm/boot/compressed/vmlinux GZIP arch/arm/boot/compressed/piggy.gzip OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:23:14 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 26472 Bytes = 25.85 kB = 0.03 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready MODPOST 192 modules AS arch/arm/boot/compressed/piggy.gzip.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:23 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 26536 Aug 8 23:23 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:23 arch/arm/boot/zImage Please notice the uImage is extremely small when this issue is encountered. Besides, "Kernel: arch/arm/boot/zImage is ready" is displayed twice, before and after the uImage log. The root cause of this is the race condition between zImage and uImage. Actually, uImage depends on zImage, but the dependency between the two is only described in arch/arm/boot/Makefile. Because arch/arm/boot/Makefile is not included from the top-level Makefile, it cannot know the dependency between zImage and uImage. Consequently, when we run make with the parallel option, Kbuild updates vmlinux first, and then two different threads descends into the arch/arm/boot/Makefile almost at the same time, one for updating zImage and the other for uImage. While one thread is re-generating zImage, the other also tries to update zImage before creating uImage on top of that. zImage is overwritten by the slower thread and then uImage is created based on the half-written zImage. This is the reason why "Kernel: arch/arm/boot/zImage is ready" is displayed twice, and a broken uImage is created. The same problem could happen on bootpImage. This commit adds dependencies among Image, zImage, uImage, and bootpImage to arch/arm/Makefile, which is included from the top-level Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-08-17 06:03:33 +03:00
bootpImage uImage: zImage
zImage: Image
arm, kbuild: make "make install" not depend on vmlinux Install targets (install, zinstall, uinstall) on arm have a dependency to vmlinux. This may cause parts of the kernel to be rebuilt during installation. We must avoid this since this may run as root. Install targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus emphasized this in: http://lkml.org/lkml/2013/7/10/600 So on arm and maybe other archs we need the same as for x86: 1648e4f8 x86, kbuild: make "make install" not depend on vmlinux This patch fixes this for arm. Dependencies are removed and instead a check to install.sh is added for the files that are needed. This issue was uncovered by this build error where the -j option is used in conjunction with install targets: $ make <makeflags> $ make <makeflags> zinstall ... DEPMOD Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease> (INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms required in this case.) The problem is that zinstall on arm due to its dependency to vmlinux does a prepare/prepare3 and finally does a forced rewrite of kernel.release even if it exists already. Rebuilding kernel.release removes it first and then recreates it. This might race with another parallel make job running depmod. So this patch should fix this one too. Also quoting $(KERNELRELEASE) arg for install.sh as this messes argument order in case it is empty (which is the case if the kernel was not built yet). Signed-off-by: Robert Richter <robert.richter@linaro.org> Signed-off-by: Robert Richter <rric@kernel.org> Acked-by: Michal Marek <mmarek@suse.cz>. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Michal Marek <mmarek@suse.cz>
2013-07-17 20:05:06 +04:00
$(BOOT_TARGETS): vmlinux
ARM: remove obsolete Makefile.boot infrastructure There are a number of old Makefile.boot files that remain from the multiplatform conversion, and three that are still in use. These provide the "ZRELADDR", "PARAMS_PHYS" and "INITRD_PHYS" values that are platform specific. It turns out that we can generally just derive this from information that is available elsewhere: - ZRELADDR is normally detected at runtime with the CONFIG_AUTO_ZRELADDR flag, but also needed to be passed to for 'make uImage'. In a multiplatform kernel, one always has to pass this as the $(LOADADDR) variable, but in the StrongARM kernels we can derive it from the sum of $(CONFIG_PHYS_OFFSET) and $(TEXT_OFFSET) that are already known. - PARAMS_PHYS and INITRD_PHYS are only used for bootpImage, which in turn is only used for the pre-ATAGS 'param_struct' based boot interface on StrongARM based machines with old boot loaders. They can both be derived from CONFIG_PHYS_OFFSET and a machine specific offset for the initrd, so all of the logic for these can be part of arch/arm/boot/bootp/Makefile. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-27 10:26:45 +03:00
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
ARM: 8576/1: avoid duplicating "Kernel: arch/arm/boot/*Image is ready" Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not generate invalid images") fixed bad image generation for the parallel building, but as its side effect, Kbuild now descends into arch/arm/boot/ again and again, duplicating the log messages. It looks clumsy, so let's display the same message only once. This commit moves the log rules from arch/arm/boot/Makefile to arch/arm/Makefile. I did not delete them completely because *Image are the final targets that users are interested in. Without this commit, the log of incremental build is like follows: $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Image arch/arm/boot/uImage is ready With this commit, it will look like follows: $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Kernel: arch/arm/boot/uImage is ready Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-05-30 05:01:23 +03:00
@$(kecho) ' Kernel: $(boot)/$@ is ready'
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
kbuild: factor out the common installation code into scripts/install.sh Many architectures have similar install.sh scripts. The first half is really generic; it verifies that the kernel image and System.map exist, then executes ~/bin/${INSTALLKERNEL} or /sbin/${INSTALLKERNEL} if available. The second half is kind of arch-specific; it copies the kernel image and System.map to the destination, but the code is slightly different. Factor out the generic part into scripts/install.sh. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-05-03 05:47:16 +03:00
$(INSTALL_TARGETS): KBUILD_IMAGE = $(boot)/$(patsubst %install,%Image,$@)
arm, kbuild: make "make install" not depend on vmlinux Install targets (install, zinstall, uinstall) on arm have a dependency to vmlinux. This may cause parts of the kernel to be rebuilt during installation. We must avoid this since this may run as root. Install targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus emphasized this in: http://lkml.org/lkml/2013/7/10/600 So on arm and maybe other archs we need the same as for x86: 1648e4f8 x86, kbuild: make "make install" not depend on vmlinux This patch fixes this for arm. Dependencies are removed and instead a check to install.sh is added for the files that are needed. This issue was uncovered by this build error where the -j option is used in conjunction with install targets: $ make <makeflags> $ make <makeflags> zinstall ... DEPMOD Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease> (INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms required in this case.) The problem is that zinstall on arm due to its dependency to vmlinux does a prepare/prepare3 and finally does a forced rewrite of kernel.release even if it exists already. Rebuilding kernel.release removes it first and then recreates it. This might race with another parallel make job running depmod. So this patch should fix this one too. Also quoting $(KERNELRELEASE) arg for install.sh as this messes argument order in case it is empty (which is the case if the kernel was not built yet). Signed-off-by: Robert Richter <robert.richter@linaro.org> Signed-off-by: Robert Richter <rric@kernel.org> Acked-by: Michal Marek <mmarek@suse.cz>. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Michal Marek <mmarek@suse.cz>
2013-07-17 20:05:06 +04:00
$(INSTALL_TARGETS):
kbuild: factor out the common installation code into scripts/install.sh Many architectures have similar install.sh scripts. The first half is really generic; it verifies that the kernel image and System.map exist, then executes ~/bin/${INSTALLKERNEL} or /sbin/${INSTALLKERNEL} if available. The second half is kind of arch-specific; it copies the kernel image and System.map to the destination, but the code is slightly different. Factor out the generic part into scripts/install.sh. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-05-03 05:47:16 +03:00
$(call cmd,install)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
ARM: 8332/1: add CONFIG_VDSO Kconfig and Makefile bits Allow users to enable the vdso in Kconfig; include the vdso in the build if CONFIG_VDSO is enabled. Add 'vdso_install' target. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-03-25 21:16:05 +03:00
PHONY += vdso_install
vdso_install:
ifeq ($(CONFIG_VDSO),y)
$(Q)$(MAKE) $(build)=arch/arm/vdso $@
endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
# My testing targets (bypasses dependencies)
ARM: remove obsolete Makefile.boot infrastructure There are a number of old Makefile.boot files that remain from the multiplatform conversion, and three that are still in use. These provide the "ZRELADDR", "PARAMS_PHYS" and "INITRD_PHYS" values that are platform specific. It turns out that we can generally just derive this from information that is available elsewhere: - ZRELADDR is normally detected at runtime with the CONFIG_AUTO_ZRELADDR flag, but also needed to be passed to for 'make uImage'. In a multiplatform kernel, one always has to pass this as the $(LOADADDR) variable, but in the StrongARM kernels we can derive it from the sum of $(CONFIG_PHYS_OFFSET) and $(TEXT_OFFSET) that are already known. - PARAMS_PHYS and INITRD_PHYS are only used for bootpImage, which in turn is only used for the pre-ATAGS 'param_struct' based boot interface on StrongARM based machines with old boot loaders. They can both be derived from CONFIG_PHYS_OFFSET and a machine specific offset for the initrd, so all of the logic for these can be part of arch/arm/boot/bootp/Makefile. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-27 10:26:45 +03:00
bp:; $(Q)$(MAKE) $(build)=$(boot) $(boot)/bootpImage
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
define archhelp
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
echo '* xipImage - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
[ARM] 4853/1: include uImage target in make help Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-03-06 18:22:17 +03:00
echo ' uImage - U-Boot wrapped zImage'
ARM: 7712/1: Remove trailing whitespace in arch/arm/Makefile Clean up some trailing whitespace issues in arch/arm/Makefile. Signed-off-by: Daniel Tang <dt.tangr@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-05-03 11:13:55 +04:00
echo ' bootpImage - Combined zImage and initial RAM disk'
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
echo ' (supply initrd image via make variable INITRD=<path>)'
echo ' install - Install uncompressed kernel'
echo ' zinstall - Install compressed kernel'
ARM: add 'uinstall' target for installing uboot kernels We have 'install' and 'zinstall' for installing Image and zImage kernels, so add 'uinstall' to complete the set. This allows developers to have a ~/bin/installkernel script which (eg) copies the kernel to the tftp server automatically once the kernel has built, resulting in a better workflow. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-08 19:18:51 +03:00
echo ' uinstall - Install U-Boot wrapped compressed kernel'
kbuild: use INSTALLKERNEL to select customized installkernel script Replace the use of CROSS_COMPILE to select a customized installkernel script with the possibility to set INSTALLKERNEL to select a custom installkernel script when running make: make INSTALLKERNEL=arm-installkernel install With this patch we are now more consistent across different architectures - they did not all support use of CROSS_COMPILE. The use of CROSS_COMPILE was a hack as this really belongs to gcc/binutils and the installkernel script does not change just because we change toolchain. The use of CROSS_COMPILE caused troubles with an upcoming patch that saves CROSS_COMPILE when a kernel is built - it would no longer be installable. [Thanks to Peter Z. for this hint] This patch undos what Ian did in commit: 0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46 ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh") The patch has been lightly tested on x86 only - but all changes looks obvious. Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin] Acked-by: Russell King <linux@arm.linux.org.uk> [arm] Acked-by: Paul Mundt <lethal@linux-sh.org> [sh] Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86] Cc: Ian Campbell <icampbell@arcom.com> Cc: Tony Luck <tony.luck@intel.com> [ia64] Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64] Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r] Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k] Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc] Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc] Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390] Cc: Thomas Gleixner <tglx@linutronix.de> [x86] Cc: Ingo Molnar <mingo@redhat.com> [x86] Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2009-07-20 23:37:11 +04:00
echo ' Install using (your) ~/bin/$(INSTALLKERNEL) or'
echo ' (distribution) /sbin/$(INSTALLKERNEL) or'
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
echo ' install to $$(INSTALL_PATH) and run lilo'
ARM: 8332/1: add CONFIG_VDSO Kconfig and Makefile bits Allow users to enable the vdso in Kconfig; include the vdso in the build if CONFIG_VDSO is enabled. Add 'vdso_install' target. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-03-25 21:16:05 +03:00
echo ' vdso_install - Install unstripped vdso.so to $$(INSTALL_MOD_PATH)/vdso'
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
endef
Reference in New Issue Copy Permalink