[U-Boot-Users] Changing u-boot relocation scheme

[Jerry Van Baren <gerald.vanbaren@ge.com>]

vb wrote:
> Wolfgang,
> 
> I wonder if you would consider (and accept a patch) changing the
> u-boot architecture as described below.
> 
> As we all are well aware u-boot is a great software package which
> speeds up bringing up new hardware immensely, its popularity is
> obviously growing very fast. One thing which (IMO anyway) slows down
> its acceptance is the way it handles relocating of itself into an
> arbitrary DRAM area. (Arbitrary meaning that it depends on many
> factors and the exact address can't be assigned ahead of time).

One thing (IMO anyway) that allows u-boot to Just Work[tm] is that it 
relocates itself to the best location available, automatically adjusting 
to the probed memory configuration.

There.  Fixed that.  ;-)

> While this relocation is seamless for u-boot in its released form, it
> becomes a pain each time a module needs to be added (not necessarily
> for following release to the Open Source community, for instance used
> for inhouse installations which include tens of thousand units for
> some companies). If these added modules were not written in position
> independent manner (namely, using structures with multiple stage
> indirect pointers interleaved with data), the effort to make these
> modules work in u-boot is very exhausting.

You lost me here.

What is a module?
How does a it relate to u-boot?
Why does it need to be relocated?
Why isn't it written in position independent manner?
How is your relocation methodology going to fixup a module's data 
structures?
What pointers are in your data structures?  Why do they need to be 
relocated?

> Here is the suggested alternative. I will talk about recent PPC
> platforms, but it could be done very similar for most of the other
> platforms I believe.
> 
> In general the PPC u-boot image consists of three parts: the bulk of
> code and data, the startup page (the top 4k mapped out of reset), and
> the reset vector (the top four bytes in the address space). The bulk
> is usually aligned at a certain address matching the bootprom size,
> and there is a gap between the bulk and the startup page.
> 
> Now, let's say we link and purge the bulk section twice, once locating
> it at offset 0 and once at the normal u-boot TEXT_BASE, building two
> binary images (not including the top 4k in both cases).
> 
> Then we compare the two images and identify all locations which are
> different. All these locations are 4 byte aligned, and all differ by
> the same amount - equal TEXT_BASE. Now we can build a table of offsets
> which need to be changed when the program is moved into a different
> location, include this table in the resulting image between the bulk
> and the startup page, and use this table when relocating code.


Gcc supports "proper" relocation, if only we knew how to make it work 
for all "reasonable" versions of gcc (and Grant's conclusion is that 
many versions of gcc in use today do *not* support the relocation).
   <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/36343/>

Grant Likely created a patch that did this in the 1.3.0 timeframe, but 
ended up reverting it due to toolset problems - it was a patch before 
its time.

To read up on the history, follow this search:
<http://search.gmane.org/?query=relocation&author=grant+likely&group=gmane.comp.boot-loaders.u-boot&sort=date&DEFAULTOP=and&xP=Zreloc%09Zchang%09Zgrant%09Zlike&xFILTERS=Gcomp.boot-loaders.u-boot---A>

> Basically, this implements a poor man's loader, and it will be
> sufficient in case the image we are dealing with is a flat binary
> (which is of course the case with u-boot). This will allow to add any
> code to u-boot without much worries about being able to relocate it
> properly. We would do away with storing certain structures in certain
> sections, dealing with GOT, etc.
> 
> I made some experiments, and this seems feasible, this could be done
> as a local customization, but I would much prefer to release it to the
> u-boot community and make it part of mainline - will you consider such
> a patch?
> 
> Thank you for reading this far, please let me know what you think,

On one hand, your proposal sounds fairly simple and independent of the 
gcc version.  The primary cost would be extra build steps
1) Link at TEXT_BASE
2) Link at address 0
3) Binary diff the two to find addresses that need relocation
4) Rebuild with the diff table (compile the diff table and relink)

On the other hand, the skeptic in me says it ain't that easy.  Go ahead, 
prove me wrong.  ;-)

> Vadim

Best regards,
gvb