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

[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

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

[Wolfgang Denk]

In message <802881.16758.qm@web32906.mail.mud.yahoo.com> 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???

> 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.

> 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.

> 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.

> TEXT_BASE: fffc0000
> CFG_MONITOR_BASE: ffe00000

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

> CFG_ENV_ADDR: ffe3f7f0
> CFG_ENV_OFFSET: 3f7f0

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

> 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?

> 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.

> 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

-- 
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?

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

[Scott Hammond]

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.

> > 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.
> 
Yeah I know read-write doesnt mean execute will work,
but at least I know I am copying from flash ok.


> > 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


--- Wolfgang Denk <wd@denx.de> wrote:

> In message
> <802881.16758.qm@web32906.mail.mud.yahoo.com> 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???
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> > TEXT_BASE: fffc0000
> > CFG_MONITOR_BASE: ffe00000
> 
> Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure
> about this?
> 
> > CFG_ENV_ADDR: ffe3f7f0
> > CFG_ENV_OFFSET: 3f7f0
> 
> Really? Not aligned to a sector boundary? Are you
> sure about this?
> 
> > 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?
> 
> > 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.
> 
> > 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
> 
> -- 
> 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?
> 

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

[Scott Hammond]

Im up!

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

> > 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

--- Wolfgang Denk <wd@denx.de> wrote:

> In message
> <802881.16758.qm@web32906.mail.mud.yahoo.com> 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???
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> > TEXT_BASE: fffc0000
> > CFG_MONITOR_BASE: ffe00000
> 
> Really? CFG_MONITOR_BASE != TEXT_BASE ? Are you sure
> about this?
> 
> > CFG_ENV_ADDR: ffe3f7f0
> > CFG_ENV_OFFSET: 3f7f0
> 
> Really? Not aligned to a sector boundary? Are you
> sure about this?
> 
> > 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?
> 
> > 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.
> 
> > 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
> 
> -- 
> 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?
> 

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

[Timur Tabi]

Scott Hammond wrote:

>> 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?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Wolfgang Denk]

In message <45B63541.5040602@freescale.com> 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

-- 
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_