[U-Boot] Changing u-boot relocation scheme

[vb]

On Wed, Jul 23, 2008 at 10:39 AM, vb <vb at vsbe.com> wrote:

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

so, I finally had some time to spend on this over the weekend, and
made it work on the canyonlands board (ppc460gt platform).

My original assessment was missing the fact that in some cases the
absolute address is split in two halves (when the 32 bit address value
is loaded into a registrer with two assembler instructions).  As a
result, there were two kinds of discrepancies between the images
located at different addresses: in the majority of cases the
difference was the same as the base address difference, and in a
couple of dozen cases the difernce between images was base address
difference shifted 16 bits to the right.

It turned out not a big deal, the code changes are minimal (100 or so
lines added and 200 or so deleted), not counting the script comparing
the images and generating the table and the resulting binary with the
table included in it.

If there is any interest, I can share the diffs with the community.

I also tried to make sense of the contents of the .fixup section
created by -mrelocatable, but I failed here - I expected it to contain
the offsets of the locatons to relocate, but it certainly is not it,
and I am not siure what it is.

The address fixup function is obviously completely isolated and can be
easily replaced to match the relocation information format.

To make sure I din not miss any place where gd->reloc_offset is used I
changed the name of the field temporarily and let the compiler find
all places where this field is used. Tesing was not all that thorough,
but inlcuded running cli commands, saving environment in flash,
downloading an image through bootp/tftp.

Let me know if anyone is interested,

cheers,
Vadim