Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 7月, 2009 1 次提交
  3. 20 6月, 2009 1 次提交
  5. 30 5月, 2009 1 次提交
    • C
      Add core support for ARMv6/v7 big-endian · 26584853
      由 Catalin Marinas 提交于 
      Starting with ARMv6, the CPUs support the BE-8 variant of big-endian
(byte-invariant). This patch adds the core support:

- setting of the BE-8 mode via the CPSR.E register for both kernel and
  user threads
- big-endian page table walking
- REV used to rotate instructions read from memory during fault
  processing as they are still little-endian format
- Kconfig and Makefile support for BE-8. The --be8 option must be passed
  to the final linking stage to convert the instructions to
  little-endian
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      26584853
  7. 25 3月, 2009 1 次提交
  9. 23 3月, 2009 1 次提交
    • E
      [ARM] pxa: add base support for Marvell's PXA168 processor line · 49cbe786
      由 Eric Miao 提交于 
      """The Marvell® PXA168 processor is the first in a family of application
processors targeted at mass market opportunities in computing and consumer
devices. It balances high computing and multimedia performance with low
power consumption to support extended battery life, and includes a wealth
of integrated peripherals to reduce overall BOM cost .... """

See http://www.marvell.com/featured/pxa168.jsp for more information.

  1. Marvell Mohawk core is a hybrid of xscale3 and its own ARM core,
     there are many enhancements like instructions for flushing the
     whole D-cache, and so on

  2. Clock reuses Russell's common clkdev, and added the basic support
     for UART1/2.

  3. Devices are a bit different from the 'mach-pxa' way, the platform
     devices are now dynamically allocated only when necessary (i.e.
     when pxa_register_device() is called). Description for each device
     are stored in an array of 'struct pxa_device_desc'. Now that:

     a. this array of device description is marked with __initdata and
        can be freed up system is fully up

     b. which means board code has to add all needed devices early in
        his initializing function

     c. platform specific data can now be marked as __initdata since
        they are allocated and copied by platform_device_add_data()

  4. only the basic UART1/2/3 are added, more devices will come later.
Signed-off-by: NJason Chagas <chagas@marvell.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>
      49cbe786
  11. 28 2月, 2009 1 次提交
  13. 02 12月, 2008 1 次提交
  15. 06 11月, 2008 1 次提交
  17. 03 10月, 2008 1 次提交
  19. 01 9月, 2008 1 次提交
  21. 07 8月, 2008 1 次提交
  23. 23 6月, 2008 1 次提交
  25. 26 1月, 2008 2 次提交
  27. 18 12月, 2007 1 次提交
  29. 22 7月, 2007 1 次提交
  31. 12 7月, 2007 1 次提交
  33. 26 6月, 2007 1 次提交
  35. 03 6月, 2007 1 次提交
  37. 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
  39. 28 9月, 2006 1 次提交
    • H
      [ARM] nommu: manage the CP15 things · f12d0d7c
      由 Hyok S. Choi 提交于 
      All the current CP15 access codes in ARM arch can be categorized and
conditioned by the defines as follows:

     Related operation	Safe condition
  a. any CP15 access	!CPU_CP15
  b. alignment trap	CPU_CP15_MMU
  c. D-cache(C-bit)	CPU_CP15
  d. I-cache		CPU_CP15 && !( CPU_ARM610 || CPU_ARM710 ||
				CPU_ARM720 || CPU_ARM740 ||
				CPU_XSCALE || CPU_XSC3 )
  e. alternate vector	CPU_CP15 && !CPU_ARM740
  f. TTB		CPU_CP15_MMU
  g. Domain		CPU_CP15_MMU
  h. FSR/FAR		CPU_CP15_MMU

For example, alternate vector is supported if and only if
"CPU_CP15 && !CPU_ARM740" is satisfied.
Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f12d0d7c
  41. 25 9月, 2006 3 次提交
  43. 02 7月, 2006 1 次提交
  45. 01 7月, 2006 1 次提交
  47. 18 6月, 2006 1 次提交
  49. 27 3月, 2006 1 次提交
  51. 24 3月, 2006 1 次提交
  53. 19 1月, 2006 1 次提交
  55. 13 1月, 2006 1 次提交
    • R
      [ARM] Allow r2 to be passed through the decompressor to the kernel · f4619025
      由 Russell King 提交于 
      This is part of a patch from Marc Singer to allow r2 to be
passed to the kernel.  Marc's original comments follow:

This revised R2 (atags pointer) patch incorporates comments from Nico
Pitre and Ben Dooks. It modifies the head.S files such that the R2
value set by the bootloader is conveyed to the kernel startup code.
The kernel head.S heuristically validates the pointer. It will set R2
to zero if it believes the pointer is invalid. Presently, it requires
that the ATAGS list reside in the first 16KiB of physical RAM.
Relaxing this contraint may be both desirable as well as tricky.
Signed-off-by: NMarc Singer <elf@buici.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f4619025
  57. 16 11月, 2005 1 次提交
  59. 05 11月, 2005 1 次提交
  61. 28 10月, 2005 1 次提交
  63. 03 5月, 2005 1 次提交
  65. 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