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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot