On Wed, Jul 23, 2008 at 10:39 AM, vb vb@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