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:
- low level init
- 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