1. 07 2月, 2008 5 次提交
    • G
      [POWERPC] bootwrapper: Build multiple cuImages · 25431333
      Grant Likely 提交于
      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: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      25431333
    • B
      [POWERPC] Fake NUMA emulation for PowerPC · 1daa6d08
      Balbir Singh 提交于
      Here's a dumb simple implementation of fake NUMA nodes for PowerPC.
      Fake NUMA nodes can be specified using the following command line
      option
      
      numa=fake=<node range>
      
      node range is of the format <range1>,<range2>,...<rangeN>
      
      Each of the rangeX parameters is passed using memparse().  I find the
      patch useful for fake NUMA emulation on my simple PowerPC machine.
      I've tested it on a numa box with the following arguments
      
      numa=fake=512M
      numa=fake=512M,768M
      numa=fake=256M,512M mem=512M
      numa=fake=1G mem=768M
      numa=fake=
      without any numa= argument
      
      The other side-effect introduced by this patch is that; in the case
      where we don't have NUMA information, we now set a node online after
      adding each LMB.  This node could very well be node 0, but in the case
      that we enable fake NUMA nodes, when we cross node boundaries, we need
      to set the new node online.
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1daa6d08
    • O
      [POWERPC] Fix compilation for CONFIG_DEBUGGER=n and CONFIG_KEXEC=y · 7dbb922c
      Olof Johansson 提交于
      Looks like "[POWERPC] kdump shutdown hook support" broke builds when
      CONFIG_DEBUGGER=n and CONFIG_KEXEC=y, such as in g5_defconfig:
      
      arch/powerpc/kernel/crash.c: In function 'default_machine_crash_shutdown':
      arch/powerpc/kernel/crash.c:388: error: '__debugger_fault_handler' undeclared (first use in this function)
      arch/powerpc/kernel/crash.c:388: error: (Each undeclared identifier is reported only once
      arch/powerpc/kernel/crash.c:388: error: for each function it appears in.)
      
      Move the debugger hooks to under CONFIG_DEBUGGER || CONFIG_KEXEC, since
      that's when the crash code is enabled.
      
      (I should have caught this with my build-script pre-merge, my bad. :( )
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7dbb922c
    • J
      [POWERPC] mpc512x: Device tree for MPC5121 ADS · bd05f91f
      John Rigby 提交于
      Minimal /dts-v1/ device tree for mpc5121 ads.
      
      port-number property in uart nodes
      will go away after the driver learns to use aliases
      Signed-off-by: NJohn Rigby <jrigby@freescale.com>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      bd05f91f
    • J
      [POWERPC] mpc512x: Basic platform support · e177edcd
      John Rigby 提交于
      512x is very similar to 83xx and most
      of this is patterned after code from 83xx.
      
      New platform:
          changed:
      	arch/powerpc/Kconfig
      	arch/powerpc/platforms/Kconfig
      	arch/powerpc/platforms/Kconfig.cputype
      	arch/powerpc/platforms/Makefile
          new:
      	arch/powerpc/platforms/512x/*
      	include/asm-powerpc/mpc512x.h
      Signed-off-by: NJohn Rigby <jrigby@freescale.com>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      e177edcd
  2. 06 2月, 2008 31 次提交
  3. 03 2月, 2008 3 次提交
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
  4. 02 2月, 2008 1 次提交