Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 1月, 2011 1 次提交
    • S
      ARM: 6617/1: mmc, Add zboot from MMC support for SuperH Mobile ARM · f45b1149
      由 Simon Horman 提交于 
      This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
hardware block.

This is achieved by the MaskROM loading the first portion
of the image into MERAM and then jumping to it. This portion
contains loader code which copies the entire image to SDRAM
and jumps to it. From there the zImage boot code proceeds
as normal, uncompressing the image into its final location
and then jumping to it.

Cc: Magnus Damm <magnus.damm@gmail.com>

Russell, please consider merging this for 2.6.38.

This patch depends on:
* "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
  which will be merged though Paul Mundt's rmobile sh-2.6.
  The absence of this patch will break the build if
  the (new) CONFIG_ZBOOT_ROM_MMCIF option is set.
  There are no subtle side-effects.

v2:
Addressed comments by Magnus Damm
* Fix copyright in vrl4.c
* Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
* Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
  as this is considered board-specific.

v3:
Addressed comments made in person by Magnus Damm
* Move mmcif_loader to be earlier in the image and
  reduce the number of blocks of boot program loaded by the MaskRom
  from 40 to 8 accordingly.
* Move LED GPIO initialisation into mmcif_progress_init
  - This leaves the partner jet script unbloated
Other
* inline mmcif_update_progress so it is a static inline in a header file

v4:
* Use htole16() and htole32() in v4rl.c to ensure
  that the output is little endian

v5:
Addressed comments by Russell King
* Simplify assembly code
* Jump to code rather than an address <- bug fix
* Use (void __iomem *) as appropriate
Roll in mackerel support
* This was previously a separate patch, only because of the order
  in which this code was developed
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f45b1149
  3. 14 1月, 2011 2 次提交
  5. 13 1月, 2011 1 次提交
  7. 07 1月, 2011 2 次提交
  9. 05 1月, 2011 1 次提交
  11. 02 1月, 2011 1 次提交
  13. 24 12月, 2010 1 次提交
    • E
      ARM: 6532/1: Allow machine to specify it's own IRQ handlers at run-time · 52108641
      由 eric miao 提交于 
      Normally different ARM platform has different way to decode the IRQ
hardware status and demultiplex to the corresponding IRQ handler.
This is highly optimized by macro irq_handler in entry-armv.S, and
each machine defines their own macro to decode the IRQ number.
However, this prevents multiple machine classes to be built into a
single kernel.

By allowing each machine to specify thier own handler, and making
function pointer 'handle_arch_irq' to point to it at run time, this
can be solved. And introduce CONFIG_MULTI_IRQ_HANDLER to allow both
solutions to work.

Comparing with the highly optimized macro of irq_handler, the new
function must be written with care not to lose too much performance.
And the IPI stuff on SMP is expected to move to the provided arch
IRQ handler as well.

The assembly code to invoke handle_arch_irq is optimized by Russell
King.
Signed-off-by: NEric Miao <eric.miao@canonical.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      52108641
  15. 23 12月, 2010 12 次提交
  17. 21 12月, 2010 2 次提交
  19. 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
    • H
      ARM: pxa: add iwmmx support for PJ4 · ef6c8445
      由 Haojian Zhuang 提交于 
      iwmmxt is used in XScale, XScale3, Mohawk and PJ4 core. But the instructions
of accessing CP0 and CP1 is changed in PJ4. Append more files to support
iwmmxt in PJ4 core.
Signed-off-by: NZhou Zhu <zzhu3@marvell.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      ef6c8445
  21. 15 12月, 2010 2 次提交
  23. 14 12月, 2010 1 次提交
  25. 09 12月, 2010 1 次提交
  27. 06 12月, 2010 1 次提交
  29. 05 12月, 2010 1 次提交
  31. 04 12月, 2010 1 次提交
  33. 30 11月, 2010 2 次提交
  35. 26 11月, 2010 1 次提交
  37. 23 11月, 2010 2 次提交
  39. 20 11月, 2010 1 次提交
    • R
      ARM: ftrace: enable function graph tracer · 0e341af8
      由 Rabin Vincent 提交于 
      Add the options to enable the function graph tracer on ARM.  Function
graph tracer support requires frame pointers, so exclude Thumb-2 and
also make sure FRAME_POINTER gets enabled when FUNCTION_GRAPH_TRACER is
used, since FUNCTION_TRACER doesn't "select FRAME_POINTER" when
ARM_UNWIND is used.  Therefore, with GCC 4.4.0+, you get plain function
tracing without frame pointers, but you'll need them if you want
function graph tracing.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRabin Vincent <rabin@rab.in>
      0e341af8
  41. 16 11月, 2010 1 次提交
    • P
      ARM: mach-shmobile: Tidy up the Kconfig bits. · 6d72ad35
      由 Paul Mundt 提交于 
      Presently each one of the CPUs manually selects the same feature set, and
there's a reasonable expectation that none of these will change for
future CPUs in the SH-Mobile / R-Mobile family, so we move those over to
the top-level ARCH_SHMOBILE.

While we're at it, all of the CPUs support optional GPIOs via the PFC,
do not have I/O ports, and expect sparse IRQ, so we bring the
configuration in line across the board.

This more or less brings the ARM-based parts in sync with their SH
counterparts.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      6d72ad35
  43. 13 11月, 2010 1 次提交