1. 10 Aug, 2017 1 commit
  2. 31 Jul, 2017 1 commit
  3. 26 Jul, 2017 1 commit
    • Michael Ellerman's avatar
      powerpc/Makefile: Fix ld version check with 64-bit LE-only toolchain · b40b2386
      Michael Ellerman authored
      In commit efe0160c ("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: efe0160c ("powerpc/64: Linker on-demand sfpr functions for modules")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      b40b2386
  4. 30 May, 2017 2 commits
  5. 28 Apr, 2017 2 commits
  6. 03 Mar, 2017 1 commit
  7. 30 Nov, 2016 1 commit
  8. 29 Nov, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc: Stop passing ARCH=ppc64 to boot Makefile · 1196d7aa
      Michael Ellerman authored
      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 20f62954 ("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 94b212c2 ("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: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1196d7aa
  9. 18 Nov, 2016 1 commit
  10. 14 Nov, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc/book3s64: Always build for power4 or later · 3a849815
      Michael Ellerman authored
      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
      468a3302 ("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: default avatarMichael Ellerman <mpe@ellerman.id.au>
      3a849815
  11. 25 Sep, 2016 1 commit
  12. 13 Sep, 2016 3 commits
  13. 10 Aug, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc/Makefile: Use cflags-y/aflags-y for setting endian options · 164af597
      Michael Ellerman authored
      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: default avatarMichael Ellerman <mpe@ellerman.id.au>
      164af597
  14. 14 Jul, 2016 1 commit
  15. 05 Jul, 2016 1 commit
  16. 12 Mar, 2016 1 commit
  17. 07 Mar, 2016 1 commit
    • Torsten Duwe's avatar
      powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel · 8c50b72a
      Torsten Duwe authored
      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: default avatarTorsten Duwe <duwe@suse.de>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8c50b72a
  18. 19 Oct, 2015 1 commit
    • Michael Ellerman's avatar
      powerpc/cell: Drop CONFIG_TUNE_CELL in favour of CONFIG_CELL_CPU · bed08b7e
      Michael Ellerman authored
      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: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      bed08b7e
  19. 01 Oct, 2015 1 commit
  20. 04 Sep, 2015 1 commit
  21. 08 Aug, 2015 1 commit
    • Scott Wood's avatar
      powerpc/85xx: Use kconfig fragments · 44d54014
      Scott Wood authored
      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's avatarScott Wood <scottwood@freescale.com>
      44d54014
  22. 11 Jun, 2015 3 commits
  23. 02 Jun, 2015 1 commit
    • Cyril Bur's avatar
      powerpc/configs: Replace pseries_le_defconfig with a Makefile target using merge_config · ea4d1a87
      Cyril Bur authored
      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: default avatarCyril Bur <cyrilbur@gmail.com>
      Reviewed-by: default avatarSamuel Mendoza-Jonas <sam.mj@au1.ibm.com>
      [mpe: Massage change log, fix white space and use ARCH not SRCARCH]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ea4d1a87
  24. 11 May, 2015 2 commits
    • Michael Ellerman's avatar
      powerpc: Reject binutils 2.24 when building little endian · 60e065f7
      Michael Ellerman authored
      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: default avatarMichael Ellerman <mpe@ellerman.id.au>
      60e065f7
    • Michael Ellerman's avatar
      powerpc: Don't do gcc version checks if we're building with clang · e79c8385
      Michael Ellerman authored
      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: default avatarMichael Ellerman <mpe@ellerman.id.au>
      e79c8385
  25. 23 Mar, 2015 1 commit
  26. 09 Jan, 2015 1 commit
  27. 25 Sep, 2014 1 commit
  28. 28 May, 2014 1 commit
    • Guenter Roeck's avatar
      powerpc: Fix 64 bit builds with binutils 2.24 · 7998eb3d
      Guenter Roeck authored
      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: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7998eb3d
  29. 30 Apr, 2014 1 commit
  30. 23 Apr, 2014 2 commits
  31. 09 Apr, 2014 1 commit
  32. 25 Nov, 2013 1 commit
    • Michael Neuling's avatar
      powerpc: Fix error when cross building TAGS & cscope · 924dd50b
      Michael Neuling authored
      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 d72b0801
          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: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      924dd50b