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

[Albert ARIBAUD]

Le 29/10/2010 13:56, Alexander Holler a écrit :
> Am 29.10.2010 11:19, schrieb Albert ARIBAUD:
>> Hi all,
>>
>> Le 29/10/2010 10:50, Alexander Holler a écrit :
>>> Hello again,
>>>
>>> I'm leaving the problem description below, what fixed it all here was to
>>> add -fPIC to the CFLAGS to instruct the compiler to generate relocatable
>>> code (again).
>>>
>>> This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5
>>
>> Did you reach tis commit by dissecting?
>
> No, I just used gitk and/or git gui blame to search when -fPIC disappeared.

Hmm... Git blame just lest you know what commit changed a line last, 
which is not enough to make sure that the change was the root cause.

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

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

> Regards,
>
> Alexander

Amicalement,
-- 
Albert.