Albert,

Thank you for your advice.

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.

This is a really good point and I need investigate how much time could really be saved by avoiding the copy.

Thanks Again, Tim Kryger

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

Wolfgang,

Please be careful in the use of terms. It appears you are using "relocating" when you actually mean "copying". Keep in mind that these are two very different operations.

I understand. Sorry for the confusion.

Note that there is no guarantee that such an approach will continue to work in future releases. Also note that you will then have to maintain your own linker script and keep it in sync with all other changes - which just adds maintenance efforts.

I agree. The linker script approach is far from ideal.

Why exactly do you care about this? What is the problem you're trying to address?

I am primarily motivated by reducing boot time but I have not yet determined exactly how much time is spent performing the copy. At this point I am simply trying to understand my options. Additionally, I was curious how others dealt with the flexibility/performance trade on boards with earlier bootloaders.

Thanks, Tim Kryger