1. 01 9月, 2008 1 次提交
  2. 06 3月, 2008 1 次提交
  3. 12 7月, 2007 1 次提交
  4. 08 5月, 2007 1 次提交
  5. 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
  6. 26 2月, 2007 2 次提交
  7. 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
  8. 12 12月, 2006 1 次提交
  9. 30 11月, 2006 1 次提交
  10. 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
  11. 18 8月, 2006 1 次提交
  12. 27 7月, 2006 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 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
  15. 25 6月, 2006 1 次提交
  16. 05 5月, 2006 1 次提交
  17. 27 3月, 2006 1 次提交
  18. 22 3月, 2006 2 次提交
  19. 14 1月, 2006 1 次提交
  20. 04 1月, 2006 1 次提交
  21. 25 11月, 2005 1 次提交
  22. 30 10月, 2005 2 次提交
  23. 10 9月, 2005 1 次提交
  24. 01 7月, 2005 1 次提交
  25. 18 6月, 2005 1 次提交
  26. 05 5月, 2005 1 次提交
    • R
      [PATCH] ARM: Fix kernel stack offset calculations · 4f7a1812
      Russell King 提交于
      Various places in the ARM kernel implicitly assumed that kernel
      stacks are always 8K due to hard coded constants.  Replace these
      constants with definitions.
      
      Correct the allowable range of kernel stack pointer values within
      the allocation.  Arrange for the entire kernel stack to be zeroed,
      not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set.
      Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
      4f7a1812
  27. 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