[U-Boot-Users] yet another hang after relocate

[Scott Hammond]

I know that this has been rehashed a thousand times,
but Im still stuck on this point.

Im using U-Boot 1.1.5 compiled with gcc 2.4.6 and make
3.80.

The boards I have use a 405GPr cpu with 2x
MT48LC4M16A2-75G mem chips (for 16MB) and an intel 2MB
JS28F160C3B flash chip.  I have several boards at
different speeds (200-333) and different mem speeds
(100-133).  Some have the 405 set to the old GP mode
and others are in the new 405GPr mode.  They all boot
and run vxworks just fine, though Im not sure if that
runs from ram or not.

The sdram setup for the 405 is extremely simple, just
a few registers and delays.  It is identical to all
the other 405 sample boards in the u-boot source,
which I assume boot just fine.  Ive played with all
the registers and delay timings involved in sdram
setup without success.

Ive added a simple mem test with and without the data
cache, which works fine either way. Also I copy the
entire 2MB flash to ram and then verify it back.
Again, no problems.

Here is a typical console output:


U-Boot 1.1.5 (Jan 22 2007 - 17:31:18)

CPU:   AMCC PowerPC 405GPr Rev. B at 200 MHz (PLB=100,
OPB=100, EBC=50 MHz)
, PCI async ext clock used       16 kB I-Cache 16 kB
D-Cache
Board: xxxx
DRAM:  16 MB
mcopt1: 80e00000
mb0cf: 46001
sdtr1: 86400d
rtr: 5f00000
status: 80000000
speed: 100000000
CFG_FLASH_BASE: ffe00000
TEXT_BASE: fffc0000
CFG_MONITOR_BASE: ffe00000
CFG_MONITOR_LEN: 40000
CFG_MALLOC_LEN: 20000
CFG_ENV_IS_IN_FLASH: 1
CFG_ENV_SIZE: 800
CFG_ENV_ADDR: ffe3f7f0
CFG_ENV_OFFSET: 3f7f0
test: 16 MB - ok
Flash copy test - ok
fffc0000: 27051956 27051956
fffc0004: 552d426f 552d426f
fffc0008: 6f742031 6f742031
fffc000c: 2e312e35 2e312e35
Top of RAM usable for U-Boot at: 01000000
Reserving 1935k for U-Boot at: 00e1c000
Reserving 128k for malloc() at: 00dfc000
Reserving 132 Bytes for Board Info at: 00dfbf7c
Reserving 48 Bytes for Global Data at: 00dfbf4c
Stack Pointer at: 00dfbf28
New Stack Pointer is: 00dfbf28


Im also dumping out the sdram registers, and a few
global defines which might be important.  The flash
test (after copying to ram) also dumps out the first
few words of TEXT_BASE in flash and in memory for
visual inspection.  This test does not supersede the
flash copy done by relocate.

I use a gpio controlled LED to pin point the crash,
and it is just as it tries to jump to ram.

I know sdram is 99% of the time the main culprit, but
I have tried many different register values for this. 
Also the setup is no different from the other 405
based boards already in uboot.  The sdram setup for
the 405 is extremely simple anyway, all the chip
programming seems to be handled by the cpu.

Is there any environment/global define, compilier
issue, execute protection, guarded page, strange
register, who knows, that might be the cause of this
other than the sdram?  Any tests I can run on the
sdram to highlight this?  Every write-verify test I
have done has worked perfectly.

I have a feeling the sdram is fine, and either
relocate's flash copy was to the wrong destination, or
the jump is going to the wrong place.

thanks for the help
Scott