Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 7月, 2008 1 次提交
  3. 10 6月, 2008 1 次提交
  5. 23 5月, 2008 1 次提交
  7. 10 5月, 2008 2 次提交
  9. 29 4月, 2008 1 次提交
    • G
      net: make ARP timeout configurable · 40cb90ee
      由 Guennadi Liakhovetski 提交于 
      Currently the timeout waiting for an ARP reply is hard set to 5 seconds.
On i.MX31ADS due to a hardware "strangeness" up to four first IP packets
to the boards get lost, which typically are ARP replies. By configuring
the timeout to a lower value we significantly improve the first network
transfer time on this board. The timeout is specified in milliseconds,
later internally it is converted to deciseconds, because it has to be
converted to hardware ticks, and CFG_HZ ranges from 900 to 27000000 on
different boards.
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NBen Warren <biggerbadderben@gmail.com>
      40cb90ee
  11. 18 4月, 2008 3 次提交
  13. 12 4月, 2008 1 次提交
  15. 08 4月, 2008 3 次提交
  17. 02 4月, 2008 1 次提交
  19. 30 3月, 2008 2 次提交
  21. 28 3月, 2008 1 次提交
  23. 27 3月, 2008 2 次提交
    • S
      ppc: Add CFG_MEM_TOP_HIDE option to hide memory area that doesn't get "touched" · 14f73ca6
      由 Stefan Roese 提交于 
      If CFG_MEM_TOP_HIDE is defined in the board config header, this specified
memory area will get subtracted from the top (end) of ram and won't get
"touched" at all by U-Boot. By fixing up gd->ram_size the Linux kernel
should gets passed the now "corrected" memory size and won't touch it
either. This should work for arch/ppc and arch/powerpc. Only Linux board
ports in arch/powerpc with bootwrapper support, which recalculate the
memory size from the SDRAM controller setup, will have to get fixed
in Linux additionally.

This patch enables this config option on some PPC440EPx boards as a workaround
for the CHIP 11 errata. Here the description from the AMCC documentation:

CHIP_11: End of memory range area restricted access.
Category: 3

Overview:
The 440EPx DDR controller does not acknowledge any
transaction which is determined to be crossing over the
end-of-memory-range boundary, even if the starting address is
within valid memory space. Any such transaction from any PLB4
master will result in a PLB time-out on PLB4 bus.

Impact:
In case of such misaligned bursts, PLB4 masters will not
retrieve any data at all, just the available data up to the
end of memory, especially the 440 CPU. For example, if a CPU
instruction required an operand located in memory within the
last 7 words of memory, the DCU master would burst read 8
words to update the data cache and cross over the
end-of-memory-range boundary. Such a DCU read would not be
answered by the DDR controller, resulting in a PLB4 time-out
and ultimately in a Machine Check interrupt. The data would
be inaccessible to the CPU.

Workaround:
Forbid any application to access the last 256 bytes of DDR
memory. For example, make your operating system believe that
the last 256 bytes of DDR memory are absent. AMCC has a patch
that does this, available for Linux.

This patch sets CFG_MEM_TOP_HIDE for the following 440EPx boards:
lwmon5, korat, sequoia

The other remaining 440EPx board were intentionally not included
since it is not clear to me, if they use the end of ram for some
other purpose. This is unclear, since these boards have CONFIG_PRAM
defined and even comments like this:

PMC440.h:
/* esd expects pram at end of physical memory.
 * So no logbuffer at the moment.
 */

It is strongly recommended to not use the last 256 bytes on those
boards too. Patches from the board maintainers are welcome.
Signed-off-by: NStefan Roese <sr@denx.de>
      14f73ca6
    • A
      README: update documentation (availability, links, etc.) · d4ee711d
      由 Anatolij Gustschin 提交于 
      Fix typo in README
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      d4ee711d
  25. 26 3月, 2008 2 次提交
  27. 19 3月, 2008 1 次提交
  29. 16 3月, 2008 1 次提交
  31. 12 3月, 2008 3 次提交
  33. 15 2月, 2008 1 次提交
    • W
      PPC: Use r2 instead of r29 as global data pointer · e7670f6c
      由 Wolfgang Denk 提交于 
      R29 was an unlucky choice as with recent toolchains (gcc-4.2.x) gcc
will refuse to use load/store multiple insns; instead, it issues a
list of simple load/store instructions upon function entry and exit,
resulting in bigger code size, which in turn makes the build for a
few boards fail.

Use r2 instead.
Signed-off-by: NWolfgang Denk <wd@denx.de>
      e7670f6c
  35. 05 2月, 2008 1 次提交
  37. 18 1月, 2008 4 次提交
  39. 17 1月, 2008 1 次提交
  41. 12 1月, 2008 1 次提交
  43. 10 1月, 2008 1 次提交
  45. 09 1月, 2008 1 次提交
  47. 17 12月, 2007 1 次提交
  49. 04 11月, 2007 1 次提交
  51. 29 8月, 2007 1 次提交
  53. 17 8月, 2007 1 次提交