Wolfgang,
Thanks for the prompt reply.
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.
For my particular board I can limit the variability of the other things you describe but have less control over the size. I had hoped to find some way to perhaps back of a fixed, larger amount from the end rather than the dynamic, smaller amount.
This is only the case when booting from NAND; it does not apply for example when booting from NOR flash.
Yes, this is precisely the situation I find myself in.
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.
My memory map is fixed but my board specific U-Boot code is still under development and if I can't guarantee the address U-Boot is loaded will be exactly the same as the computed address I am in trouble. If it changes ever so slightly, I could find myself in the situation where U-Boot tries to relocate on top of itself which would be much worse than the current inefficient but safe relocation.
I am considering creating a linker directives script for my board that will align the end of BSS to the next larger power of two from its current address. This doesn't seem like the cleanest solution but it I believe it would allow me to make code changes without too much fear of causing a change to the relocation address. Do you think this would be a reasonable approach to take?
Thanks, Tim Kryger