#
ca3d3aa1 |
|
29-Feb-2024 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc: Remove cpu-as-y completely cpu-as-y is there to force assembler building options. But there is no need for that. GCC is passed the necessary options and it automatically pass the appropriate option to GAS. GCC is given -maltivec when relevant, so no need for -Wa,-maltivec either. And -Wa,-many is wrong as it will hide innapropriate instructions. Better to detect them and handle them on a case by case basis. The setting of -Wa,-many was added by commit 960e30029863 ("powerpc/Makefile: Fix PPC_BOOK3S_64 ASFLAGS") in order to fix an issue with clang and the passed -Wa,-mpower4 option. But we have now removed it expecting the compiler to automatically pass the proper options and instructions based on -mcpu=power4. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240229122521.762431-5-mpe@ellerman.id.au
|
#
af1ebca5 |
|
29-Feb-2024 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
2947a456 |
|
09-Jan-2024 |
Nathan Chancellor <nathan@kernel.org> |
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>
|
#
402928b5 |
|
06-Dec-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
22f17b02 |
|
06-Dec-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
dc420877 |
|
06-Dec-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
50832720 |
|
29-Mar-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
0f71dcfb |
|
19-Jun-2023 |
Naveen N Rao <naveen@kernel.org> |
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
|
#
54a11654 |
|
19-Jan-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
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
|
#
25ea739e |
|
30-May-2023 |
Naveen N Rao <naveen@kernel.org> |
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
|
#
f5df87b8 |
|
06-Jun-2023 |
Nicholas Piggin <npiggin@gmail.com> |
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
|
#
9ecda934 |
|
14-Apr-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
596ddea8 |
|
14-Apr-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
bac94962 |
|
14-Apr-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
22db99d6 |
|
29-Mar-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
228c7a95 |
|
29-Mar-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
77e69ee7 |
|
07-Apr-2023 |
Nicholas Piggin <npiggin@gmail.com> |
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
|
#
7e3a68be |
|
07-Apr-2023 |
Nicholas Piggin <npiggin@gmail.com> |
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
|
#
dc5dac74 |
|
07-Apr-2023 |
Nicholas Piggin <npiggin@gmail.com> |
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
|
#
78f09298 |
|
04-Apr-2023 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
7c3bd836 |
|
15-Feb-2023 |
Nathan Chancellor <nathan@kernel.org> |
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
|
#
31f48f16 |
|
11-Jan-2023 |
Nathan Chancellor <nathan@kernel.org> |
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>
|
#
bfb03af7 |
|
19-Dec-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc: Pass correct CPU reference to assembler Jan-Benedict reported issue with building ppc64e_defconfig with mainline GCC work: powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -Wa,-me500 -Wa,-me500mc -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages: arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `stdu' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `stdu' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `std' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `std' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `ld' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `ld' ... make[1]: *** [arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/gettimeofday-64.o] Error 1 make: *** [arch/powerpc/Makefile:387: vdso_prepare] Error 2 This is due to assembler being called with -me500mc which is a 32 bits target. The problem comes from the fact that CONFIG_PPC_E500MC is selected for both the e500mc (32 bits) and the e5500 (64 bits), and therefore the following makefile rule is wrong: cpu-as-$(CONFIG_PPC_E500MC) += $(call as-option,-Wa$(comma)-me500mc) Today we have CONFIG_TARGET_CPU which provides the identification of the expected CPU, it is used for GCC. Once GCC knows the target CPU, it adds the correct CPU option to assembler, no need to add it explicitly. With that change (And also commit 45f7091aac35 ("powerpc/64: Set default CPU in Kconfig")), it now is: powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -mcpu=e500mc64 -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Pali Rohár <pali@kernel.org> [mpe: Retain -Wa,-mpower4 -Wa,-many for Book3S 64 builds for now] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/758ad54128fa9dd2fdedc4c511592111cbded900.1671475543.git.christophe.leroy@csgroup.eu
|
#
45f7091a |
|
25-Jan-2023 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
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
|
#
a400c287 |
|
23-Jan-2023 |
Nicolas Saenz Julienne <nsaenz@kernel.org> |
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>
|
#
ce697cce |
|
24-Sep-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: remove head-y syntax Kbuild puts the objects listed in head-y at the head of vmlinux. Conventionally, we do this for head*.S, which contains the kernel entry point. A counter approach is to control the section order by the linker script. Actually, the code marked as __HEAD goes into the ".head.text" section, which is placed before the normal ".text" section. I do not know if both of them are needed. From the build system perspective, head-y is not mandatory. If you can achieve the proper code placement by the linker script only, it would be cleaner. I collected the current head-y objects into head-object-list.txt. It is a whitelist. My hope is it will be reduced in the long run. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
#
4b2a9315 |
|
22-Sep-2022 |
Nicholas Piggin <npiggin@gmail.com> |
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
|
#
7fd123e5 |
|
20-Sep-2022 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64s: update cpu selection options Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so make that clear in the option name. The POWER5_CPU option is dropped because it's uncommon, and GENERIC_CPU covers it. -mtune= before power8 is dropped because the minimum gcc version supports power8, and tuning is made consistent between big and little endian. A 970 option is added for PowerPC 970 / G5 because they still have a user base, and -mtune=power8 does not generate good code for the 970. This also updates the ISA versions document to add Power4/Power4+ because I didn't realise Power4+ used 2.01. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220921014103.587954-2-npiggin@gmail.com
|
#
58ec7f06 |
|
20-Sep-2022 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64s: Fix GENERIC_CPU build flags for PPC970 / G5 Big-endian GENERIC_CPU supports 970, but builds with -mcpu=power5. POWER5 is ISA v2.02 whereas 970 is v2.01 plus Altivec. 2.02 added the popcntb instruction which a compiler might use. Use -mcpu=power4. Fixes: 471d7ff8b51b ("powerpc/64s: Remove POWER4 support") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220921014103.587954-1-npiggin@gmail.com
|
#
688de017 |
|
19-Sep-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc: Change CONFIG_E500 to CONFIG_PPC_E500 It will be used outside arch/powerpc, make it clear its a powerpc configuration item. And we already have CONFIG_PPC_E500MC, so that will make it more consistent. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/e63b22083c11c4300f4a82d3123a46e5fdd54fa6.1663606876.git.christophe.leroy@csgroup.eu
|
#
dfc3095c |
|
19-Sep-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc: Remove CONFIG_FSL_BOOKE PPC_85xx is PPC32 only. PPC_85xx always selects E500 and is the only PPC32 that selects E500. FSL_BOOKE is selected when E500 and PPC32 are selected. So FSL_BOOKE is redundant with PPC_85xx. Remove FSL_BOOKE. And rename four files accordingly. cpu_setup_fsl_booke.S is not renamed because it is linked to PPC_FSL_BOOK3E and not to FSL_BOOKE as suggested by its name. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/08e3e15594e66d63b9e89c5b4f9c35153913c28f.1663606875.git.christophe.leroy@csgroup.eu
|
#
d6b551b8 |
|
11-Jul-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei') With GCC 12, corenet64_smp_defconfig leads to the following build errors: CC arch/powerpc/kernel/irq.o {standard input}: Assembler messages: {standard input}:3616: Error: unrecognized opcode: `wrteei' {standard input}:5689: Error: unrecognized opcode: `wrteei' CC arch/powerpc/kernel/pmc.o {standard input}: Assembler messages: {standard input}:42: Error: unrecognized opcode: `mfpmr' {standard input}:53: Error: unrecognized opcode: `mtpmr' CC arch/powerpc/kernel/io.o {standard input}: Assembler messages: {standard input}:376: Error: unrecognized opcode: `mbar' ... CC arch/powerpc/mm/nohash/book3e_hugetlbpage.o {standard input}: Assembler messages: {standard input}:291: Error: unrecognized opcode: `tlbsx' {standard input}:482: Error: unrecognized opcode: `tlbwe' {standard input}:608: Error: unrecognized opcode: `lbarx' {standard input}:608: Error: unrecognized opcode: `stbcx.' -mpcu=powerpc64 cannot be used anymore for book3e, it must be a booke CPU. But then we get: CC arch/powerpc/lib/xor_vmx.o cc1: error: AltiVec not supported in this target Altivec is not supported with -mcpu=e5500 so don't allow selection of altivec when e5500 is selected. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/77255a5a957967723b84d0356d9e5fb21569f4e8.1657549153.git.christophe.leroy@csgroup.eu
|
#
446cda1b |
|
11-Jul-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc/32: Don't always pass -mcpu=powerpc to the compiler Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic machine type for 32-bit compile"), when building a 32 bits kernel with a bi-arch version of GCC, or when building a book3s/32 kernel, the option -mcpu=powerpc is passed to GCC at all time, relying on it being eventually overriden by a subsequent -mcpu=xxxx. But when building the same kernel with a 32 bits only version of GCC, that is not done, relying on gcc being built with the expected default CPU. This logic has two problems. First, it is a bit fragile to rely on whether the GCC version is bi-arch or not, because today we can have bi-arch versions of GCC configured with a 32 bits default. Second, there are some versions of GCC which don't support -mcpu=powerpc, for instance for e500 SPE-only versions. So, stop relying on this approximative logic and allow the user to decide whether he/she wants to use the toolchain's default CPU or if he/she wants to set one, and allow only possible CPUs based on the selected target. Reported-by: Pali Rohár <pali@kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/d4df724691351531bf46d685d654689e5dfa0d74.1657549153.git.christophe.leroy@csgroup.eu
|
#
5b89492c |
|
08-May-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
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
|
#
661aa880 |
|
08-May-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
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
|
#
f774f5bb |
|
02-May-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
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>
|
#
2863dd2d |
|
15-Feb-2022 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc/Makefile: Don't pass -mcpu=powerpc64 when building 32-bit When CONFIG_GENERIC_CPU=y (true for all our defconfigs) we pass -mcpu=powerpc64 to the compiler, even when we're building a 32-bit kernel. This happens because we have an ifdef CONFIG_PPC_BOOK3S_64/else block in the Makefile that was written before 32-bit supported GENERIC_CPU. Prior to that the else block only applied to 64-bit Book3E. The GCC man page says -mcpu=powerpc64 "[specifies] a pure ... 64-bit big endian PowerPC ... architecture machine [type], with an appropriate, generic processor model assumed for scheduling purposes." It's unclear how that interacts with -m32, which we are also passing, although obviously -m32 is taking precedence in some sense, as the 32-bit kernel only contains 32-bit instructions. This was noticed by inspection, not via any bug reports, but it does affect code generation. Comparing before/after code generation, there are some changes to instruction scheduling, and the after case (with -mcpu=powerpc64 removed) the compiler seems more keen to use r8. Fix it by making the else case only apply to Book3E 64, which excludes 32-bit. Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220215112858.304779-1-mpe@ellerman.id.au
|
#
81df21de |
|
15-Feb-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc: Fix 'sparse' checking on PPC64le 'sparse' is architecture agnostic and knows nothing about ELF ABI version. Just like it gets arch and powerpc type and endian from Makefile, it also need to get _CALL_ELF from there, otherwise it won't set PPC64_ELF_ABI_v2 macro for PPC64le and won't check the correct code. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/ac1312f2451aa558bb2a8806b4d0aa2020f0c176.1644928018.git.christophe.leroy@csgroup.eu
|
#
fd1feade |
|
21-Jan-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
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
|
#
f5140cab |
|
20-Dec-2021 |
Daniel Axtens <dja@axtens.net> |
powerpc: check for support for -Wa,-m{power4,any} LLVM's integrated assembler does not like either -Wa,-mpower4 or -Wa,-many. So just don't pass them if they're not supported. Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211221055904.555763-3-aik@ozlabs.ru
|
#
a3ad84da |
|
20-Dec-2021 |
Alan Modra <amodra@au1.ibm.com> |
powerpc/toc: Future proof kernel toc This patch future-proofs the kernel against linker changes that might put the toc pointer at some location other than .got+0x8000, by replacing __toc_start+0x8000 with .TOC. throughout. If the kernel's idea of the toc pointer doesn't agree with the linker, bad things happen. prom_init.c code relocating its toc is also changed so that a symbolic __prom_init_toc_start toc-pointer relative address is calculated rather than assuming that it is always at toc-pointer - 0x8000. The length calculations loading values from the toc are also avoided. It's a little incestuous to do that with unreloc_toc picking up adjusted values (which is fine in practice, they both adjust by the same amount if all goes well). I've also changed the way .got is aligned in vmlinux.lds and zImage.lds, mostly so that dumping out section info by objdump or readelf plainly shows the alignment is 256. This linker script feature was added 2005-09-27, available in FSF binutils releases from 2.17 onwards. Should be safe to use in the kernel, I think. Finally, put *(.got) before the prom_init.o entry which only needs *(.toc), so that the GOT header goes in the correct place. I don't believe this makes any difference for the kernel as it would for dynamic objects being loaded by ld.so. That change is just to stop lusers who blindly copy kernel scripts being led astray. Of course, this change needs the prom_init.c changes. Some notes on .toc and .got. .toc is a compiler generated section of addresses. .got is a linker generated section of addresses, generally built when the linker sees R_*_*GOT* relocations. In the case of powerpc64 ld.bfd, there are multiple generated .got sections, one per input object file. So you can somewhat reasonably write in a linker script an input section statement like *prom_init.o(.got .toc) to mean "the .got and .toc section for files matching *prom_init.o". On other architectures that doesn't make sense, because the linker generally has just one .got section. Even on powerpc64, note well that the GOT entries for prom_init.o may be merged with GOT entries from other objects. That means that if prom_init.o references, say, _end via some GOT relocation, and some other object also references _end via a GOT relocation, the GOT entry for _end may be in the range __prom_init_toc_start to __prom_init_toc_end and if the kernel does something special to GOT/TOC entries in that range then the value of _end as seen by objects other than prom_init.o will be affected. On the other hand the GOT entry for _end may not be in the range __prom_init_toc_start to __prom_init_toc_end. Which way it turns out is deterministic but a detail of linker operation that should not be relied on. A feature of ld.bfd is that input .toc (and .got) sections matching one linker input section statement may be sorted, to put entries used by small-model code first, near the toc base. This is why scripts for powerpc64 normally use *(.got .toc) rather than *(.got) *(.toc), since the first form allows more freedom to sort. Another feature of ld.bfd is that indirect addressing sequences using the GOT/TOC may be edited by the linker to relative addressing. In many cases relative addressing would be emitted by gcc for -mcmodel=medium if you appropriately decorate variable declarations with non-default visibility. The original patch is here: https://lore.kernel.org/linuxppc-dev/20210310034813.GM6042@bubble.grove.modra.org/ Signed-off-by: Alan Modra <amodra@au1.ibm.com> [aik: removed non-relocatable which is gone in 24d33ac5b8ffb] [aik: added <=2.24 check] [aik: because of llvm-as, kernel_toc_addr() uses "mr" instead of global register variable] Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211221055904.555763-2-aik@ozlabs.ru
|
#
8212f898 |
|
13-Oct-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
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)
|
#
336868af |
|
14-Sep-2021 |
Ard Biesheuvel <ardb@kernel.org> |
powerpc: smp: remove hack to obtain offset of task_struct::cpu Instead of relying on awful hacks to obtain the offset of the cpu field in struct task_struct, move it back into struct thread_info, which does not create the same level of circular dependency hell when trying to include the header file that defines it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
03557853 |
|
13-Aug-2021 |
Fangrui Song <maskray@google.com> |
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
|
#
86ff0bce |
|
29-Jul-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
powerpc: move the install rule to arch/powerpc/Makefile Currently, the install target in arch/powerpc/Makefile descends into arch/powerpc/boot/Makefile to invoke the shell script, but there is no good reason to do so. arch/powerpc/Makefile can run the shell script directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210729141937.445051-3-masahiroy@kernel.org
|
#
d92cc4d5 |
|
12-May-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild arch/$(SRCARCH)/Kbuild is useful for Makefile cleanups because you can use the obj-y syntax. Add an empty file if it is missing in arch/$(SRCARCH)/. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
f259fb89 |
|
28-Apr-2021 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
3027a37c |
|
18-Apr-2021 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc: Only define _TASK_CPU for 32-bit We have some interesting code in our Makefile to define _TASK_CPU, based on awk'ing the value out of asm-offsets.h. It exists to circumvent some circular header dependencies that prevent us from referring to task_struct in the relevant code. See the comment around _TASK_CPU in smp.h for more detail. Maybe one day we can come up with a better solution, but for now we can at least limit that logic to 32-bit, because it's not needed for 64-bit. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210418131641.1186227-1-mpe@ellerman.id.au
|
#
802b5560 |
|
09-Mar-2021 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc/Makefile: Remove workaround for gcc versions below 4.9 Commit 6ec4476ac825 ("Raise gcc version requirement to 4.9") made it impossible to build with gcc 4.8 and under. Remove related workaround. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/a1e552006b8c51f23edd2f6cabdd9a986c631146.1615380184.git.christophe.leroy@csgroup.eu
|
#
052c805a |
|
12-Dec-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: LD_VERSION redenomination Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion macros") introduced scripts/ld-version.sh for GCC LTO. At that time, this script handled 5 version fields because GCC LTO needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272) The code snippet from the submitted patch was as follows: # We need HJ Lu's Linux binutils because mainline binutils does not # support mixing assembler and LTO code in the same ld -r object. # XXX check if the gcc plugin ld is the expected one too # XXX some Fedora binutils should also support it. How to check for that? ifeq ($(call ld-ifversion,-ge,22710001,y),y) ... However, GCC LTO was not merged into the mainline after all. (https://lkml.org/lkml/2014/4/8/272) So, the 4th and 5th fields were never used, and finally removed by commit 0d61ed17dd30 ("ld-version: Drop the 4th and 5th version components"). Since then, the last 4-digits returned by this script is always zeros. Remove the meaningless last 4-digits. This makes the version format consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
#
7a3c90df |
|
14-Jan-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
arch: powerpc: Stop building and using oprofile The "oprofile" user-space tools don't use the kernel OPROFILE support any more, and haven't in a long time. User-space has been converted to the perf interfaces. This commits stops building oprofile for powerpc and removes any reference to it from directories in arch/powerpc/ apart from arch/powerpc/oprofile, which will be removed in the next commit (this is broken into two commits as the size of the commit became very big, ~5k lines). Note that the member "oprofile_cpu_type" in "struct cpu_spec" isn't removed as it was also used by other parts of the code. Suggested-by: Christoph Hellwig <hch@infradead.org> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Robert Richter <rric@kernel.org> Acked-by: William Cohen <wcohen@redhat.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
#
5d823447 |
|
24-Nov-2020 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
91bf6955 |
|
27-Sep-2020 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
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
|
#
7fe2de24 |
|
27-Sep-2020 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc/vdso: Stripped VDSO is not needed, don't build it Since commit 24b659a13866 ("powerpc: Use unstripped VDSO image for more accurate profiling data"), only the unstripped VDSO image has been used. Partially revert commit 8150caad0226 ("[POWERPC] powerpc vDSO: install unstripped copies on disk") to avoid building the stripped version. And the unstripped version in $(MODLIB)/vdso/ is not required anymore as it is the one embedded in the kernel image. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/5986ca25be44fe6e9790486304507f240077d8c4.1601197618.git.christophe.leroy@csgroup.eu
|
#
59612b24 |
|
19-Nov-2020 |
Nathan Chancellor <nathan@kernel.org> |
kbuild: Hoist '--orphan-handling' into Kconfig Currently, '--orphan-handling=warn' is spread out across four different architectures in their respective Makefiles, which makes it a little unruly to deal with in case it needs to be disabled for a specific linker version (in this case, ld.lld 10.0.1). To make it easier to control this, hoist this warning into Kconfig and the main Makefile so that disabling it is simpler, as the warning will only be enabled in a couple places (main Makefile and a couple of compressed boot folders that blow away LDFLAGS_vmlinx) and making it conditional is easier due to Kconfig syntax. One small additional benefit of this is saving a call to ld-option on incremental builds because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN. To keep the list of supported architectures the same, introduce CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to gain this automatically after all of the sections are specified and size asserted. A special thanks to Kees Cook for the help text on this config. Link: https://github.com/ClangBuiltLinux/linux/issues/1187 Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
#
e02152ba |
|
16-Nov-2020 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc: Drop -me200 addition to build flags Currently a build with CONFIG_E200=y will fail with: Error: invalid switch -me200 Error: unrecognized option -me200 Upstream binutils has never supported an -me200 option. Presumably it was supported at some point by either a fork or Freescale internal binutils. We can't support code that we can't even build test, so drop the addition of -me200 to the build flags, so we can at least build with CONFIG_E200=y. Reported-by: Németh Márton <nm127@freemail.hu> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Scott Wood <oss@buserror.net> Link: https://lore.kernel.org/r/20201116120913.165317-1-mpe@ellerman.id.au
|
#
533090e5 |
|
06-Oct-2020 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
powerpc/32s: Rename head_32.S to head_book3s_32.S Unlike PPC64 which had a single head_64.S, PPC32 are multiple ones. There is the head_32.S, selected by default based on the value of BITS and overridden based on some CONFIG_ values. This leads to thinking that it may be selected by different types of PPC32 platform but indeed it ends up being selected by book3s/32 only. Make that explicit by: - Not doing any default selection based on BITS. - Renaming head_32.S to head_book3s_32.S. - Get head_book3s_32.S selected only by CONFIG_PPC_BOOK3S_32. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> [mpe: Fix head_$(BITS).o reference in arch/powerpc/Makefile] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/319d379f696412681c66a987cc75e6abf8f958d2.1601975100.git.christophe.leroy@csgroup.eu
|
#
596b0474 |
|
07-Sep-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: preprocess module linker script There was a request to preprocess the module linker script like we do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512) The difference between vmlinux.lds and module.lds is that the latter is needed for external module builds, thus must be cleaned up by 'make mrproper' instead of 'make clean'. Also, it must be created by 'make modules_prepare'. You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by 'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to arch/$(SRCARCH)/include/asm/module.lds.h, which is included from scripts/module.lds.S. scripts/module.lds is fine because 'make clean' keeps all the build artifacts under scripts/. You can add arch-specific sections in <asm/module.lds.h>. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Jessica Yu <jeyu@kernel.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Jessica Yu <jeyu@kernel.org>
|
#
548ad77d |
|
22-Dec-2016 |
Imre Kaloz <kaloz@openwrt.org> |
powerpc/4xx: ppc4xx compile flag optimizations This patch splits up the compile flags between ppc40x and ppc44x. Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1482393968-60623-1-git-send-email-john@phrozen.org
|
#
ba96301c |
|
05-Mar-2020 |
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> |
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
|
#
c04868df |
|
05-Mar-2020 |
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> |
powerpc: Drop -fno-dwarf2-cfi-asm The original commit/discussion adding -fno-dwarf2-cfi-asm refers to R_PPC64_REL32 relocations not being handled by our module loader: http://lkml.kernel.org/r/20090224065112.GA6690@bombadil.infradead.org However, that is now handled thanks to commit 9f751b82b491d ("powerpc/module: Add support for R_PPC64_REL32 relocations"). So, drop this flag from our Makefile. Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/9b22a064de6eb1301d92177eb3a38559df7005d3.1583415544.git.naveen.n.rao@linux.vnet.ibm.com
|
#
d42c6d0f |
|
18-Feb-2020 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
465bfd9c |
|
18-Nov-2019 |
Nathan Chancellor <nathan@kernel.org> |
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
|
#
58b12eb2 |
|
28-May-2019 |
Michael Ellerman <mpe@ellerman.id.au> |
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
|
#
56347074 |
|
12-Jul-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
powerpc: remove meaningless KBUILD_ARFLAGS addition The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked in a useful way because it is always overridden by the following code in the top Makefile: # use the deterministic mode of AR if available KBUILD_ARFLAGS := $(call ar-option,D) The code in the top Makefile was added in 2011, by commit 40df759e2b9e ("kbuild: Fix build with binutils <= 2.19"). The KBUILD_ARFLAGS addition for ppc has always been dead code from the beginning. Nobody has reported a problem since 43c9127d94d6 ("powerpc: Add option to use thin archives"), so this code was unneeded. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190713032106.8509-1-yamada.masahiro@socionext.com
|
#
10df0638 |
|
14-Aug-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: rebuild modules when module linker scripts are updated Currently, the timestamp of module linker scripts are not checked. Add them to the dependency of modules so they are correctly rebuilt. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
117acf5c |
|
20-Aug-2019 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc/Makefile: Always pass --synthetic to nm if supported Back in 2004 we added logic to arch/ppc64/Makefile to pass the --synthetic option to nm, if it was supported by nm. Then in 2005 when arch/ppc64 and arch/ppc were merged, the logic to add --synthetic was moved inside an #ifdef CONFIG_PPC64 block within arch/powerpc/Makefile, and has remained there since. That was fine, though crufty, until recently when a change to init/Kconfig added a config time check that uses $(NM). On powerpc that leads to an infinite loop because Kconfig uses $(NM) to calculate some values, then the powerpc Makefile changes $(NM), which Kconfig notices and restarts. The original commit that added --synthetic simply said: On new toolchains we need to use nm --synthetic or we miss code symbols. And the nm man page says that the --synthetic option causes nm to: Include synthetic symbols in the output. These are special symbols created by the linker for various purposes. So it seems safe to always pass --synthetic if nm supports it, ie. on 32-bit and 64-bit, it just means 32-bit kernels might have more symbols reported (and in practice I see no extra symbols). Making it unconditional avoids the #ifdef CONFIG_PPC64, which in turn avoids the infinite loop. Debugged-by: Peter Collingbourne <pcc@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Will Deacon <will@kernel.org>
|
#
9cc342f6 |
|
13-May-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
treewide: prefix header search paths with $(srctree)/ Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter"). [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
ff6d2782 |
|
21-Mar-2019 |
Ben Hutchings <ben@decadent.org.uk> |
powerpc: vdso: Make vdso32 installation conditional in vdso_install The 32-bit vDSO is not needed and not normally built for 64-bit little-endian configurations. However, the vdso_install target still builds and installs it. Add the same config condition as is normally used for the build. Fixes: e0d005916994 ("powerpc/vdso: Disable building the 32-bit VDSO ...") Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
af5cd05d |
|
06-Feb-2019 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
a273fa38 |
|
06-Feb-2019 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
f7354cca |
|
31-Jan-2019 |
Christophe Leroy <christophe.leroy@c-s.fr> |
powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU Now that thread_info is similar to task_struct, its address is in r2 so CURRENT_THREAD_INFO() macro is useless. This patch removes it. This patch also moves the 'tovirt(r2, r2)' down just before the reactivation of MMU translation, so that we keep the physical address of 'current' in r2 until then. It avoids a few calls to tophys(). At the same time, as the 'cpu' field is not anymore in thread_info, TI_CPU is renamed TASK_CPU by this patch. It also allows to get rid of a couple of '#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE' as ACCOUNT_CPU_USER_ENTRY() and ACCOUNT_CPU_USER_EXIT() are empty when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not defined. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> [mpe: Fix a missed conversion of TI_CPU idle_6xx.S] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
ed1cd6de |
|
31-Jan-2019 |
Christophe Leroy <christophe.leroy@c-s.fr> |
powerpc: Activate CONFIG_THREAD_INFO_IN_TASK This patch activates CONFIG_THREAD_INFO_IN_TASK which moves the thread_info into task_struct. Moving thread_info into task_struct has the following advantages: - It protects thread_info from corruption in the case of stack overflows. - Its address is harder to determine if stack addresses are leaked, making a number of attacks more difficult. This has the following consequences: - thread_info is now located at the beginning of task_struct. - The 'cpu' field is now in task_struct, and only exists when CONFIG_SMP is active. - thread_info doesn't have anymore the 'task' field. This patch: - Removes all recopy of thread_info struct when the stack changes. - Changes the CURRENT_THREAD_INFO() macro to point to current. - Selects CONFIG_THREAD_INFO_IN_TASK. - Modifies raw_smp_processor_id() to get ->cpu from current without including linux/sched.h to avoid circular inclusion and without including asm/asm-offsets.h to avoid symbol names duplication between ASM constants and C constants. - Modifies klp_init_thread_info() to take a task_struct pointer argument. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Add task_stack.h to livepatch.h to fix build fails] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
b00899b8 |
|
10-Jan-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
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>
|
#
ab66dcc7 |
|
17-Dec-2018 |
Firoz Khan <firoz.khan@linaro.org> |
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>
|
#
72e7bcc2 |
|
11-Nov-2018 |
Joel Stanley <joel@jms.id.au> |
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>
|
#
ebd1d3b7 |
|
05-Dec-2018 |
Mathieu Malaterre <malat@debian.org> |
powerpc/32: Move the old 6xx -mcpu logic before the TARGET_CPU logic The code: ifdef CONFIG_6xx KBUILD_CFLAGS += -mcpu=powerpc endif was added in 2006 in commit f48b8296b315 ("[PATCH] powerpc32: Set cpu explicitly in kernel compiles"). This change was acceptable since the TARGET_CPU logic was 64-bit only. Since commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") this logic is no longer acceptable after the TARGET_CPU specific. It currently appends -mcpu=powerpc at the end of the command line, after any TARGET_CPU specific: gcc -Wp,-MD,init/.do_mounts.o.d ... -mcpu=powerpc -mbig-endian -m32 ... -mcpu=e300c2 ... -mcpu=powerpc ... ../init/do_mounts.c Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
63fea0af |
|
11-Nov-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
x86, powerpc: Remove -funit-at-a-time compiler option entirely GCC 4.6 manual says: -funit-at-a-time This option is left for compatibility reasons. -funit-at-a-time has no effect, while -fno-unit-at-a-time implies -fno-toplevel-reorder and -fno-section-anchors. Enabled by default. Remove it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Richard Weinberger <richard@sigma-star.at> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linuxppc-dev@lists.ozlabs.org Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1541990120-9643-3-git-send-email-yamada.masahiro@socionext.com
|
#
d7cceda9 |
|
17-Nov-2018 |
Christophe Leroy <christophe.leroy@c-s.fr> |
powerpc: change CONFIG_6xx to CONFIG_PPC_BOOK3S_32 Today we have: config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" [depends on PPC32 within a choice] config PPC_BOOK3S def_bool y depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 config 6xx def_bool y depends on PPC32 && PPC_BOOK3S 6xx is therefore redundant with PPC_BOOK3S_32. In order to make the code clearer, lets use preferably PPC_BOOK3S_32. This will allow to remove CONFIG_6xx in a later patch. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
721c01ba |
|
14-Nov-2018 |
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> |
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>
|
#
076f421d |
|
30-Oct-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
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>
|
#
c47ca98d |
|
09-Oct-2018 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc: Move core kernel logic into arch/powerpc/Kbuild This is a nice cleanup, arch/powerpc/Makefile is long and messy so moving this out helps a little. It also allows us to do: $ make arch/powerpc Which can be helpful if you just want to compile test some changes to arch code and not link everything. Finally it also gives us a single place to do subdir-cc-flags assignments which affect the whole of arch/powerpc, which we will do in a future patch. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
960e3002 |
|
10-Oct-2018 |
Joel Stanley <joel@jms.id.au> |
powerpc/Makefile: Fix PPC_BOOK3S_64 ASFLAGS Ever since commit 15a3204d24a3 ("powerpc/64s: Set assembler machine type to POWER4") we force -mpower4 to be passed to the assembler irrespective of the CFLAGS used (for Book3s 64). When building a powerpc64 kernel with clang, clang will not add -many to the assembler flags, so any instructions that the compiler has generated that are not available on power4 will cause an error: /usr/bin/as -a64 -mppc64 -mlittle-endian -mpower8 \ -I ./arch/powerpc/include -I ./arch/powerpc/include/generated \ -I ./include -I ./arch/powerpc/include/uapi \ -I ./arch/powerpc/include/generated/uapi -I ./include/uapi \ -I ./include/generated/uapi -I arch/powerpc -I arch/powerpc \ -maltivec -mpower4 -o init/do_mounts.o /tmp/do_mounts-3b0a3d.s /tmp/do_mounts-51ce54.s:748: Error: unrecognized opcode: `isel' GCC does include -many, so the GCC driven gas call will succeed: as -v -I ./arch/powerpc/include -I ./arch/powerpc/include/generated -I ./include -I ./arch/powerpc/include/uapi -I ./arch/powerpc/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -I arch/powerpc -I arch/powerpc -a64 -mpower8 -many -mlittle -maltivec -mpower4 -o init/do_mounts.o Note that isel is power7 and above for IBM CPUs. GCC only generates it for Power9 and above, but the above test was run against the clang generated assembly. Peter Bergner explains: When using -many -mpower4, gas will first try and find a matching power4 mnemonic and failing that, it will then allow any valid mnemonic that gas knows about. GCC's use of -many predates me though. IIRC, Alan looked at trying to remove it, but I forget why he didn't. Could be either a gcc or gas issue at the time. I'm not sure whether issue still exists or not. He and I have modified how gas works internally a fair amount since he tried removing gcc use of -many. I will also note that when using -many, gas will choose the first mnemonic that matches in the mnemonic table and we have (mostly) sorted the table so that server mnemonics show up earlier in the table than other mnemonics, so they'll be seen/chosen first. By explicitly setting -many we can build with Clang and GCC while retaining the -mpower4 option. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
bad96de8 |
|
01-Oct-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
powerpc: remove leftover code of old GCC version checks Clean up the leftover of commit f2910f0e6835 ("powerpc: remove old GCC version checks"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
06ec27ae |
|
27-Sep-2018 |
Christophe Leroy <christophe.leroy@c-s.fr> |
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>
|
#
c3ff2a51 |
|
27-Sep-2018 |
Christophe Leroy <christophe.leroy@c-s.fr> |
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>
|
#
37c8a5fa |
|
10-Jan-2018 |
Rob Herring <robh@kernel.org> |
kbuild: consolidate Devicetree dtb build rules There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Paul Burton <paul.burton@mips.com> Acked-by: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-kbuild@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: uclinux-h8-devel@lists.sourceforge.jp Cc: linux-mips@linux-mips.org Cc: nios2-dev@lists.rocketboards.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
1acf1cf8 |
|
13-Oct-2015 |
Rob Herring <robh@kernel.org> |
powerpc: build .dtb files in dts directory Align powerpc with other architectures which build the dtb files in the same directory as the dts files. This is also in line with most other build targets which are located in the same directory as the source. This move will help enable the 'dtbs' target which builds all the dtbs regardless of kernel config. This transition could break some scripts if they expect dtb files in the old location. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
6977f95e |
|
13-Sep-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer 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>
|
#
2a056f58 |
|
13-Sep-2018 |
Nicholas Piggin <npiggin@gmail.com> |
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>
|
#
f2910f0e |
|
13-Sep-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc: remove old GCC version checks GCC 4.6 is the minimum supported now. 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>
|
#
d503ac53 |
|
23-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
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>
|
#
cc62d20c |
|
07-Jun-2018 |
Christophe Leroy <christophe.leroy@c-s.fr> |
powerpc: Make CPU selection logic generic in Makefile At the time being, when adding a new CPU for selection, both Kconfig.cputype and Makefile have to be modified. This patch moves into Kconfig.cputype the name of the CPU to me passed to the -mcpu= argument. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Rename the option to TARGET_CPU to echo the gcc documentation] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
badf436f |
|
06-Aug-2018 |
Rodrigo R. Galvao <rosattig@linux.vnet.ibm.com> |
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>
|
#
64de5d8d |
|
09-Jul-2018 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
8db0c9d4 |
|
09-Jul-2018 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
4e4a4b75 |
|
12-Jul-2018 |
James Clarke <jrtc27@jrtc27.com> |
powerpc/Makefile: Assemble with -me500 when building for E500 Some of the assembly files use instructions specific to BookE or E500, which are rejected with the now-default -mcpu=powerpc, so we must pass -me500 to the assembler just as we pass -me200 for E200. Fixes: 4bf4f42a2feb ("powerpc/kbuild: Set default generic machine type for 32-bit compile") Signed-off-by: James Clarke <jrtc27@jrtc27.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
69a84059 |
|
14-Jun-2018 |
Michael Jeanson <mjeanson@efficios.com> |
powerpc/e500mc: Set assembler machine type to e500mc In binutils 2.26 a new opcode for the "wait" instruction was added for the POWER9 and has precedence over the one specific to the e500mc. Commit ebf714ff3756 ("powerpc/e500mc: Add support for the wait instruction in e500_idle") uses this instruction specifically on the e500mc to work around an erratum. This results in an invalid instruction in idle_e500 when we build for the e500mc on bintutils >= 2.26 with the default assembler machine type. Since multiplatform between e500 and non-e500 is not supported, set the assembler machine type globaly when CONFIG_PPC_E500MC=y. Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Paul Mackerras <paulus@samba.org> CC: Michael Ellerman <mpe@ellerman.id.au> CC: Kumar Gala <galak@kernel.crashing.org> CC: Vakul Garg <vakul.garg@nxp.com> CC: Scott Wood <swood@redhat.com> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> CC: linuxppc-dev@lists.ozlabs.org CC: linux-kernel@vger.kernel.org CC: stable@vger.kernel.org Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
abba7597 |
|
30-May-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/kbuild: move -mprofile-kernel check to Kconfig This eliminates the workaround that requires disabling -mprofile-kernel by default in Kconfig. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
#
1c389763 |
|
28-May-2018 |
Christophe Leroy <christophe.leroy@c-s.fr> |
powerpc/Makefile: set -mcpu=860 flag for the 8xx When compiled with GCC 8.1, vmlinux is significantly bigger than with GCC 4.8. When looking at the generated code with objdump, we notice that all functions and loops when a 16 bytes alignment. This significantly increases the size of the kernel. It is pointless and even counterproductive as on the 8xx 'nop' also consumes one clock cycle. Size of vmlinux with GCC 4.8: text data bss dec hex filename 5801948 1626076 457796 7885820 7853fc vmlinux Size of vmlinux with GCC 8.1: text data bss dec hex filename 6764592 1630652 456476 8851720 871108 vmlinux Size of vmlinux with GCC 8.1 and this patch: text data bss dec hex filename 6331544 1631756 456476 8419776 8079c0 vmlinux Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
1421dc6d |
|
30-May-2018 |
Nicholas Piggin <npiggin@gmail.com> |
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>
|
#
af3901cb |
|
30-May-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/kbuild: Remove CROSS32 defines from top level powerpc Makefile Switch VDSO32 build over to use CROSS32_COMPILE directly, and have it pass in -m32 after the standard c_flags. This allows endianness overrides to be removed and the endian and bitness flags moved into standard flags variables. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
4bf4f42a |
|
30-May-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/kbuild: Set default generic machine type for 32-bit compile Some 64-bit toolchains uses the wrong ISA variant for compiling 32-bit kernels, even with -m32. Debian's powerpc64le is one such case, and that is because it is built with --with-cpu=power8. So when cross compiling a 32-bit kernel with a 64-bit toolchain, set -mcpu=powerpc initially, which is the generic 32-bit powerpc machine type and scheduling model. CPU and platform code can override this with subsequent -mcpu flags if necessary. This is not done for 32-bit toolchains otherwise it would override their defaults, which are presumably set appropriately for the environment (moreso than a 64-bit cross compiler). This fixes a lot of build failures due to incompatible assembly when compiling 32-bit kernel with the Debian powerpc64le 64-bit toolchain. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
4b7e5532 |
|
20-Feb-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64s: Add POWER9 CPU type selection Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
a73657ea |
|
20-Feb-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64: Add GENERIC_CPU support for little endian Add GENERIC_CPU support for little-endian rather than using POWER8 specific selection for POWER9 and above. Restrict GENERIC_CPU to POWER8 and above on little endian. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Duplicate GENERIC_CPU to avoid a kbuild warning about the prompt being redefined. Spell out that GENERIC means >= POWER4 for BE.] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
471d7ff8 |
|
20-Feb-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64s: Remove POWER4 support POWER4 has been broken since at least the change 49d09bf2a6 ("powerpc/64s: Optimise MSR handling in exception handling"), which requires mtmsrd L=1 support. This was introduced in ISA v2.01, and POWER4 supports ISA v2.00. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
15a3204d |
|
20-Feb-2018 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64s: Set assembler machine type to POWER4 Rather than override the machine type in .S code (which can hide wrong or ambiguous code generation for the target), set the type to power4 for all assembly. This also means we need to be careful not to build power4-only code when we're not building for Book3S, such as the "power7" versions of copyuser/page/memcpy. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Fix Book3E build, don't build the "power7" variants for non-Book3S] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
51d42f0f |
|
28-Feb-2018 |
Segher Boessenkool <segher@kernel.crashing.org> |
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>
|
#
5c45b528 |
|
06-Dec-2017 |
Alan Modra <amodra@gmail.com> |
powerpc/modules: Fix alignment of .toc section in kernel modules powerpc64 gcc can generate code that offsets an address, to access part of an object in memory. If the address is a -mcmodel=medium toc pointer relative address then code like the following is possible. addis r9,r2,var@toc@ha ld r3,var@toc@l(r9) ld r4,(var+8)@toc@l(r9) This works fine so long as var is naturally aligned, *and* r2 is sufficiently aligned. If not, there is a possibility that the offset added to access var+8 wraps over a n*64k+32k boundary. Modules don't have any guarantee that r2 is sufficiently aligned. Moreover, code generated by older compilers generates a .toc section with 2**0 alignment, which can result in relocation failures at module load time even without the wrap problem. Thus, this patch links modules with an aligned .toc section (Makefile and module.lds changes), and forces alignment for out of tree modules or those without a .toc section (module_64.c changes). Signed-off-by: Alan Modra <amodra@gmail.com> [desnesn: updated patch to apply to powerpc-next kernel v4.15 ] Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com> [mpe: Fix out-of-tree build, swap -256 for ~0xff, reflow comment] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
968159c0 |
|
08-Aug-2017 |
Christophe Leroy <christophe.leroy@c-s.fr> |
powerpc/8xx: Getting rid of remaining use of CONFIG_8xx Two config options exist to define powerpc MPC8xx: * CONFIG_PPC_8xx * CONFIG_8xx arch/powerpc/platforms/Kconfig.cputype has contained the following comment about CONFIG_8xx item for some years: "# this is temp to handle compat with arch=ppc" arch/powerpc is now the only place with remaining use of CONFIG_8xx: get rid of them. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
3603c52f |
|
24-Jul-2017 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
b40b2386 |
|
25-Jul-2017 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
83a092cf |
|
11-May-2017 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc: Link warning for orphan sections Add --orphan-handling=warn to final link flags. This ensures we can handle all sections explicitly. This would have caught subtle breakage such as 7de3b27bac47da9de08409df1d69664acbb72197 at build-time. Also bring existing orphan sections into the fold: - .text.hot and .text.unlikely are compiler generated sections. - .sdata2, .dynsbss, .plt are used by PPC32 - We previously did not specify DWARF_DEBUG or STABS_DEBUG - DWARF_DEBUG did not include all DWARF sections that can be emitted - A number of sections are unused and can be discarded. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
efe0160c |
|
11-May-2017 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc/64: Linker on-demand sfpr functions for modules For final link, the powerpc64 linker generates fpr save/restore functions on-demand, placing them in the .sfpr section. Starting with binutils 2.25, these can be provided for non-final links with --save-restore-funcs. Use that where possible for module links. This saves about 200 bytes per module (~60kB) on powernv defconfig build. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
b71c9ffb |
|
25-Nov-2016 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc: Add arch/powerpc/tools directory Move a couple of existing scripts under there. Remove scripts directory: a script is a tool, a tool is not a script. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
f188d052 |
|
25-Nov-2016 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc: Use the new post-link pass to check relocations Currently powerpc has to introduce a dependency on its default build target zImage in order to run a relocation check pass over the linked vmlinux. This is deficient because the check is not run if the plain vmlinux target is built, or if one of the other boot targets is built. Switch to using the kbuild post-link pass, added in commit fbe6e37dab97 ("kbuild: add arch specific post-link Makefile") in order to run this check. In future powerpc will use this to do more complicated operations, but initially using it for something simple is a good first step. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
4dc831aa |
|
26-Nov-2016 |
Nicholas Piggin <npiggin@gmail.com> |
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>
|
#
0d976313 |
|
29-Nov-2016 |
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
powerpc: Add purgatory for kexec_file_load() implementation. This purgatory implementation is based on the versions from kexec-tools and kexec-lite, with additional changes. Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
1196d7aa |
|
21-Nov-2016 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
43c9127d |
|
18-Oct-2016 |
Nicholas Piggin <npiggin@gmail.com> |
powerpc: Add option to use thin archives Add an option to use thin archives to build the kernel. Thin archives are explained in commit a5967db9af51 ("kbuild: allow architectures to use thin archives instead of ld -r"). This is a gradual way to introduce the option to testers. Some change to the way we invoke ar is required so it can be used by scripts/link-vmlinux.sh. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Make it an explicit option not dependant on COMPILE_TEST] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
3a849815 |
|
19-Oct-2016 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc/book3s64: Always build for power4 or later When we're not compiling for a specific CPU, ie. none of the CONFIG_POWERx_CPU options are set, and CONFIG_GENERIC_CPU *is* set, we currently don't pass any -mcpu option to the compiler. This means the compiler builds for a "generic" Power CPU. But back in 2014 we dropped support for pre power4 CPUs in commit 468a33028edd ("powerpc: Drop support for pre-POWER4 cpus"). Given that, there's no point in building the kernel to run on pre power4 cpus. So update the flags we pass to the compiler when CONFIG_GENERIC_CPU is set, to specify -mcpu=power4. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
e0b80f00 |
|
22-Sep-2016 |
Claudiu Manoil <claudiu.manoil@nxp.com> |
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>
|
#
57073e27 |
|
11-Aug-2016 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
68201fbb |
|
11-Aug-2016 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
d312603a |
|
11-Aug-2016 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc/Makefile: CROSS32AS is unused, remove it In fact it makes no sense at all to have this defined on little endian builds. Since we disabled the 32-bit VDSO on little endian, we don't build any 32-bit code when building a little endian kernel. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
164af597 |
|
09-Aug-2016 |
Michael Ellerman <mpe@ellerman.id.au> |
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>
|
#
62c2c5cf |
|
11-Jul-2016 |
Daniel Axtens <dja@axtens.net> |
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>
|
#
9ddf0075 |
|
25-Nov-2015 |
Anton Blanchard <anton@samba.org> |
powerpc: Avoid -maltivec when using clang integrated assembler Check the assembler supports -maltivec by wrapping it with call as-option. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
43de32c5 |
|
22-Feb-2016 |
Alessio Igor Bogani <alessio.bogani@elettra.eu> |
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>
|
#
8c50b72a |
|
02-Mar-2016 |
Torsten Duwe <duwe@lst.de> |
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>
|
#
bed08b7e |
|
13-Oct-2015 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc/cell: Drop CONFIG_TUNE_CELL in favour of CONFIG_CELL_CPU The TUNE_CELL option allows you to build a kernel that runs on multiple CPUs but is tuned (ie. optimised) to run on Cell CPUs. Now days no one is building a distro in that fashion, and any users who are building custom kernels for their Cell machines are better off building with CONFIG_CELL_CPU, which builds a kernel that only runs on Cell and therefore can be optimised even more aggresively. Dropping the option also avoids confusing other users, who are presented with an option to tune for Cell when they are not building for a Cell CPU at all. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
2adc48a6 |
|
22-Sep-2015 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc: Add ppc64le_defconfig Based directly on ppc64_defconfig using merge_config. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
5631d9c4 |
|
19-Aug-2015 |
Michal Marek <mmarek@suse.com> |
kbuild: Fix clang detection We cannot detect clang before including the arch Makefile, because that can set the default cross compiler. We also cannot detect clang after including the arch Makefile, because powerpc wants to know about clang. Solve this by using an deferred variable. This costs us a few shell invocations, but this is only a constant number. Reported-by: Behan Webster <behanw@converseincode.com> Reported-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michal Marek <mmarek@suse.com>
|
#
44d54014 |
|
29-Jul-2015 |
Scott Wood <scottwood@freescale.com> |
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>
|
#
238abecd |
|
25-May-2015 |
Anton Blanchard <anton@samba.org> |
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>
|
#
92d6cf2d |
|
25-May-2015 |
Anton Blanchard <anton@samba.org> |
powerpc: Don't use -mno-strict-align on clang We added -mno-strict-align in commit f036b3681962 (powerpc: Work around little endian gcc bug) to fix gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Clang doesn't understand it. We need to use a conditional because we can't use the simpler call cc-option here. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
a50a862e |
|
25-May-2015 |
Anton Blanchard <anton@samba.org> |
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>
|
#
ea4d1a87 |
|
25-May-2015 |
Cyril Bur <cyrilbur@gmail.com> |
powerpc/configs: Replace pseries_le_defconfig with a Makefile target using merge_config Rather than continuing to maintain a copy of pseries_defconfig with CONFIG_CPU_LITTLE_ENDIAN enabled, use the generic merge_config script and use an le.config to enable little endian on top of pseries_defconfig without the need for a duplicated _defconfig file. This method will require less maintenance in the future and will ensure that both 'defconfigs' are always in sync. It is worth noting that the seemingly more simple approach of: pseries_le_defconfig: pseries_defconfig $(Q)$(MAKE) le.config Will not work when building using O=builddir. The obvious fix to that: pseries_le_defconfig: $(Q)$(MAKE) -f $(srctree)/Makefile pseries_defconfig le.config Also does not work. This is because if we have for example: config FOO depends on CPU_BIG_ENDIAN select BAR Then BAR will be enabled by the first call to kconfig (via pseries_defconfig), and then will remain enabled after we merge le.config, even though FOO will have been turned off. The solution is to ensure to only invoke the kconfig logic once, after we have merged all the config fragments. This ensures nothing is select'ed on that should then be disabled by the later merged configs. This is done through the explicit call to make olddefconfig Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Reviewed-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> [mpe: Massage change log, fix white space and use ARCH not SRCARCH] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
60e065f7 |
|
23-Apr-2015 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc: Reject binutils 2.24 when building little endian There is a bug in binutils 2.24 which causes miscompilation if we're building little endian and using weak symbols (which the kernel does). It is fixed in binutils commit 57fa7b8c7e59 "Correct elf_merge_st_other arguments for weak symbols", which is in binutils 2.25 and has been backported to the binutils 2.24 branch and has been picked up by most distros it seems. However if we're running stock 2.24 (no extra version) then the bug is present, so check for that and bail. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
e79c8385 |
|
21-Apr-2015 |
Michael Ellerman <mpe@ellerman.id.au> |
powerpc: Don't do gcc version checks if we're building with clang We have several checks for bad gcc versions in our Makefile. These don't apply if we're building with clang, so skip them in that case. The obvious check would be for ${COMPILER} = "gcc", but because of the way the logic in the top level Makefile conditionally sets COMPILER, it's possible that we're building with gcc but COMPILER was not set. So instead check for ${COMPILER} != "clang", which we know is currently the only other possibility. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
a71aa05e |
|
17-Mar-2015 |
Stephen Rothwell <sfr@canb.auug.org.au> |
powerpc: Convert relocs_check to a shell script using grep This runs a bit faster and removes another use of perl from the kernel build. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-By: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
665d92e3 |
|
24-Dec-2014 |
Masahiro Yamada <yamada.m@jp.panasonic.com> |
kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion The macros cc-version, cc-fullversion and ld-version take no argument. It is not necessary to add $(call ...) to invoke them. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Helge Deller <deller@gmx.de> [parisc] Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
ff2e466a |
|
15-Sep-2014 |
Anton Blanchard <anton@samba.org> |
powerpc: Add POWER8 CPU selection This allows the user to build a kernel targeted at POWER8 (ie gcc -mcpu=power8). Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
#
7998eb3d |
|
15-May-2014 |
Guenter Roeck <linux@roeck-us.net> |
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>
|
#
d5b35cff |
|
24-Feb-2014 |
Alistair Popple <alistair@popple.id.au> |
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>
|
#
721aeaa9 |
|
10-Mar-2014 |
Anton Blanchard <anton@samba.org> |
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>
|
#
58aedccb |
|
22-Apr-2014 |
Anton Blanchard <anton@samba.org> |
powerpc: Don't build assembly files with ABIv2 We avoid ABIv2 when building c files since commit b2ca8c89 (powerpc: Don't use ELFv2 ABI to build the kernel). Do the same for assembly files. Signed-off-by: Anton Blanchard <anton@samba.org>
|
#
d3d35d95 |
|
11-Mar-2014 |
Tony Breeds <tony@bakeyournoodle.com> |
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>
|
#
924dd50b |
|
20-Nov-2013 |
Michael Neuling <mikey@neuling.org> |
powerpc: Fix error when cross building TAGS & cscope Currently if I cross build TAGS or cscope from x86 I get this: % make ARCH=powerpc TAGS gcc-4.8.real: error: unrecognized command line option ‘-mbig-endian’ GEN TAGS % I'm not setting CROSS_COMPILE= as logically I shouldn't need to and I haven't needed to in the past when building TAGS or cscope. Also, the above completess correct as the error is not fatal to the build. This was caused by: commit d72b08017161ab385d4ae080ea415c9eb7ceef83 Author: Ian Munsie <imunsie@au1.ibm.com> powerpc: Add ability to build little endian kernels The below fixes this by testing for the -mbig-endian option before adding it. I've not done the same thing in the little endian case as if -mlittle-endian doesn't exist, we probably want to fail quickly as you probably have an old big endian compiler. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
cbf8a358 |
|
21-Nov-2013 |
Tiejun Chen <tiejun.chen@windriver.com> |
powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU well If CONFIG_ALTIVEC is enabled for CoreNet64, and if we also select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64 into $CFLAGS. But Altivec option not allowed with e500mc64, then some compiling errors occur like this: CC arch/powerpc/lib/xor_vmx.o arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1 make: *** [arch/powerpc/lib] Error 2 So we should restrict e500mc64 in altivec scenario. Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
|
#
b2ca8c89 |
|
20-Nov-2013 |
Alistair Popple <alistair@popple.id.au> |
powerpc: Don't use ELFv2 ABI to build the kernel The kernel doesn't build correctly using the ELFv2 ABI. This patch ensures that the ELFv1 ABI is used when building a kernel with an ELFv2 enabled compiler. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
f036b368 |
|
22-Sep-2013 |
Anton Blanchard <anton@samba.org> |
powerpc: Work around little endian gcc bug Temporarily work around an ICE we are seeing while building in little endian mode: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
d72b0801 |
|
22-Sep-2013 |
Ian Munsie <imunsie@au1.ibm.com> |
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>
|
#
a0588015 |
|
22-Sep-2013 |
Anton Blanchard <anton@samba.org> |
powerpc: uname should return ppc64le/ppcle on little endian builds We need to distinguish between big endian and little endian environments, so fix uname to return the right thing. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
847f56b0 |
|
15-Aug-2013 |
Scott Wood <scottwood@freescale.com> |
powerpc/e500: Set -mcpu flag for 32-bit e500 Unlike 64-bit, we don't currently support multiplatform between e500 and non-e500, so the -mcpu is not configurable at this time. -msoft-float is specified when testing for -mcpu=8540 because otherwise some older toolchains will fail with "error: E500 and FPRs not supported". Signed-off-by: Scott Wood <scottwood@freescale.com>
|
#
01718ba6 |
|
20-Aug-2013 |
Scott Wood <scottwood@freescale.com> |
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>
|
#
f49596a4 |
|
20-Aug-2013 |
Scott Wood <scottwood@freescale.com> |
powerpc/85xx: Remove -Wa,-me500 This caused lwsync to be converted to sync on 64-bit (on 32-bit lwsync is generated at runtime, and so wasn't affected). Not using lwsync caused a significant slowdown on certain workloads. Setting this flag for any e500-enabled build is also not friendly to multiplatform kernels. Signed-off-by: Scott Wood <scottwood@freescale.com>
|
#
5ba840ec |
|
13-Aug-2013 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
Revert "powerpc/e500: Update compilation flags with core specific options" This reverts commit c8db32c8669f7de05b820ee4934926405af52188. The commit breaks the build of all my 64-bit embedded configs. It looks like gcc-4.7.3 doesn't know about e5500. Additionally it incorrectly does -mcpu=e5500 on a config that has both e5500 and A2 support enabled. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> ---
|
#
c8db32c8 |
|
30-Jul-2013 |
Catalin Udma <catalin.udma@freescale.com> |
powerpc/e500: Update compilation flags with core specific options If CONFIG_E500 is enabled, the compilation flags are updated specifying the target core -mcpu=e5500/e500mc/8540 Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 The assembler option is redundant if the -mcpu= flag is set. The patch fixes the kernel compilation problem for e5500/e6500 when using gcc option -mcpu=e5500/e6500. Signed-off-by: Catalin Udma <catalin.udma@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
|
#
98679fb0 |
|
12-Dec-2012 |
Anton Blanchard <anton@samba.org> |
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>
|
#
1fbe9cf2 |
|
26-Nov-2012 |
Anton Blanchard <anton@samba.org> |
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>
|
#
5ac47f7a |
|
26-Nov-2012 |
Anton Blanchard <anton@samba.org> |
powerpc: Relocate prom_init.c on 64bit The ppc64 kernel can get loaded at any address which means our very early init code in prom_init.c must be relocatable. We do this with a pretty nasty RELOC() macro that we wrap accesses of variables with. It is very fragile and sometimes we forget to add a RELOC() to an uncommon path or sometimes a compiler change breaks it. 32bit has a much more elegant solution where we build prom_init.c with -mrelocatable and then process the relocations manually. Unfortunately we can't do the equivalent on 64bit and we would have to build the entire kernel relocatable (-pie), resulting in a large increase in kernel footprint (megabytes of relocation data). The relocation data will be marked __initdata but it still creates more pressure on our already tight memory layout at boot. Alan Modra pointed out that the 64bit ABI is relocatable even if we don't build with -pie, we just need to relocate the TOC. This patch implements that idea and relocates the TOC entries of prom_init.c. An added bonus is there are very few relocations to process which helps keep boot times on simulators down. gcc does not put 64bit integer constants into the TOC but to be safe we may want a build time script which passes through the prom_init.c TOC entries to make sure everything looks reasonable. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
323a6bf1 |
|
13-Sep-2012 |
Michael Ellerman <michael@ellerman.id.au> |
powerpc: Add a powerpc implementation of SHA-1 This patch adds a crypto driver which provides a powerpc accelerated implementation of SHA-1, accelerated in that it is written in asm. Original patch by Paul, minor fixups for upstream by moi. Lightly tested on 64-bit with the test program here: http://michael.ellerman.id.au/files/junkcode/sha1test.c Seems to work, and is "not slower" than the generic version. Needs testing on 32-bit. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
8662d0bc |
|
18-Sep-2012 |
Matthew McClintock <msm@freescale.com> |
powerpc: dtc is required to build dtb files Fixes this following: $ make distclean; make corenet32_smp_defconfig; make p4080ds.dtb CLEAN arch/powerpc/boot CLEAN scripts/basic CLEAN scripts/dtc CLEAN scripts/genksyms CLEAN scripts/kconfig CLEAN scripts/mod CLEAN scripts CLEAN include/config include/generated CLEAN .config HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --silentoldconfig Kconfig DTC arch/powerpc/boot/p4080ds.dtb /bin/sh: /local/home/mattsm/git/linux/scripts/dtc/dtc: No such file or directory make[1]: *** [arch/powerpc/boot/p4080ds.dtb] Error 1 make: *** [p4080ds.dtb] Error 2 Signed-off-by: Matthew McClintock <msm@freescale.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
95ead5d7 |
|
13-Jun-2012 |
Seth Jennings <sjenning@linux.vnet.ibm.com> |
crypto: nx - move nx build to driver/crypto Makefile When the nx driver was pulled, the Makefile that actually builds it is arch/powerpc/Makefile. This is unnatural. This patch moves the line that builds the nx driver from arch/powerpc/Makefile to drivers/crypto/Makefile where it belongs. Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com> Acked-by: Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
aef7b31c |
|
11-Apr-2012 |
Kent Yoder <key@linux.vnet.ibm.com> |
powerpc/crypto: Build files for the nx device driver These files support configuring and building the nx device driver. Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
d23c6fb4 |
|
17-Apr-2012 |
Anton Blanchard <anton@samba.org> |
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>
|
#
894a65c8 |
|
17-Apr-2012 |
Anton Blanchard <anton@samba.org> |
powerpc: Remove altivec fix for gcc versions before 4.0 Now we require gcc 4.0 on 64-bit we can remove the pre gcc 4.0 -maltivec workaround. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
82a85084 |
|
17-Apr-2012 |
Anton Blanchard <anton@samba.org> |
powerpc: Require gcc 4.0 on 64-bit Older versions of gcc had issues with using -maltivec together with -mcpu of a non altivec capable CPU. We work around it by specifying -mcpu=970, but the logic is complicated. In preparation for adding more -mcpu targets, remove the workaround and just require gcc 4.0 for 64-bit builds. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
f2699491 |
|
20-Feb-2012 |
Michael Ellerman <michael@ellerman.id.au> |
powerpc/perf: Move perf core & PMU code into a subdirectory The perf code has grown a lot since it started, and is big enough to warrant its own subdirectory. For reference it's ~60% bigger than the oprofile code. It declutters the kernel directory, makes it simpler to grep for "just perf stuff", and allows us to shorten some filenames. While we're at it, make it more obvious that we have two implementations of the core perf logic. One for (roughly) Book3S CPUs, which was the original implementation, and the other for Freescale embedded CPUs. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
9c5f7d39 |
|
14-Dec-2011 |
Suzuki Poulose <suzuki@in.ibm.com> |
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>
|
#
11eab297 |
|
01-Dec-2011 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
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>
|
#
e1fc235d |
|
07-Sep-2010 |
Matthew McClintock <msm@freescale.com> |
arch/powerpc: Remove duplicate/redundant Altivec entries In lieu of having multiple similiar lines, we can just have one generic cpu-as line for CONFIG_ALTIVEC Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
a9a8f77a |
|
07-Nov-2011 |
Kyle Moffett <Kyle.D.Moffett@boeing.com> |
powerpc: Remove buggy 9-year-old test for binutils < 2.12.1 Recent binutils refuses to assemble AltiVec opcodes when in e500/SPE mode, as some of those opcodes alias the "SPE" instructions. This triggers an ancient binutils version check even when building a kernel with CONFIG_ALTIVEC disabled. In theory, the check could be conditionalized on CONFIG_ALTIVEC, but in practice it has long outlived its utility. It is virtually impossible to find binutils older than 2.12.1 (released 2002) in the wild anymore. Even ancient RedHat Enterprise Linux 4 has binutils-2.14. To fix the kernel build when done natively on e500 systems with this new binutils, the test is simply removed. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
0ca87f05 |
|
20-Jul-2011 |
Matt Evans <matt@ozlabs.org> |
net: filter: BPF 'JIT' compiler for PPC64 An implementation of a code generator for BPF programs to speed up packet filtering on PPC64, inspired by Eric Dumazet's x86-64 version. Filter code is generated as an ABI-compliant function in module_alloc()'d mem with stackframe & prologue/epilogue generated if required (simple filters don't need anything more than an li/blr). The filter's local variables, M[], live in registers. Supports all BPF opcodes, although "complicated" loads from negative packet offsets (e.g. SKF_LL_OFF) are not yet supported. There are a couple of further optimisations left for future work; many-pass assembly with branch-reach reduction and a register allocator to push M[] variables into volatile registers would improve the code quality further. This currently supports big-endian 64-bit PowerPC only (but is fairly simple to port to PPC32 or LE!). Enabled in the same way as x86-64: echo 1 > /proc/sys/net/core/bpf_jit_enable Or, enabled with extra debug output: echo 2 > /proc/sys/net/core/bpf_jit_enable Signed-off-by: Matt Evans <matt@ozlabs.org> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
af9719c3 |
|
30-Jun-2011 |
Anton Blanchard <anton@samba.org> |
powerpc: Use -mtraceback=no gcc 4.7 will be more strict about parsing the -mtraceback option: gcc: error: unrecognized argument in option '-mtraceback=none' gcc: note: valid arguments to '-mtraceback=' are: full no part gcc used to do a 2 char compare so both "no" and "none" would match. Switch to using -mtraceback=no should work everywhere. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
c686ecf5 |
|
15-Aug-2010 |
Anatolij Gustschin <agust@denx.de> |
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>
|
#
e32e78c5 |
|
02-Aug-2010 |
Sam Ravnborg <sam@ravnborg.org> |
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>
|
#
6588169d |
|
28-Jul-2010 |
Sam Ravnborg <sam@ravnborg.org> |
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line It is now possible to assign options to AS, CC and LD on the command line - which is only used when building modules. {A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile in the arch makefiles, thus users had no way to specify additional options to AS, CC, LD when building modules without overriding the original value. Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE that is used by arch specific files and free up {A,C,LD}FLAGS_MODULE so they can be assigned on the command line. All arch Makefiles that used the old variables has been updated. Note: Previously we had a MODFLAGS variable for both AS and CC. But in favour of consistency this was dropped. So in some cases arch Makefile has one assignmnet replaced by two assignmnets. Note2: MODFLAGS was not documented and is dropped without any notice. I do not expect much/any breakage from this. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Denys Vlasenko <vda.linux@googlemail.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Chen Liqin <liqin.chen@sunplusct.com> Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin] Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32] Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
7fca5dc8 |
|
29-Jun-2010 |
Stephen Rothwell <sfr@canb.auug.org.au> |
powerpc: Fix module building for gcc 4.5 and 64 bit Gcc 4.5 is now generating out of line register save and restore in the function prefix and postfix when we use -Os. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
d0679c73 |
|
02-Feb-2010 |
Andi Kleen <andi@firstfloor.org> |
kbuild: move -fno-dwarf2-cfi-asm to powerpc only Better dwarf2 unwind information is a good thing, it allows better debugging with kgdb and crash and helps systemtap. Commit 003086497f07f7f1e67c0c295e261740f822b377 ("Build with -fno-dwarf2-cfi-asm") disabled some CFI information globally to work around a module loader bug on powerpc. But this disables the better unwind tables for all architectures, not just powerpc. Move the workaround to powerpc and also add a suitable comment that's it really a workaround. This improves dwarf2 unwind tables on x86 at least. Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
|
#
144ef909 |
|
14-Sep-2009 |
Tony Breeds <tony@bakeyournoodle.com> |
powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLE When using CONFIG_RELOCATABLE, we build the kernel as a position independent executable. The kernel then uses a little bit of relocation code to relocate itself. That code only deals with R_PPC64_RELATIVE relocations though. If for some reason you use assembly constructs such as LOAD_REG_IMMEDIATE() to load the address of a symbol, you'll generate different kinds of relocations that won't be processed properly and bad things will happen. (We have 2 such bugs today). The perl script tries to filter out "known" bad ones. It's possible that we are missing some in the case of a weak function that nobody implements, we'll see if we get false positive and fix it. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
51b563fc |
|
19-Sep-2009 |
Sam Ravnborg <sam@ravnborg.org> |
arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0 Albin Tonnerre <albin.tonnerre@free-electrons.com> reported: Bash 4 filters out variables which contain a dot in them. This happends to be the case of CPPFLAGS_vmlinux.lds. This is rather unfortunate, as it now causes build failures when using SHELL=/bin/bash to compile, or when bash happens to be used by make (eg when it's /bin/sh) Remove the common definition of CPPFLAGS_vmlinux.lds by pushing relevant stuff to either Makefile.build or the arch specific kernel/Makefile where we build the linker script. This is also nice cleanup as we move the information out where it is used. Notes for the different architectures touched: arm - we use an already exported symbol cris - we use a config symbol aleady available [Not build tested] mips - the jiffies complexity has moved to vmlinux.lds.S where we need it. Added a few variables to CPPFLAGS - they are only used by the linker script. [Not build tested] powerpc - removed assignment that is not needed [not build tested] sparc - simplified it using $(BITS) um - introduced a few new exported variables to deal with this xtensa - added options to CPP invocation [not build tested] Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
caa27b66 |
|
20-Jul-2009 |
Sam Ravnborg <sam@ravnborg.org> |
kbuild: use INSTALLKERNEL to select customized installkernel script Replace the use of CROSS_COMPILE to select a customized installkernel script with the possibility to set INSTALLKERNEL to select a custom installkernel script when running make: make INSTALLKERNEL=arm-installkernel install With this patch we are now more consistent across different architectures - they did not all support use of CROSS_COMPILE. The use of CROSS_COMPILE was a hack as this really belongs to gcc/binutils and the installkernel script does not change just because we change toolchain. The use of CROSS_COMPILE caused troubles with an upcoming patch that saves CROSS_COMPILE when a kernel is built - it would no longer be installable. [Thanks to Peter Z. for this hint] This patch undos what Ian did in commit: 0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46 ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh") The patch has been lightly tested on x86 only - but all changes looks obvious. Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin] Acked-by: Russell King <linux@arm.linux.org.uk> [arm] Acked-by: Paul Mundt <lethal@linux-sh.org> [sh] Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86] Cc: Ian Campbell <icampbell@arcom.com> Cc: Tony Luck <tony.luck@intel.com> [ia64] Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64] Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r] Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k] Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc] Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc] Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390] Cc: Thomas Gleixner <tglx@linutronix.de> [x86] Cc: Ingo Molnar <mingo@redhat.com> [x86] Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
f7d4f68d |
|
23-Jul-2009 |
Frans Pop <elendil@planet.nl> |
powerpc: Makefile simplification through use of cc-ifversion Signed-off-by: Frans Pop <elendil@planet.nl> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
e821ea70 |
|
02-Jun-2009 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
powerpc: Move VMX and VSX asm code to vector.S Currently, load_up_altivec and give_up_altivec are duplicated in 32-bit and 64-bit. This creates a common implementation that is moved away from head_32.S, head_64.S and misc_64.S and into vector.S, using the same macros we already use for our common implementation of load_up_fpu. I also moved the VSX code over to vector.S though in that case I didn't make it build on 32-bit (yet). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
1a3d1fc2 |
|
09-Mar-2009 |
Liu Yu <yu.liu@freescale.com> |
powerpc/math-emu: Fix efp dependence There is no dependece between efp and math-emu. But when disable math-emu the efp code cannot be built. Signed-off-by: Liu Yu <yu.liu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
#
55b9121b |
|
28-Oct-2008 |
Kumar Gala <galak@kernel.crashing.org> |
powerpc: Remove unncessary SPE related compiler flag After testing of various compiler flag combinations by Nate Case it was determined that -mabi=no-spe has no impact on the compiler generating SPE instructions. Only -mno-spe and -mspe=no do. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
#
606576ce |
|
06-Oct-2008 |
Steven Rostedt <rostedt@goodmis.org> |
ftrace: rename FTRACE to FUNCTION_TRACER Due to confusion between the ftrace infrastructure and the gcc profiling tracer "ftrace", this patch renames the config options from FTRACE to FUNCTION_TRACER. The other two names that are offspring from FTRACE DYNAMIC_FTRACE and FTRACE_MCOUNT_RECORD will stay the same. This patch was generated mostly by script, and partially by hand. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
ce400c01 |
|
01-Sep-2008 |
Thiemo Seufer <ths@linutronix.de> |
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>
|
#
549e8152 |
|
29-Aug-2008 |
Paul Mackerras <paulus@samba.org> |
powerpc: Make the 64-bit kernel as a position-independent executable This implements CONFIG_RELOCATABLE for 64-bit by making the kernel as a position-independent executable (PIE) when it is set. This involves processing the dynamic relocations in the image in the early stages of booting, even if the kernel is being run at the address it is linked at, since the linker does not necessarily fill in words in the image for which there are dynamic relocations. (In fact the linker does fill in such words for 64-bit executables, though not for 32-bit executables, so in principle we could avoid calling relocate() entirely when we're running a 64-bit kernel at the linked address.) The dynamic relocations are processed by a new function relocate(addr), where the addr parameter is the virtual address where the image will be run. In fact we call it twice; once before calling prom_init, and again when starting the main kernel. This means that reloc_offset() returns 0 in prom_init (since it has been relocated to the address it is running at), which necessitated a few adjustments. This also changes __va and __pa to use an equivalent definition that is simpler. With the relocatable kernel, PAGE_OFFSET and MEMORY_START are constants (for 64-bit) whereas PHYSICAL_START is a variable (and KERNELBASE ideally should be too, but isn't yet). With this, relocatable kernels still copy themselves down to physical address 0 and run there. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
7563dc64 |
|
02-Sep-2008 |
Tony Breeds <tony@bakeyournoodle.com> |
powerpc: Work around gcc's -fno-omit-frame-pointer bug This bug is causing random crashes (http://bugzilla.kernel.org/show_bug.cgi?id=11414). -fno-omit-frame-pointer is only needed on powerpc when -pg is also supplied, and there is a gcc bug that causes incorrect code generation on 32-bit powerpc when -fno-omit-frame-pointer is used---it uses stack locations below the stack pointer, which is not allowed by the ABI because those locations can and sometimes do get corrupted by an interrupt. This ensures that CONFIG_FRAME_POINTER is only selected by ftrace. When CONFIG_FTRACE is enabled we also pass -mno-sched-epilog to work around the gcc codegen bug. Patch based on work by: Andreas Schwab <schwab@suse.de> Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
70bf0333 |
|
25-Jun-2008 |
Grant Likely <grant.likely@secretlab.ca> |
powerpc/bootwrapper: Add documentation of boot wrapper targets There have been many questions on and off the mailing list about how exactly the bootwrapper is used for embedded targets. Add some documentation and help text to try and clarify the system. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
1976aef9 |
|
07-Jun-2008 |
Segher Boessenkool <segher@kernel.crashing.org> |
powerpc: Get rid of CROSS32{AS,LD,OBJCOPY} CROSS32AS and CROSS32LD are never used (instead, CROSS32CC is used with proper command line options). CROSS32OBJCOPY isn't used anymore either, since the "wrapper" stuff was added. Remove these unused variables. Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
da3de6df |
|
12-Jun-2008 |
Kumar Gala <galak@kernel.crashing.org> |
[POWERPC] Fix -Os kernel builds with newer gcc versions GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the kernel if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE. To fix this we add the use the save/restore code from gcc and simplified it down for our needs (integer only). Additionally, we have to link this code into each module. The other solution was to add EXPORT_SYMBOL() which meant going through the trampoline which seemed nonsensical for these out-of-line routines. Finally, we add some checks to prom_init_check.sh to ignore the out-of-line save/restore functions. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
8d6bcd6e |
|
24-May-2008 |
Grant Likely <grant.likely@secretlab.ca> |
[POWERPC] bootwrapper: add simpleImage* to list of boot targets Without simpleImage% in the BOOT_TARGETS list, it is impossible to build any of the simpleImages. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
|
#
bbf45ba5 |
|
16-Apr-2008 |
Hollis Blanchard <hollisb@us.ibm.com> |
KVM: ppc: PowerPC 440 KVM implementation This functionality is definitely experimental, but is capable of running unmodified PowerPC 440 Linux kernels as guests on a PowerPC 440 host. (Only tested with 440EP "Bamboo" guests so far, but with appropriate userspace support other SoC/board combinations should work.) See Documentation/powerpc/kvm_440.txt for technical details. [stephen: build fix] Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> Acked-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Avi Kivity <avi@qumranet.com>
|
#
1993cbf4 |
|
15-Apr-2008 |
Kumar Gala <galak@kernel.crashing.org> |
[POWERPC] Provide access to arch/powerpc include path on ppc64 There does not appear to be any reason that we shouldn't just have -Iarch/$(ARCH) on both ppc32 and ppc64 builds. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
e04018e8 |
|
24-Mar-2008 |
Grant Likely <grant.likely@secretlab.ca> |
[POWERPC] add target for building .dtb files Call dtc from the Makefile instead of the wrapper script so that the dt blobs can be generated with a simple make invocation. Using this patch allows board ports to trigger automatic building of .dtb files by adding them to the image-y target list. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
|
#
595be948 |
|
21-Feb-2008 |
Grant Likely <grant.likely@secretlab.ca> |
[POWERPC] Fix zImage-dtb.initrd build error The pattern substitution rules were failing when used with zImage-dtb targets. If zImage-dtb.initrd was selected, the pattern substitution would generate "zImage.initrd-dtb" instead of "zImage-dtb.initrd" which caused the build to fail. This renames zImage-dtb to dtbImage to avoid the problem entirely. By not using the zImage prefix then is no potential for namespace collisions. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
3f85d63e |
|
15-Feb-2008 |
Sam Ravnborg <sam@ravnborg.org> |
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>
|
#
25431333 |
|
06-Feb-2008 |
Grant Likely <grant.likely@secretlab.ca> |
[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>
|
#
773f76b1 |
|
02-Dec-2007 |
David Woodhouse <dwmw2@infradead.org> |
[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>
|
#
0197cd2e |
|
18-Oct-2007 |
Kumar Gala <galak@kernel.crashing.org> |
[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>
|
#
06c5040c |
|
15-Oct-2007 |
Sam Ravnborg <sam@neptun.(none)> |
kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP The variable CPPFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the tree and enabling one to use: make CPPFLAGS=... to specify additional CPP commandline options. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
222d394d |
|
15-Oct-2007 |
Sam Ravnborg <sam@neptun.(none)> |
kbuild: enable 'make AFLAGS=...' to add additional options to AS The variable AFLAGS 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 AFLAGS with KBUILD_AFLAGS all over the tree. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
a0f97e06 |
|
14-Oct-2007 |
Sam Ravnborg <sam@neptun.(none)> |
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>
|
#
ca786f83 |
|
02-Oct-2007 |
Adrian Bunk <bunk@kernel.org> |
[POWERPC] Select proper defconfig for crosscompiles The trick for finding the right defconfig is neat, but you forgot to provide an i686_defconfig. ;-) More seriously, cross compiling the defconfig is often useful, e.g. for testing the compilation of patches that touch multiple architectures, and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is non-empty. Signed-off-by: Adrian Bunk <bunk@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Olof Johansson <olof@lixom.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
8150caad |
|
02-Oct-2007 |
Roland McGrath <roland@redhat.com> |
[POWERPC] powerpc vDSO: install unstripped copies on disk This keeps an unstripped copy of the vDSO images built before they are stripped and embedded in the kernel. The unstripped copies get installed in $(MODLIB)/vdso/ by "make install". These files can be useful when they contain source-level debugging information. Signed-off-by: Roland McGrath <roland@redhat.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
2578bfae |
|
20-Sep-2007 |
Stephen Rothwell <sfr@canb.auug.org.au> |
[POWERPC] Create and use CONFIG_WORD_SIZE Linus made this suggestion for the x86 merge and this starts the process for powerpc. We assume that CONFIG_PPC64 implies CONFIG_PPC_MERGE and CONFIG_PPC_STD_MMU_32 implies CONFIG_PPC_STD_MMU. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
3164cccd |
|
14-Sep-2007 |
Arnd Bergmann <arnd@arndb.de> |
[POWERPC] add Kconfig option for optimizing for cell Since the PPE on cell is an in-order core, it suffers significantly from wrong instruction scheduling. This adds a Kconfig option that enables passing -mtune=cell to gcc in order to generate object code that runs well on cell. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
2f6c9d96 |
|
17-Aug-2007 |
Kumar Gala <galak@kernel.crashing.org> |
[POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32 We no longer have any dependancies on include/asm-ppc so we can get ride of the makefile hacks to include it in the build process. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
#
15f6527e |
|
20-Aug-2007 |
Josh Boyer <jwboyer@linux.vnet.ibm.com> |
[POWERPC] Rename 4xx paths to 40x 4xx is a bit of a misnomer for certain things, as they really apply to PowerPC 40x only. Rename some of the files to clean this up. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: David Gibson <david@gibson.dropbear.id.au>
|
#
f5e83fa4 |
|
19-May-2007 |
Segher Boessenkool <segher@kernel.crashing.org> |
powerpc: Refuse to build 64-bit with GCC-4.2.0 and CONFIG_MODULES ...since this won't work (compiler bug, see <http://gcc.gnu.org/PR31490>). Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
941b7adf |
|
31-May-2007 |
Mark A. Greer <mgreer@mvista.com> |
[POWERPC] Remove 'make zImage.dts' feature Being able to selectively wrap a device tree with the zIimage at build time has been deemed unnecessary, so this removes Makefile support for that feature. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
0570d4ed |
|
28-May-2007 |
Stephen Rothwell <sfr@canb.auug.org.au> |
[POWERPC] Create a zImage for legacy iSeries This zImage is really just the stripped vmlinux, but it means that there is one less special case for iSeries and also that the zImages will be built for a combined kernel build that happens to include iSeries. This zImage boots fine on legacy iSeries. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
8995ac87 |
|
16-May-2007 |
Segher Boessenkool <segher@kernel.crashing.org> |
[POWERPC] Specify GNUTARGET on $(AR) invocations Without this, some versions of GNU ar fail to create an archive index if the object files it is packing together are of a different object format than ar's default format (for example, binutils compiled to default to 64-bit, with 32-bit objects). Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
916066d5 |
|
11-May-2007 |
Mark A. Greer <mgreer@mvista.com> |
[POWERPC] Add Makefile rules to wrap dts file in zImage Add 'zImage.dts' and 'zImage.dts_initrd' build rules that automatically compile and wrap a dts file from arch/powerpc/boot/dts into the zImage file. The resulting zImage will be arch/powerpc/boot/zImage.dts.<platform> and arch/powerpc/boot/zImage.dts_initrd.<platform>, respectively. Having separate rules allows the user to choose whether to include a device tree--and which device tree--at build time. This is useful when one Makefile target builds a zImage that runs on several platforms except for differing device trees. By just setting CONFIG_DEVICE_TREE and running "make zImage.dts" the exact zImage you want is built without Makefile bloat or manually running the wrapper script. The dts file is expected to be arch/powerpc/boot/dts/$(CONFIG_DEVICE_TREE) Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
a6afacb6 |
|
30-Apr-2007 |
David Gibson <david@gibson.dropbear.id.au> |
[POWERPC] Small cleanups to the cuboot bootwrapper code This patch makes a few small cleanups to the cuboot code. - It removes the double layered selection of images, via cuboot-plat-y, instead having the cuboot platforms directly select a suitable image-y (this changes the name of the final cuboot image from plain cuImage to cuImage.<platform>). - Factors out some code in the wrapper that's potentially useful to platforms other than uboot. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
928370c6 |
|
10-Apr-2007 |
Akinobu Mita <mita@fixstars.com> |
[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>
|
#
57647a4d |
|
22-Mar-2007 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
[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>
|
#
0fdd717e |
|
16-Apr-2007 |
Scott Wood <scottwood@freescale.com> |
[POWERPC] bootwrapper: Add a cuboot platform and a cuImage target The cuImage target will build a uImage with bootwrapper code and a device tree. The default device tree and platform file are determined by the kernel configuration. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
2bf11819 |
|
27-Sep-2006 |
Paul Mackerras <paulus@samba.org> |
[POWERPC] Create a "wrapper" script and use it in arch/powerpc/boot This puts the knowledge of how to create various sorts of zImage wrappers into a script called "wrapper" that could be used outside of the kernel tree. This changes arch/powerpc/boot so it first builds the files that the wrapper script needs, then runs it to create whatever flavours of zImage are required. This version does uImages as well. The zImage names are changed slightly; zImage.pseries is the one with the PT_NOTE program header entry added, and zImage.pmac is the one without. If the zImage.pseries gets made, it will also get hardlinked to zImage; otherwise, if zImage.pmac is made, it gets hardlinked to zImage. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
227318bb |
|
10-Jun-2006 |
Anton Blanchard <anton@samba.org> |
[POWERPC] Remove stale 64bit on 32bit kernel code Remove some stale POWER3/POWER4/970 on 32bit kernel support. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
f48b8296 |
|
11-Apr-2006 |
Olaf Hering <olh@suse.de> |
[PATCH] powerpc32: Set cpu explicitly in kernel compiles Compile the 32bit kernel with -mcpu=powerpc. This reduces the imagesize when a compiler is used that defaults to -mtune=power4. It inserts lots of nops to please the 64bit cpu instruction scheduling. But all these nops are not needed for 32bit kernels. Example with SLES10 gcc 4.1.0 and arch/powerpc/configs/pmac32_defconfig: vmlinux vmlinux.strip vmlinux.gz -O2 4980515 4187528 1846829 -Os 4618801 3827084 1673333 -O2 -mcpu=powerpc 4738851 3945868 1816253 -Os -mcpu=powerpc 4532785 3741068 1664688 Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
5cd27208 |
|
27-Mar-2006 |
Kumar Gala <galak@kernel.crashing.org> |
powerpc: move math-emu over to arch/powerpc Towards the goal of having arch/powerpc not build anything over in arch/ppc move math-emu over. Also, killed some references to arch/ppc/ in the arch/powerpc Makefile which should belong in drivers/ when the particular sub-arch's move over to arch/powerpc. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
#
e7e2d2da |
|
27-Mar-2006 |
Paul Mackerras <paulus@samba.org> |
powerpc: Don't compile in arch/ppc/kernel for 32-bit ARCH=powerpc All of the things needed for 32-bit ARCH=powerpc builds have now moved to arch/powerpc/kernel, so we don't need to go down into arch/ppc/kernel any more, and we can remove the CONFIG_PPC_MERGE conditional from arch/ppc/kernel/Makefile. There were two files still referenced in the merge section of arch/ppc/kernel/Makefile: ppc-stub.o, depending on CONFIG_KGDB, and dma-mapping.o, depending on CONFIG_NOT_COHERENT_CACHE. None of the platforms currently in ARCH=powerpc have caches that aren't coherent with DMA, but when we do get one we'll move dma-mapping.c over. As for CONFIG_KGDB, none of the Kconfig files in the tree define it, so I'll let it languish for now. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
4f193362 |
|
05-Mar-2006 |
Paul Smith <psmith@gnu.org> |
kbuild: change kbuild to not rely on incorrect GNU make behavior The kbuild system takes advantage of an incorrect behavior in GNU make. Once this behavior is fixed, all files in the kernel rebuild every time, even if nothing has changed. This patch ensures kbuild works with both the incorrect and correct behaviors of GNU make. For more details on the incorrect behavior, see: http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html Changes in this patch: - Keep all targets that are to be marked .PHONY in a variable, PHONY. - Add .PHONY: $(PHONY) to mark them properly. - Remove any $(PHONY) files from the $? list when determining whether targets are up-to-date or not. Signed-off-by: Paul Smith <psmith@gnu.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
70567293 |
|
10-Feb-2006 |
Andreas Gruenbacher <agruen@suse.de> |
[PATCH] Fix building external modules on ppc32 We are setting up sources for building external modules like this: /usr/src/linux-obj> # create a .config file /usr/src/linux-obj> make -C /usr/src/linux O=$PWD oldconfig /usr/src/linux-obj> make -C /usr/src/linux O=$PWD prepare /usr/src/linux-obj> make -C /usr/src/linux O=$PWD scripts /usr/src/linux-obj> make -C /usr/src/linux O=$PWD clean After that, external modules can be built with: /usr/src/module> make -C /usr/src/linux-obj M=$PWD This fails for ppc32 because the `make clean' removes the arch/powerpc/include directory. This should be done in archmrproper instead of in archclean. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
00adbf62 |
|
16-Jan-2006 |
Kumar Gala <galak@gate.crashing.org> |
[PATCH] powerpc: Add CONFIG_DEFAULT_UIMAGE for embedded boards Embedded boards that u-boot require a kernel image in the uImage format. This allows a given board to specify it wants a uImage built by default. This also fixes a warning at config time, as this symbol is referred to in arch/powerpc/platforms/83xx/Kconfig. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
774fee58 |
|
02-Feb-2006 |
Geoff Levand <geoffrey.levand@am.sony.com> |
[PATCH] powerpc: Add missing vmlinux.bin target With this patch 'make vmlinux.bin' works. This is needed by some embedded platforms. Kumar already added the routines to actually build the image in arch/powerpc/boot/Makefile. Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
f4fc4a5b |
|
16-Jan-2006 |
Kumar Gala <galak@gate.crashing.org> |
[PATCH] powerpc: Add CONFIG_DEFAULT_UIMAGE to build a uImage by default for a board Embedded boards that u-boot require a kernel image in the uImage format. This allows a given board to specify it wants a uImage built by default. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
135f0b17 |
|
12-Jan-2006 |
Tom Rini <trini@kernel.crashing.org> |
[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>
|
#
9e1c72a4 |
|
12-Jan-2006 |
Tom Rini <trini@kernel.crashing.org> |
[PATCH] Remove bzImage target Since the documentation no longer tells people to 'make bzImage', and with the previous patch nothing more than 'make' is required to get the right bootable images (just like on i386 now), this removes the bzImage -> zImage target redirect on ARCH=powerpc Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
8c441a57 |
|
22-Nov-2005 |
Kumar Gala <galak@gate.crashing.org> |
[PATCH] powerpc: Add support for building uImages powerpc: Add support for building uImages Add support to build a kernel image bootable by u-boot. Most of the makefile foo is taken from arch/ppc/boot/images/Makefile Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
ad14336d |
|
08-Jan-2006 |
Sam Ravnborg <sam@mars.ravnborg.org> |
kbuild: remove GCC_VERSION This was causing some ordering problems. Remove the up-front evaluation and just revaluate the compiler version each time we need it. (The up-front evaluation was problematic because some architectures modify the value of $(CC)). Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
#
55bb239e |
|
21-Nov-2005 |
Stephen Rothwell <sfr@canb.auug.org.au> |
[PATCH] powerpc: remove arch/powerpc/include hack for 64 bit With the removal of include/asm-powerpc, we no longer need arch/powerpc/include/asm for the 64 bit build. We also do not need -Iarch/powerpc for the 64 bit build either. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
8a5abdf8 |
|
17-Nov-2005 |
Paul Mackerras <paulus@samba.org> |
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>
|
#
437a58db |
|
17-Nov-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Move remaining .c files from arch/ppc64 to arch/powerpc This also deletes the now-unused Makefiles under arch/ppc64. Both of the files moved over could use some merging, but for now I have moved them as-is and arranged for them to be used only in 64-bit kernels. For 32-bit kernels we still use arch/ppc/kernel/idle.c and drivers/char/generic_nvram.c as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
94b212c2 |
|
15-Nov-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Move ppc64 boot wrapper code over to arch/powerpc This also extends the code to handle 32-bit ELF vmlinux files as well as 64-bit ones. This is sufficient for booting on new-world 32-bit powermacs (i.e. all recent machines). Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
50092b23 |
|
13-Nov-2005 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
[PATCH] powerpc: Always rebuild arch/powerpc/include/asm symlink This patch uses a FORCE dependency on the arch/powerpc/include/asm symlink so that it always gets rebuilt, thus avoiding all sort of funny errors if the .config is changed between 32 and 64 bits. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
e19e4ab4 |
|
02-Nov-2005 |
Michael Ellerman <michael@ellerman.id.au> |
powerpc: Set entry point and text address in linker script Currently we set the kernel entry point and the address of the text section in the Makefile, using CONFIG_KERNEL_START. But we've already got <asm/page.h> in the linker script, so we can just use KERNELBASE directly. That means if we ever change KERNELBASE there's one less place to change it. And we can set the entry point with ENTRY(). There are zero differences from "readelf -a vmlinux" with or without this patch. Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
|
#
d3f67fbb |
|
28-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Add -mno-altivec for ARCH=powerpc builds Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
f78541dc |
|
28-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Merge xmon The merged version follows the ppc64 version pretty closely mostly, and in fact ARCH=ppc64 now uses the arch/powerpc/xmon version. The main difference for ppc64 is that the 'p' command to call show_state (which was always pretty dodgy) has been replaced by the ppc32 'p' command, which calls a given procedure (so in fact the old 'p' command behaviour can be achieved with 'p $show_state'). Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
03f88e9f |
|
19-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
ppc64: Minor compilation fixes This defines CONFIG_PPC_STD_MMU for ppc64, changes an instance of sys32_ to compat_sys_ in the ppc64 syscall table, and removes a reference to a non-existent arch/powerpc/xmon/Makefile. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
77f543cb |
|
17-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Fix various compile errors with ARCH=ppc, ppc64 and powerpc This makes ppc use the syscalls.c from arch/powerpc/kernel, exports copy_and_flush from head_32.S for use by prom_init.c (ARCH=powerpc), and consolidates the sys_fadvise64_64 implementations for 32-bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
190554db |
|
13-Oct-2005 |
Stephen Rothwell <sfr@canb.auug.org.au> |
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>
|
#
20f62954 |
|
10-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Make building the boot image work for both 32-bit and 64-bit At the moment we don't have a merged arch/powerpc/boot, so we build the boot images in arch/ppc/boot and arch/ppc64/boot. Unfortunately the makefile targets are different in those two directories, so this makes a change to accommodate both for the moment. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
9994a338 |
|
10-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S The system call table has been consolidated into systbl.S. We have separate 32-bit and 64-bit versions of entry.S and misc.S since the code is mostly sufficiently different to be not worth merging. There are some common bits that will be extracted in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
daec962e |
|
10-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Use arch/powerpc/mm and arch/powerpc/lib for 64-bit This also puts a copy of indirect_pci.c in arch/powerpc/sysdev so that we don't need to build in arch/ppc/syslib. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
70d64cea |
|
10-Oct-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Rename files to have consistent _32/_64 suffixes This doesn't change any code, just renames things so we consistently have foo_32.c and foo_64.c where we have separate 32- and 64-bit versions. Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
cabb5587 |
|
30-Sep-2005 |
Stephen Rothwell <sfr@canb.auug.org.au> |
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>
|
#
bd142b70 |
|
29-Sep-2005 |
Stephen Rothwell <sfr@canb.auug.org.au> |
ppc64: simplify the build a little Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
|
#
a3a9e99e |
|
27-Sep-2005 |
Paul Mackerras <paulus@samba.org> |
powerpc: Fix building in the old arch's boot directory for now Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
bbeb3f4c |
|
26-Sep-2005 |
Stephen Rothwell <sfr@canb.auug.org.au> |
powerpc: clean up after powermac build merge Complete moving arch/ppc64/kernel/mpic.h, include/asm-ppc/reg.h, include/asm-ppc64/kdebug.h and include/asm-ppc64/kprobes.h Add arch/powerpc/platforms/Makefile and use it from arch/powerpc/Makefile Introduce OLDARCH temporarily so we can point back to the originating architecture Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
|
#
14cf11af |
|
26-Sep-2005 |
Paul Mackerras <paulus@samba.org> |
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>
|