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