1. 20 3月, 2006 5 次提交
  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. 06 10月, 2005 1 次提交
    • D
      [SPARC64]: Fix initrd when net booting. · 9ad98c5b
      David S. Miller 提交于
      By allocating early memory for the firmware page tables, we
      can write over the beginning of the initrd image.
      
      So what we do now is:
      
      1) Read in firmware translations table while still on the
         firmware's trap table.
      2) Switch to Linux trap table.
      3) Init bootmem.
      4) Build firmware page tables using __alloc_bootmem().
      
      And this keeps the initrd from being clobbered.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ad98c5b
  4. 05 10月, 2005 1 次提交
  5. 30 9月, 2005 1 次提交
  6. 29 9月, 2005 2 次提交
  7. 27 9月, 2005 1 次提交
  8. 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
  9. 24 9月, 2005 1 次提交
  10. 23 9月, 2005 2 次提交
    • 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
    • D
      [SPARC64]: Kill readjust_prom_translations() · 40fd3533
      David S. Miller 提交于
      Testing shows that the prom_unmap() calls do absolutely
      nothing.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40fd3533
  11. 22 9月, 2005 5 次提交
  12. 08 9月, 2005 1 次提交
  13. 28 7月, 2005 1 次提交
  14. 28 6月, 2005 1 次提交
    • D
      [SPARC64]: Avoid membar instructions in delay slots. · b445e26c
      David S. Miller 提交于
      In particular, avoid membar instructions in the delay
      slot of a jmpl instruction.
      
      UltraSPARC-I, II, IIi, and IIe have a bug, documented in
      the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
      
      The long and short of it is that if the IMU unit misses
      on a branch or jmpl, and there is a store buffer synchronizing
      membar in the delay slot, the chip can stop fetching instructions.
      
      If interrupts are enabled or some other trap is enabled, the
      chip will unwedge itself, but performance will suffer.
      
      We already had a workaround for this bug in a few spots, but
      it's better to have the entire tree sanitized for this rule.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b445e26c
  15. 06 5月, 2005 1 次提交
  16. 18 4月, 2005 1 次提交
  17. 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