1. 16 5月, 2009 1 次提交
  2. 13 5月, 2009 1 次提交
  3. 02 5月, 2009 1 次提交
  4. 01 5月, 2009 1 次提交
  5. 30 4月, 2009 1 次提交
  6. 17 4月, 2009 3 次提交
  7. 05 4月, 2009 7 次提交
  8. 31 3月, 2009 3 次提交
  9. 22 3月, 2009 6 次提交
  10. 21 3月, 2009 1 次提交
    • T
      Fix all linker script to handle all rodata sections · f62fb999
      Trent Piepho 提交于
      A recent gcc added a new unaligned rodata section called '.rodata.str1.1',
      which needs to be added the the linker script.  Instead of just adding this
      one section, we use a wildcard ".rodata*" to get all rodata linker section
      gcc has now and might add in the future.
      
      However, '*(.rodata*)' by itself will result in sub-optimal section
      ordering.  The sections will be sorted by object file, which causes extra
      padding between the unaligned rodata.str.1.1 of one object file and the
      aligned rodata of the next object file.  This is easy to fix by using the
      SORT_BY_ALIGNMENT command.
      
      This patch has not be tested one most of the boards modified.  Some boards
      have a linker script that looks something like this:
      
      *(.text)
      . = ALIGN(16);
      *(.rodata)
      *(.rodata.str1.4)
      *(.eh_frame)
      
      I change this to:
      
      *(.text)
      . = ALIGN(16);
      *(.eh_frame)
      *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
      
      This means the start of rodata will no longer be 16 bytes aligned.
      However, the boundary between text and rodata/eh_frame is still aligned to
      16 bytes, which is what I think the real purpose of the ALIGN call is.
      Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
      f62fb999
  11. 25 1月, 2009 1 次提交
  12. 16 12月, 2008 1 次提交
  13. 14 12月, 2008 2 次提交
  14. 07 12月, 2008 1 次提交
  15. 21 11月, 2008 1 次提交
    • S
      AT91: Enable PLLB for USB · 3e0cda07
      Stelian Pop 提交于
      At least some (old ?) versions of the AT91Bootstrap do not set up the
      PLLB correctly to 48 MHz in order to make USB host function correctly.
      
      This patch sets up the PLLB to the same values Linux uses, and makes USB
      work ok on the following CPUs:
      	- AT91CAP9
      	- AT91SAM9260
      	- AT91SAM9263
      
      This patch also defines CONFIG_USB_STORAGE and CONFIG_CMD_FAT for all
      the relevant AT91CAP9/AT91SAM9 atmel boards.
      Signed-off-by: NStelian Pop <stelian@popies.net>
      Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      3e0cda07
  16. 19 11月, 2008 1 次提交
  17. 05 11月, 2008 1 次提交
  18. 19 10月, 2008 1 次提交
  19. 12 9月, 2008 1 次提交
  20. 11 9月, 2008 1 次提交
    • H
      ARM DaVinci: Fix broken HW ECC for large page NAND. · 9b05aa78
      Hugo Villeneuve 提交于
      Based on original patch by Bernard Blackham <bernard@largestprime.net>
      
      U-boot's HW ECC support for large page NAND on Davinci is completely
      broken.  Some kernels, such as the 2.6.10 one supported by
      MontaVista for DaVinci, rely upon this broken behaviour as they
      share the same code for ECCs. In the existing scheme, error
      detection *might* work on large page, but error correction
      definitely does not.  Small page ECC correction works, but the
      format is not compatible with the mainline git kernel.
      
      This patch adds ECC code that matches what is currently in the
      Davinci git repository (since NAND support was added in 2.6.24).
      This makes the ECC and OOB layout written by u-boot compatible with
      Linux for both small page and large page devices and fixes ECC
      correction for large page devices.
      
      The old behaviour can be restored by defining the macro
      CFG_DAVINCI_BROKEN_ECC, which is undefined by default.
      Signed-off-by: NHugo Villeneuve <hugo.villeneuve@lyrtech.com>
      Acked-by: NSergey Kubushyn <ksi@koi8.net>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      9b05aa78
  21. 03 9月, 2008 1 次提交
  22. 31 8月, 2008 1 次提交
    • S
      ARM DaVinci: Changing function names for EMAC driver · fcaac589
      Sandeep Paulraj 提交于
      DM644x is just one of a series of DaVinci chips that use the EMAC driver.
      By replacing all the function names that start with dm644x_* to davinci_*
      we make these function more portable. I have tested this change on my EVM.
      DM6467 is another DaVinci SOC which uses the EMAC driver and i will
      be sending patches that add DaVinci DM6467 support to the list soon.
      Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
      fcaac589
  23. 25 8月, 2008 2 次提交