From mboxrd@z Thu Jan 1 00:00:00 1970 From: J. William Campbell Date: Tue, 13 Feb 2007 10:23:49 -0800 Subject: [U-Boot-Users] [PATCH] Fixup relocation patch.] In-Reply-To: <528646bc0702130851l1befaeebwb44b6a3fb8515d72@mail.gmail.com> References: <45D1DB7D.7050403@fagorautomation.es> <45D1E58D.6030905@aotek.es> <528646bc0702130851l1befaeebwb44b6a3fb8515d72@mail.gmail.com> Message-ID: <45D20235.3080903@comcast.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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. > > >