[U-Boot] U-Boot proper(not SPL) relocate option

[Tom Rini]

On Sun, Nov 26, 2017 at 11:16:45PM +0900, Masahiro Yamada wrote:
[snip]
> This discussion should have happened.
> U-Boot boot sequence is crazily inefficient.
> 
> 
> 
> When we talk about "relocation", two things are happening.
> 
>  [1] U-Boot proper copies itself to the very end of DRAM
>  [2] Fix-up the global symbols
> 
> In my opinion, only [2] is useful.
> 
> 
> SPL initializes the DRAM, so it knows the base and size of DRAM.
> SPL should be able to load the U-Boot proper to the final destination.
> So, [1] is unnecessary.

Knowing this final destination isn't necessarily easy in all cases.  One
thing to keep in mind here is that long long ago, U-Boot did not do this
relocation step.  But that was also well before SPL, so some level of
what was made easier with relocation isn't so necessary now.

It's also somewhat of an important safety feature.  We have a lot of
values that get re-used (and sometimes re-based) without sufficient
care.  Take for example where for the longest time nearly everyone on
ARM32 was loading the kernel to.  Having U-Boot automatically end up way
out of the way rather than hoping everyone calculates a good address
that won't get stepped on is important.  It's also one of those things
that will change over time as features get added / changed and our
footprint grows.  We're already fairly often talking about "oops, what
do we do now to keep X into size constraint of $Y storage?".  It'll be
even worse to deal with "oops, adding $X means we need more run-time
space".

All of that said, I'd be happy to see logs showing that we in fact spend
a measurable amount of time in relocation and what we can do about it.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171127/32f70783/attachment.sig>