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

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

[Joakim Tjernlund]

> From: Txema Lopez [mailto:tlopez at aotek.es] 
> Sent: 14 February 2007 09:01
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] Fixup relocation patch.]
> 
> Joakim Tjernlund wrote:
> 
> >I wonder, how far off is a fully relocatable u-boot? That 
> is, burn it anywhere
> >in flash and start it from there?
> >
> > Jocke
> >
> >  
> >
> Hi Jocke,
> The patch was done precisely for it. You can copy a U-Boot 
> image from an 
> address in flash to another and calculate the new pointers in 
> the GOT an 
> FIXUP sections before do the copy.
> But you need another change in U-Boot to turn it fully relocatable. 
> U-Boot is hardly joined with the link address TEXT_BASE. You must 
> replace it for a label in U-Boot and change the lines in the 
> U-Boot code 
> where there is a direct or indirect reference (as 
> CFG_MONITOR_BASE) to 
> TEXT_BASE.
> 
> Best regards,
> Txema

Hi Txema

Can you give an example on how to change these references to
TEXT_BASE/CFG_MONITOR_BASE?

 Regards
         Jocke

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

[Txema Lopez]

Joakim Tjernlund wrote:

>Hi Txema
>
>Can you give an example on how to change these references to
>TEXT_BASE/CFG_MONITOR_BASE?
>
> Regards
>         Jocke
>  
>
Hi Jocke,

An example in C code in the board_init_f() function.

#ifdef CFG_BOOT_RELOCATABLE
len = (ulong)&_end - (ulong)&_start ;
#else
len = (ulong)&_end - CFG_MONITOR_BASE;
#endif

An example in assembler in the relocate_code function.

#ifdef CFG_BOOT_RELOCATABLE
lwz r4, GOT(_start)
#else
lis r4, CFG_MONITOR_BASE at h /* Source Address */
ori r4, r4, CFG_MONITOR_BASE at l
#endif


Anyway, if you are very interested in it I can made a patch for the 
1.1.6 version (but merged with our custom board code) and send it to you 
out of the list to take a look.

Best regards,
Txema.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070214/fe0d3da5/attachment.vcf 

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

[Joakim Tjernlund]

On Wed, 2007-02-14 at 12:27 +0100, Txema Lopez wrote:
> Joakim Tjernlund wrote:
> 
> >Hi Txema
> >
> >Can you give an example on how to change these references to
> >TEXT_BASE/CFG_MONITOR_BASE?
> >
> > Regards
> >         Jocke
> >  
> >
> Hi Jocke,
> 
> An example in C code in the board_init_f() function.
> 
> #ifdef CFG_BOOT_RELOCATABLE
> len = (ulong)&_end - (ulong)&_start ;
> #else
> len = (ulong)&_end - CFG_MONITOR_BASE;
> #endif
> 
> An example in assembler in the relocate_code function.
> 
> #ifdef CFG_BOOT_RELOCATABLE
> lwz r4, GOT(_start)
> #else
> lis r4, CFG_MONITOR_BASE at h /* Source Address */
> ori r4, r4, CFG_MONITOR_BASE at l
> #endif
> 

Thanks, now I get it.

> 
> Anyway, if you are very interested in it I can made a patch for the 
> 1.1.6 version (but merged with our custom board code) and send it to you 
> out of the list to take a look.

Yes I am interested, but I am leaving for a 2 week vacation soon, so I
will get back to you about this.

 Thanks again
        Jocke

> 
> Best regards,
> Txema.

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

[Txema Lopez]

Joakim Tjernlund wrote:

>I wonder, how far off is a fully relocatable u-boot? That is, burn it anywhere
>in flash and start it from there?
>
> Jocke
>
>  
>
Hi Jocke,
The patch was done precisely for it. You can copy a U-Boot image from an 
address in flash to another and calculate the new pointers in the GOT an 
FIXUP sections before do the copy.
But you need another change in U-Boot to turn it fully relocatable. 
U-Boot is hardly joined with the link address TEXT_BASE. You must 
replace it for a label in U-Boot and change the lines in the U-Boot code 
where there is a direct or indirect reference (as CFG_MONITOR_BASE) to 
TEXT_BASE.

Best regards,
Txema
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070214/5dee477f/attachment.vcf 

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

