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

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

[Tim Kryger]

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

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

[Albert ARIBAUD]

Hi Tim,

Le 14/02/2011 18:01, Tim Kryger a ?crit :
> 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

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.

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

[Wolfgang Denk]

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

-- 
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

[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

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

[Tim Kryger]

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

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

[Wolfgang Denk]

Dear Tim Kryger,

In message <loom.20110214T194343-739@post.gmane.org> you wrote:
> 
> 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.

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 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?

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.

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

[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