1. 24 4月, 2008 2 次提交
    • K
      [POWERPC] Port fixmap from x86 and use for kmap_atomic · 2c419bde
      Kumar Gala 提交于
      The fixmap code from x86 allows us to have compile time virtual addresses
      that we change the physical addresses of at run time.
      
      This is useful for applications like kmap_atomic, PCI config that is done
      via direct memory map, kexec/kdump.
      
      We got ride of CONFIG_HIGHMEM_START as we can now determine a more optimal
      location for PKMAP_BASE based on where the fixmap addresses start and
      working back from there.
      
      Additionally, the kmap code in asm-powerpc/highmem.h always had debug
      enabled.  Moved to using CONFIG_DEBUG_HIGHMEM to determine if we should
      have the extra debug checking.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      2c419bde
    • K
      [POWERPC] 85xx: Add support for relocatable kernel (and booting at non-zero) · 37dd2bad
      Kumar Gala 提交于
      Added support to allow an 85xx kernel to be run from a non-zero physical
      address (useful for cooperative asymmetric multiprocessing situations and
      kdump).  The support can be configured at compile time by setting
      CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
      desired.
      
      Alternatively, the kernel build can set CONFIG_RELOCATABLE.  Setting this
      config option causes the kernel to determine at runtime the physical
      addresses of CONFIG_PAGE_OFFSET and CONFIG_KERNEL_START.  If
      CONFIG_RELOCATABLE is set, then CONFIG_PHYSICAL_START has no meaning.
      However, CONFIG_PHYSICAL_START will always be used to set the LOAD program
      header physical address field in the resulting ELF image.
      
      Currently we are limited to running at a physical address that is a
      multiple of 256M.  This is due to how we map TLBs to cover
      lowmem.  This should be fixed to allow 64M or maybe even 16M alignment
      in the future.  It is considered an error to try and run a kernel at a
      non-aligned physical address.
      
      All the magic for this support is accomplished by proper initialization
      of the kernel memory subsystem and use of ARCH_PFN_OFFSET.
      
      The use of ARCH_PFN_OFFSET only affects normal memory and not IO mappings.
      ioremap uses map_page and isn't affected by ARCH_PFN_OFFSET.
      
      /dev/mem continues to allow access to any physical address in the system
      regardless of how CONFIG_PHYSICAL_START is set.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      37dd2bad
  2. 17 4月, 2008 4 次提交
  3. 01 4月, 2008 1 次提交
  4. 14 2月, 2008 1 次提交
  5. 04 10月, 2007 1 次提交
  6. 03 10月, 2007 1 次提交
  7. 17 8月, 2007 1 次提交
  8. 14 6月, 2007 1 次提交
  9. 13 4月, 2007 1 次提交
    • B
      [POWERPC] DEBUG_PAGEALLOC for 32-bit · 88df6e90
      Benjamin Herrenschmidt 提交于
      Here's an implementation of DEBUG_PAGEALLOC for ppc32. It disables BAT
      mapping and is only tested with Hash table based processor though it
      shouldn't be too hard to adapt it to others.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      
       arch/powerpc/Kconfig.debug       |    9 ++++++
       arch/powerpc/mm/init_32.c        |    4 +++
       arch/powerpc/mm/pgtable_32.c     |   52 +++++++++++++++++++++++++++++++++++++++
       arch/powerpc/mm/ppc_mmu_32.c     |    4 ++-
       include/asm-powerpc/cacheflush.h |    6 ++++
       5 files changed, 74 insertions(+), 1 deletion(-)
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      88df6e90
  10. 01 7月, 2006 1 次提交
  11. 22 3月, 2006 1 次提交
  12. 09 1月, 2006 1 次提交
    • B
      [PATCH] powerpc: Unify udbg (#2) · 51d3082f
      Benjamin Herrenschmidt 提交于
      This patch unifies udbg for both ppc32 and ppc64 when building the
      merged achitecture. xmon now has a single "back end". The powermac udbg
      stuff gets enriched with some ADB capabilities and btext output. In
      addition, the early_init callback is now called on ppc32 as well,
      approx. in the same order as ppc64 regarding device-tree manipulations.
      The init sequences of ppc32 and ppc64 are getting closer, I'll unify
      them in a later patch.
      
      For now, you can force udbg to the scc using "sccdbg" or to btext using
      "btextdbg" on powermacs. I'll implement a cleaner way of forcing udbg
      output to something else than the autodetected OF output device in a
      later patch.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      51d3082f
  13. 10 11月, 2005 1 次提交
  14. 27 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Purge bootinfo.h · e37bc5df
      David Gibson 提交于
      With ARCH=powerpc we assume the presence of a device tree, so we don't
      require any support for the old bi_recs method of passing boot
      parameters.  Likewise, we've never needed it for ppc64, but we still
      had an include/asm-ppc64/bootinfo.h from which nothing was used.  This
      patch removes that file, and all references to it in arch/ppc64 and
      arch/powerpc.  A related, unused variable 'boot_mem_size' is also
      removed from setup_32.c.  The bootinfo stuff remains in ARCH=ppc for
      the time being.
      
      Built and booted on Power5 (ARCH=ppc64 and ARCH=powerpc), built for
      32-bit powermac (ARCH=powerpc and ARCH=ppc).
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e37bc5df
  15. 26 10月, 2005 1 次提交
  16. 22 10月, 2005 1 次提交
  17. 17 10月, 2005 1 次提交
    • P
      powerpc: Initialize btext subsystem later, after prom_init · 30cd4a4e
      Paul Mackerras 提交于
      We were initializing the btext stuff from prom_init(), thus breaking
      the rule that all communication between prom_init() and the rest of
      the kernel has to be via the flattened device tree.  This removes
      the btext initialization calls from prom_init() and initializes it
      instead after the device tree is unflattened.  It would be nice to
      do it earlier, but that needs some more infrastructure to find the
      properties we need in the flattened device tree.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      30cd4a4e
  18. 10 10月, 2005 1 次提交
  19. 06 10月, 2005 1 次提交
    • P
      powerpc: Merge lmb.c and make MM initialization use it. · 7c8c6b97
      Paul Mackerras 提交于
      This also creates merged versions of do_init_bootmem, paging_init
      and mem_init and moves them to arch/powerpc/mm/mem.c.  It gets rid
      of the mem_pieces stuff.
      
      I made memory_limit a parameter to lmb_enforce_memory_limit rather
      than a global referenced by that function.  This will require some
      small changes to ppc64 if we want to continue building ARCH=ppc64
      using the merged lmb.c.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7c8c6b97
  20. 28 9月, 2005 1 次提交
  21. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af
  22. 19 9月, 2005 1 次提交
  23. 05 9月, 2005 2 次提交
  24. 28 7月, 2005 1 次提交
    • A
      [PATCH] ppc32: 8xx avoid icbi misbehaviour in __flush_dcache_icache_phys · bf85fa6c
      Anton Wllert 提交于
      On 8xx, in the case where a pagefault happens for a process who's not
      the owner of the vma in question (ptrace for instance), the flush
      operation is performed via the physical address.
      
      Unfortunately, that results in a strange, unexplainable "icbi"
      instruction fault, most likely due to a CPU bug (see oops below).
      
      Avoid that by flushing the page via its kernel virtual address.
      
      Oops: kernel access of bad area, sig: 11 [#2]
      NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tainted
      MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
      DAR: 00000010, DSISR: C2000000
      TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
      Last syscall: 26
      GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
      00000001
      GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
      00000001
      GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
      C01E0000
      GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
      C02ACB00
      NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
      LR [c000b060] flush_dcache_icache_page+0x20/0x30
      Call trace:
      [c000b154] update_mmu_cache+0x7c/0xa4
      [c005ae98] do_wp_page+0x460/0x5ec
      [c005c8a0] handle_mm_fault+0x7cc/0x91c
      [c005ccec] get_user_pages+0x2fc/0x65c
      [c0027104] access_process_vm+0x9c/0x1d4
      [c00076e0] sys_ptrace+0x240/0x4a4
      [c0002bd0] ret_from_syscall+0x0/0x44
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bf85fa6c
  25. 28 6月, 2005 1 次提交
    • M
      [PATCH] 8xx: avoid "dcbst" misbehaviour with unpopulated TLB · bb165746
      Marcelo Tosatti 提交于
      The proposed _tlbie call at update_mmu_cache() is safe because:
      
      Addresses for which update_mmu_cache() gets invocated are never inside the
      static kernel virtual mapping, meaning that there is no risk for the
      _tlbie() here to be thrashing the pinned entry, as Dan suspected.
      
      The intermediate TLB state in which this bug can be triggered is not
      visible by userspace or any other contexts, except the page fault handling
      path.  So there is no need to worry about userspace dcbxxx users.
      
      The other solution to this is to avoid dcbst misbehaviour in the first
      place, which involves changing in-kernel "dcbst" callers to use 8xx
      specific SPR's.
      
      Summary:
      
      On 8xx, cache control instructions (particularly "dcbst" from
      flush_dcache_icache) fault as write operation if there is an unpopulated
      TLB entry for the address in question.  To workaround that, we invalidate
      the TLB here, thus avoiding dcbst misbehaviour.
      Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb165746
  26. 22 6月, 2005 2 次提交
  27. 20 5月, 2005 1 次提交
    • P
      [PATCH] ppc32: don't call progress functions after boot · 6c37a88c
      Paul Mackerras 提交于
      On ppc32, the platform code can supply a "progress" function that is
      used to show progress through the boot.  These functions are usually
      in an init section and so can't be called after the init pages are
      freed.  Now that the cpu bringup code can be called after the system
      is booted (for hotplug cpu) we can get the situation where the
      progress function can be called after boot.  The simple fix is to set
      the progress function pointer to NULL when the init pages are freed,
      and that is what this patch does (note that all callers already check
      whether the function pointer is NULL before trying to call it).
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6c37a88c
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4