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

[J. William Campbell <jwilliamcampbell@comcast.net>]

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

Best Regards,
Bill Campbell

>On 2/13/07, Txema Lopez <tlopez@aotek.es> wrote:
>  
>
>>Grant Likely wrote:
>>
>>    
>>
>>>I needed to add the -mrelocatable flag to the linker flags in cpu/ppc4xx/config.mk (I did not remove the -fPIC flag when I did this).  Without -mrelocatable, the .fixup section would remain empty.
>>>
>>>
>>>      
>>>
>>It's not the case of the MPC5200. It's enough with the -fPIC flag. It
>>could be a problem with the gcc cross compiler/linker for the ppc4xx.
>>    
>>
>
>I actually tried it on the 5200 also, and I didn't get the fixup
>section without -mrelocatable.  Might be a gcc version difference.
>I'm using ELDK 4.0 which uses gcc 4.0.  What version of gcc are you
>using?
>
>  
>
>>I'm sorry but I've got not time to do this task by now. I'm not sure if
>>this work must be done by only one persone or by the people who have the
>>equipment to test it. Anway, if you are a volunteer for me is OK.
>>    
>>
>
>Okay, I'll take this on then.
>
>g.
>
>  
>