In message f608b67d0807231039i434e96dbvda86590776db2cb0@mail.gmail.com you wrote:
I wonder if you would consider (and accept a patch) changing the u-boot architecture as described below.
Consider: always. Accept: if it makes more sense than the current implementation.
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).
The address is not arbitrary, and in fact it CANNOT be determined in advance, especially on boards with varying RAM sized (for example using standard DIMMs). Since U-Boot will relocate itself normally to the end of the available RAM, you cannot know the relocation address in advance. Also, for example things like the PRAM size can be set by the user through environment variables - again this will cause the relocation address to become variable.
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.
I don't understand what you mean. Either you link statically with the U-Boot image, or you use standalone programs. In both situations no such problem as described by you exists.
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.
I don't think so.
In general the PPC u-boot image consists of three parts: the bulk of
No, this is by far not general, not even for PPC.
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.
Why would we do that? The compiler already generates such a table for free - the GOT.
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 don't see how your "poor man's" GOT would be any better than the compiler generated one - except that it's horribly non-standard and glumpsy?
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?
I don't understand which problem you're trying to fix, and I don't see that your solution would be any better than what we have now.
Best regards,
Wolfgang Denk