Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 23 3月, 2015 1 次提交
  3. 10 1月, 2015 1 次提交
  5. 25 9月, 2014 1 次提交
  7. 28 5月, 2014 1 次提交
    • G
      powerpc: Fix 64 bit builds with binutils 2.24 · 7998eb3d
      由 Guenter Roeck 提交于 
      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: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7998eb3d
  9. 01 5月, 2014 1 次提交
  11. 23 4月, 2014 2 次提交
  13. 09 4月, 2014 1 次提交
  15. 25 11月, 2013 1 次提交
    • M
      powerpc: Fix error when cross building TAGS & cscope · 924dd50b
      由 Michael Neuling 提交于 
      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: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      924dd50b
  17. 23 11月, 2013 1 次提交
    • T
      powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU well · cbf8a358
      由 Tiejun Chen 提交于 
      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: NTiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: NScott Wood <scottwood@freescale.com>
      cbf8a358
  19. 21 11月, 2013 1 次提交
  21. 11 10月, 2013 3 次提交
  23. 21 8月, 2013 3 次提交
  25. 14 8月, 2013 1 次提交
  27. 08 8月, 2013 1 次提交
  29. 10 1月, 2013 4 次提交
    • A
      powerpc: Avoid load of static chain register when calling nested functions... · 98679fb0
      由 Anton Blanchard 提交于 
      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: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      98679fb0
    • A
      powerpc: Build kernel with -mcmodel=medium · 1fbe9cf2
      由 Anton Blanchard 提交于 
      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: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1fbe9cf2
    • A
      powerpc: Relocate prom_init.c on 64bit · 5ac47f7a
      由 Anton Blanchard 提交于 
      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: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5ac47f7a
    • M
      powerpc: Add a powerpc implementation of SHA-1 · 323a6bf1
      由 Michael Ellerman 提交于 
      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: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      323a6bf1
  31. 15 11月, 2012 1 次提交
    • M
      powerpc: dtc is required to build dtb files · 8662d0bc
      由 Matthew McClintock 提交于 
      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: NMatthew McClintock <msm@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8662d0bc
  33. 27 6月, 2012 1 次提交
  35. 16 5月, 2012 1 次提交
  37. 30 4月, 2012 3 次提交
  39. 23 2月, 2012 1 次提交
  41. 20 12月, 2011 1 次提交
    • S
      powerpc: Process dynamic relocations for kernel · 9c5f7d39
      由 Suzuki Poulose 提交于 
      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: NSuzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: NJosh 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: NJosh Boyer <jwboyer@gmail.com>
      9c5f7d39
  43. 08 12月, 2011 1 次提交
    • B
      powerpc: Add support for OpenBlockS 600 · 11eab297
      由 Benjamin Herrenschmidt 提交于 
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      11eab297
  45. 28 11月, 2011 1 次提交
  47. 17 11月, 2011 1 次提交
    • K
      powerpc: Remove buggy 9-year-old test for binutils < 2.12.1 · a9a8f77a
      由 Kyle Moffett 提交于 
      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: NKyle Moffett <Kyle.D.Moffett@boeing.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a9a8f77a
  49. 22 7月, 2011 1 次提交
    • M
      net: filter: BPF 'JIT' compiler for PPC64 · 0ca87f05
      由 Matt Evans 提交于 
      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: NMatt Evans <matt@ozlabs.org>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ca87f05
  51. 01 7月, 2011 1 次提交
  53. 24 8月, 2010 1 次提交
  55. 09 8月, 2010 1 次提交
  57. 03 8月, 2010 1 次提交
    • S
      kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line · 6588169d
      由 Sam Ravnborg 提交于 
      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: NSam 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: NMichal Marek <mmarek@suse.cz>
      6588169d
  59. 08 7月, 2010 1 次提交