13 Jan, 2019

1 commit


23 Aug, 2017

1 commit


10 Aug, 2017

1 commit

  • 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
    Signed-off-by: Michael Ellerman

    Christophe Leroy
     

31 Jul, 2017

1 commit

  • 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
    Reviewed-by: Cyril Bur

    Michael Ellerman
     

26 Jul, 2017

1 commit

  • 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

    Michael Ellerman
     

30 May, 2017

2 commits

  • 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
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     
  • 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
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     

28 Apr, 2017

2 commits

  • 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
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     
  • 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
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     

03 Mar, 2017

1 commit

  • 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
    Tested-by: Naveen N. Rao
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     

30 Nov, 2016

1 commit


29 Nov, 2016

1 commit

  • 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

    Michael Ellerman
     

18 Nov, 2016

1 commit

  • 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
    Signed-off-by: Nicholas Piggin
    [mpe: Make it an explicit option not dependant on COMPILE_TEST]
    Signed-off-by: Michael Ellerman

    Nicholas Piggin
     

14 Nov, 2016

1 commit

  • 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

    Michael Ellerman
     

25 Sep, 2016

1 commit


13 Sep, 2016

3 commits


10 Aug, 2016

1 commit

  • 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

    Michael Ellerman
     

14 Jul, 2016

1 commit

  • 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
    Signed-off-by: Daniel Axtens
    Signed-off-by: Michael Ellerman

    Daniel Axtens
     

05 Jul, 2016

1 commit


14 Mar, 2016

1 commit


12 Mar, 2016

1 commit


07 Mar, 2016

1 commit

  • 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
    Signed-off-by: Michael Ellerman

    Torsten Duwe
     

19 Oct, 2015

1 commit

  • 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
    Signed-off-by: Michael Ellerman

    Michael Ellerman
     

01 Oct, 2015

1 commit


09 Sep, 2015

1 commit

  • Pull core kbuild updates from Michal Marek:
    - modpost portability fix
    - linker script fix
    - genksyms segfault fix
    - fixdep cleanup
    - fix for clang detection

    * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
    kbuild: Fix clang detection
    kbuild: fixdep: drop meaningless hash table initialization
    kbuild: fixdep: optimize code slightly
    genksyms: Regenerate parser
    genksyms: Duplicate function pointer type definitions segfault
    kbuild: Fix .text.unlikely placement
    Avoid conflict with host definitions when cross-compiling

    Linus Torvalds
     

04 Sep, 2015

1 commit

  • 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
    Reported-by: Anton Blanchard
    Signed-off-by: Michal Marek

    Michal Marek
     

08 Aug, 2015

1 commit

  • 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

    Scott Wood
     

11 Jun, 2015

3 commits


02 Jun, 2015

1 commit

  • 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
    Reviewed-by: Samuel Mendoza-Jonas
    [mpe: Massage change log, fix white space and use ARCH not SRCARCH]
    Signed-off-by: Michael Ellerman

    Cyril Bur
     

11 May, 2015

2 commits

  • 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

    Michael Ellerman
     
  • 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

    Michael Ellerman
     

23 Mar, 2015

1 commit


10 Jan, 2015

1 commit


25 Sep, 2014

1 commit


28 May, 2014

2 commits

  • Merge the binutils and kexec fixes.

    Benjamin Herrenschmidt
     
  • 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:
    Signed-off-by: Guenter Roeck
    Signed-off-by: Benjamin Herrenschmidt

    Guenter Roeck