[Txema Lopez]

Grant Likely wrote:

>
> 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 using a gcc 3.3.6 version patched for uclibc (buidroot patches).  
This is the command line of the compiler call.

/home/txema/ppc5200/build_powerpc/toolchain/bin/powerpc-linux-uclibc-gcc 
-g -O1 -fno-common -fno-schedule-insns -fno-schedule-insns2   -fPIC 
-ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xFE040100  
-I/home/txema/ppc5200/build_powerpc/system/u-boot/include -fno-builtin 
-ffreestanding -nostdinc -isystem 
/home/txema/ppc5200/build_powerpc/toolchain/lib/gcc-lib/powerpc-linux-uclibc/3.3.6/include 
-pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC5xxx -ffixed-r2 
-ffixed-r29 -mstring -mcpu=603e -mmultiple -DTEXT_BASE=0xFE040100 
-I/home/txema/ppc5200/build_powerpc/system/u-boot/board -Wall 
-Wstrict-prototypes -c -o usb_storage.o usb_storage.c

BR
Txema,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070214/38b9e4c5/attachment.vcf 

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

[Grant Likely]

On 2/13/07, J. William Campbell <jwilliamcampbell@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

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

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Grant Likely
> Sent: den 13 februari 2007 17:51
> To: Txema Lopez
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] Fixup relocation patch.]
> 
> 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.

I wonder, how far off is a fully relocatable u-boot? That is, burn it anywhere
in flash and start it from there?

 Jocke

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

[J. William Campbell]

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

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

[Grant Likely]

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.

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

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

[Grant Likely]

On 2/13/07, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> On Tue, 2007-02-13 at 17:21 +0100, Txema Lopez 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 added -mrelocatable to gcc during compile, but not to the linking
> stage and that worked too.

Sorry, my mistake.  I needed the -mrelocatable flag for *compiling*,
not linking.  :)

g.

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

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

[Joakim Tjernlund]

On Tue, 2007-02-13 at 17:21 +0100, Txema Lopez 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 added -mrelocatable to gcc during compile, but not to the linking
stage and that worked too.

How do you guys link? This is how I do:
UNDEF_SYM=`powerpc-softfloat-linux-gnu-objdump -x lib_generic/libgeneric.a board/tmcu/libtmcu.a cpu/mpc83xx/libmpc83xx.a lib_ppc/libppc.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/nand/libnand.a drivers/nand_legacy/libnand_legacy.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a cpu/mpc83xx/qe/ucc/libucc.a cpu/mpc83xx/qe/libqe.a |sed  -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
		cd /usr/local/src/tm-uboot/u-boot && powerpc-softfloat-linux-gnu-ld -Bstatic -T /usr/local/src/tm-uboot/u-boot/board/tmcu/u-boot.lds -Ttext 0xF8020000  -n $UNDEF_SYM cpu/mpc83xx/start.o cpu/mpc83xx/resetvec.o \
			--start-group lib_generic/libgeneric.a board/tmcu/libtmcu.a cpu/mpc83xx/libmpc83xx.a lib_ppc/libppc.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/nand/libnand.a drivers/nand_legacy/libnand_legacy.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a cpu/mpc83xx/qe/ucc/libucc.a cpu/mpc83xx/qe/libqe.a --end-group -L /usr/lib/gcc/powerpc-softfloat-linux-gnu/3.4.6 -lgcc \
			-Map u-boot.map -o u-boot

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

[Txema Lopez]

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.

>However, -mrelocatable is a powerpc-only flag.  I don't know what the magic flag is to do the same on arm/mips/etc.  
>
It should be the -fPIC flag. But I think that the main problem is the 
existence or not of a piece of code that copy the fixup section elements 
from flash to ram and adjust it as the powerpc code does it. I think we 
need the help of other architectures experts to resolve this doubt.

>It would be great if this can get sorted out for all u-boot targets.  It's an invasive change though.  I think your right that having it wrapped in a conditional is the right way to start, but I would start with a patchset that fixes up all powerpc targets first and get it out for comments/testing before it gets merged to mainline.  Once powerpc is proven, then turn to look at the other architectures. 
>
I agree.

> I'll happily help you with this task.
>  
>
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.

BR,
Txema
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070213/4a2f2edd/attachment.vcf