1. 09 3月, 2011 1 次提交
  2. 26 2月, 2011 1 次提交
    • N
      ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel · d239b1dc
      Nicolas Pitre 提交于
      We currently presume a 4x expansion to guess the decompressed kernel size
      in order to determine if the decompressed kernel is in conflict with
      the location where zImage is loaded.  This guess may cause many issues
      by overestimating the final kernel image size:
      
      - This may force a needless relocation if the location of zImage was
        fine, wasting some precious microseconds of boot time.
      
      - The relocation may be located way too far, possibly overwriting the
        initrd image in RAM.
      
      - If the kernel image includes a large already-compressed initramfs image
        then the problem is even more exacerbated.
      
      And if by some strange means the 4x guess is too low then we may overwrite
      ourselves with the decompressed image.
      
      So let's use the exact decompressed kernel image size instead.  For that
      we need to rely on the stat command, but this is hardly a new build
      dependency as the kernel already depends on many external commands
      to be built provided by the coreutils package where stat is found.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d239b1dc
  3. 24 2月, 2011 3 次提交
  4. 19 2月, 2011 1 次提交
  5. 25 1月, 2011 2 次提交
    • A
      ARM: 6597/1: Add basic architecture support for VIA/WonderMedia 85xx SoC's · 21f47fbc
      Alexey Charkov 提交于
      This adds support for the family of Systems-on-Chip produced initially
      by VIA and now its subsidiary WonderMedia that have recently become
      widespread in lower-end Chinese ARM-based tablets and netbooks.
      
      Support is included for both VT8500 and WM8505, selectable by a
      configuration switch at kernel build time.
      
      Included are basic machine initialization files, register and
      interrupt definitions, support for the on-chip interrupt controller,
      high-precision OS timer, GPIO lines, necessary macros for early debug,
      pulse-width-modulated outputs control, as well as platform device
      configurations for the specific drivers implemented elsewhere.
      Signed-off-by: NAlexey Charkov <alchark@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      21f47fbc
    • 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
  6. 05 12月, 2010 1 次提交
  7. 30 11月, 2010 3 次提交
  8. 22 11月, 2010 1 次提交
  9. 19 9月, 2010 1 次提交
  10. 10 9月, 2010 1 次提交
  11. 11 8月, 2010 1 次提交
  12. 05 8月, 2010 1 次提交
  13. 29 7月, 2010 1 次提交
  14. 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
  15. 07 7月, 2010 3 次提交
  16. 24 6月, 2010 1 次提交
  17. 17 6月, 2010 5 次提交
  18. 25 5月, 2010 1 次提交
  19. 06 5月, 2010 1 次提交
  20. 14 4月, 2010 1 次提交
  21. 08 4月, 2010 1 次提交
  22. 15 3月, 2010 2 次提交
  23. 13 3月, 2010 1 次提交
    • M
      ARM: 5985/2: ARM: Fix Samsung build after "ARM: Eliminate decompressor -Dstatic= PIC hack" · a2302b45
      Mark Brown 提交于
      Commit 5de813b6 (ARM: Eliminate decompressor -Dstatic= PIC hack) among
      other things changed the declared type of the error() function to an
      extern, conflicting with the forward declartion in the Samsung
      plat/uncompress.h which appears to have been relying on the static
      being defined away, causing build failures since error() ends up with
      a GOT relocation but the linker script discards all GOT relocated
      data and functions:
      
      arch/arm/boot/compressed/decompress.o: In function `gunzip':
      /home/broonie/git/linux-2.6/arch/arm/boot/compressed/../../../../lib/decompress_
      +inflate.c:68: undefined reference to `error'
      
      and so on. Fix this by moving the declaration into uncompress/misc.c
      where it is shared with the rest of the code, correcting the definition
      as we go.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a2302b45
  24. 26 2月, 2010 2 次提交
    • 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
    • R
      ARM: Eliminate decompressor -Dstatic= PIC hack · 5de813b6
      Russell King 提交于
      We used to build decompressors with -Dstatic= to avoid any local data
      being generated.  The problem is that local data generates GOTOFF
      relocations, which means we can't relocate the data relative to the
      text segment.
      
      Global data, on the other hand, goes through the GOT, and can be
      relocated anywhere.
      
      Unfortunately, with the new decompressors, this presents a problem
      since they declare static data within functions, and this leads to
      stack overflow.
      
      Fix this by separating out the decompressor code into a separate file,
      and removing 'static' from BSS data in misc.c.
      
      Also, discard the .data section - this means that should we end up
      with read/write initialized data, the decompressor will fail to link
      and the problem will be obvious.
      Acked-by: NNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5de813b6
  25. 13 2月, 2010 1 次提交
  26. 05 2月, 2010 1 次提交
  27. 20 1月, 2010 1 次提交