Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 8月, 2010 1 次提交
  3. 12 7月, 2010 1 次提交
    • E
      ARM: Auto calculate ZRELADDR and provide option for exceptions · e69edc79
      由 Eric Miao 提交于 
      As long as the zImage is placed within the 128MB range from the start of
memory, ZRELADDR (Address where the decompressed kernel will be placed,
usually == PHYS_OFFSET + TEXT_OFFSET) can be determined at run-time by
masking PC with 0xf80000000.

Running through all the Makefile.boot, all those zreladdr-y
addresses == 0x[0-f][08]00_0000 + TEXT_OFFSET can be determined at
run-time.

Option CONFIG_AUTO_ZRELADDR and CONFIG_ZRELADDR are introduced,
CONFIG_ZRELADDR _must_ be explicitly specified if:

- ((zreladdr-y - TEXT_OFFSET) & ~0xf8000000) != 0, which means
  masking PC with 0xf8000000 will result in an incorrect address.
  Currently this is only a problem on u300.

- or the assumption of the zImage being loaded by the bootloader within
  the first 128MB of RAM is incorrect

- or when ZBOOT_ROM is used, where the above assumption is usually wrong.

[ukleinek: changed mask from 0xf0000000 to 0xf8000000 for mx1 and shark
+ some review fixes from the mailing list]
Original-Idea-and-Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      e69edc79
  5. 07 7月, 2010 1 次提交
  7. 17 6月, 2010 5 次提交
  9. 06 5月, 2010 1 次提交
  11. 08 4月, 2010 1 次提交
  13. 15 3月, 2010 1 次提交
  15. 26 2月, 2010 1 次提交
    • R
      ARM: Fix decompressor's kernel size estimation for ROM=y · 98e12b5a
      由 Russell King 提交于 
      Commit 2552fc27 changed the way the decompressor decides if it is safe
to decompress the kernel directly to its final location.  Unfortunately,
it took the top of the compressed data as being the stack pointer,
which it is for ROM=n cases.  However, for ROM=y, the stack pointer
is not relevant, and results in the wrong answer.

Fix this by explicitly storing the end of the biggybacked data in the
decompressor, and use that to calculate the compressed image size.

CC: <stable@kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      98e12b5a
  17. 13 2月, 2010 1 次提交
  19. 20 1月, 2010 1 次提交
  21. 28 11月, 2009 1 次提交
  23. 24 7月, 2009 3 次提交
  25. 20 6月, 2009 1 次提交
  27. 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
  29. 25 3月, 2009 1 次提交
  31. 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
  33. 28 2月, 2009 1 次提交
  35. 02 12月, 2008 1 次提交
  37. 06 11月, 2008 1 次提交
  39. 03 10月, 2008 1 次提交
  41. 01 9月, 2008 1 次提交
  43. 07 8月, 2008 1 次提交
  45. 23 6月, 2008 1 次提交
  47. 26 1月, 2008 2 次提交
  49. 18 12月, 2007 1 次提交
  51. 22 7月, 2007 1 次提交
  53. 12 7月, 2007 1 次提交
  55. 26 6月, 2007 1 次提交
  57. 03 6月, 2007 1 次提交
  59. 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
  61. 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
  63. 25 9月, 2006 2 次提交