[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler <holler@ahsoftware.de>]

Am 29.10.2010 14:08, schrieb Albert ARIBAUD:

>>>> with -pie in LDFLAGS, which I don't understand (does not mean I have
>>>> much experience how the compiler and linker are working in regard to
>>>> relocatable code).
>>>>
>>
>>> That needs some more analysis.
>>>
>>> -fPIC without GOT relocation does nothing good, and with it, does not
>>> enough -- hence the ELF relocation patches replacing -fPIC with -pie,
>>> which is *intended* for relocating executables. these two machanisms are
>>> not meant to be used together.
>>>
>>> Can you be more specific about this:
>>
>> Adding
>>
>> printf("nand_chip: %p\n",&nand_chip[0]);
>>
>> to nand_init() in drivers/mtd/nand.c
>>
>> a non relocated address will be printed without -fPIC. After adding
>> -fPIC to the CFLAGS the address is relocated. U-Boot fails there first
>> because nand_chip[0] contains function pointers which are used while
>> scanning the NAND.
>
> Weird: I introduced -pie precisely because it relocates pointers in data
> structures while -fPIC does not -- I'd hit the issue myself. I assume I
> can test this with an OpenRD board, which has NAND also.
>
>> And because they aren't relocated, but only the
>> relocated BSS will be cleared, the following code in nand_set_defaults()
>> in drivers/mtd/nand/nand_base.c will not initialize cmdfunc
>>
>> if (chip->cmdfunc == NULL)
>> chip->cmdfunc = nand_command;
>>
>> with the result that chip->cmdfunc is called later which just points to
>> somewhere (because the not relocated BSS isn't cleared).
>
> Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT,
> the start.S code clears the relocated BSS. Are we in a case where you
> prevent part of the relocation process, such as by using
> CONFIG_SKIP_RELOCATE_UBOOT?

The (wrong, not relocated) location of nand_chip (building without 
-fPIC) is inside the BSS before relocation through sta?t.S. This part of 
RAM will not be cleared because it shouldn't be used.

>> I'm having this problem with both gcc 4.3.4 and gcc 4.5.1 (along with
>> binutils 2.20.1). I'm compiling native.
>>
>> I've got the idea to add -fPIC while staring add the assembler output of
>> nand.c, trying to understand whats happening.
>>
>> I could send another mail to the list, when I've checked what happens
>> when I'm cross-compiling using the ELDK (I think the ELDK uses 4.2.x),
>> attaching 4 times nand.s (4.3.4.non-working, 4.5.1.non-working,
>> 4.5.1.fPIC.working, 4.2.x.currently_unknown).
>>
>> nand.s is about 55kB, don't know if I should send about 200k in one mail
>> to ml.
>
> Providing the location on the Net of the toolchains will be enough,
> (along with which version of nand.c you're using if that matters).

I'm using Gentoo where it's easy to swith the compiler (on a DockStar ~ 
Sheevaplug = Kirkwood Feroceon 88FR131) to compile the current HEAD of 
the master

Regards,

Alexander