[U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL

[Minkyu Kang]

Hello,

On 8 January 2011 19:49, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
>>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>>> index 684f2d2..4eeb12a 100644
>>> --- a/arch/arm/cpu/armv7/start.S
>>> +++ b/arch/arm/cpu/armv7/start.S
>>> @@ -195,6 +195,8 @@ copy_loop:
>>>      add     r3, r3, r0              /* r3<- rel dyn end in FLASH */
>>> fixloop:
>>>      ldr     r0, [r2]                /* r0<- location to fix up, IN FLASH! */
>>> +    cmp     r0, #0
>>> +    beq     fixskip
>>
>> I doubt this is correct. In my investigations for 'NULL fixup' (->  see http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906) pointed out that only symbols in 'absolute fixup' loop could be 'NULL' if there is a not aliased/empty weakly linked symbol. I did never see a 'NULL' symbol for 'relative fixup' loop!
>>
>> Therefore I doubt it is correct to check the location at this place. Can you please give an example?
>>
>> regards
>>
>> Andreas Bießmann
>
> Oops. Thanks Andreas for pointing this out. I second the question.
>

I found another case.
Please see commit message.
"There is possibility that pointers set to NULL before relocation"

Simple test.
Declared function pointer.

int (*test_func)(void);

And then, set to NULL at arch_cpu_init()

I got follow result.

___address____|________0________4________8________C
  ZSD:44833440|>00000000 00000017 44800024 00000017
  ZSD:44833450| 44800028 00000017 4480002C 00000017

44833440(test_func) is zero and relative fixup (0x17).

In this case, because of try to load the data from r0 (line 216),
system is hang.
So, we have to skip the fixup.

Thanks
Minkyu Kang.
-- 
from. prom.
www.promsoft.net