1. 26 5月, 2011 1 次提交
  2. 11 5月, 2011 1 次提交
  3. 11 3月, 2011 1 次提交
  4. 18 2月, 2011 4 次提交
  5. 16 2月, 2011 1 次提交
  6. 10 2月, 2011 1 次提交
  7. 01 2月, 2011 1 次提交
  8. 20 12月, 2010 2 次提交
    • D
      ARM: 6516/1: Allow SMP_ON_UP to work with Thumb-2 kernels. · ed3768a8
      Dave Martin 提交于
        * __fixup_smp_on_up has been modified with support for the
          THUMB2_KERNEL case.  For THUMB2_KERNEL only, fixups are split
          into halfwords in case of misalignment, since we can't rely on
          unaligned accesses working before turning the MMU on.
      
          No attempt is made to optimise the aligned case, since the
          number of fixups is typically small, and it seems best to keep
          the code as simple as possible.
      
        * Add a rotate in the fixup_smp code in order to support
          CPU_BIG_ENDIAN, as suggested by Nicolas Pitre.
      
        * Add an assembly-time sanity-check to ALT_UP() to ensure that
          the content really is the right size (4 bytes).
      
          (No check is done for ALT_SMP().  Possibly, this could be fixed
          by splitting the two uses ot ALT_SMP() (ALT_SMP...SMP_UP versus
          ALT_SMP...SMP_UP_B) into two macros.  In the first case,
          ALT_SMP needs to expand to >= 4 bytes, not == 4.)
      
        * smp_mpidr.h (which implements ALT_SMP()/ALT_UP() manually due
          to macro limitations) has not been modified: the affected
          instruction (mov) has no 16-bit encoding, so the correct
          instruction size is satisfied in this case.
      
        * A "mode" parameter has been added to smp_dmb:
      
          smp_dmb arm @ assumes 4-byte instructions (for ARM code, e.g. kuser)
          smp_dmb     @ uses W() to ensure 4-byte instructions for ALT_SMP()
      
          This avoids assembly failures due to use of W() inside smp_dmb,
          when assembling pure-ARM code in the vectors page.
      
          There might be a better way to achieve this.
      
        * Kconfig: make SMP_ON_UP depend on
          (!THUMB2_KERNEL || !BIG_ENDIAN) i.e., THUMB2_KERNEL is now
          supported, but only if !BIG_ENDIAN (The fixup code for Thumb-2
          currently assumes little-endian order.)
      
      Tested using a single generic realview kernel on:
      	ARM RealView PB-A8 (CONFIG_THUMB2_KERNEL={n,y})
      	ARM RealView PBX-A9 (SMP)
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ed3768a8
    • R
      ARM: SMP: use more sane register allocation for __fixup_smp_on_up · 0eb0511d
      Russell King 提交于
      Use r0,r3-r6 rather than r0,r3,r4,r6,r7, which makes it easier to
      understand which registers can be modified.  Also document which
      registers hold values which must be preserved.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0eb0511d
  9. 30 11月, 2010 2 次提交
  10. 20 10月, 2010 1 次提交
  11. 08 10月, 2010 4 次提交
  12. 05 10月, 2010 1 次提交
    • R
      ARM: Allow SMP kernels to boot on UP systems · f00ec48f
      Russell King 提交于
      UP systems do not implement all the instructions that SMP systems have,
      so in order to boot a SMP kernel on a UP system, we need to rewrite
      parts of the kernel.
      
      Do this using an 'alternatives' scheme, where the kernel code and data
      is modified prior to initialization to replace the SMP instructions,
      thereby rendering the problematical code ineffectual.  We use the linker
      to generate a list of 32-bit word locations and their replacement values,
      and run through these replacements when we detect a UP system.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f00ec48f
  13. 24 11月, 2009 1 次提交
  14. 24 7月, 2009 1 次提交
  15. 01 9月, 2008 1 次提交
  16. 06 3月, 2008 1 次提交
  17. 12 7月, 2007 1 次提交
  18. 08 5月, 2007 1 次提交
  19. 04 5月, 2007 1 次提交
    • N
      [ARM] 4227/1: minor head.S fixups · 40435792
      Nicolas Pitre 提交于
      Let's surround constructs like:
      
      	orr	r3, r3, #(KERNEL_RAM_PADDR & 0x00f00000)
      
      between .if .endif since (KERNEL_RAM_PADDR & 0x00f00000) is 0 in 99% of
      all cases.
      
      Also let's mask PHYS_OFFSET with 0x00f00000 instead of 0x00e00000.
      Section mappings are really 1MB not 2MB and the 2MB groupping is
      a higher level issue already much better enforced with
      
      #if (PHYS_OFFSET & 0x001fffff)
      #error "PHYS_OFFSET must be at an even 2MiB boundary!"
      #endif
      
      at the top of the file.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      40435792
  20. 26 2月, 2007 2 次提交
  21. 24 1月, 2007 1 次提交
    • L
      [ARM] 4102/1: Allow for PHYS_OFFSET on any valid 2MiB address · d4e1c889
      Linus Walleij 提交于
      This patchs allows the offset to the first page of
      physical memory to be on any 2MB boundary
      whereas the previous code could only handle psysical
      offset to any 16MB boundary (0xNN000000) or any 1MB
      boundary below 0x01000000 (e.g. 0x00N00000). The
      problem is a consequence of the orr one-byte syntax,
      so we fix this and we can place the first bank of
      memory at 0x28e00000. I have also included an explicit
      check that disallow compilation when PHYS_OFFSET is
      not on a 2MiB boundary. head.S would be the proper place
      to have this at since this is the first file that
      attempts to use PHYS_OFFSET during compile.
      Signed-off-by: NLinus Walleij <triad@df.lth.se>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d4e1c889
  22. 12 12月, 2006 1 次提交
  23. 30 11月, 2006 1 次提交
  24. 30 9月, 2006 1 次提交
    • L
      [ARM] 3809/3: get rid of 4 megabyte kernel image size limit · 2552fc27
      Lennert Buytenhek 提交于
      We currently have a hardcoded 4 megabyte uncompressed kernel image
      size limit, which is easily exceeded by, for example, enabling some of
      the various kernel debugging options.
      
      When setting up the initial page tables (which is where this 4M limit
      is hardcoded), it's actually relatively easy to find out the true size
      of the uncompressed kernel image and create enough page table entries
      for things to fit, so this patch makes it so.
      
      In the decompressor, we also need to know the size of the uncompressed
      kernel image, to figure out whether there is any chance that uncompressing
      the kernel might overwrite the compressed kernel image stored elsewhere
      in memory. We don't have that info at this boot stage, though, so we
      approximate the size of the uncompressed kernel by taking the compressed
      kernel image size and allowing for a maximum 4x expansion.
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2552fc27
  25. 18 8月, 2006 1 次提交
  26. 27 7月, 2006 1 次提交
  27. 01 7月, 2006 1 次提交
  28. 30 6月, 2006 1 次提交
    • R
      [ARM] Set bit 4 on section mappings correctly depending on CPU · 8799ee9f
      Russell King 提交于
      On some CPUs, bit 4 of section mappings means "update the
      cache when written to".  On others, this bit is required to
      be one, and others it's required to be zero.  Finally, on
      ARMv6 and above, setting it turns on "no execute" and prevents
      speculative prefetches.
      
      With all these combinations, no one value fits all CPUs, so we
      have to pick a value depending on the CPU type, and the area
      we're mapping.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8799ee9f
  29. 25 6月, 2006 1 次提交
  30. 05 5月, 2006 1 次提交
  31. 27 3月, 2006 1 次提交