hi Heiko,
On Tue Nov 02, 2010 at 09:55:46AM +0100, Heiko Schocher wrote:
Hello Wolfgang,
Wolfgang Denk wrote:
Dear Heiko Schocher,
In message 4CCFAFE4.3000600@denx.de you wrote:
- preloader copies first page of nand (nand_spl code) to 0xbb000000 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
Why is this relocation needed? I understand that this 0xbb000000
Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ...
I am not sure about all the ARM boards using nand_spl, but atleast on the hawkboard for which i have submitted patches, i have removed the call to relocate_code in nand_spl in V5. This is not needed at least on this board, as the nand_spl gets copied directly to the RAM.
But as codesize changes (and with it relocation address) this is not a perfect solution.
Indeed. CONFIG_SYS_NAND_U_BOOT_SIZE should be dropped, and the avtual value should be derived from the actual U-Boot image building process.
Yep.
But i have a doubt here. In case of hawkboard, the very reason we have a nand_spl booting stage is because the initial bootloader(RBL from TI) does not use the ECC layout as used by the davinci nand driver in u-boot. We flash the nand_spl separately by booting over UART[1]. In case, we compute the u-boot size dynamically, it would be needed to flash the nand_spl each time we build u-boot.
Can we make a change such that we define an upper limit for the u-boot size, and the build produces a warning/error in case the u-boot size goes above this limit. We can avoid flashing the nand_spl each time using this method.
[1] - Please check doc/README.hawkboard http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/88139
-sughosh