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
     

05 May, 2014

1 commit


01 May, 2014

1 commit

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

    Alistair Popple
     

23 Apr, 2014

2 commits


09 Apr, 2014

1 commit

  • 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
    Signed-off-by: Anton Blanchard
    Signed-off-by: Benjamin Herrenschmidt

    Tony Breeds
     

25 Nov, 2013

1 commit

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

    Michael Neuling
     

23 Nov, 2013

1 commit

  • 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
    Signed-off-by: Scott Wood

    Tiejun Chen
     

21 Nov, 2013

1 commit


11 Oct, 2013

3 commits


21 Aug, 2013

3 commits

  • 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

    Scott Wood
     
  • 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

    Scott Wood
     
  • 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

    Scott Wood