20 Dec, 2011

1 commit

  • 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
    Signed-off-by: Josh Poimboeuf
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Alan Modra
    Cc: Kumar Gala
    Cc: linuxppc-dev
    Signed-off-by: Josh Boyer

    Suzuki Poulose
     

08 Dec, 2011

1 commit

  • 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

    Benjamin Herrenschmidt
     

28 Nov, 2011

1 commit


17 Nov, 2011

1 commit

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

    Kyle Moffett
     

26 Jul, 2011

1 commit

  • * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (99 commits)
    drivers/virt: add missing linux/interrupt.h to fsl_hypervisor.c
    powerpc/85xx: fix mpic configuration in CAMP mode
    powerpc: Copy back TIF flags on return from softirq stack
    powerpc/64: Make server perfmon only built on ppc64 server devices
    powerpc/pseries: Fix hvc_vio.c build due to recent changes
    powerpc: Exporting boot_cpuid_phys
    powerpc: Add CFAR to oops output
    hvc_console: Add kdb support
    powerpc/pseries: Fix hvterm_raw_get_chars to accept < 16 chars, fixing xmon
    powerpc/irq: Quieten irq mapping printks
    powerpc: Enable lockup and hung task detectors in pseries and ppc64 defeconfigs
    powerpc: Add mpt2sas driver to pseries and ppc64 defconfig
    powerpc: Disable IRQs off tracer in ppc64 defconfig
    powerpc: Sync pseries and ppc64 defconfigs
    powerpc/pseries/hvconsole: Fix dropped console output
    hvc_console: Improve tty/console put_chars handling
    powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
    powerpc/mm: Fix output of total_ram.
    powerpc/cpufreq: Add cpufreq driver for Momentum Maple boards
    powerpc: Correct annotations of pmu registration functions
    ...

    Fix up trivial Kconfig/Makefile conflicts in arch/powerpc, drivers, and
    drivers/cpufreq

    Linus Torvalds
     

22 Jul, 2011

1 commit

  • 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
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Matt Evans
     

01 Jul, 2011

1 commit

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

    Anton Blanchard
     

24 Aug, 2010

1 commit

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

    Anatolij Gustschin
     

09 Aug, 2010

1 commit

  • 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
    Tested-by: Thomas Backlund
    Cc: Michal Marek
    Cc: stable
    Signed-off-by: Sam Ravnborg
    Signed-off-by: Benjamin Herrenschmidt

    Sam Ravnborg
     

04 Aug, 2010

1 commit


03 Aug, 2010

1 commit

  • 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
    Cc: Denys Vlasenko
    Cc: Haavard Skinnemoen
    Cc: Mike Frysinger
    Cc: Tony Luck
    Cc: Geert Uytterhoeven
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: Martin Schwidefsky
    Cc: Chen Liqin
    Acked-by: Mike Frysinger [blackfin]
    Acked-by: Haavard Skinnemoen [avr32]
    Signed-off-by: Michal Marek

    Sam Ravnborg
     

08 Jul, 2010

1 commit


06 Feb, 2010

1 commit

  • 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
    Cc: Kyle McMartin
    Signed-off-by: Andrew Morton
    Acked-by: Benjamin Herrenschmidt
    Signed-off-by: Michal Marek

    Andi Kleen
     

24 Sep, 2009

1 commit

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

    Tony Breeds
     

20 Sep, 2009

2 commits

  • Albin Tonnerre 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
    Cc: Russell King
    Cc: Mikael Starvik
    Cc: Jesper Nilsson
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: "David S. Miller"
    Cc: Jeff Dike
    Cc: Chris Zankel
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • 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
    Acked-by: Mike Frysinger [blackfin]
    Acked-by: Russell King [arm]
    Acked-by: Paul Mundt [sh]
    Acked-by: "H. Peter Anvin" [x86]
    Cc: Ian Campbell
    Cc: Tony Luck [ia64]
    Cc: Fenghua Yu [ia64]
    Cc: Hirokazu Takata [m32r]
    Cc: Geert Uytterhoeven [m68k]
    Cc: Kyle McMartin [parisc]
    Cc: Benjamin Herrenschmidt [powerpc]
    Cc: Martin Schwidefsky [s390]
    Cc: Thomas Gleixner [x86]
    Cc: Ingo Molnar [x86]
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

20 Aug, 2009

1 commit


09 Jun, 2009

1 commit

  • 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

    Benjamin Herrenschmidt
     

11 Mar, 2009

1 commit


03 Dec, 2008

1 commit


21 Oct, 2008

1 commit

  • 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
    Signed-off-by: Ingo Molnar

    Steven Rostedt
     

16 Sep, 2008

2 commits

  • Those two are required on my fresh gcc 4.3.1.

    Signed-off-by: Thiemo Seufer
    Signed-off-by: Sebastian Siewior
    Signed-off-by: Paul Mackerras

    Thiemo Seufer
     
  • 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

    Paul Mackerras
     

03 Sep, 2008

1 commit

  • 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
    Segher Boessenkool

    Signed-off-by: Tony Breeds
    Signed-off-by: Paul Mackerras

    Tony Breeds
     

04 Jul, 2008

1 commit


30 Jun, 2008

1 commit

  • 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
    Signed-off-by: Paul Mackerras

    Segher Boessenkool
     

16 Jun, 2008

1 commit

  • 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
    Signed-off-by: Paul Mackerras

    Kumar Gala
     

11 Jun, 2008

1 commit


27 Apr, 2008

1 commit

  • 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
    Acked-by: Paul Mackerras
    Signed-off-by: Stephen Rothwell
    Signed-off-by: Avi Kivity

    Hollis Blanchard
     

17 Apr, 2008

1 commit


03 Apr, 2008

1 commit

  • 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
    Signed-off-by: Josh Boyer

    Grant Likely
     

13 Mar, 2008

1 commit

  • 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
    Acked-by: Geoff Levand
    Signed-off-by: Paul Mackerras

    Grant Likely
     

19 Feb, 2008

1 commit


07 Feb, 2008

1 commit

  • 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
    Signed-off-by: Paul Mackerras

    Grant Likely
     

06 Dec, 2007

1 commit

  • 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
    Signed-off-by: Paul Mackerras

    David Woodhouse
     

09 Nov, 2007

1 commit

  • 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

    Kumar Gala
     

16 Oct, 2007

2 commits

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

15 Oct, 2007

1 commit

  • 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
     

03 Oct, 2007

1 commit

  • 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
    Acked-by: Sam Ravnborg
    Cc: Benjamin Herrenschmidt
    Cc: Olof Johansson
    Signed-off-by: Andrew Morton
    Signed-off-by: Paul Mackerras

    Adrian Bunk