1. 20 3月, 2006 3 次提交
    • D
      [SPARC64]: Kill sole argument passed to setup_tba(). · a8b900d8
      David S. Miller 提交于
      No longer used, and move extern declaration to a header file.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8b900d8
    • D
      [SPARC64]: Elminate all usage of hard-coded trap globals. · 56fb4df6
      David S. Miller 提交于
      UltraSPARC has special sets of global registers which are switched to
      for certain trap types.  There is one set for MMU related traps, one
      set of Interrupt Vector processing, and another set (called the
      Alternate globals) for all other trap types.
      
      For what seems like forever we've hard coded the values in some of
      these trap registers.  Some examples include:
      
      1) Interrupt Vector global %g6 holds current processors interrupt
         work struct where received interrupts are managed for IRQ handler
         dispatch.
      
      2) MMU global %g7 holds the base of the page tables of the currently
         active address space.
      
      3) Alternate global %g6 held the current_thread_info() value.
      
      Such hardcoding has resulted in some serious issues in many areas.
      There are some code sequences where having another register available
      would help clean up the implementation.  Taking traps such as
      cross-calls from the OBP firmware requires some trick code sequences
      wherein we have to save away and restore all of the special sets of
      global registers when we enter/exit OBP.
      
      We were also using the IMMU TSB register on SMP to hold the per-cpu
      area base address, which doesn't work any longer now that we actually
      use the TSB facility of the cpu.
      
      The implementation is pretty straight forward.  One tricky bit is
      getting the current processor ID as that is different on different cpu
      variants.  We use a stub with a fancy calling convention which we
      patch at boot time.  The calling convention is that the stub is
      branched to and the (PC - 4) to return to is in register %g1.  The cpu
      number is left in %g6.  This stub can be invoked by using the
      __GET_CPUID macro.
      
      We use an array of per-cpu trap state to store the current thread and
      physical address of the current address space's page tables.  The
      TRAP_LOAD_THREAD_REG loads %g6 with the current thread from this
      table, it uses __GET_CPUID and also clobbers %g1.
      
      TRAP_LOAD_IRQ_WORK is used by the interrupt vector processing to load
      the current processor's IRQ software state into %g6.  It also uses
      __GET_CPUID and clobbers %g1.
      
      Finally, TRAP_LOAD_PGD_PHYS loads the physical address base of the
      current address space's page tables into %g7, it clobbers %g1 and uses
      __GET_CPUID.
      
      Many refinements are possible, as well as some tuning, with this stuff
      in place.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56fb4df6
    • D
      [SPARC64]: Move away from virtual page tables, part 1. · 74bf4312
      David S. Miller 提交于
      We now use the TSB hardware assist features of the UltraSPARC
      MMUs.
      
      SMP is currently knowingly broken, we need to find another place
      to store the per-cpu base pointers.  We hid them away in the TSB
      base register, and that obviously will not work any more :-)
      
      Another known broken case is non-8KB base page size.
      
      Also noticed that flush_tlb_all() is not referenced anywhere, only
      the internal __flush_tlb_all() (local cpu only) is used by the
      sparc64 port, so we can get rid of flush_tlb_all().
      
      The kernel gets it's own 8KB TSB (swapper_tsb) and each address space
      gets it's own private 8K TSB.  Later we can add code to dynamically
      increase the size of per-process TSB as the RSS grows.  An 8KB TSB is
      good enough for up to about a 4MB RSS, after which the TSB starts to
      incur many capacity and conflict misses.
      
      We even accumulate OBP translations into the kernel TSB.
      
      Another area for refinement is large page size support.  We could use
      a secondary address space TSB to handle those.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74bf4312
  2. 13 10月, 2005 1 次提交
    • D
      [SPARC64]: Fix boot failures on SunBlade-150 · c9c10830
      David S. Miller 提交于
      The sequence to move over to the Linux trap tables from
      the firmware ones needs to be more air tight.  It turns
      out that to be %100 safe we do need to be able to translate
      OBP mappings in our TLB miss handlers early.
      
      In order not to eat up a lot of kernel image memory with
      static page tables, just use the translations array in
      the OBP TLB miss handlers.  That solves the bulk of the
      problem.
      
      Furthermore, to make sure the OBP TLB miss path will work
      even before the fixed MMU globals are loaded, explicitly
      load %g1 to TLB_SFSR at the beginning of the i-TLB and
      d-TLB miss handlers.
      
      To ease the OBP TLB miss walking of the prom_trans[] array,
      we sort it then delete all of the non-OBP entries in there
      (for example, there are entries for the kernel image itself
      which we're not interested in at all).
      
      We also save about 32K of kernel image size with this change.
      Not a bad side effect :-)
      
      There are still some reasons why trampoline.S can't use the
      setup_trap_table() yet.  The most noteworthy are:
      
      1) OBP boots secondary processors with non-bias'd stack for
         some reason.  This is easily fixed by using a small bootup
         stack in the kernel image explicitly for this purpose.
      
      2) Doing a firmware call via the normal C call prom_set_trap_table()
         goes through the whole OBP enter/exit sequence that saves and
         restores OBP and Linux kernel state in the MMUs.  This path
         unfortunately does a "flush %g6" while loading up the OBP locked
         TLB entries for the firmware call.
      
         If we setup the %g6 in the trampoline.S code properly, that
         is in the PAGE_OFFSET linear mapping, but we're not on the
         kernel trap table yet so those addresses won't translate properly.
      
         One idea is to do a by-hand firmware call like we do in the
         early bootup code and elsewhere here in trampoline.S  But this
         fails as well, as aparently the secondary processors are not
         booted with OBP's special locked TLB entries loaded.  These
         are necessary for the firwmare to processes TLB misses correctly
         up until the point where we take over the trap table.
      
      This does need to be resolved at some point.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9c10830
  3. 12 10月, 2005 1 次提交
    • D
      [SPARC64]: Fix net booting on Ultra5 · b1b510aa
      David S. Miller 提交于
      We were not doing alignment properly when remapping the kernel image.
      
      What we want is a 4MB aligned physical address to map at KERNBASE.
      Mistakedly we were 4MB aligning the virtual address where the kernel
      initially sits, that's wrong.
      
      Instead, we should PAGE align the virtual address, then 4MB align the
      physical address result the prom gives to us.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1b510aa
  4. 11 10月, 2005 1 次提交
    • D
      [SPARC64]: Fix Ultra5, Ultra60, et al. boot failures. · 5d8e1b18
      David S. Miller 提交于
      On the boot processor, we need to do the move onto the Linux trap
      table a little bit differently else we'll take unhandlable faults in
      the firmware address space.
      
      Previously we would do the following:
      
      1) Disable PSTATE_IE in %pstate.
      2) Set %tba by hand to sparc64_ttable_tl0
      3) Initialize alternate, mmu, and interrupt global
         trap registers.
      4) Call prom_set_traptable()
      
      That doesn't work very well actually with the way we boot the kernel
      VM these days.  It worked by luck on many systems because the firmware
      accesses for the prom_set_traptable() call happened to be loaded into
      the TLB already, something we cannot assume.
      
      So the new scheme is this:
      
      1) Clear PSTATE_IE in %pstate and set %pil to 15
      2) Call prom_set_traptable()
      3) Initialize alternate, mmu, and interrupt global
         trap registers.
      
      and this works quite well.  This sequence has been moved into a
      callable function in assembler named setup-trap_table().  The idea is
      that eventually trampoline.S can use this code as well.  That isn't
      possible currently due to some complications, but eventually we should
      be able to do it.
      
      Thanks to Meelis Roos for the Ultra5 boot failure report.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d8e1b18
  5. 05 10月, 2005 1 次提交
  6. 29 9月, 2005 1 次提交
  7. 26 9月, 2005 1 次提交
    • D
      [SPARC64]: Add CONFIG_DEBUG_PAGEALLOC support. · 56425306
      David S. Miller 提交于
      The trick is that we do the kernel linear mapping TLB miss starting
      with an instruction sequence like this:
      
      	ba,pt		%xcc, kvmap_load
      	 xor		%g2, %g4, %g5
      
      succeeded by an instruction sequence which performs a full page table
      walk starting at swapper_pg_dir.
      
      We first take over the trap table from the firmware.  Then, using this
      constant PTE generation for the linear mapping area above, we build
      the kernel page tables for the linear mapping.
      
      After this is setup, we patch that branch above into a "nop", which
      will cause TLB misses to fall through to the full page table walk.
      
      With this, the page unmapping for CONFIG_DEBUG_PAGEALLOC is trivial.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56425306
  8. 23 9月, 2005 2 次提交
    • D
      [SPARC64]: Fix comment typo in head.S · a8201c61
      David S. Miller 提交于
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8201c61
    • D
      [SPARC64]: Rewrite bootup sequence. · bff06d55
      David S. Miller 提交于
      Instead of all of this cpu-specific code to remap the kernel
      to the correct location, use portable firmware calls to do
      this instead.
      
      What we do now is the following in position independant
      assembler:
      
      	chosen_node = prom_finddevice("/chosen");
      	prom_mmu_ihandle_cache = prom_getint(chosen_node, "mmu");
      	vaddr = 4MB_ALIGN(current_text_addr());
      	prom_translate(vaddr, &paddr_high, &paddr_low, &mode);
      	prom_boot_mapping_mode = mode;
      	prom_boot_mapping_phys_high = paddr_high;
      	prom_boot_mapping_phys_low = paddr_low;
      	prom_map(-1, 8 * 1024 * 1024, KERNBASE, paddr_low);
      
      and that replaces the massive amount of by-hand TLB probing and
      programming we used to do here.
      
      The new code should also handle properly the case where the kernel
      is mapped at the correct address already (think: future kexec
      support).
      
      Consequently, the bulk of remap_kernel() dies as does the entirety
      of arch/sparc64/prom/map.S
      
      We try to share some strings in the PROM library with the ones used
      at bootup, and while we're here mark input strings to oplib.h routines
      with "const" when appropriate.
      
      There are many more simplifications now possible.  For one thing, we
      can consolidate the two copies we now have of a lot of cpu setup code
      sitting in head.S and trampoline.S.
      
      This is a significant step towards CONFIG_DEBUG_PAGEALLOC support.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bff06d55
  9. 22 9月, 2005 1 次提交
  10. 31 8月, 2005 1 次提交
  11. 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