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

[vb]

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

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.

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.

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,

Vadim