[U-Boot-Users] AT91RM9200 boot.bin interaction with u-boot and SDRAM

[Craig Robinson]

SNIP
the main difference between our board and the EK is the
> size of the SDRAM. We use half that on the EK (16Meg rather than 32Meg).
So,
> reading the source code for both u-boot and boot.bin, I'm thinking that we
> need to change some things to take into account the change in SDRAM. What
I
> think I need to alter is: 
> 
> boot.bin - 
> 
> main.c 
> #define DST 0x21f00000 to 0x20f00000
> entry.S
> redefine STACK to be 0x21000000 not 0x22000000
> 
> u-boot - 
> 
> change TEXT_BASE to 0x20f00000
> redefine PHYS_SDRAM_SIZE to 0x1000000 in <board>.h
> 
> Is this correct and have I missed anything? 
>> 

>This looks OK to me. I do not know if this is everything needed.
>YOu might have a look at where you store your environment.

Ok, thanks Ulf.

>> Also, is it broadly correct to say that boot.bin does the following: 
> 
> 1. low level init
> 2. uncompress a gzipped file from SRC in parallel flash and put it in
SDRAM
> at DST
> 3. jump to unzipped file at DST.
> 
>> If this is the case, then do we need to also ensure that
>> CONFIG_SKIP_RELOCATE_UBOOT is defined? Is there a point to this aside
from
>> saving space in flash? 

>I think You need to relocate to SDRAM, 
>if you have linked the U-boot as you mention above.

I agree. However, what I meant was that if boot.bin is already copying the
unzipped u-boot code to the correct place in SRAM, is there a need for
u-boot to do the same? Is this in fact what boot.bin does? Have I totally
missed the point here?

Is boot.bin something that Atmel provided to support a number of potential
applications like u-boot and can, therefore, be used as a convenience with
u-boot rather than as a necessity? Suppose I'm just curious really since it
works in the EK and I'm keen to follow that approach on our board since I
know it to be good. 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.11/1071 - Release Date: 15/10/2007
06:48