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

[Wolfgang Denk <wd@denx.de>]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I object to intellect without discipline;  I object to power without
constructive purpose.
	-- Spock, "The Squire of Gothos", stardate 2124.5