yet another hang after relocate

U-Boot-Users Scott Hammond 3 participants 6 messages Jan 22, 2007 – Jan 23, 2007

lore

Share & tools

lore

Scott Hammond

author

2007-01-22 23:54 UTC #0 lore raw

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

Wolfgang Denk

2007-01-23 00:08 UTC #1 lore raw

Quoted 3 lines · In message <[email protected]> you wrote:

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

Why don't you use current U-Boot code your new development?

And what the heck is GCC 2.4.6???

Quoted 3 lines

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.

See the FAQ.

Quoted 2 lines

The sdram setup for the 405 is extremely simple, just a few registers and delays. It is identical to all

You still have to get it right.

Quoted 4 lines

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.

See the FAQ why this doesn't mean anything.

Quoted 2 lines

TEXT_BASE: fffc0000
CFG_MONITOR_BASE: ffe00000

Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure about this?

Quoted 2 lines

CFG_ENV_ADDR: ffe3f7f0
CFG_ENV_OFFSET: 3f7f0

Really? Not aligned to a sector boundary? Are you sure about this?

Quoted 2 lines

Top of RAM usable for U-Boot at: 01000000 Reserving 1935k for U-Boot at: 00e1c000

Really? Your U-Boot image needs nearly 2 MB ? Are you sure about this?

Quoted 2 lines

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

...as expected for a FAQ #1 entry question.

Quoted 1 line

I have a feeling the sdram is fine, and either

Your feeling may be wrong. And your U-Boot is misconfigured, too.

Best regards,

Wolfgang Denk

Signature · 6 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report! - Ken Burchill?

Scott Hammond

author

2007-01-23 00:35 UTC #2 lore raw

Sorry I meant gcc 3.4.6

This is the error I get at the end of building U-Boot 1.1.6:

