1. 07 5月, 2009 26 次提交
  2. 05 5月, 2009 7 次提交
  3. 01 5月, 2009 4 次提交
  4. 28 4月, 2009 3 次提交
    • T
      arm: Use __INIT macro instead of .text.init. · 991da17e
      Tim Abbott 提交于
      arm is placing some code in the .text.init section, but it does not
      reference that section in its linker scripts.
      
      This change moves this code from the .text.init section to the
      .init.text section, which is presumably where it belongs.
      Signed-off-by: NTim Abbott <tabbott@mit.edu>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      991da17e
    • D
      davinci: DM644x: NAND: update partitioning · 3e9c18e1
      David Brownell 提交于
      Update NAND partitioning for the dm6446 evm, unmasking the hidden
      data at the beginning and letting the kernel be updated from Linux.
      
       - This is boot-compatible with TI's software (U-Boot 1.20 and both
         the 2.6.10 and 2.6.18 kernels), in terms of startup and loading
         kernels from flash.
      
       - In the same way, it's also boot-compatible with mainline U-Boot,
         which stores U-Boot params in block 0 not block 16.
      
       - It's not quite compatible with systems that previously used NAND
         partitions to hold (filesystem) data.  The compatibilities are a
         bit different based on which kernel was used previously
           + Users of TI/MV kernels no longer see mtd2 "params"
             (mainline u-boot env is in a different place)
      	* Filesystem is now mtd2 ... vs mtd3
           + Users of GIT kernels now see mtd0 and mtd1 partitions
      	* Filesystem partition starts 640 KBytes earlier
      	* Filesystem is now mtd2 ... vs mtd0
           * Linux now *uses* the flash-resident BBT
      	* Removes annoying slowdown/hiccup during boot
      	* Potentially ~64KB less space available with TI/MV kernels
      
      If you *used* NAND partitions from Linux, there is no solution that's
      fully compatible with all previous kernels in those respects ... ergo
      this "best compromise".  It'd be good to back back up the filesystem
      data; or, carry your own backwards-compatibility patch for awhile.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      3e9c18e1
    • K
      davinci: update DM644x support in preparation for more SoCs · d0e47fba
      Kevin Hilman 提交于
      Rework DM644x code into SoC specific and board specific parts.
      This is also to generalize the structure a bit so it's easier to add
      support for new SoCs in the DaVinci family.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      d0e47fba