On 10/6/2010 2:43 AM, Graeme Russ wrote:
> On 06/10/10 01:48, Reinhard Meyer wrote:
>> ---
>> arch/arm/cpu/arm926ejs/start.S | 8 ++++-
>> arch/arm/lib/board.c | 57
>> +++++++++++++++++++++++++++++++++++++++-
>> include/configs/top9000_9xe.h | 1 +
>> 3 files changed, 63 insertions(+), 3 deletions(-)
>>
> I had a quick look at this and nothing is jumping out at me. Of course I am
> not familiar with ARM asm...
>
> I don't see any reason why this ultimately will not work eventually. You
> may be having some issues with the transition from asm->C->asm through the
> relocation - This was an especially painful thing for me involving an
> intermediate trampoline which I have only recently figured out how to remove.
>
> Maybe some memory barriers are needed to stop the C optimiser mangling things?
>
> I am sure what you have is very close to the real solution :)
>
> I do think the main relocation fixup loop can be moved into a common
> library in which case we can add additional case statements. The nice thing
> is that x86 as all Type 8 which is specifically allocated to x86 so my "if
Hi All,
I think that type 8 IS NOT allocated to the 386. For instance,
R_PPC_ADDR14_BRTAKEN also has a value of 8. So does R_ARM_ABS8. I think
that there will be a lot of #ifdefs just to keep the references
symbolic. Many of the different platform relocation types will come out
to be the same code in the switch statement, but different symbolic
names. There will also be some entries that are processor specific and
have no equivalent on other processors. I think it would be a good idea
to use the symbolic values of the Relocation types (as opposed to
integer constants), as it will make the code clearer. There are sort of
two ways to organize the code inside the switch statement. Since the
code inside the switch statement is very short, it might be best for
each architecture (ELF format) to be bunched together, even at the
expense of repeating the same executable statements that some other
formats may use, as follows:
#ifdef PPC
case R_PPC_ADDR32: /* S + A */
<code to do the deed>
break;
case R_PPC_RELATIVE: /* B + A */
<code to do the deed>
break;
#endif
#ifdef I386
case R_386_32: /* S + A */ /* I think this is the other
location type Graeme used, but I could be wrong */
<code to do the deed>
break;
case R_386_RELATIVE: /* B + A */
<code to do the deed>
break;
#endif
#ifdef ARM
case R_ARM_ABS32: /* S + A */ /* I don't remember the ARM
relocation types used */
<code to do the deed>
break;
case R_ARM_REL32: /* B + A - P */
<code to do the deed>
break;
#endif
Or we could group the various Relocation types by what they actually do:
#ifdef PPC
case R_PPC_ADDR32: /* S + A */
#endif
#ifdef I386
case R_386_32: /* S + A */ /* I think this is the other
location type Graeme used, but I could be wrong */
#endif
#ifdef ARM
case R_ARM_ABS32: /* S + A */ /* I don't remember the ARM
relocation types used */
#endif
<code to do the deed>
break;
#ifdef PPC
case R_PPC_RELATIVE: /* B + A */
#endif
#ifdef I386
case R_386_RELATIVE: /* B + A */
#endif
<code to do the deed>
break;
#ifdef ARM
case R_ARM_REL32: /* B + A - P */
<code to do the deed>
break;
#endif
Note that the ARM_REL32 is defined differently than the PPC/I386
relative, FWIW. I also don't know what to use for the names of the
binary formats. It would be nice if we could use something already in
the header files? Thoughts on all this solicited!
Best Regards,
Bill Campbell
>> TEXT_BASE" checks can be kept. For size freaks, we could litter the code
> with #ifdefs to remove un-needed cases ;)
>
> Interestingly, ARM is adding gd->reloc_off while x86 is subtracting
> gd->reloc_off. If this is correct, I need to change the calculation of
> gd_reloc_off to be consistent
Adding is the way the specifications define it. add B+A.
Best Regards,
Bill Campbell
> Regards,
>
> Graeme
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