-Map u-boot.map -o u-boot
cpu/ppc4xx/resetvec.o(.debug_info+0x14): relocation truncated to fit: R_PPC_ADDR32 against `.resetvec'+4
make: *** [u-boot] Error 1

I seem to get this regardless of which standard board I try to build for. This particular one came from walnut_config. 1.1.5 didnt have this problem, so I started using that.

Quoted 9 lines

Quoted 1 line
Ive added a simple mem test with and without the
data
Quoted 1 line
cache, which works fine either way. Also I copy
the
Quoted 2 lines
entire 2MB flash to ram and then verify it back.
Again, no problems.
See the FAQ why this doesn't mean anything.

Yeah I know read-write doesnt mean execute will work, but at least I know I am copying from flash ok.

Quoted 5 lines

Quoted 2 lines
TEXT_BASE: fffc0000
CFG_MONITOR_BASE: ffe00000
Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure about this?

Yeah these defines did seem strange to me, thats why I was dumping them out. Ill dig into this and see if that isnt the source of the problem.

thanks,
Scott

Quoted 82 lines · --- Wolfgang Denk

In message <[email protected]> you
Quoted 2 lines · wrote:
Im using U-Boot 1.1.5 compiled with gcc 2.4.6 and
make
Quoted 1 line
3.80.
Why don't you use current U-Boot code your new development?
And what the heck is GCC 2.4.6???
Quoted 1 line
and others are in the new 405GPr mode. They all
boot
Quoted 1 line
and run vxworks just fine, though Im not sure if
that
Quoted 1 line
runs from ram or not.
See the FAQ.
Quoted 1 line
The sdram setup for the 405 is extremely simple,
just
Quoted 1 line
a few registers and delays. It is identical to
all
You still have to get it right.
Quoted 1 line
Ive added a simple mem test with and without the
data
Quoted 1 line
cache, which works fine either way. Also I copy
the
Quoted 2 lines
entire 2MB flash to ram and then verify it back.
Again, no problems.
See the FAQ why this doesn't mean anything.
Quoted 2 lines
TEXT_BASE: fffc0000
CFG_MONITOR_BASE: ffe00000
Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure about this?
Quoted 2 lines
CFG_ENV_ADDR: ffe3f7f0
CFG_ENV_OFFSET: 3f7f0
Really? Not aligned to a sector boundary? Are you sure about this?
Quoted 2 lines
Top of RAM usable for U-Boot at: 01000000
Reserving 1935k for U-Boot at: 00e1c000
Really? Your U-Boot image needs nearly 2 MB ? Are you sure about this?
Quoted 1 line
I use a gpio controlled LED to pin point the
crash,
Quoted 1 line
and it is just as it tries to jump to ram.
...as expected for a FAQ #1 entry question.
Quoted 1 line
I have a feeling the sdram is fine, and either
Your feeling may be wrong. And your U-Boot is misconfigured, too.
Best regards,
Wolfgang Denk
Signature · 10 lines
Software Engineering:  Embedded and Realtime
Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80
Email: wd at denx.de
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk
abort,
Then the socket packet pocket has an error to
report! - Ken Burchill?

Scott Hammond

author

2007-01-23 00:55 UTC #3 lore raw

In reply to Wolfgang Denk

Im up!

Now running in RAM - U-Boot at: 00fdc000

Quoted 5 lines

Quoted 2 lines
TEXT_BASE: fffc0000
CFG_MONITOR_BASE: ffe00000
Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure about this?

That was it, the CFG_MONITOR_BASE was wrong. Might I suggest to add a 'Check your text_base/cfg_monitor_base/cfg_flash_base' to the relocate faq? That would have saved me two days of banging on the poor sdram.

thanks for your help,
Scott

Quoted 82 lines · --- Wolfgang Denk

In message <[email protected]> you
Quoted 2 lines · wrote:
Im using U-Boot 1.1.5 compiled with gcc 2.4.6 and
make
Quoted 1 line
3.80.
Why don't you use current U-Boot code your new development?
And what the heck is GCC 2.4.6???
Quoted 1 line
and others are in the new 405GPr mode. They all
boot
Quoted 1 line
and run vxworks just fine, though Im not sure if
that
Quoted 1 line
runs from ram or not.
See the FAQ.
Quoted 1 line
The sdram setup for the 405 is extremely simple,
just
Quoted 1 line
a few registers and delays. It is identical to
all
You still have to get it right.
Quoted 1 line
Ive added a simple mem test with and without the
data
Quoted 1 line
cache, which works fine either way. Also I copy
the
Quoted 2 lines
entire 2MB flash to ram and then verify it back.
Again, no problems.
See the FAQ why this doesn't mean anything.
Quoted 2 lines
TEXT_BASE: fffc0000
CFG_MONITOR_BASE: ffe00000
Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure about this?
Quoted 2 lines
CFG_ENV_ADDR: ffe3f7f0
CFG_ENV_OFFSET: 3f7f0
Really? Not aligned to a sector boundary? Are you sure about this?
Quoted 2 lines
Top of RAM usable for U-Boot at: 01000000
Reserving 1935k for U-Boot at: 00e1c000
Really? Your U-Boot image needs nearly 2 MB ? Are you sure about this?
Quoted 1 line
I use a gpio controlled LED to pin point the
crash,
Quoted 1 line
and it is just as it tries to jump to ram.
...as expected for a FAQ #1 entry question.
Quoted 1 line
I have a feeling the sdram is fine, and either
Your feeling may be wrong. And your U-Boot is misconfigured, too.
Best regards,
Wolfgang Denk
Signature · 10 lines
Software Engineering:  Embedded and Realtime
Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80
Email: wd at denx.de
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk
abort,
Then the socket packet pocket has an error to
report! - Ken Burchill?

Timur Tabi

2007-01-23 16:18 UTC #4 lore raw

Quoted 4 lines · Scott Hammond

Quoted 2 lines
Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure about this?
That was it, the CFG_MONITOR_BASE was wrong.

Is there a situation where you would ever want CFG_MONITOR_BASE to be unequal to TEXT_BASE?

Signature · 2 lines

Timur Tabi
Linux Kernel Developer @ Freescale

Wolfgang Denk

2007-01-23 16:53 UTC #5 lore raw

Quoted 3 lines · In message <[email protected]> you wrote:

Is there a situation where you would ever want CFG_MONITOR_BASE to be unequal to TEXT_BASE?

Yes. For example that's a requirement of the current implementation on some non-PPC architectures - ARM, for example, has usually CFG_MONITOR_BASE set to 0 (= start of boot flash), while TEXT_BASE points somewhere to RAM.

Best regards,

Wolfgang Denk

Signature · 4 lines

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Be careful what you wish for. You never know who will be listening.
                                      - Terry Pratchett, _Soul Music_