Re: [Gumstix-users] Loading u-boot from within u-boot

[Craig H. <cr...@gu...>]

On Jul 11, 2007, at 5:28 AM, David Hearn wrote:

> I've found the following in board\gumstix\config.mk
>
> ifeq ($(BR2_TARGET_GUMSTIX_VERDEX),y)
> 	TEXT_BASE  = 0x5C000000
> 	PLATFORM_CPPFLAGS += -DGUMSTIX_VERDEX
> endif
> ifeq ($(BR2_TARGET_GUMSTIX_BASIXCONNEX),y)
> 	TEXT_BASE  = 0xA3F00000
> 	PLATFORM_CPPFLAGS += -DGUMSTIX_PXA255
>
> Out of curiousity, can anyone shed any light on why the Verdex version
> had the base relocated to that address?

The PXA270 includes 256kB of SRAM on-die, addressed at 0x5c000000.   
The verdex uses that SRAM to load u-boot to.  Part of the reason for  
this is to allow a super-cheap verdex version with no off-CPU SDRAM  
as a possible product for OEM customers.

> Anyway, I replaced the Verdex TEXT_BASE with the Basix/Connex text  
> base
> (A3F00000) and got the same issue as before - it hanging during  
> boot.  I
> also tried A2000000 address and got the same issue - both times  
> hanging
> during dram_init()

Hmm.  Can you add some printf's in dram_init to hone in on where it's  
crashing?

> I note that Dave Hylands wrote about this in the "uboot testing"  
> thread,
> where he said:
>
> "So, you don't want to load to the address that the current u-boot is
> runnung from, and the only address I could use with u-boot-1.1.4 to
> load 1.2.0 was 5c000000"
>
> I'm running 1.1.4 (running from A3F0000000) and want to load  
> 1.2.0.  So
> it suggests I need to load to 5c000000, but when I try that I get:
>
> U-Boot 1.1.4 (Mar  1 2007 - 17:10:55) - PXA270@600 MHz - 1321
>
> *** Welcome to Gumstix ***
>
> U-Boot code: A3F00000 -> A3F25850  BSS: -> A3F5AE70
> RAM Configuration:
> Bank #0: a0000000 128 MB
> Flash: 32 MB
> Using default environment
>
> SMC91C1111-0
> Net:   SMC91C1111-0
> Hit any key to stop autoboot:  0
> GUM> loadb 5c000000
> Cannot load to 0x5C000000 -- address not in RAM

U-boot 1.1.4 didn't know about the block of SRAM at 5c000000 -- loadb  
to a2000000 then cp from there to 5c000000

> So it appears I can't do a loadb to that address, although Dave did a
> fsload 5c000000 ..... - does this mean I need to load via a CF card
> then?  I guess that should work as I'm currently running 1.1.4 which
> works with CF, once I've gone to 1.2.0 I won't be able to use the  
> CF in
> u-boot.
>
> Sound right?  Why can't I do a loadb to 5c000000 when a fsload  
> works to
> the same address?

I don't know that it does; it's possible that loadb has a destination  
check which fsload doesn't though.  The purpose of that destination  
check is to stop people trying to, eg, loadb 0x00 and thereby hosing  
their flash as the loadb just dumbly writes a bytestream, not trying  
to wrap it in flash write commands.

C