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

[vb]

Jerry, thank you for your reply, please see below:

On Wed, Jul 23, 2008 at 2:46 PM, Jerry Van Baren <gerald.vanbaren at ge.com> wrote:
> vb wrote:
>>  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.  ;-)
>


Sorry, I was not clear - it indeed is a great property of u-boot that
it can run on any probed memory config. What I meant to say was that
the way it relocates itself is not perfect, and this is why u-boot is
not becoming more ubiquitous.

>> 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?

for the purposes of this discussion any .o file or any library of .o files.

> How does a it relate to u-boot?

I need to extend u-boot with certain functionality available from those modules.

> Why does it need to be relocated?

because the  modules are now part of u-boot, they need to be relocated
along with the rest of the image.

> Why isn't it written in position independent manner?

because they come from different sources, not concerned with u-boot,
and just work and need to be ported as is.

> How is your relocation methodology going to fixup a module's data
> structures?

The relocation will adjust only pointers to absolute addresses stored
in text/data segments.

> What pointers are in your data structures?  Why do they need to be
> relocated?
>

in some cases data structures include pointers to other data
structures, etc. (This is called  'tree' btw, sorry couldn't resist
:-)

[snip]
>
> 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/>
>

well, if there is a pointer to a data element or to a function stored
in a data structure, the .bin image is built and fixed using actual
addresses set by the linker. How can gcc help here?

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

I will read up on this.

[snip]

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

add here inserting code to process the table and modify pointers after
relocation (which is already being done, but suing a different
algorithm)

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

I am sure it is doable, I am just trying to understand if this would
be accepted in general, because it can be done differently depending
if one needs to push it upstream or not.

cheers,
/vb

>> Vadim
>
> Best regards,
> gvb
>