[U-Boot] Avoiding Relocation on ARM When Earlier Bootloader Inits RAM?

[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