Dear Tim Kryger,
In message loom.20110214T175951-507@post.gmane.org you wrote:
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
It varies not only then. It may also vary when you are for example using features like protected RAm or frame buffers with adjustable resolution / color depth. Then the location in RAM may even depend on settings of environment variables, i. e. it can change dynamically from boot to boot.
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
This is only the case when booting from NAND; it does not apply for example when booting from NOR flash.
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.
There are situation where the memory map is fixed and doesn;t change - then you can U-Boot load to it's final location, and no second copy is needed.
Best regards,
Wolfgang Denk