[U-Boot-Users] [PATCH] Fixup relocation patch.]

[Grant Likely]

On 2/13/07, J. William Campbell <jwilliamcampbell at comcast.net> wrote:
> Grant Likely wrote:
> Hi Grant,
>    Are you are still going ahead with the patch to add a device level cp
> and cmp function to u-boot?  Let me know if you are not proceeding, and
> I will try to fit it in to my schedule.

Yep; I'm working towards it.  I've got some patches in my local tree
which will provide a command set that MMC and dataflash can use so
they can be moved out of the cmd_mem functions.  In fact, that's how I
learned about the relocation issue.  It was in writing this code that
I came across the static initializer problem.

Instead of adding yet another set of manual fixups; I'd like to focus
on getting the C environment right first.

>    On what I hope is a different note, this relocation patch will be a
> big problem across different architectures, so I hope you are not
> relying on it. First, -fPIC is
> not used in several u-boot ports. The Blackfin u-boot_1..1.3  for
> example builds a u-boot that is not PIC. Several other processors do
> almost the same thing, where the code is not relocated but the variables
> are re-located from rom to ram. In those cases, u-boot runs from ROM
> with variables in ram.

Okay, fair enough; but I'm not so much concerned with getting all
platforms to relocate in the same way.  What I am concerned about is
the fact that u-boot has a broken C environment that requires manual
fixups to work right.  I don't think anyone thinks this is desirable,
and it should be fixable on all supported platforms (but it might be
hard).

For the targets which use relocation, this means fixing the linker
script and making sure -fPIC/-mrelocatable/whatever works in the right
way.

On other targets, different magic is needed.  Heck, for all I know,
some boards might already be working.  gd->reloc_off is used for all
the manual fixups.  If there are any platforms where gd->reloc_off ==
0 then those platforms are already working, and therefore doesn't need
any work.

For boards that relocate only the data section; maybe the linker
script should be modified to specify both a vma and lma for the data
sections; so the program looks for them at the vma, but elf and bin
images place them at the lma.  Then the data is already in the correct
place after relocation; no fixup required.

> Mr. Denk doesn't like this approach, but people
> do it and will continue to do it particularly on cores embedded into
> FPGAs, where u-boot is not the first bootstrap to run. The power-pc
> -fPIC approach simply won't work in those cases.  Also, -fPIC code is
> generally buggy on new CPUs for quite a while after the compiler is
> first ported to them. It was quite some time after the Blackfin port was
> working before PIC code was working. We appear to see differences
> between gcc versions even today on power-pcs, let alone more obscure
> CPUs. Therefore,  requiring PIC code to make the boot loader work at all
> is probably not going to be popular. The existing approach is probably
> the way it is because people had so much trouble making "unified"
> relocation work on all configurations. Worst-case, during initial port
> to a new chip, you can build u-boot to run in rom at a fixed location
> without PIC and know the ram references that need relocating will be
> relocated. That won't be true with the new approach.

Okay, I did not describe the problem well; I agree that trying to move
*all* platforms to -fPIC is not a good idea.

Heck, most of the u-boot code could care less about relocation and
only needs a working C environment.  In fact, I've got a number of
powerpc targets where I'd *prefer* to compile it without -fPIC
(because SDRAM is initialized and u-boot is loaded via a different
mechanism).  There is no reason why many architectures couldn't
support both -fPIC and non-fPIC builds.  (with the inherent design
tradeoffs).

>  The total number of relocations done in the u-boot code explicitly is
> small enough that it is better, IMNSHO, to preserve the existing
> approach.

Preserve the way each platform does or does not relocate: I agree 100%
Preserve the broken C environment: Hell No!  We can do better!  :-D

> Function tables can be built/relocated at run time without
> much cost, as is done with the stdio functions. If you can come up with
> a way to make the single-point relocation work for all the different
> ways different systems use u-boot, More Power To You, but I would lay
> long odds that this is possible.

understood, and I agree.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195