[U-Boot-Users] yet another hang after relocate
sehammond at yahoo.com
Tue Jan 23 00:54:39 CET 2007
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
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
DRAM: 16 MB
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
More information about the U-Boot