[U-Boot-Users] 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
fre 2007-10-12 klockan 13:32 +0100 skrev Craig Robinson:
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?
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.
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.
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
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
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.
I think the U-Boot: boot.bin was added after Atmel created the separate boot.bin.
Since the AT91 boots from a various of sources, keeping a separate boot.bin allows you to boot the same U-Boot from any flash memory. You can store the u-boot in parallel flash, dataflash, NAND flash or whatever.
If you use the internal boot.bin, it will only work when programmed into a parallel flash.
Note that the environment storage will make this a little fuzzy. The U-Boot is compiled to store the environment in a certain type of memory. If you put it in serial EEPROM (not recommended due to speed) then you can have a single image which can be booted from any type of flash, but if you compile for a dataflash environment storage, you have to have a dataflash there...
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
participants (2)
-
Craig Robinson -
Ulf Samuelsson