AT91RM9200 boot.bin interaction with u-boot and SDRAM

Dear Ulf,

A while back
(http://www.nabble.com/at91rm9200---silent-console-tf4418118.html#a12631849)
you pointed me at the atmel patched source for u-boot 1.2.0. I have compiled and run this on the EK with out problems. Thank-you.

However, I now come to getting u-boot to function on our EK based hardware. Our new board has AT49BV642D flash and I have added support to the code for this part (still compiles and runs on the EK). Aside from a total lack of Ethernet support, 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?

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?

Many thanks in advance.
Craig Robinson.

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.8/1064 - Release Date: 11/10/2007 15:09

size of the SDRAM. We use half that on the EK (16Meg rather than 32Meg).

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

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?

Quoted 1 line

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.

Quoted 1 line

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

at DST
3. jump to unzipped file at DST.

Quoted 2 lines

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

Quoted 1 line

saving space in flash?

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

Quoted 4 lines

Quoted 1 line

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

Quoted 5 lines

at DST
3. jump to unzipped file at DST.

Quoted 2 lines

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

Quoted 4 lines

Quoted 1 line

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.