kevin/linux
1
Fork 0
Code
7998df0b64
linux/arch/powerpc/Makefile

427 lines
14 KiB
Makefile
Raw Normal View History

powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
# This file is included by the global makefile so that you can add your own
kbuild: use more subdir- for visiting subdirectories while cleaning Documentation/kbuild/makefiles.rst suggests to use "archclean" for cleaning arch/$(SRCARCH)/boot/, but it is not a hard requirement. Since commit d92cc4d51643 ("kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild"), we can use the "subdir- += boot" trick for all architectures. This can take advantage of the parallel option (-j) for "make clean". I also cleaned up the comments in arch/$(SRCARCH)/Makefile. The "archdep" target no longer exists. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
2021-10-12 23:36:22 -07:00
# architecture-specific flags and dependencies.
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07: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) 1994 by Linus Torvalds
# Changes for PPC by Gary Thomas
# Rewritten by Cort Dougan and Paul Mackerras
#
powerpc/Makefile: Auto detect cross compiler If no cross compiler is specified, try to auto detect one. Look for various combinations, matching: powerpc(64(le)?)?(-unknown)?-linux(-gnu)?- There are more possibilities, but the above is known to find a compiler on Fedora and Ubuntu (which use linux-gnu-), and also detects the kernel.org cross compilers (which use linux-). This allows cross compiling with simply: # Ubuntu $ sudo apt install gcc-powerpc-linux-gnu # Fedora $ sudo dnf install gcc-powerpc64-linux-gnu $ make ARCH=powerpc defconfig $ make ARCH=powerpc -j 4 Inspired by arch/parisc/Makefile. Acked-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-4-mpe@ellerman.id.au
2023-12-06 04:55:48 -07:00
ifdef cross_compiling
ifeq ($(CROSS_COMPILE),)
# Auto detect cross compiler prefix.
# Look for: (powerpc(64(le)?)?)(-unknown)?-linux(-gnu)?-
CC_ARCHES := powerpc powerpc64 powerpc64le
CC_SUFFIXES := linux linux-gnu unknown-linux-gnu
CROSS_COMPILE := $(call cc-cross-prefix, $(foreach a,$(CC_ARCHES), \
$(foreach s,$(CC_SUFFIXES),$(a)-$(s)-)))
endif
endif
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
HAS_BIARCH := $(call cc-option-yn, -m32)
# Set default 32 bits cross compilers for vdso and boot wrapper
CROSS32_COMPILE ?=
powerpc: Fix defconfig choice logic when cross compiling Our logic for choosing defconfig doesn't work well in some situations. For example if you're on a ppc64le machine but you specify a non-empty CROSS_COMPILE, in order to use a non-default toolchain, then defconfig will give you ppc64_defconfig (big endian): $ make CROSS_COMPILE=~/toolchains/gcc-8/bin/powerpc-linux- defconfig *** Default configuration is based on 'ppc64_defconfig' This is because we assume that CROSS_COMPILE being set means we can't be on a ppc machine and rather than checking we just default to ppc64_defconfig. We should just ignore CROSS_COMPILE, instead check the machine with uname and if it's one of ppc, ppc64 or ppc64le then use that defconfig. If it's none of those then we fall back to ppc64_defconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-06 22:16:52 -07:00
# If we're on a ppc/ppc64/ppc64le machine use that defconfig, otherwise just use
powerpc/Makefile: Default to ppc64le_defconfig when cross building If the kernel is being cross compiled, there is no information from uname on which defconfig is most appropriate, so the Makefile defaults to ppc64. However these days almost all distros that support powerpc are little endian, so it's more likely that defaulting to ppc64le_defconfig will produce something useful for a user. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-3-mpe@ellerman.id.au
2023-12-06 04:55:47 -07:00
# ppc64le_defconfig because we have nothing better to go on.
powerpc: Fix defconfig choice logic when cross compiling Our logic for choosing defconfig doesn't work well in some situations. For example if you're on a ppc64le machine but you specify a non-empty CROSS_COMPILE, in order to use a non-default toolchain, then defconfig will give you ppc64_defconfig (big endian): $ make CROSS_COMPILE=~/toolchains/gcc-8/bin/powerpc-linux- defconfig *** Default configuration is based on 'ppc64_defconfig' This is because we assume that CROSS_COMPILE being set means we can't be on a ppc machine and rather than checking we just default to ppc64_defconfig. We should just ignore CROSS_COMPILE, instead check the machine with uname and if it's one of ppc, ppc64 or ppc64le then use that defconfig. If it's none of those then we fall back to ppc64_defconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-06 22:16:52 -07:00
uname := $(shell uname -m)
powerpc/Makefile: Default to ppc64le_defconfig when cross building If the kernel is being cross compiled, there is no information from uname on which defconfig is most appropriate, so the Makefile defaults to ppc64. However these days almost all distros that support powerpc are little endian, so it's more likely that defaulting to ppc64le_defconfig will produce something useful for a user. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-3-mpe@ellerman.id.au
2023-12-06 04:55:47 -07:00
KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64le)_defconfig
powerpc: Move defconfig over and remove remaining arch/ppc64 files make defconfig will now use arch/powerpc/configs/ppc64_defconfig if running on a ppc64 system. I need to add an arch/powerpc/configs/ppc_defconfig sometime. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-17 22:39:08 -07:00
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' > /dev/null; then echo y; else echo n; fi)
ifeq ($(new_nm),y)
NM := $(NM) --synthetic
endif
powerpc/Makefile: Drop CONFIG_WORD_SIZE for BITS Commit 2578bfae84a7 ("[POWERPC] Create and use CONFIG_WORD_SIZE") added CONFIG_WORD_SIZE, and suggests that other arches were going to do likewise. But that never happened, powerpc is the only architecture which uses it. So switch to using a simple make variable, BITS, like x86, sh, sparc and tile. It is also easier to spell and simpler, avoiding any confusion about whether it's defined due to ordering of make vs kconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-10 23:03:14 -07:00
# BITS is used as extension for files which are available in a 32 bit
# and a 64 bit version to simplify shared Makefiles.
# e.g.: obj-y += foo_$(BITS).o
export BITS
ifdef CONFIG_PPC64
BITS := 64
else
BITS := 32
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
endif
powerpc/Makefile: Construct the UTS_MACHINE value more concisely Use the standard Kbuild trick of foo-y to make the construction of UTC_MACHINE less verbose. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-10 23:03:15 -07:00
machine-y = ppc
machine-$(CONFIG_PPC64) += 64
machine-$(CONFIG_CPU_LITTLE_ENDIAN) += le
UTS_MACHINE := $(subst $(space),,$(machine-y))
powerpc: fix uname -m It will now give ppc64 on 64bit platforms and ppc on 32bit platforms. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
2005-10-12 23:14:15 -07:00
powerpc: remove checks for binutils older than 2.25 Commit e4412739472b ("Documentation: raise minimum supported version of binutils to 2.25") allows us to remove the checks for old binutils. There is no more user for ld-ifversion. Remove it as well. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230119082250.151485-1-masahiroy@kernel.org
2023-01-19 01:22:50 -07:00
ifeq ($(CONFIG_PPC64)$(CONFIG_LD_IS_BFD),yy)
powerpc/Makefile: Fix ld version check with 64-bit LE-only toolchain In commit efe0160cfd40 ("powerpc/64: Linker on-demand sfpr functions for modules"), we added an ld version check early in the powerpc top-level Makefile. Because the Makefile runs before the kernel config is setup, the checks for CONFIG_CPU_LITTLE_ENDIAN etc. all take the default case. So we end up configuring ld for 32-bit big endian. That would be OK, except that for historical (or perhaps no) reason, we use 'override LD' to add the endian flags to the LD variable itself, rather than the normal approach of adding them to LDFLAGS. The end result is that when we check the ld version we run it as: $(CROSS_COMPILE)ld -EB -m elf32ppc --version This often works, unless you are using a 64-bit only and/or little endian only, toolchain. In which case you see something like: $ make defconfig powerpc64le-linux-ld: unrecognised emulation mode: elf32ppc Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim /bin/sh: 1: [: -ge: unexpected operator The proper fix is to stop using 'override LD', but that will require a fair bit of testing. Instead we can fix it for now just by reordering the Makefile to do the version check earlier. Fixes: efe0160cfd40 ("powerpc/64: Linker on-demand sfpr functions for modules") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-25 22:00:42 -07:00
# Have the linker provide sfpr if possible.
# There is a corresponding test in arch/powerpc/lib/Makefile
KBUILD_LDFLAGS_MODULE += --save-restore-funcs
else
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
endif
powerpc/Makefiles: Convert ifeq to ifdef where possible In Makefiles if we're testing a CONFIG_FOO symbol for equality with 'y' we can instead just use ifdef. The latter reads easily, so convert to it where possible. Signed-off-by: Rodrigo R. Galvao <rosattig@linux.vnet.ibm.com> Reviewed-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 09:42:03 -07:00
ifdef CONFIG_CPU_LITTLE_ENDIAN
powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS The powerpc toolchain can compile combinations of 32/64 bit and big/little endian, so it's convenient to consider, e.g., `CC -m64 -mbig-endian` To be the C compiler for the purpose of invoking it to build target artifacts. So overriding the CC variable to include these flags works for this purpose. Unfortunately that is not compatible with the way the proposed new Kconfig macro language will work. After previous patches in this series, these flags can be carefully passed in using flags instead. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-30 05:19:21 -07:00
KBUILD_CFLAGS += -mlittle-endian
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-23 16:20:39 -07:00
KBUILD_LDFLAGS += -EL
powerpc: Add ability to build little endian kernels This patch allows the kbuild system to successfully compile a kernel for the little endian PowerPC64 architecture. A subsequent patch will add the CONFIG_CPU_LITTLE_ENDIAN kernel config option which must be set to build such a kernel. If cross compiling, CROSS_COMPILE must point to a suitable toolchain (compiled for the powerpc64le-linux and powerpcle-linux targets). Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-09-22 19:05:11 -07:00
LDEMULATION := lppc
GNUTARGET := powerpcle
MULTIPLEWORD := -mno-multiple
powerpc/le: Avoid creatng R_PPC64_TOCSAVE relocations for modules. When building modules with a native le toolchain the linker will generate R_PPC64_TOCSAVE relocations when it's safe to omit saving r2 on a plt call. This isn't helpful in the conext of a kernel module and the kernel will fail to load those modules with an error like: nf_conntrack: Unknown ADD relocation: 109 This patch tells the linker to avoid createing R_PPC64_TOCSAVE relocations allowing modules to load. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-03-11 21:12:01 -07:00
KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
powerpc: Add ability to build little endian kernels This patch allows the kbuild system to successfully compile a kernel for the little endian PowerPC64 architecture. A subsequent patch will add the CONFIG_CPU_LITTLE_ENDIAN kernel config option which must be set to build such a kernel. If cross compiling, CROSS_COMPILE must point to a suitable toolchain (compiled for the powerpc64le-linux and powerpcle-linux targets). Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-09-22 19:05:11 -07:00
else
powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS The powerpc toolchain can compile combinations of 32/64 bit and big/little endian, so it's convenient to consider, e.g., `CC -m64 -mbig-endian` To be the C compiler for the purpose of invoking it to build target artifacts. So overriding the CC variable to include these flags works for this purpose. Unfortunately that is not compatible with the way the proposed new Kconfig macro language will work. After previous patches in this series, these flags can be carefully passed in using flags instead. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-30 05:19:21 -07:00
KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
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-23 16:20:39 -07:00
KBUILD_LDFLAGS += -EB
powerpc: Add ability to build little endian kernels This patch allows the kbuild system to successfully compile a kernel for the little endian PowerPC64 architecture. A subsequent patch will add the CONFIG_CPU_LITTLE_ENDIAN kernel config option which must be set to build such a kernel. If cross compiling, CROSS_COMPILE must point to a suitable toolchain (compiled for the powerpc64le-linux and powerpcle-linux targets). Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-09-22 19:05:11 -07:00
LDEMULATION := ppc
GNUTARGET := powerpc
MULTIPLEWORD := -mmultiple
endif
powerpc: Fix compiling a BE kernel with a powerpc64le toolchain GCC can compile with either endian, but the default ABI version is set based on the default endianness of the toolchain. Alan Modra says: you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc generate powerpc64 code The opposite is true for powerpc64 when generating -mlittle it requires -mabi=elfv2 to generate v2 ABI, which we were already doing. This change adds ABI annotations together with endianness for all cases, LE and BE. This fixes the case of building a BE kernel with a toolchain that is LE by default. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-26 19:46:20 -07:00
ifdef CONFIG_PPC64
powerpc: Don't add -mabi= flags when building with Clang When building pseries_defconfig, building vdso32 errors out: error: unknown target ABI 'elfv1' This happens because -m32 in clang changes the target to 32-bit, which does not allow the ABI to be changed. Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a powerpc64le toolchain") added these flags to fix building big endian kernels with a little endian GCC. Clang doesn't need -mabi because the target triple controls the default value. -mlittle-endian and -mbig-endian manipulate the triple into either powerpc64-* or powerpc64le-*, which properly sets the default ABI. Adding a debug print out in the PPC64TargetInfo constructor after line 383 above shows this: $ echo | ./clang -E --target=powerpc64-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 $ echo | ./clang -E --target=powerpc64le-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64le-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 Don't specify -mabi when building with clang to avoid the build error with -m32 and not change any code generation. -mcall-aixdesc is not an implemented flag in clang so it can be safely excluded as well, see commit 238abecde8ad ("powerpc: Don't use gcc specific options on clang"). pseries_defconfig successfully builds after this patch and powernv_defconfig and ppc44x_defconfig don't regress. Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> [mpe: Trim clang links in change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191119045712.39633-2-natechancellor@gmail.com
2019-11-18 21:57:10 -07:00
ifndef CONFIG_CC_IS_CLANG
powerpc: Add CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2 At the time being, we use CONFIG_CPU_LITTLE_ENDIAN and CONFIG_CPU_BIG_ENDIAN to pass -mabi=elfv1 or elfv2 to compiler, then define a PPC64_ELF_ABI_v1 or PPC64_ELF_ABI_v2 macro in asm/types.h based on _CALL_ELF define set by the compiler. Make it more straight forward with a CONFIG option that is directly usable. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1eca1addbc550167da9841c7340a010d0c4b2200.1652074503.git.christophe.leroy@csgroup.eu
2022-05-08 22:36:06 -07:00
cflags-$(CONFIG_PPC64_ELF_ABI_V1) += $(call cc-option,-mabi=elfv1)
cflags-$(CONFIG_PPC64_ELF_ABI_V1) += $(call cc-option,-mcall-aixdesc)
aflags-$(CONFIG_PPC64_ELF_ABI_V1) += $(call cc-option,-mabi=elfv1)
aflags-$(CONFIG_PPC64_ELF_ABI_V2) += -mabi=elfv2
powerpc: Fix compiling a BE kernel with a powerpc64le toolchain GCC can compile with either endian, but the default ABI version is set based on the default endianness of the toolchain. Alan Modra says: you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc generate powerpc64 code The opposite is true for powerpc64 when generating -mlittle it requires -mabi=elfv2 to generate v2 ABI, which we were already doing. This change adds ABI annotations together with endianness for all cases, LE and BE. This fixes the case of building a BE kernel with a toolchain that is LE by default. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-26 19:46:20 -07:00
endif
powerpc: Don't add -mabi= flags when building with Clang When building pseries_defconfig, building vdso32 errors out: error: unknown target ABI 'elfv1' This happens because -m32 in clang changes the target to 32-bit, which does not allow the ABI to be changed. Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a powerpc64le toolchain") added these flags to fix building big endian kernels with a little endian GCC. Clang doesn't need -mabi because the target triple controls the default value. -mlittle-endian and -mbig-endian manipulate the triple into either powerpc64-* or powerpc64le-*, which properly sets the default ABI. Adding a debug print out in the PPC64TargetInfo constructor after line 383 above shows this: $ echo | ./clang -E --target=powerpc64-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 $ echo | ./clang -E --target=powerpc64le-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64le-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 Don't specify -mabi when building with clang to avoid the build error with -m32 and not change any code generation. -mcall-aixdesc is not an implemented flag in clang so it can be safely excluded as well, see commit 238abecde8ad ("powerpc: Don't use gcc specific options on clang"). pseries_defconfig successfully builds after this patch and powernv_defconfig and ppc44x_defconfig don't regress. Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> [mpe: Trim clang links in change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191119045712.39633-2-natechancellor@gmail.com
2019-11-18 21:57:10 -07:00
endif
powerpc: Fix compiling a BE kernel with a powerpc64le toolchain GCC can compile with either endian, but the default ABI version is set based on the default endianness of the toolchain. Alan Modra says: you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc generate powerpc64 code The opposite is true for powerpc64 when generating -mlittle it requires -mabi=elfv2 to generate v2 ABI, which we were already doing. This change adds ABI annotations together with endianness for all cases, LE and BE. This fixes the case of building a BE kernel with a toolchain that is LE by default. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-26 19:46:20 -07:00
kbuild: replace cc-name test with CONFIG_CC_IS_CLANG Evaluating cc-name invokes the compiler every time even when you are not compiling anything, like 'make help'. This is not efficient. The compiler type has been already detected in the Kconfig stage. Use CONFIG_CC_IS_CLANG, instead. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Paul Burton <paul.burton@mips.com> (MIPS) Acked-by: Joel Stanley <joel@jms.id.au>
2018-10-30 06:26:33 -07:00
ifndef CONFIG_CC_IS_CLANG
powerpc/Makefile: Use cflags-y/aflags-y for setting endian options When we introduced the little endian support, we added the endian flags to CC directly using override. I don't know the history of why we did that, I suspect no one does. Although this mostly works, it has one bug, which is that CROSS32CC doesn't get -mbig-endian. That means when the compiler is little endian by default and the user is building big endian, vdso32 is incorrectly compiled as little endian and the kernel fails to build. Instead we can add the endian flags to cflags-y/aflags-y, and then append those to KBUILD_CFLAGS/KBUILD_AFLAGS. This has the advantage of being 1) less ugly, 2) the documented way of adding flags in the arch Makefile and 3) it fixes building vdso32 with a LE toolchain. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-09 05:43:46 -07:00
cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align
endif
powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS The powerpc toolchain can compile combinations of 32/64 bit and big/little endian, so it's convenient to consider, e.g., `CC -m64 -mbig-endian` To be the C compiler for the purpose of invoking it to build target artifacts. So overriding the CC variable to include these flags works for this purpose. Unfortunately that is not compatible with the way the proposed new Kconfig macro language will work. After previous patches in this series, these flags can be carefully passed in using flags instead. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-30 05:19:21 -07:00
cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
powerpc/Makefile: Use cflags-y/aflags-y for setting endian options When we introduced the little endian support, we added the endian flags to CC directly using override. I don't know the history of why we did that, I suspect no one does. Although this mostly works, it has one bug, which is that CROSS32CC doesn't get -mbig-endian. That means when the compiler is little endian by default and the user is building big endian, vdso32 is incorrectly compiled as little endian and the kernel fails to build. Instead we can add the endian flags to cflags-y/aflags-y, and then append those to KBUILD_CFLAGS/KBUILD_AFLAGS. This has the advantage of being 1) less ugly, 2) the documented way of adding flags in the arch Makefile and 3) it fixes building vdso32 with a LE toolchain. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-09 05:43:46 -07:00
aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
ifeq ($(HAS_BIARCH),y)
powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS The powerpc toolchain can compile combinations of 32/64 bit and big/little endian, so it's convenient to consider, e.g., `CC -m64 -mbig-endian` To be the C compiler for the purpose of invoking it to build target artifacts. So overriding the CC variable to include these flags works for this purpose. Unfortunately that is not compatible with the way the proposed new Kconfig macro language will work. After previous patches in this series, these flags can be carefully passed in using flags instead. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-30 05:19:21 -07:00
KBUILD_CFLAGS += -m$(BITS)
powerpc: Remove linker flag from KBUILD_AFLAGS When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it points out that KBUILD_AFLAGS contains a linker flag, which will be unused: clang: error: -Wl,-a32: 'linker' input unused [-Werror,-Wunused-command-line-argument] This was likely supposed to be '-Wa,-a$(BITS)'. However, this change is unnecessary, as all supported versions of clang and gcc will pass '-a64' or '-a32' to GNU as based on the value of '-m'; the behavior of the latest stable release of the oldest supported major version of each compiler is shown below and each compiler's latest release exhibits the same behavior (GCC 12.2.0 and Clang 15.0.6). $ powerpc64-linux-gcc --version | head -1 powerpc64-linux-gcc (GCC) 5.5.0 $ powerpc64-linux-gcc -m64 -### -x assembler-with-cpp -c -o /dev/null /dev/null &| grep 'as ' .../as -a64 -mppc64 -many -mbig -o /dev/null /tmp/cctwuBzZ.s $ powerpc64-linux-gcc -m32 -### -x assembler-with-cpp -c -o /dev/null /dev/null &| grep 'as ' .../as -a32 -mppc -many -mbig -o /dev/null /tmp/ccaZP4mF.sg $ clang --version | head -1 Ubuntu clang version 11.1.0-++20211011094159+1fdec59bffc1-1~exp1~20211011214622.5 $ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \ -x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as "/usr/bin/powerpc64-linux-gnu-as" "-a64" "-mppc64" "-many" "-o" "/dev/null" "/tmp/null-80267c.s" $ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \ -x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as "/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "/dev/null" "/tmp/null-ab8f8d.s" Remove this flag altogether to avoid future issues. Fixes: 1421dc6d4829 ("powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-01-11 20:05:02 -07:00
KBUILD_AFLAGS += -m$(BITS)
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-23 16:20:39 -07:00
KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
endif
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard=tls
powerpc/64: add stack protector support On PPC64, as register r13 points to the paca_struct at all time, this patch adds a copy of the canary there, which is copied at task_switch. That new canary is then used by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r13 -mstack-protector-guard-offset=offsetof(struct paca_struct, canary)) Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:55 -07:00
ifdef CONFIG_PPC64
cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard-reg=r13
else
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard-reg=r2
powerpc/64: add stack protector support On PPC64, as register r13 points to the paca_struct at all time, this patch adds a copy of the canary there, which is copied at task_switch. That new canary is then used by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r13 -mstack-protector-guard-offset=offsetof(struct paca_struct, canary)) Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:55 -07:00
endif
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
powerpc: Process dynamic relocations for kernel The following patch implements the dynamic relocation processing for PPC32 kernel. relocate() accepts the target virtual address and relocates the kernel image to the same. Currently the following relocation types are handled : R_PPC_RELATIVE R_PPC_ADDR16_LO R_PPC_ADDR16_HI R_PPC_ADDR16_HA The last 3 relocations in the above list depends on value of Symbol indexed whose index is encoded in the Relocation entry. Hence we need the Symbol Table for processing such relocations. Note: The GNU ld for ppc32 produces buggy relocations for relocation types that depend on symbols. The value of the symbols with STB_LOCAL scope should be assumed to be zero. - Alan Modra Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Josh Poimboeuf <jpoimboe@linux.vnet.ibm.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alan Modra <amodra@au1.ibm.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-14 15:58:12 -07:00
LDFLAGS_vmlinux-y := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
powerpc: Add "-z notext" flag to disable diagnostic Object files used to link .tmp_vmlinux.kallsyms1 have many R_PPC64_ADDR64 relocations in non-SHF_WRITE sections. There are many text relocations (e.g. in .rela___ksymtab_gpl+* and .rela__mcount_loc sections) in a -pie link and are disallowed by LLD: ld.lld: error: can't create dynamic relocation R_PPC64_ADDR64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in arch/powerpc/kernel/head_64.o >>> referenced by arch/powerpc/kernel/head_64.o:(__restart_table+0x10) Newer GNU ld configured with "--enable-textrel-check=error" will report an error as well: $ ld-new -EL -m elf64lppc -pie ... -o .tmp_vmlinux.kallsyms1 ... ld-new: read-only segment has dynamic relocations Add "-z notext" to suppress the errors. Non-CONFIG_RELOCATABLE builds use the default -no-pie mode and thus R_PPC64_ADDR64 relocations can be resolved at link-time. Reported-by: Itaru Kitayama <itaru.kitayama@riken.jp> Co-developed-by: Bill Wendling <morbo@google.com> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Bill Wendling <morbo@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210813200511.1905703-1-morbo@google.com
2021-08-13 13:05:11 -07:00
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) += -z notext
powerpc: Process dynamic relocations for kernel The following patch implements the dynamic relocation processing for PPC32 kernel. relocate() accepts the target virtual address and relocates the kernel image to the same. Currently the following relocation types are handled : R_PPC_RELATIVE R_PPC_ADDR16_LO R_PPC_ADDR16_HI R_PPC_ADDR16_HA The last 3 relocations in the above list depends on value of Symbol indexed whose index is encoded in the Relocation entry. Hence we need the Symbol Table for processing such relocations. Note: The GNU ld for ppc32 produces buggy relocations for relocation types that depend on symbols. The value of the symbols with STB_LOCAL scope should be assumed to be zero. - Alan Modra Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Josh Poimboeuf <jpoimboe@linux.vnet.ibm.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Alan Modra <amodra@au1.ibm.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-14 15:58:12 -07:00
LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc/Makefiles: Convert ifeq to ifdef where possible In Makefiles if we're testing a CONFIG_FOO symbol for equality with 'y' we can instead just use ifdef. The latter reads easily, so convert to it where possible. Signed-off-by: Rodrigo R. Galvao <rosattig@linux.vnet.ibm.com> Reviewed-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 09:42:03 -07:00
ifdef CONFIG_PPC64
powerpc/64: modules support building with PCREL addresing Build modules using PCREL addressing when CONFIG_PPC_KERNEL_PCREL=y. - The module loader must handle several new relocation types: * R_PPC64_REL24_NOTOC is a function call handled like R_PPC_REL24, but does not restore r2 upon return. The external function call stub is changed to use pcrel addressing to load the function pointer rather than based on the module TOC. * R_PPC64_GOT_PCREL34 is a reference to external data. A GOT table must be built by hand, because the linker adds this during the final link (which is not done for kernel modules). The GOT table is built similarly to the way the external function call stub table is. This section is called .mygot because .got has a special meaning for the linker and can become upset. * R_PPC64_PCREL34 is used for local data addressing, but there is a special case where the percpu section is moved at load-time to the percpu area which is out of range of this relocation. This requires the PCREL34 relocations are converted to use GOT_PCREL34 addressing. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Some coding style & formatting fixups] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-7-npiggin@gmail.com
2023-04-07 19:17:52 -07:00
ifndef CONFIG_PPC_KERNEL_PCREL
powerpc: Build kernel with -mcmodel=medium Finally remove the two level TOC and build with -mcmodel=medium. Unfortunately we can't build modules with -mcmodel=medium due to the tricks the kernel module loader plays with percpu data: # -mcmodel=medium breaks modules because it uses 32bit offsets from # the TOC pointer to create pointers where possible. Pointers into the # percpu data area are created by this method. # # The kernel module loader relocates the percpu data section from the # original location (starting with 0xd...) to somewhere in the base # kernel percpu data space (starting with 0xc...). We need a full # 64bit relocation for this to work, hence -mcmodel=large. On older kernels we fall back to the two level TOC (-mminimal-toc) Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-11-26 10:41:08 -07:00
ifeq ($(call cc-option-yn,-mcmodel=medium),y)
# -mcmodel=medium breaks modules because it uses 32bit offsets from
# the TOC pointer to create pointers where possible. Pointers into the
# percpu data area are created by this method.
#
# The kernel module loader relocates the percpu data section from the
# original location (starting with 0xd...) to somewhere in the base
# kernel percpu data space (starting with 0xc...). We need a full
# 64bit relocation for this to work, hence -mcmodel=large.
KBUILD_CFLAGS_MODULE += -mcmodel=large
else
export NO_MINIMAL_TOC := -mno-minimal-toc
endif
endif
powerpc/64: modules support building with PCREL addresing Build modules using PCREL addressing when CONFIG_PPC_KERNEL_PCREL=y. - The module loader must handle several new relocation types: * R_PPC64_REL24_NOTOC is a function call handled like R_PPC_REL24, but does not restore r2 upon return. The external function call stub is changed to use pcrel addressing to load the function pointer rather than based on the module TOC. * R_PPC64_GOT_PCREL34 is a reference to external data. A GOT table must be built by hand, because the linker adds this during the final link (which is not done for kernel modules). The GOT table is built similarly to the way the external function call stub table is. This section is called .mygot because .got has a special meaning for the linker and can become upset. * R_PPC64_PCREL34 is used for local data addressing, but there is a special case where the percpu section is moved at load-time to the percpu area which is out of range of this relocation. This requires the PCREL34 relocations are converted to use GOT_PCREL34 addressing. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Some coding style & formatting fixups] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-7-npiggin@gmail.com
2023-04-07 19:17:52 -07:00
endif
powerpc: Build kernel with -mcmodel=medium Finally remove the two level TOC and build with -mcmodel=medium. Unfortunately we can't build modules with -mcmodel=medium due to the tricks the kernel module loader plays with percpu data: # -mcmodel=medium breaks modules because it uses 32bit offsets from # the TOC pointer to create pointers where possible. Pointers into the # percpu data area are created by this method. # # The kernel module loader relocates the percpu data section from the # original location (starting with 0xd...) to somewhere in the base # kernel percpu data space (starting with 0xc...). We need a full # 64bit relocation for this to work, hence -mcmodel=large. On older kernels we fall back to the two level TOC (-mminimal-toc) Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-11-26 10:41:08 -07:00
powerpc: Only use -mtraceback=no, -mno-string and -msoft-float if toolchain supports it These options are not recognised on LLVM, so use call cc-option to check for support. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-25 15:53:27 -07:00
CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
powerpc: Add CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2 At the time being, we use CONFIG_CPU_LITTLE_ENDIAN and CONFIG_CPU_BIG_ENDIAN to pass -mabi=elfv1 or elfv2 to compiler, then define a PPC64_ELF_ABI_v1 or PPC64_ELF_ABI_v2 macro in asm/types.h based on _CALL_ELF define set by the compiler. Make it more straight forward with a CONFIG option that is directly usable. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1eca1addbc550167da9841c7340a010d0c4b2200.1652074503.git.christophe.leroy@csgroup.eu
2022-05-08 22:36:06 -07:00
ifdef CONFIG_PPC64_ELF_ABI_V2
powerpc: Don't use gcc specific options on clang We have code to choose between several options, eg. -mabi=elfv2 vs -mcall-aixdesc, and -mcmodel=medium vs -mminimal-toc. But these are all GCC specific, so use cc-option on all of them. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-25 15:53:29 -07:00
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
powerpc: Build little endian ppc64 kernel with ABIv2 Build the little endian ppc64 kernel with ABIv2 if the toolchain supports it. We can identify an ABIv2 capable toolchain by the -mabi=elfv2 compiler flag. Signed-off-by: Anton Blanchard <anton@samba.org>
2014-03-10 03:06:12 -07:00
else
powerpc: Fix use of '-mabi=elfv2' with clang '-mabi=elfv2' is not added to clang's invocations when CONFIG_PPC64_ELF_ABI_V2 is enabled, resulting in the generation of elfv1 code, as evidenced by the orphan section warnings/errors: ld.lld: error: vmlinux.a(arch/powerpc/kernel/prom_init.o):(.opd) is being placed in '.opd' ld.lld: error: vmlinux.a(init/main.o):(.opd) is being placed in '.opd' ld.lld: error: vmlinux.a(init/version.o):(.opd) is being placed in '.opd' To resolve this, add '-mabi=elfv2' to CFLAGS with clang. This uncovers an issue in the 32-bit vDSO: error: unknown target ABI 'elfv2' The ELFv2 ABI cannot be used when building code for a 32-bit target. To resolve this, just remove the '-mabi' flags from the assembler flags, as it was only needed for preprocessing (the _CALL_ELF macro) but this was cleaned up in commit 5b89492c03e5 ("powerpc: Finalise cleanup around ABI use"). Tested-by: "Erhard F." <erhard_f@mailbox.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230118-ppc64-elfv2-llvm-v1-2-b9e2ec9da11d@kernel.org
2023-02-15 11:41:16 -07:00
ifndef CONFIG_CC_IS_CLANG
powerpc: Fix compiling a BE kernel with a powerpc64le toolchain GCC can compile with either endian, but the default ABI version is set based on the default endianness of the toolchain. Alan Modra says: you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc generate powerpc64 code The opposite is true for powerpc64 when generating -mlittle it requires -mabi=elfv2 to generate v2 ABI, which we were already doing. This change adds ABI annotations together with endianness for all cases, LE and BE. This fixes the case of building a BE kernel with a toolchain that is LE by default. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-26 19:46:20 -07:00
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
powerpc: Don't use gcc specific options on clang We have code to choose between several options, eg. -mabi=elfv2 vs -mcall-aixdesc, and -mcmodel=medium vs -mminimal-toc. But these are all GCC specific, so use cc-option on all of them. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-25 15:53:29 -07:00
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
powerpc: Build little endian ppc64 kernel with ABIv2 Build the little endian ppc64 kernel with ABIv2 if the toolchain supports it. We can identify an ABIv2 capable toolchain by the -mabi=elfv2 compiler flag. Signed-off-by: Anton Blanchard <anton@samba.org>
2014-03-10 03:06:12 -07:00
endif
powerpc: Don't add -mabi= flags when building with Clang When building pseries_defconfig, building vdso32 errors out: error: unknown target ABI 'elfv1' This happens because -m32 in clang changes the target to 32-bit, which does not allow the ABI to be changed. Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a powerpc64le toolchain") added these flags to fix building big endian kernels with a little endian GCC. Clang doesn't need -mabi because the target triple controls the default value. -mlittle-endian and -mbig-endian manipulate the triple into either powerpc64-* or powerpc64le-*, which properly sets the default ABI. Adding a debug print out in the PPC64TargetInfo constructor after line 383 above shows this: $ echo | ./clang -E --target=powerpc64-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 $ echo | ./clang -E --target=powerpc64le-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64le-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 Don't specify -mabi when building with clang to avoid the build error with -m32 and not change any code generation. -mcall-aixdesc is not an implemented flag in clang so it can be safely excluded as well, see commit 238abecde8ad ("powerpc: Don't use gcc specific options on clang"). pseries_defconfig successfully builds after this patch and powernv_defconfig and ppc44x_defconfig don't regress. Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> [mpe: Trim clang links in change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191119045712.39633-2-natechancellor@gmail.com
2019-11-18 21:57:10 -07:00
endif
powerpc: Don't use gcc specific options on clang We have code to choose between several options, eg. -mabi=elfv2 vs -mcall-aixdesc, and -mcmodel=medium vs -mminimal-toc. But these are all GCC specific, so use cc-option on all of them. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-25 15:53:29 -07:00
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc))
powerpc: Avoid load of static chain register when calling nested functions through a pointer on 64bit The ppc64 ABI has a static chain register (r11) which is only used when calling nested functions through a pointer. Considering that we take a dim view of nested functions in the kernel, we have a lot of unnecessary overhead here. gcc 4.7 has an option to disable loading of r11 so lets use it. If hell freezes over and hipsters manage to litter the kernel with nested functions, gcc will give us an error message and won't simply compile bad code: You cannot take the address of a nested function if you use the -mno-pointers-to-nested-functions option. Furthermore our kernel module trampolines don't setup the static chain register so adding this option and forcing gcc to error out makes even more sense. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-12-12 07:43:12 -07:00
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
powerpc/64: Always build with 128-bit long double The amdgpu driver builds some of its code with hard-float enabled, whereas the rest of the kernel is built with soft-float. When building with 64-bit long double, if soft-float and hard-float objects are linked together, the build fails due to incompatible ABI tags. In the past there have been build errors in the amdgpu driver caused by this, some of those were due to bad intermingling of soft & hard-float code, but those issues have now all been fixed since commit 58ddbecb14c7 ("drm/amd/display: move remaining FPU code to dml folder"). However it's still possible for soft & hard-float objects to end up linked together, if the amdgpu driver is built-in to the kernel along with the test_emulate_step.c code, which uses soft-float. That happens in an allyesconfig build. Currently those build errors are avoided because the amdgpu driver is gated on 128-bit long double being enabled. But that's not a detail the amdgpu driver should need to be aware of, and if another driver starts using hard-float the same problem would occur. All versions of the 64-bit ABI specify that long-double is 128-bits. However some compilers, notably the kernel.org ones, are built to use 64-bit long double by default. Apart from this issue of soft vs hard-float, the kernel doesn't care what size long double is. In particular the kernel using 128-bit long double doesn't impact userspace's ability to use 64-bit long double, as musl does. So always build the 64-bit kernel with 128-bit long double. That should avoid any build errors due to the incompatible ABI tags. Excluding the code that uses soft/hard-float, the vmlinux is identical with/without the flag. It does mean any code which is incorrectly intermingling soft & hard-float code will build without error, so those bugs will need to be caught by testing rather than at build time. For more background see: - commit d11219ad53dc ("amdgpu: disable powerpc support for the newer display engine") - commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc") - https://lore.kernel.org/r/dab9cbd8-2626-4b99-8098-31fe76397d2d@app.fastmail.com Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Link: https://msgid.link/20230404102847.3303623-1-mpe@ellerman.id.au
2023-04-04 03:28:47 -07:00
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mlong-double-128)
powerpc: Keep const vars out of writable .sdata Newer gcc will support "-mno-readonly-in-sdata"[1], which makes sure that the optimization on PPC32 for variables getting moved into the .sdata section will not apply to const variables (which must be in .rodata). This was originally noticed in mm/rodata_test.c when rodata_test_data was not static: c0695034 g O .data 00000004 rodata_test_data After this patch with an updated compiler, this is correctly in .rodata. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411 Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-28 18:02:49 -07:00
powerpc/32: Avoid unsupported flags with clang When building for ppc32 with clang these flags are unsupported: -ffixed-r2 and -mmultiple llvm's lib/Target/PowerPC/PPCRegisterInfo.cpp marks r2 as reserved on when building for SVR4ABI and !ppc64: // The SVR4 ABI reserves r2 and r13 if (Subtarget.isSVR4ABI()) { // We only reserve r2 if we need to use the TOC pointer. If we have no // explicit uses of the TOC pointer (meaning we're a leaf function with // no constant-pool loads, etc.) and we have no potential uses inside an // inline asm block, then we can treat r2 has an ordinary callee-saved // register. const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>(); if (!TM.isPPC64() || FuncInfo->usesTOCBasePtr() || MF.hasInlineAsm()) markSuperRegs(Reserved, PPC::R2); // System-reserved register markSuperRegs(Reserved, PPC::R13); // Small Data Area pointer register } This means we can safely omit -ffixed-r2 when building for 32-bit targets. The -mmultiple/-mno-multiple flags are not supported by clang, so platforms that might support multiple miss out on using multiple word instructions. We wrap these flags in cc-option so that when Clang gains support the kernel will be able use these flags. Clang 8 can then build a ppc44x_defconfig which boots in Qemu: make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- ppc44x_defconfig ./scripts/config -e CONFIG_DEVTMPFS -d DEVTMPFS_MOUNT make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- qemu-system-ppc -M bamboo \ -kernel arch/powerpc/boot/zImage \ -dtb arch/powerpc/boot/dts/bamboo.dtb \ -initrd ~/ppc32-440-rootfs.cpio \ -nographic -serial stdio -monitor pty -append "console=ttyS0" Link: https://github.com/ClangBuiltLinux/linux/issues/261 Link: https://bugs.llvm.org/show_bug.cgi?id=39556 Link: https://bugs.llvm.org/show_bug.cgi?id=39555 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-11 22:28:06 -07:00
# Clang unconditionally reserves r2 on ppc32 and does not support the flag
treewide: update LLVM Bugzilla links LLVM moved their issue tracker from their own Bugzilla instance to GitHub issues. While all of the links are still valid, they may not necessarily show the most up to date information around the issues, as all updates will occur on GitHub, not Bugzilla. Another complication is that the Bugzilla issue number is not always the same as the GitHub issue number. Thankfully, LLVM maintains this mapping through two shortlinks: https://llvm.org/bz<num> -> https://bugs.llvm.org/show_bug.cgi?id=<num> https://llvm.org/pr<num> -> https://github.com/llvm/llvm-project/issues/<mapped_num> Switch all "https://bugs.llvm.org/show_bug.cgi?id=<num>" links to the "https://llvm.org/pr<num>" shortlink so that the links show the most up to date information. Each migrated issue links back to the Bugzilla entry, so there should be no loss of fidelity of information here. Link: https://lkml.kernel.org/r/20240109-update-llvm-links-v1-3-eb09b59db071@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Fangrui Song <maskray@google.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Mykola Lysenko <mykolal@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-09 15:16:31 -07:00
# https://llvm.org/pr39555
powerpc/32: Avoid unsupported flags with clang When building for ppc32 with clang these flags are unsupported: -ffixed-r2 and -mmultiple llvm's lib/Target/PowerPC/PPCRegisterInfo.cpp marks r2 as reserved on when building for SVR4ABI and !ppc64: // The SVR4 ABI reserves r2 and r13 if (Subtarget.isSVR4ABI()) { // We only reserve r2 if we need to use the TOC pointer. If we have no // explicit uses of the TOC pointer (meaning we're a leaf function with // no constant-pool loads, etc.) and we have no potential uses inside an // inline asm block, then we can treat r2 has an ordinary callee-saved // register. const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>(); if (!TM.isPPC64() || FuncInfo->usesTOCBasePtr() || MF.hasInlineAsm()) markSuperRegs(Reserved, PPC::R2); // System-reserved register markSuperRegs(Reserved, PPC::R13); // Small Data Area pointer register } This means we can safely omit -ffixed-r2 when building for 32-bit targets. The -mmultiple/-mno-multiple flags are not supported by clang, so platforms that might support multiple miss out on using multiple word instructions. We wrap these flags in cc-option so that when Clang gains support the kernel will be able use these flags. Clang 8 can then build a ppc44x_defconfig which boots in Qemu: make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- ppc44x_defconfig ./scripts/config -e CONFIG_DEVTMPFS -d DEVTMPFS_MOUNT make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- qemu-system-ppc -M bamboo \ -kernel arch/powerpc/boot/zImage \ -dtb arch/powerpc/boot/dts/bamboo.dtb \ -initrd ~/ppc32-440-rootfs.cpio \ -nographic -serial stdio -monitor pty -append "console=ttyS0" Link: https://github.com/ClangBuiltLinux/linux/issues/261 Link: https://bugs.llvm.org/show_bug.cgi?id=39556 Link: https://bugs.llvm.org/show_bug.cgi?id=39555 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-11 22:28:06 -07:00
CFLAGS-$(CONFIG_PPC32) := $(call cc-option, -ffixed-r2)
# Clang doesn't support -mmultiple / -mno-multiple
treewide: update LLVM Bugzilla links LLVM moved their issue tracker from their own Bugzilla instance to GitHub issues. While all of the links are still valid, they may not necessarily show the most up to date information around the issues, as all updates will occur on GitHub, not Bugzilla. Another complication is that the Bugzilla issue number is not always the same as the GitHub issue number. Thankfully, LLVM maintains this mapping through two shortlinks: https://llvm.org/bz<num> -> https://bugs.llvm.org/show_bug.cgi?id=<num> https://llvm.org/pr<num> -> https://github.com/llvm/llvm-project/issues/<mapped_num> Switch all "https://bugs.llvm.org/show_bug.cgi?id=<num>" links to the "https://llvm.org/pr<num>" shortlink so that the links show the most up to date information. Each migrated issue links back to the Bugzilla entry, so there should be no loss of fidelity of information here. Link: https://lkml.kernel.org/r/20240109-update-llvm-links-v1-3-eb09b59db071@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Fangrui Song <maskray@google.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Mykola Lysenko <mykolal@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-09 15:16:31 -07:00
# https://llvm.org/pr39556
powerpc/32: Avoid unsupported flags with clang When building for ppc32 with clang these flags are unsupported: -ffixed-r2 and -mmultiple llvm's lib/Target/PowerPC/PPCRegisterInfo.cpp marks r2 as reserved on when building for SVR4ABI and !ppc64: // The SVR4 ABI reserves r2 and r13 if (Subtarget.isSVR4ABI()) { // We only reserve r2 if we need to use the TOC pointer. If we have no // explicit uses of the TOC pointer (meaning we're a leaf function with // no constant-pool loads, etc.) and we have no potential uses inside an // inline asm block, then we can treat r2 has an ordinary callee-saved // register. const PPCFunctionInfo *FuncInfo = MF.getInfo<PPCFunctionInfo>(); if (!TM.isPPC64() || FuncInfo->usesTOCBasePtr() || MF.hasInlineAsm()) markSuperRegs(Reserved, PPC::R2); // System-reserved register markSuperRegs(Reserved, PPC::R13); // Small Data Area pointer register } This means we can safely omit -ffixed-r2 when building for 32-bit targets. The -mmultiple/-mno-multiple flags are not supported by clang, so platforms that might support multiple miss out on using multiple word instructions. We wrap these flags in cc-option so that when Clang gains support the kernel will be able use these flags. Clang 8 can then build a ppc44x_defconfig which boots in Qemu: make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- ppc44x_defconfig ./scripts/config -e CONFIG_DEVTMPFS -d DEVTMPFS_MOUNT make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- qemu-system-ppc -M bamboo \ -kernel arch/powerpc/boot/zImage \ -dtb arch/powerpc/boot/dts/bamboo.dtb \ -initrd ~/ppc32-440-rootfs.cpio \ -nographic -serial stdio -monitor pty -append "console=ttyS0" Link: https://github.com/ClangBuiltLinux/linux/issues/261 Link: https://bugs.llvm.org/show_bug.cgi?id=39556 Link: https://bugs.llvm.org/show_bug.cgi?id=39555 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-11 22:28:06 -07:00
CFLAGS-$(CONFIG_PPC32) += $(call cc-option, $(MULTIPLEWORD))
powerpc: Keep const vars out of writable .sdata Newer gcc will support "-mno-readonly-in-sdata"[1], which makes sure that the optimization on PPC32 for variables getting moved into the .sdata section will not apply to const variables (which must be in .rodata). This was originally noticed in mm/rodata_test.c when rodata_test_data was not static: c0695034 g O .data 00000004 rodata_test_data After this patch with an updated compiler, this is correctly in .rodata. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411 Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-02-28 18:02:49 -07:00
CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
powerpc: Add 64-bit CPU targets for gcc Add a menu to select various 64-bit CPU targets for gcc. We default to -mtune=power7 and if gcc doesn't understand that we fallback to -mtune=power4. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-04-17 11:45:28 -07:00
powerpc: consolidate -mno-sched-epilog into FTRACE flags Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-13 22:08:53 -07:00
ifdef CONFIG_FUNCTION_TRACER
powerpc/ftrace: Add support for -fpatchable-function-entry GCC v13.1 updated support for -fpatchable-function-entry on ppc64le to emit nops after the local entry point, rather than before it. This allows us to use this in the kernel for ftrace purposes. A new script is added under arch/powerpc/tools/ to help detect if nops are emitted after the function local entry point, or before the global entry point. With -fpatchable-function-entry, we no longer have the profiling instructions generated at function entry, so we only need to validate the presence of two nops at the ftrace location in ftrace_init_nop(). We patch the preceding instruction with 'mflr r0' to match the -mprofile-kernel ABI for subsequent ftrace use. This changes the profiling instructions used on ppc32. The default -pg option emits an additional 'stw' instruction after 'mflr r0' and before the branch to _mcount 'bl _mcount'. This is very similar to the original -mprofile-kernel implementation on ppc64le, where an additional 'std' instruction was used to save LR to its save location in the caller's stackframe. Subsequently, this additional store was removed in later compiler versions for performance reasons. The same reasons apply for ppc32 so we only patch in a 'mflr r0'. Signed-off-by: Naveen N Rao <naveen@kernel.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/68586d22981a2c3bb45f27a2b621173d10a7d092.1687166935.git.naveen@kernel.org
2023-06-19 02:47:34 -07:00
ifdef CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY
KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
CC_FLAGS_FTRACE := -fpatchable-function-entry=2
else
powerpc: consolidate -mno-sched-epilog into FTRACE flags Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-13 22:08:53 -07:00
CC_FLAGS_FTRACE := -pg
powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel Firstly we add logic to Kconfig to allow a user to choose if they want mprofile-kernel. This has to be user-selectable because only some current toolchains support it. If we enabled it unconditionally we would prevent some users from building the kernel entirely. Arguably it would be nice if we could detect if mprofile-kernel was available, and use it then. However that would violate the principle of least surprise because a user having choosen options such as live patching, would then see them quietly disabled at build time. We also make the user selectable option negative, ie. it disables when selected, so that allyesconfig continues to build on old toolchains. Once we've decided we do want to use mprofile-kernel, we then add a script which checks it actually works. That is because there are versions of gcc that accept the flag but don't generate correct code. Due to the way kconfig works, we can't error out when we detect a non-working toolchain. If we did a user would never be able to modify their config and run oldconfig - because the check would block oldconfig from running. Instead we emit a warning and add a bogus flag to CFLAGS so that the build will fail. Signed-off-by: Torsten Duwe <duwe@suse.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-03-02 21:27:00 -07:00
ifdef CONFIG_MPROFILE_KERNEL
powerpc: consolidate -mno-sched-epilog into FTRACE flags Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-13 22:08:53 -07:00
CC_FLAGS_FTRACE += -mprofile-kernel
endif
powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel Firstly we add logic to Kconfig to allow a user to choose if they want mprofile-kernel. This has to be user-selectable because only some current toolchains support it. If we enabled it unconditionally we would prevent some users from building the kernel entirely. Arguably it would be nice if we could detect if mprofile-kernel was available, and use it then. However that would violate the principle of least surprise because a user having choosen options such as live patching, would then see them quietly disabled at build time. We also make the user selectable option negative, ie. it disables when selected, so that allyesconfig continues to build on old toolchains. Once we've decided we do want to use mprofile-kernel, we then add a script which checks it actually works. That is because there are versions of gcc that accept the flag but don't generate correct code. Due to the way kconfig works, we can't error out when we detect a non-working toolchain. If we did a user would never be able to modify their config and run oldconfig - because the check would block oldconfig from running. Instead we emit a warning and add a bogus flag to CFLAGS so that the build will fail. Signed-off-by: Torsten Duwe <duwe@suse.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-03-02 21:27:00 -07:00
endif
powerpc/ftrace: Add support for -fpatchable-function-entry GCC v13.1 updated support for -fpatchable-function-entry on ppc64le to emit nops after the local entry point, rather than before it. This allows us to use this in the kernel for ftrace purposes. A new script is added under arch/powerpc/tools/ to help detect if nops are emitted after the function local entry point, or before the global entry point. With -fpatchable-function-entry, we no longer have the profiling instructions generated at function entry, so we only need to validate the presence of two nops at the ftrace location in ftrace_init_nop(). We patch the preceding instruction with 'mflr r0' to match the -mprofile-kernel ABI for subsequent ftrace use. This changes the profiling instructions used on ppc32. The default -pg option emits an additional 'stw' instruction after 'mflr r0' and before the branch to _mcount 'bl _mcount'. This is very similar to the original -mprofile-kernel implementation on ppc64le, where an additional 'std' instruction was used to save LR to its save location in the caller's stackframe. Subsequently, this additional store was removed in later compiler versions for performance reasons. The same reasons apply for ppc32 so we only patch in a 'mflr r0'. Signed-off-by: Naveen N Rao <naveen@kernel.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/68586d22981a2c3bb45f27a2b621173d10a7d092.1687166935.git.naveen@kernel.org
2023-06-19 02:47:34 -07:00
endif
powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel Firstly we add logic to Kconfig to allow a user to choose if they want mprofile-kernel. This has to be user-selectable because only some current toolchains support it. If we enabled it unconditionally we would prevent some users from building the kernel entirely. Arguably it would be nice if we could detect if mprofile-kernel was available, and use it then. However that would violate the principle of least surprise because a user having choosen options such as live patching, would then see them quietly disabled at build time. We also make the user selectable option negative, ie. it disables when selected, so that allyesconfig continues to build on old toolchains. Once we've decided we do want to use mprofile-kernel, we then add a script which checks it actually works. That is because there are versions of gcc that accept the flag but don't generate correct code. Due to the way kconfig works, we can't error out when we detect a non-working toolchain. If we did a user would never be able to modify their config and run oldconfig - because the check would block oldconfig from running. Instead we emit a warning and add a bogus flag to CFLAGS so that the build will fail. Signed-off-by: Torsten Duwe <duwe@suse.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-03-02 21:27:00 -07:00
powerpc/64: Set default CPU in Kconfig Since commit 0069f3d14e7a ("powerpc/64e: Tie PPC_BOOK3E_64 to PPC_E500MC"), the only possible BOOK3E/64 are E500, so no need of a default CPU over the E5500. When the user selects book3e, they must have an e500 compatible compiler, and it won't work anymore with the default -mcpu=power64, see commit d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')"). For book3s/64, replace GENERIC_CPU by POWERPC64_CPU to match the PPC32 POWERPC_CPU, and set a default mpcu value in Kconfig directly. When a user selects a particular CPU, they must ensure the compiler has the requested capability. Therefore, remove hidden fallback, instead offer user the possibility to say they want to use the toolchain default. Fixes: d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')") Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/76c11197b058193dcb8e8b26adffba09cfbdab11.1674632329.git.christophe.leroy@csgroup.eu
2023-01-25 00:38:59 -07:00
CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU)
powerpc: Add 64-bit CPU targets for gcc Add a menu to select various 64-bit CPU targets for gcc. We default to -mtune=power7 and if gcc doesn't understand that we fallback to -mtune=power4. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-04-17 11:45:28 -07:00
powerpc/64s: Move CPU -mtune options into Kconfig Currently the -mtune options are set in the Makefile, depending on what the compiler supports. One downside of doing it that way is that the chosen -mtune option is not recorded in the .config. Another downside is that if there's ever a need to do more complicated logic to calculate the correct option, that gets messy in the Makefile. So move the determination of which -mtune option to use into Kconfig logic. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230329234308.2215833-1-mpe@ellerman.id.au
2023-03-29 16:43:08 -07:00
CFLAGS-y += $(CONFIG_TUNE_CPU)
powerpc/booke64: Use appropriate -mcpu By default use -mcpu=powerpc64 rather than -mtune=power7 Add options for e5500/e6500, with fallbacks for older compilers. Hide the POWER cpu options in booke configs. Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-08-20 17:55:36 -07:00
powerpc: Fix 64 bit builds with binutils 2.24 With binutils 2.24, various 64 bit builds fail with relocation errors such as arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o The assembler maintainer says: I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Cc: <stable@vger.kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-05-15 09:33:42 -07:00
asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
powerpc/Makefile: Don't use $(ARCH) unnecessarily There's no need to use $(ARCH) for references to the arch directory in the source tree, it is always arch/powerpc. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-1-mpe@ellerman.id.au
2023-12-06 04:55:45 -07:00
KBUILD_CPPFLAGS += -I $(srctree)/arch/powerpc $(asinstr)
powerpc: remove redundant header search path additions The same path -Iarch/$(ARCH) is passed to KBUILD_CPPFLAGS, KBUILD_AFLAGS, and KBUILD_CFLAGS. As you see in scripts/Makefile.lib, KBUILD_CPPFLAGS is passed to c_flags and a_flags as well. Passing it to KBUILD_CPPFLAGS is enough. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-01-10 20:22:32 -07:00
KBUILD_AFLAGS += $(AFLAGS-y)
powerpc: Only use -mtraceback=no, -mno-string and -msoft-float if toolchain supports it These options are not recognised on LLVM, so use call cc-option to check for support. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-25 15:53:27 -07:00
KBUILD_CFLAGS += $(call cc-option,-msoft-float)
powerpc/build: Remove -pipe from compilation flags x86 removed -pipe in commit 437e88ab8f9e2 ("x86/build: Remove -pipe from KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it, so that seems to be the way the world's going. Compile performance building defconfig on a POWER10 PowerNV system was in the noise after 10 builds each. No point in adding options unless they help something, so remove it. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230606064830.184083-1-npiggin@gmail.com
2023-06-05 23:48:30 -07:00
KBUILD_CFLAGS += $(CFLAGS-y)
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-14 13:21:35 -07:00
CPP = $(CC) -E $(KBUILD_CFLAGS)
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc/Makefile: Drop CONFIG_WORD_SIZE for BITS Commit 2578bfae84a7 ("[POWERPC] Create and use CONFIG_WORD_SIZE") added CONFIG_WORD_SIZE, and suggests that other arches were going to do likewise. But that never happened, powerpc is the only architecture which uses it. So switch to using a simple make variable, BITS, like x86, sh, sparc and tile. It is also easier to spell and simpler, avoiding any confusion about whether it's defined due to ordering of make vs kconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-10 23:03:14 -07:00
CHECKFLAGS += -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
powerpc/sparse: Pass endianness to sparse Explicitly give sparse an endianness in the Makefile, so that it doesn't get confused. Normally we have #ifdef one and #else the other, so it doesn't usually matter, but we have been bitten by it before, and indeed this patch fixes a number of sparse errors. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-07-11 17:54:51 -07:00
ifdef CONFIG_CPU_BIG_ENDIAN
CHECKFLAGS += -D__BIG_ENDIAN__
else
powerpc: Finalise cleanup around ABI use Now that we have CONFIG_PPC64_ELF_ABI_V1 and CONFIG_PPC64_ELF_ABI_V2, get rid of all indirect detection of ABI version. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/709d9d69523c14c8a9fba4486395dca0f2d675b1.1652074503.git.christophe.leroy@csgroup.eu
2022-05-08 22:36:08 -07:00
CHECKFLAGS += -D__LITTLE_ENDIAN__
powerpc/sparse: Pass endianness to sparse Explicitly give sparse an endianness in the Makefile, so that it doesn't get confused. Normally we have #ifdef one and #else the other, so it doesn't usually matter, but we have been bitten by it before, and indeed this patch fixes a number of sparse errors. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-07-11 17:54:51 -07:00
endif
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc/Makefiles: Convert ifeq to ifdef where possible In Makefiles if we're testing a CONFIG_FOO symbol for equality with 'y' we can instead just use ifdef. The latter reads easily, so convert to it where possible. Signed-off-by: Rodrigo R. Galvao <rosattig@linux.vnet.ibm.com> Reviewed-by: Mauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-08-06 09:42:03 -07:00
ifdef CONFIG_476FPE_ERR46
ppc476: Enable a linker work around for IBM errata #46 This patch adds an option to enable a work around for an icache bug on 476 that can cause execution of stale instructions when falling through pages (IBM errata #46). It requires a recent version of binutils which supports the --ppc476-workaround option. The work around enables the appropriate linker options and ensures that all module output sections are aligned to 4K page boundaries. The work around is only required when building modules. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-02-24 00:00:56 -07:00
KBUILD_LDFLAGS_MODULE += --ppc476-workaround \
-T $(srctree)/arch/powerpc/platforms/44x/ppc476_modules.lds
endif
powerpc/64s: POWER10 CPU Kconfig build option This adds basic POWER10_CPU option, which builds with -mcpu=power10. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220923033004.536127-1-npiggin@gmail.com
2022-09-22 20:30:04 -07:00
# No prefix or pcrel
powerpc/64: Add support to build with prefixed instructions Add an option to build kernel and module with prefixed instructions if the CPU and toolchain support it. This is not related to kernel support for userspace execution of prefixed instructions. Building with prefixed instructions breaks some extended inline asm memory addressing, for example it will provide immediates that exceed the range of simple load/store displacement. Whether this is a toolchain or a kernel asm problem remains to be seen. For now, these are replaced with simpler and less efficient direct register addressing when compiling with prefixed. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-4-npiggin@gmail.com
2023-04-07 19:17:49 -07:00
ifdef CONFIG_PPC_KERNEL_PREFIXED
KBUILD_CFLAGS += $(call cc-option,-mprefixed)
else
powerpc/64s: POWER10 CPU Kconfig build option This adds basic POWER10_CPU option, which builds with -mcpu=power10. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220923033004.536127-1-npiggin@gmail.com
2022-09-22 20:30:04 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-prefixed)
powerpc/64: Add support to build with prefixed instructions Add an option to build kernel and module with prefixed instructions if the CPU and toolchain support it. This is not related to kernel support for userspace execution of prefixed instructions. Building with prefixed instructions breaks some extended inline asm memory addressing, for example it will provide immediates that exceed the range of simple load/store displacement. Whether this is a toolchain or a kernel asm problem remains to be seen. For now, these are replaced with simpler and less efficient direct register addressing when compiling with prefixed. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-4-npiggin@gmail.com
2023-04-07 19:17:49 -07:00
endif
powerpc/64: vmlinux support building with PCREL addresing PC-Relative or PCREL addressing is an extension to the ELF ABI which uses Power ISA v3.1 PC-relative instructions to calculate addresses, rather than the traditional TOC scheme. Add an option to build vmlinux using pcrel addressing. Modules continue to use TOC addressing. - TOC address helpers and r2 are poisoned with -1 when running vmlinux. r2 could be used for something useful once things are ironed out. - Assembly must call C functions with @notoc annotation, or the linker complains aobut a missing nop after the call. This is done with the CFUNC macro introduced earlier. - Boot: with the exception of prom_init, the execution branches to the kernel virtual address early in boot, before any addresses are generated, which ensures 34-bit pcrel addressing does not miss the high PAGE_OFFSET bits. TOC relative addressing has a similar requirement. prom_init does not go to the virtual address and its addresses should not carry over to the post-prom kernel. - Ftrace trampolines are converted from TOC addressing to pcrel addressing, including module ftrace trampolines that currently use the kernel TOC to find ftrace target functions. - BPF function prologue and function calling generation are converted from TOC to pcrel. - copypage_64.S has an interesting problem, prefixed instructions have alignment restrictions so the linker can add padding, which makes the assembler treat the difference between two local labels as non-constant even if alignment is arranged so padding is not required. This may need toolchain help to solve nicely, for now move the prefix instruction out of the alternate patch section to work around it. This reduces kernel text size by about 6%. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-6-npiggin@gmail.com
2023-04-07 19:17:51 -07:00
ifdef CONFIG_PPC_KERNEL_PCREL
KBUILD_CFLAGS += $(call cc-option,-mpcrel)
else
powerpc/64s: POWER10 CPU Kconfig build option This adds basic POWER10_CPU option, which builds with -mcpu=power10. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220923033004.536127-1-npiggin@gmail.com
2022-09-22 20:30:04 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-pcrel)
powerpc/64: vmlinux support building with PCREL addresing PC-Relative or PCREL addressing is an extension to the ELF ABI which uses Power ISA v3.1 PC-relative instructions to calculate addresses, rather than the traditional TOC scheme. Add an option to build vmlinux using pcrel addressing. Modules continue to use TOC addressing. - TOC address helpers and r2 are poisoned with -1 when running vmlinux. r2 could be used for something useful once things are ironed out. - Assembly must call C functions with @notoc annotation, or the linker complains aobut a missing nop after the call. This is done with the CFUNC macro introduced earlier. - Boot: with the exception of prom_init, the execution branches to the kernel virtual address early in boot, before any addresses are generated, which ensures 34-bit pcrel addressing does not miss the high PAGE_OFFSET bits. TOC relative addressing has a similar requirement. prom_init does not go to the virtual address and its addresses should not carry over to the post-prom kernel. - Ftrace trampolines are converted from TOC addressing to pcrel addressing, including module ftrace trampolines that currently use the kernel TOC to find ftrace target functions. - BPF function prologue and function calling generation are converted from TOC to pcrel. - copypage_64.S has an interesting problem, prefixed instructions have alignment restrictions so the linker can add padding, which makes the assembler treat the difference between two local labels as non-constant even if alignment is arranged so padding is not required. This may need toolchain help to solve nicely, for now move the prefix instruction out of the alternate patch section to work around it. This reduces kernel text size by about 6%. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230408021752.862660-6-npiggin@gmail.com
2023-04-07 19:17:51 -07:00
endif
powerpc/64s: POWER10 CPU Kconfig build option This adds basic POWER10_CPU option, which builds with -mcpu=power10. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220923033004.536127-1-npiggin@gmail.com
2022-09-22 20:30:04 -07:00
# No AltiVec or VSX or MMA instructions when building kernel
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-14 13:21:35 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
powerpc: Add 64-bit CPU targets for gcc Add a menu to select various 64-bit CPU targets for gcc. We default to -mtune=power7 and if gcc doesn't understand that we fallback to -mtune=power4. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-04-17 11:45:28 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-vsx)
powerpc/64s: POWER10 CPU Kconfig build option This adds basic POWER10_CPU option, which builds with -mcpu=power10. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220923033004.536127-1-npiggin@gmail.com
2022-09-22 20:30:04 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-mma)
powerpc: Add -mno-altivec for ARCH=powerpc builds Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-28 22:31:17 -07:00
[POWERPC] Add -mno-spe for ARCH=powerpc builds Newer GCC's are capable of autovectorization for ISA extensions like AltiVec and SPE. If we happen to build with one of those compilers we will get SPE instructions in random kernel code. Today we only allow basic interger code in the kernel and FP, AltiVec, or SPE in special explicit locations that have handled the proper saving and restoring of the register state (since on uniprocessor we lazy context switch the register state for FP, AltiVec, and SPE). -mno-spe disables the compiler for automatically generating SPE instructions without our knowledge. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-10-18 14:53:19 -07:00
# No SPE instruction when building kernel
powerpc: Enforce a non-spe kernel build even on broken compilers Those two are required on my fresh gcc 4.3.1. Signed-off-by: Thiemo Seufer <ths@linutronix.de> Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-01 07:23:02 -07:00
# (We use all available options to help semi-broken compilers)
[POWERPC] Add -mno-spe for ARCH=powerpc builds Newer GCC's are capable of autovectorization for ISA extensions like AltiVec and SPE. If we happen to build with one of those compilers we will get SPE instructions in random kernel code. Today we only allow basic interger code in the kernel and FP, AltiVec, or SPE in special explicit locations that have handled the proper saving and restoring of the register state (since on uniprocessor we lazy context switch the register state for FP, AltiVec, and SPE). -mno-spe disables the compiler for automatically generating SPE instructions without our knowledge. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-10-18 14:53:19 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-spe)
powerpc: Enforce a non-spe kernel build even on broken compilers Those two are required on my fresh gcc 4.3.1. Signed-off-by: Thiemo Seufer <ths@linutronix.de> Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-01 07:23:02 -07:00
KBUILD_CFLAGS += $(call cc-option,-mspe=no)
[POWERPC] Add -mno-spe for ARCH=powerpc builds Newer GCC's are capable of autovectorization for ISA extensions like AltiVec and SPE. If we happen to build with one of those compilers we will get SPE instructions in random kernel code. Today we only allow basic interger code in the kernel and FP, AltiVec, or SPE in special explicit locations that have handled the proper saving and restoring of the register state (since on uniprocessor we lazy context switch the register state for FP, AltiVec, and SPE). -mno-spe disables the compiler for automatically generating SPE instructions without our knowledge. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-10-18 14:53:19 -07:00
powerpc: Suppress .eh_frame generation GCC v8 defaults to enabling -fasynchronous-unwind-tables due to https://gcc.gnu.org/r259298, which results in .eh_frame section being generated. This results in additional disk usage by the build, as well as the kernel modules. Since the kernel has no use for this, this section is discarded. Add -fno-asynchronous-unwind-tables to KBUILD_CFLAGS to suppress generation of .eh_frame section. Note that our VDSOs need .eh_frame, but are not affected by this change since our VDSO code are all in assembly. Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1ed7cd84a7d1a3180b30c0c60e70eed8bb8b40c3.1583415544.git.naveen.n.rao@linux.vnet.ibm.com
2020-03-05 07:35:30 -07:00
# Don't emit .eh_frame since we have no use for it
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
[POWERPC] Always use -mno-string The string load/store instructions are unimplemented on some processors and slow (microcoded) on some others. It's simplest to just not use them at all. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-21 23:23:44 -07:00
# Never use string load/store instructions as they are
# often slow when they are implemented at all
powerpc: Only use -mtraceback=no, -mno-string and -msoft-float if toolchain supports it These options are not recognised on LLVM, so use call cc-option to check for support. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-05-25 15:53:27 -07:00
KBUILD_CFLAGS += $(call cc-option,-mno-string)
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc/Makefile: Use cflags-y/aflags-y for setting endian options When we introduced the little endian support, we added the endian flags to CC directly using override. I don't know the history of why we did that, I suspect no one does. Although this mostly works, it has one bug, which is that CROSS32CC doesn't get -mbig-endian. That means when the compiler is little endian by default and the user is building big endian, vdso32 is incorrectly compiled as little endian and the kernel fails to build. Instead we can add the endian flags to cflags-y/aflags-y, and then append those to KBUILD_CFLAGS/KBUILD_AFLAGS. This has the advantage of being 1) less ugly, 2) the documented way of adding flags in the arch Makefile and 3) it fixes building vdso32 with a LE toolchain. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-08-09 05:43:46 -07:00
KBUILD_AFLAGS += $(aflags-y)
KBUILD_CFLAGS += $(cflags-y)
[PATCH] powerpc/boot: Better use of defaultimage- The following reworks how defaultimage- is used. We default to zImage here and then override it on platforms that need something more (uImage in the future) or less (vmlinux on iSeries). Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-01-12 16:55:58 -07:00
# Default to zImage, override when needed
[POWERPC] bootwrapper: Build multiple cuImages Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image with a fdt blob which means for any given configuration only one dts file can be selected and so support for only one board can be built This moves the selection of the default .dts file out of the kernel config and into the bootwrapper makefile. The makefile chooses which images to build based on the kernel config and the dts source file name is taken directly from the image name. For example "cuImage.ebony" will use "ebony.dts" as the device tree source file. In addition, this patch allows a specific image to be requested from the command line by adding "cuImage.%" and "treeImage.%" targets to the list of valid built targets in arch/powerpc/Makefile. This allows the default dts selection to be overridden. Another advantage to this change is it allows a single defconfig to be supplied for all boards using the same chip family and only differing in the device tree. Important note: This patch adds two new zImage targets; zImage.dtb.% and zImage.dtb.initrd.% for zImages with embedded dtb files. Currently there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc, adder875-redboot and ep8248e. This patch *changes the zImage filenames* for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'. This new zImage.dtb targets were added so that the .dts file could be part of the dependancies list for building them. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-06 11:18:34 -07:00
all: zImage
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable <stable@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-02 13:47:48 -07:00
# With make 3.82 we cannot mix normal and wildcard targets
powerpc: Fix typo in uImage target Commit e32e78c5ee8aadef020fbaecbe6fb741ed9029fd (powerpc: fix build with make 3.82) introduced a typo in uImage target and broke building uImage: make: *** No rule to make target `uImage'. Stop. Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: stable <stable@kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-15 15:26:56 -07:00
BOOT_TARGETS1 := zImage zImage.initrd uImage
powerpc: Add support for OpenBlockS 600 So I've had one of these for a while and it looks like the vendor never bothered submitting the support upstream. This adds it using ppc40x_simple and provides a device-tree. There are some changes to the boot wrapper because the way u-boot works on this thing, it seems to expect a multipart image with the kernel, initrd and dtb in it. The USB support is missing as it needs the yet unmerged driver for the DWC OTG part and the GPIOs may need further definition in the dts. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-12-01 12:35:08 -07:00
BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.% uImage.%
powerpc: make iSeries build Merge vmlinux.lds.S. Also remove arch/powerpc/kernel/vmlinux.lds which is a generated file. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
2005-09-29 23:16:52 -07:00
powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable <stable@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-02 13:47:48 -07:00
PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
powerpc: make iSeries build Merge vmlinux.lds.S. Also remove arch/powerpc/kernel/vmlinux.lds which is a generated file. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
2005-09-29 23:16:52 -07:00
powerpc/Makefile: Don't use $(ARCH) unnecessarily There's no need to use $(ARCH) for references to the arch directory in the source tree, it is always arch/powerpc. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-1-mpe@ellerman.id.au
2023-12-06 04:55:45 -07:00
boot := arch/powerpc/boot
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable <stable@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-02 13:47:48 -07:00
$(BOOT_TARGETS1): vmlinux
powerpc: Stop passing ARCH=ppc64 to boot Makefile Back in 2005 when the ppc/ppc64 merge started, we used to build the kernel code in arch/powerpc but use the boot code from arch/ppc or arch/ppc64 depending on whether we were building for 32 or 64-bit. Originally we called the boot Makefile passing ARCH=$(OLDARCH), where OLDARCH was ppc or ppc64. In commit 20f629549b30 ("powerpc: Make building the boot image work for both 32-bit and 64-bit") (2005-10-11) we split the call for 32/64-bit using an ifeq check, because the two Makefiles took different targets, and explicitly passed ARCH=ppc64 for the 64-bit case and ARCH=ppc for the 32-bit case. Then in commit 94b212c29f68 ("powerpc: Move ppc64 boot wrapper code over to arch/powerpc") (2005-11-16) we moved the boot code into arch/powerpc and dropped the ppc case, but kept passing ARCH=ppc64 to arch/powerpc/boot/Makefile. Since then there have been several more boot targets added, all of which have copied the ARCH=ppc64 setting, such that now we have four targets using it. Currently it seems that nothing actually uses the ARCH value, but that's basically just luck, and in particular it prevents us from using the generic cpp_lds_S rule. It's also clearly wrong, ARCH=ppc64 is dead, buried and cremated. Fix it by dropping the setting of ARCH completely, the correct value is exported by the top level Makefile. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-21 03:14:33 -07:00
$(Q)$(MAKE) $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable <stable@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-02 13:47:48 -07:00
$(BOOT_TARGETS2): vmlinux
powerpc: Stop passing ARCH=ppc64 to boot Makefile Back in 2005 when the ppc/ppc64 merge started, we used to build the kernel code in arch/powerpc but use the boot code from arch/ppc or arch/ppc64 depending on whether we were building for 32 or 64-bit. Originally we called the boot Makefile passing ARCH=$(OLDARCH), where OLDARCH was ppc or ppc64. In commit 20f629549b30 ("powerpc: Make building the boot image work for both 32-bit and 64-bit") (2005-10-11) we split the call for 32/64-bit using an ifeq check, because the two Makefiles took different targets, and explicitly passed ARCH=ppc64 for the 64-bit case and ARCH=ppc for the 32-bit case. Then in commit 94b212c29f68 ("powerpc: Move ppc64 boot wrapper code over to arch/powerpc") (2005-11-16) we moved the boot code into arch/powerpc and dropped the ppc case, but kept passing ARCH=ppc64 to arch/powerpc/boot/Makefile. Since then there have been several more boot targets added, all of which have copied the ARCH=ppc64 setting, such that now we have four targets using it. Currently it seems that nothing actually uses the ARCH value, but that's basically just luck, and in particular it prevents us from using the generic cpp_lds_S rule. It's also clearly wrong, ARCH=ppc64 is dead, buried and cremated. Fix it by dropping the setting of ARCH completely, the correct value is exported by the top level Makefile. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-21 03:14:33 -07:00
$(Q)$(MAKE) $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable <stable@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-02 13:47:48 -07:00
powerpc/Makefile: Mark phony targets as PHONY Some of our phony targets are not marked as such. This can lead to confusing errors, eg: $ make clean $ touch install $ make install make: 'install' is up to date. $ Fix it by adding them to the PHONY variable which is marked phony in the top-level Makefile, or in scripts/Makefile.build for the boot Makefile. Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200219000434.15872-1-mpe@ellerman.id.au
2020-02-18 17:04:34 -07:00
PHONY += bootwrapper_install
powerpc: fix build with make 3.82 Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Cc: stable <stable@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-08-02 13:47:48 -07:00
bootwrapper_install:
powerpc: Stop passing ARCH=ppc64 to boot Makefile Back in 2005 when the ppc/ppc64 merge started, we used to build the kernel code in arch/powerpc but use the boot code from arch/ppc or arch/ppc64 depending on whether we were building for 32 or 64-bit. Originally we called the boot Makefile passing ARCH=$(OLDARCH), where OLDARCH was ppc or ppc64. In commit 20f629549b30 ("powerpc: Make building the boot image work for both 32-bit and 64-bit") (2005-10-11) we split the call for 32/64-bit using an ifeq check, because the two Makefiles took different targets, and explicitly passed ARCH=ppc64 for the 64-bit case and ARCH=ppc for the 32-bit case. Then in commit 94b212c29f68 ("powerpc: Move ppc64 boot wrapper code over to arch/powerpc") (2005-11-16) we moved the boot code into arch/powerpc and dropped the ppc case, but kept passing ARCH=ppc64 to arch/powerpc/boot/Makefile. Since then there have been several more boot targets added, all of which have copied the ARCH=ppc64 setting, such that now we have four targets using it. Currently it seems that nothing actually uses the ARCH value, but that's basically just luck, and in particular it prevents us from using the generic cpp_lds_S rule. It's also clearly wrong, ARCH=ppc64 is dead, buried and cremated. Fix it by dropping the setting of ARCH completely, the correct value is exported by the top level Makefile. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-11-21 03:14:33 -07:00
$(Q)$(MAKE) $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
[POWERPC] Implement 'make bootwrapper_install' This adds a 'bootwrapper_install' make target for the powerpc architecture, which installs the wrapper script, intermediate object files and device-tree sources for later use. This will then allow bootable zImages to be created other than in the context of a kernel build. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-02 19:56:58 -07:00
kbuild: Add config fragment merge functionality So far this function was only used locally in powerpc, some other architectures might benefit from it. Move it into scripts/Makefile.defconf. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230124110213.3221264-10-alexander.stein@ew.tq-group.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-24 04:02:12 -07:00
include $(srctree)/scripts/Makefile.defconf
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64le_defconfig
powerpc: Add ppc64le_defconfig Based directly on ppc64_defconfig using merge_config. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-09-22 22:40:35 -07:00
ppc64le_defconfig:
$(call merge_into_defconfig,ppc64_defconfig,le)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64le_guest_defconfig
powerpc/configs: Add KVM guest defconfig This patch adds new defconfig options for powerpc KVM guest and guest.config with additional config symbols enabled, which is to build kernel to boot without initramfs and can be used as place holder for guest specific additional config symbols in future. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-14 23:49:50 -07:00
ppc64le_guest_defconfig:
powerpc/configs: Incorporate generic kvm_guest.config into guest configs Incorporate the generic kvm_guest.config into the powerpc guest configs, ppc64[le]_guest_defconfig. This brings in some useful options, in particular 9P support, and also means future additions to the generic file will be automatically picked up by the powerpc configs. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-30-mpe@ellerman.id.au
2023-04-14 06:24:13 -07:00
$(call merge_into_defconfig,ppc64_defconfig,le guest kvm_guest)
powerpc/configs: Add KVM guest defconfig This patch adds new defconfig options for powerpc KVM guest and guest.config with additional config symbols enabled, which is to build kernel to boot without initramfs and can be used as place holder for guest specific additional config symbols in future. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-14 23:49:50 -07:00
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64_guest_defconfig
powerpc/configs: Add KVM guest defconfig This patch adds new defconfig options for powerpc KVM guest and guest.config with additional config symbols enabled, which is to build kernel to boot without initramfs and can be used as place holder for guest specific additional config symbols in future. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-14 23:49:50 -07:00
ppc64_guest_defconfig:
powerpc/configs: Incorporate generic kvm_guest.config into guest configs Incorporate the generic kvm_guest.config into the powerpc guest configs, ppc64[le]_guest_defconfig. This brings in some useful options, in particular 9P support, and also means future additions to the generic file will be automatically picked up by the powerpc configs. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-30-mpe@ellerman.id.au
2023-04-14 06:24:13 -07:00
$(call merge_into_defconfig,ppc64_defconfig,be guest kvm_guest)
powerpc/configs: Add KVM guest defconfig This patch adds new defconfig options for powerpc KVM guest and guest.config with additional config symbols enabled, which is to build kernel to boot without initramfs and can be used as place holder for guest specific additional config symbols in future. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-11-14 23:49:50 -07:00
powerpc/configs: Make pseries_le an alias for ppc64le_guest Rather than trying to keep multiple configs up to date, make pseries_le_defconfig an alias for ppc64le_guest_defconfig. ppc64le_guest_defconfig should work in all cases that pseries_le_defconfig currently does, but if not we can update it. Move pseries_le_defconfig down in the Makefile, so it appears after ppc64le_guest_defconfig in the help output. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-31-mpe@ellerman.id.au
2023-04-14 06:24:14 -07:00
generated_configs += pseries_le_defconfig
pseries_le_defconfig: ppc64le_guest_defconfig
powerpc/configs: Make pseries_defconfig an alias for ppc64le_guest Rather than trying to keep multiple configs up to date, make pseries_defconfig an alias for ppc64le_guest_defconfig. NOTE, pseries_defconfig was a big endian config, but this commit switches it to little endian. Almost all distros are ppc64le these days, so little endian is much more likely to be what a user wants when they build for "pseries". For an actual big endian guest, use ppc64_guest_defconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-32-mpe@ellerman.id.au
2023-04-14 06:24:15 -07:00
generated_configs += pseries_defconfig
pseries_defconfig: ppc64le_guest_defconfig
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += powernv_be_defconfig
powerpc/configs: Add a powernv_be_defconfig Although pretty much everyone using powernv is running little endian, we should still test we can build for big endian. So add a powernv_be_defconfig, which is autogenerated by flipping the endian symbol in powernv_defconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
2017-07-24 05:50:45 -07:00
powernv_be_defconfig:
$(call merge_into_defconfig,powernv_defconfig,be)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += mpc85xx_defconfig
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
mpc85xx_defconfig:
powerpc/configs: Rename foo_basic_defconfig to foo_base.config We have several "defconfigs" that are not actually full defconfigs they are just a base set of options which are then merged with other fragments to produce a working defconfig. The most obvious example is corenet_basic_defconfig which only contains one symbol CONFIG_CORENET_GENERIC=y. And in fact if you build it as a "defconfig" that one symbol ends up undefined, because its prerequisites are missing. There is also mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. To avoid confusion, rename these config fragments to "foo_base.config" to make it clearer that they are not full defconfigs and are instaed just fragments that are used to generate real defconfigs. Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190528081614.26096-1-mpe@ellerman.id.au
2019-05-28 01:16:14 -07:00
$(call merge_into_defconfig,mpc85xx_base.config,\
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
85xx-32bit 85xx-hw fsl-emb-nonhw)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += mpc85xx_smp_defconfig
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
mpc85xx_smp_defconfig:
powerpc/configs: Rename foo_basic_defconfig to foo_base.config We have several "defconfigs" that are not actually full defconfigs they are just a base set of options which are then merged with other fragments to produce a working defconfig. The most obvious example is corenet_basic_defconfig which only contains one symbol CONFIG_CORENET_GENERIC=y. And in fact if you build it as a "defconfig" that one symbol ends up undefined, because its prerequisites are missing. There is also mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. To avoid confusion, rename these config fragments to "foo_base.config" to make it clearer that they are not full defconfigs and are instaed just fragments that are used to generate real defconfigs. Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190528081614.26096-1-mpe@ellerman.id.au
2019-05-28 01:16:14 -07:00
$(call merge_into_defconfig,mpc85xx_base.config,\
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += corenet32_smp_defconfig
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
corenet32_smp_defconfig:
powerpc/configs: Rename foo_basic_defconfig to foo_base.config We have several "defconfigs" that are not actually full defconfigs they are just a base set of options which are then merged with other fragments to produce a working defconfig. The most obvious example is corenet_basic_defconfig which only contains one symbol CONFIG_CORENET_GENERIC=y. And in fact if you build it as a "defconfig" that one symbol ends up undefined, because its prerequisites are missing. There is also mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. To avoid confusion, rename these config fragments to "foo_base.config" to make it clearer that they are not full defconfigs and are instaed just fragments that are used to generate real defconfigs. Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190528081614.26096-1-mpe@ellerman.id.au
2019-05-28 01:16:14 -07:00
$(call merge_into_defconfig,corenet_base.config,\
arch/powerpc: Add CONFIG_FSL_DPAA to corenetXX_smp_defconfig Enable the drivers on the powerpc arch. Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Scott Wood <oss@buserror.net>
2016-09-22 08:04:12 -07:00
85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw dpaa)
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += corenet64_smp_defconfig
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
corenet64_smp_defconfig:
powerpc/configs: Rename foo_basic_defconfig to foo_base.config We have several "defconfigs" that are not actually full defconfigs they are just a base set of options which are then merged with other fragments to produce a working defconfig. The most obvious example is corenet_basic_defconfig which only contains one symbol CONFIG_CORENET_GENERIC=y. And in fact if you build it as a "defconfig" that one symbol ends up undefined, because its prerequisites are missing. There is also mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. To avoid confusion, rename these config fragments to "foo_base.config" to make it clearer that they are not full defconfigs and are instaed just fragments that are used to generate real defconfigs. Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190528081614.26096-1-mpe@ellerman.id.au
2019-05-28 01:16:14 -07:00
$(call merge_into_defconfig,corenet_base.config,\
arch/powerpc: Add CONFIG_FSL_DPAA to corenetXX_smp_defconfig Enable the drivers on the powerpc arch. Signed-off-by: Roy Pledge <roy.pledge@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Scott Wood <oss@buserror.net>
2016-09-22 08:04:12 -07:00
85xx-64bit 85xx-smp altivec 85xx-hw fsl-emb-nonhw dpaa)
powerpc/85xx: Use kconfig fragments Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood <scottwood@freescale.com>
2015-07-29 16:14:04 -07:00
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += mpc86xx_defconfig
powerpc/86xx: Switch to kconfig fragments approach Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu> Signed-off-by: Scott Wood <oss@buserror.net>
2016-02-22 02:26:14 -07:00
mpc86xx_defconfig:
powerpc/configs: Rename foo_basic_defconfig to foo_base.config We have several "defconfigs" that are not actually full defconfigs they are just a base set of options which are then merged with other fragments to produce a working defconfig. The most obvious example is corenet_basic_defconfig which only contains one symbol CONFIG_CORENET_GENERIC=y. And in fact if you build it as a "defconfig" that one symbol ends up undefined, because its prerequisites are missing. There is also mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. To avoid confusion, rename these config fragments to "foo_base.config" to make it clearer that they are not full defconfigs and are instaed just fragments that are used to generate real defconfigs. Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190528081614.26096-1-mpe@ellerman.id.au
2019-05-28 01:16:14 -07:00
$(call merge_into_defconfig,mpc86xx_base.config,\
powerpc/86xx: Switch to kconfig fragments approach Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu> Signed-off-by: Scott Wood <oss@buserror.net>
2016-02-22 02:26:14 -07:00
86xx-hw fsl-emb-nonhw)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += mpc86xx_smp_defconfig
powerpc/86xx: Switch to kconfig fragments approach Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu> Signed-off-by: Scott Wood <oss@buserror.net>
2016-02-22 02:26:14 -07:00
mpc86xx_smp_defconfig:
powerpc/configs: Rename foo_basic_defconfig to foo_base.config We have several "defconfigs" that are not actually full defconfigs they are just a base set of options which are then merged with other fragments to produce a working defconfig. The most obvious example is corenet_basic_defconfig which only contains one symbol CONFIG_CORENET_GENERIC=y. And in fact if you build it as a "defconfig" that one symbol ends up undefined, because its prerequisites are missing. There is also mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. To avoid confusion, rename these config fragments to "foo_base.config" to make it clearer that they are not full defconfigs and are instaed just fragments that are used to generate real defconfigs. Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190528081614.26096-1-mpe@ellerman.id.au
2019-05-28 01:16:14 -07:00
$(call merge_into_defconfig,mpc86xx_base.config,\
powerpc/86xx: Switch to kconfig fragments approach Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu> Signed-off-by: Scott Wood <oss@buserror.net>
2016-02-22 02:26:14 -07:00
86xx-smp 86xx-hw fsl-emb-nonhw)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc32_allmodconfig
powerpc: Add ppc32_allmodconfig defconfig target Because the allmodconfig logic just sets every symbol to M or Y, it has the effect of always generating a 64-bit config, because CONFIG_PPC64 becomes Y. So to make it easier for folks to test 32-bit code, provide a phony defconfig target that generates a 32-bit allmodconfig. The 32-bit port has several mutually exclusive CPU types, we choose the Book3S variants as that's what the help text in Kconfig says is most common. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-07-09 07:24:25 -07:00
ppc32_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/book3s_32.config \
-f $(srctree)/Makefile allmodconfig
powerpc: Add allmodconfig for all 32-bit sub-arches 32-bit powerpc kernels can be built for one of 5 sub-arches, see Kconfig.cputype: PPC_BOOK3S_32: "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" PPC_85xx: "Freescale 85xx" PPC_8xx: "Freescale 8xx" 40x: "AMCC 40x" 44x: "AMCC 44x, 46x or 47x" By default none of these are built for a plain allmodconfig build, because it selects PPC64 which builds a 64-bit kernel. There is already a ppc32_allmodconfig, which enables PPC_BOOK3S_32. Add similar targets for the other 32-bit sub-arches to increase build coverage: ppc40x_allmodconfig ppc44x_allmodconfig ppc8xx_allmodconfig ppc85xx_allmodconfig Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240229114108.743810-1-mpe@ellerman.id.au
2024-02-29 04:41:08 -07:00
generated_configs += ppc40x_allmodconfig
ppc40x_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/40x.config \
-f $(srctree)/Makefile allmodconfig
generated_configs += ppc44x_allmodconfig
ppc44x_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/44x.config \
-f $(srctree)/Makefile allmodconfig
generated_configs += ppc8xx_allmodconfig
ppc8xx_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/8xx.config \
-f $(srctree)/Makefile allmodconfig
generated_configs += ppc85xx_allmodconfig
ppc85xx_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-32bit.config \
-f $(srctree)/Makefile allmodconfig
powerpc: Add ppc32_allmodconfig defconfig target Because the allmodconfig logic just sets every symbol to M or Y, it has the effect of always generating a 64-bit config, because CONFIG_PPC64 becomes Y. So to make it easier for folks to test 32-bit code, provide a phony defconfig target that generates a 32-bit allmodconfig. The 32-bit port has several mutually exclusive CPU types, we choose the Book3S variants as that's what the help text in Kconfig says is most common. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-07-09 07:24:25 -07:00
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc_defconfig
powerpc/32: Add ppc_defconfig Add a generic 32-bit defconfig called ppc_defconfig. This means we'll have a defconfig matching "uname -m" for all cases. This config is mostly intended for build testing but if someone wants to tweak it to get it booting on something that would be fine too. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-06 22:16:51 -07:00
ppc_defconfig:
$(call merge_into_defconfig,book3s_32.config,)
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64le_allmodconfig
powerpc: Add ppc64le and ppc64_book3e allmodconfig targets Similarly as we just did for 32-bit, add phony targets for generating a little endian and Book3E allmodconfig. These aren't covered by the regular allmodconfig, which is big endian and Book3S due to the way the Kconfig symbols are structured. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-07-09 07:24:26 -07:00
ppc64le_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/le.config \
-f $(srctree)/Makefile allmodconfig
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64le_allnoconfig
powerpc/configs: Add ppc64le_allnoconfig target Add a phony target for ppc64le_allnoconfig, which tests some combinations of CONFIG symbols that aren't covered by any of our defconfigs. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201125031551.2112715-1-mpe@ellerman.id.au
2020-11-24 20:15:51 -07:00
ppc64le_allnoconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/ppc64le.config \
-f $(srctree)/Makefile allnoconfig
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64_book3e_allmodconfig
powerpc: Add ppc64le and ppc64_book3e allmodconfig targets Similarly as we just did for 32-bit, add phony targets for generating a little endian and Book3E allmodconfig. These aren't covered by the regular allmodconfig, which is big endian and Book3S due to the way the Kconfig symbols are structured. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-07-09 07:24:26 -07:00
ppc64_book3e_allmodconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \
-f $(srctree)/Makefile allmodconfig
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc32_randconfig
powerpc/Makefile: Add ppc32/ppc64_randconfig targets Make it easier to generate a 32 or 64-bit specific randconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Requested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210428132700.3426100-1-mpe@ellerman.id.au
2021-04-28 06:27:00 -07:00
ppc32_randconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/32-bit.config \
-f $(srctree)/Makefile randconfig
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
generated_configs += ppc64_randconfig
powerpc/Makefile: Add ppc32/ppc64_randconfig targets Make it easier to generate a 32 or 64-bit specific randconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Requested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210428132700.3426100-1-mpe@ellerman.id.au
2021-04-28 06:27:00 -07:00
ppc64_randconfig:
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/64-bit.config \
-f $(srctree)/Makefile randconfig
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
PHONY += $(generated_configs)
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
define archhelp
powerpc/Makefile: Don't prefix archhelp commands with "@" It's not necessary to prefix every command in archhelp with "@" (to suppress echoing the command), because that is done by the top level Makefile when it evaluates archhelp. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230329072334.2023357-1-mpe@ellerman.id.au
2023-03-29 00:23:33 -07:00
echo '* zImage - Build default images selected by kernel config'
powerpc/Makefile: Don't use $(ARCH) unnecessarily There's no need to use $(ARCH) for references to the arch directory in the source tree, it is always arch/powerpc. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-1-mpe@ellerman.id.au
2023-12-06 04:55:45 -07:00
echo ' zImage.* - Compressed kernel image (arch/powerpc/boot/zImage.*)'
powerpc/Makefile: Don't prefix archhelp commands with "@" It's not necessary to prefix every command in archhelp with "@" (to suppress echoing the command), because that is done by the top level Makefile when it evaluates archhelp. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230329072334.2023357-1-mpe@ellerman.id.au
2023-03-29 00:23:33 -07:00
echo ' uImage - U-Boot native image format'
echo ' cuImage.<dt> - Backwards compatible U-Boot image for older'
echo ' versions which do not support device trees'
echo ' dtbImage.<dt> - zImage with an embedded device tree blob'
echo ' simpleImage.<dt> - Firmware independent image.'
echo ' treeImage.<dt> - Support for older IBM 4xx firmware (not U-Boot)'
echo ' install - Install kernel using'
echo ' (your) ~/bin/$(INSTALLKERNEL) or'
echo ' (distribution) /sbin/$(INSTALLKERNEL) or'
echo ' install to $$(INSTALL_PATH) and run lilo'
powerpc/Makefile: Don't use $(ARCH) unnecessarily There's no need to use $(ARCH) for references to the arch directory in the source tree, it is always arch/powerpc. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-1-mpe@ellerman.id.au
2023-12-06 04:55:45 -07:00
echo ' *_defconfig - Select default config from arch/powerpc/configs'
powerpc/Makefile: Don't prefix archhelp commands with "@" It's not necessary to prefix every command in archhelp with "@" (to suppress echoing the command), because that is done by the top level Makefile when it evaluates archhelp. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230329072334.2023357-1-mpe@ellerman.id.au
2023-03-29 00:23:33 -07:00
echo ''
echo ' Targets with <dt> embed a device tree blob inside the image'
echo ' These targets support board with firmware that does not'
echo ' support passing a device tree directly. Replace <dt> with the'
powerpc/Makefile: Don't use $(ARCH) unnecessarily There's no need to use $(ARCH) for references to the arch directory in the source tree, it is always arch/powerpc. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-1-mpe@ellerman.id.au
2023-12-06 04:55:45 -07:00
echo ' name of a dts file from the arch/powerpc/boot/dts/ directory'
powerpc/Makefile: Don't prefix archhelp commands with "@" It's not necessary to prefix every command in archhelp with "@" (to suppress echoing the command), because that is done by the top level Makefile when it evaluates archhelp. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230329072334.2023357-1-mpe@ellerman.id.au
2023-03-29 00:23:33 -07:00
echo ' (minus the .dts extension).'
powerpc/Makefile: Add generated defconfigs to help output Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig - Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig - Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> [mpe: Fix PHONY bug which broke in-tree build, thanks rmclure] Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au
2023-03-29 00:23:34 -07:00
echo
$(foreach cfg,$(generated_configs),
printf " %-27s - Build for %s\\n" $(cfg) $(subst _defconfig,,$(cfg));)
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
endef
powerpc/Makefile: Mark phony targets as PHONY Some of our phony targets are not marked as such. This can lead to confusing errors, eg: $ make clean $ touch install $ make install make: 'install' is up to date. $ Fix it by adding them to the PHONY variable which is marked phony in the top-level Makefile, or in scripts/Makefile.build for the boot Makefile. Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200219000434.15872-1-mpe@ellerman.id.au
2020-02-18 17:04:34 -07:00
PHONY += install
x86: fix vdso_install breaks user "make install" I suggest to make the vdso_install step independent as in following patch. This solves the issue at ahnd and still gives us the posibility to install the files should they be needed. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-02-16 04:36:10 -07:00
install:
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-02 19:47:16 -07:00
$(call cmd,install)
[POWERPC] Enable make install make help on powerpc says make install is available. But it failed due to no rule to make install. This patch enables make install to work. Signed-off-by: Akinobu Mita <mita@fixstars.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-10 04:05:31 -07:00
powerpc/vdso: Retrieve sigtramp offsets at buildtime This is copied from arm64. Instead of using runtime generated signal trampoline offsets, get offsets at buildtime. If the said trampoline doesn't exist, build will fail. So no need to check whether the trampoline exists or not in the VDSO. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/f8bfd6812c3e3678b1cdb4d55a52f9eb022b40d3.1601197618.git.christophe.leroy@csgroup.eu
2020-09-27 02:16:33 -07:00
ifeq ($(KBUILD_EXTMOD),)
# We need to generate vdso-offsets.h before compiling certain files in kernel/.
# In order to do that, we should use the archprepare target, but we can't since
# asm-offsets.h is included in some files used to generate vdso-offsets.h, and
# asm-offsets.h is built in prepare0, for which archprepare is a dependency.
# Therefore we need to generate the header after prepare0 has been made, hence
# this hack.
prepare: vdso_prepare
vdso_prepare: prepare0
$(if $(CONFIG_VDSO32),$(Q)$(MAKE) \
powerpc/vdso: Merge vdso64 and vdso32 into a single directory merge vdso64 into vdso32 and rename it vdso. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/4dbe05cc130f6a0858d09ac72e436c373cb08b70.1642782130.git.christophe.leroy@csgroup.eu
2022-01-21 09:30:27 -07:00
$(build)=arch/powerpc/kernel/vdso include/generated/vdso32-offsets.h)
powerpc/vdso: Retrieve sigtramp offsets at buildtime This is copied from arm64. Instead of using runtime generated signal trampoline offsets, get offsets at buildtime. If the said trampoline doesn't exist, build will fail. So no need to check whether the trampoline exists or not in the VDSO. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/f8bfd6812c3e3678b1cdb4d55a52f9eb022b40d3.1601197618.git.christophe.leroy@csgroup.eu
2020-09-27 02:16:33 -07:00
$(if $(CONFIG_PPC64),$(Q)$(MAKE) \
powerpc/vdso: Merge vdso64 and vdso32 into a single directory merge vdso64 into vdso32 and rename it vdso. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/4dbe05cc130f6a0858d09ac72e436c373cb08b70.1642782130.git.christophe.leroy@csgroup.eu
2022-01-21 09:30:27 -07:00
$(build)=arch/powerpc/kernel/vdso include/generated/vdso64-offsets.h)
powerpc/vdso: Retrieve sigtramp offsets at buildtime This is copied from arm64. Instead of using runtime generated signal trampoline offsets, get offsets at buildtime. If the said trampoline doesn't exist, build will fail. So no need to check whether the trampoline exists or not in the VDSO. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/f8bfd6812c3e3678b1cdb4d55a52f9eb022b40d3.1601197618.git.christophe.leroy@csgroup.eu
2020-09-27 02:16:33 -07:00
endif
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
archprepare: checkbin
powerpc: generate uapi header and system call table files System call table generation script must be run to gener- ate unistd_32/64.h and syscall_table_32/64/c32/spu.h files. This patch will have changes which will invokes the script. This patch will generate unistd_32/64.h and syscall_table- _32/64/c32/spu.h files by the syscall table generation script invoked by parisc/Makefile and the generated files against the removed files must be identical. The generated uapi header file will be included in uapi/- asm/unistd.h and generated system call table header file will be included by kernel/systbl.S file. Signed-off-by: Firoz Khan <firoz.khan@linaro.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-12-17 03:40:36 -07:00
archheaders:
$(Q)$(MAKE) $(build)=arch/powerpc/kernel/syscalls all
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
ifdef CONFIG_STACKPROTECTOR
prepare: stack_protector_prepare
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
powerpc/Makefile: Mark phony targets as PHONY Some of our phony targets are not marked as such. This can lead to confusing errors, eg: $ make clean $ touch install $ make install make: 'install' is up to date. $ Fix it by adding them to the PHONY variable which is marked phony in the top-level Makefile, or in scripts/Makefile.build for the boot Makefile. Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200219000434.15872-1-mpe@ellerman.id.au
2020-02-18 17:04:34 -07:00
PHONY += stack_protector_prepare
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
stack_protector_prepare: prepare0
powerpc/64: add stack protector support On PPC64, as register r13 points to the paca_struct at all time, this patch adds a copy of the canary there, which is copied at task_switch. That new canary is then used by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r13 -mstack-protector-guard-offset=offsetof(struct paca_struct, canary)) Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:55 -07:00
ifdef CONFIG_PPC64
$(eval KBUILD_CFLAGS += -mstack-protector-guard-offset=$(shell awk '{if ($$2 == "PACA_CANARY") print $$3;}' include/generated/asm-offsets.h))
else
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
$(eval KBUILD_CFLAGS += -mstack-protector-guard-offset=$(shell awk '{if ($$2 == "TASK_CANARY") print $$3;}' include/generated/asm-offsets.h))
endif
powerpc/64: add stack protector support On PPC64, as register r13 points to the paca_struct at all time, this patch adds a copy of the canary there, which is copied at task_switch. That new canary is then used by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r13 -mstack-protector-guard-offset=offsetof(struct paca_struct, canary)) Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:55 -07:00
endif
powerpc/32: add stack protector support This functionality was tentatively added in the past (commit 6533b7c16ee5 ("powerpc: Initial stack protector (-fstack-protector) support")) but had to be reverted (commit f2574030b0e3 ("powerpc: Revert the initial stack protector support") because of GCC implementing it differently whether it had been built with libc support or not. Now, GCC offers the possibility to manually set the stack-protector mode (global or tls) regardless of libc support. This time, the patch selects HAVE_STACKPROTECTOR only if -mstack-protector-guard=tls is supported by GCC. On PPC32, as register r2 points to current task_struct at all time, the stack_canary located inside task_struct can be used directly by using the following GCC options: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary)) The protector is disabled for prom_init and bootx_init as it is too early to handle it properly. $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT [ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64 [ 134.943666] [ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835 [ 134.963380] Call Trace: [ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable) [ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260 [ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64 [ 134.982769] [c6615e00] [ffffffff] 0xffffffff Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-27 00:05:53 -07:00
powerpc/Makefile: Mark phony targets as PHONY Some of our phony targets are not marked as such. This can lead to confusing errors, eg: $ make clean $ touch install $ make install make: 'install' is up to date. $ Fix it by adding them to the PHONY variable which is marked phony in the top-level Makefile, or in scripts/Makefile.build for the boot Makefile. Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200219000434.15872-1-mpe@ellerman.id.au
2020-02-18 17:04:34 -07:00
PHONY += checkbin
powerpc: Merge enough to start building in arch/powerpc. This creates the directory structure under arch/powerpc and a bunch of Kconfig files. It does a first-cut merge of arch/powerpc/mm, arch/powerpc/lib and arch/powerpc/platforms/powermac. This is enough to build a 32-bit powermac kernel with ARCH=powerpc. For now we are getting some unmerged files from arch/ppc/kernel and arch/ppc/syslib, or arch/ppc64/kernel. This makes some minor changes to files in those directories and files outside arch/powerpc. The boot directory is still not merged. That's going to be interesting. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-25 23:04:21 -07:00
checkbin:
powerpc: Fail build if using recordmcount with binutils v2.37 binutils v2.37 drops unused section symbols, which prevents recordmcount from capturing mcount locations in sections that have no non-weak symbols. This results in a build failure with a message such as: Cannot find symbol for section 12: .text.perf_callchain_kernel. kernel/events/callchain.o: failed The change to binutils was reverted for v2.38, so this behavior is specific to binutils v2.37: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b Objtool is able to cope with such sections, so this issue is specific to recordmcount. Fail the build and print a warning if binutils v2.37 is detected and if we are using recordmcount. Cc: stable@vger.kernel.org Suggested-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Naveen N Rao <naveen@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230530061436.56925-1-naveen@kernel.org
2023-05-29 23:14:36 -07:00
@if test "x${CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT}" = "xy" -a \
"x${CONFIG_LD_IS_BFD}" = "xy" -a \
"${CONFIG_LD_VERSION}" = "23700" ; then \
echo -n '*** binutils 2.37 drops unused section symbols, which recordmcount ' ; \
echo 'is unable to handle.' ; \
echo '*** Please use a different binutils version.' ; \
false ; \
fi
Copy Permalink