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