Hi Tim,
Le 14/02/2011 18:01, Tim Kryger a écrit :
Hello,
After looking at code, searching the mailing list archive, and reviewing the git commit log, I now understand that for ARM relocation is performed unless U-Boot is already running at its final destination as computed within board_init_f. Since this computation attempts to back off from the end of RAM the resulting address varies when U-Boot changes size. On my board I have an earlier bootloader that initializes RAM. Presently, it copies U-Boot near the start of RAM and lets U-Boot relocate itself to the end. This is inefficient and I would like to eliminate the extra copy. I suspect that my situation is not unique and would be grateful to anyone willing to share their thoughts or experiences on how best to deal with this.
Thanks, Tim Kryger
What you are looking for requires that the bootloader compute where U-Boot should end up in RAM, just like U-Boot would compute it too. It certainly is not easy, possibly even impossible due to run-time memory allocation from top of RAM before the U-boot location is computed.
Note that even if you can compute the address, you would save a copy, but you would still need to go through the relocation code, which takes a while too.
Besides, loading U-boot at the lowest location then relocating up is doing precisely what the feature is supposed to do: have a single U-Boot binary able to run on variants of a board with different amounts of RAM. Preloading at a fixed address would defeat the idea.
Amicalement,