Avoiding Relocation on ARM When Earlier Bootloader Inits RAM?

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

Hi Tim,

Le 14/02/2011 18:01, Tim Kryger a ?crit :

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,

Albert.

Albert,

Thank you for your advice.

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

Dear Tim Kryger,

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.

This is only the case when booting from NAND; it does not apply for example when booting from NOR flash.

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

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In general, they do what you want, unless you want consistency.
                                    - Larry Wall in the perl man page

Wolfgang,

Thanks for the prompt reply.

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.

Yes, this is precisely the situation I find myself in.

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

Dear Tim Kryger,

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.

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.

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

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Build a system that even a fool can use and only a fool will want  to
use it.

Wolfgang,

I understand. Sorry for the confusion.

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

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