[U-Boot] arm: wrong Relocation and not cleared BSS

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 30/10/2010 15:08, Alexander Holler a ?crit :
> Hello,
>
> to give the topic a better meaning and to summarize what I think is
> currently happening along with some "pictures" for a better understanding:

You may be right, but for now this is not necessarily what really 
happens, so the subjet is still somewhat of a misnomer.

> We are starting with code (c) and data (d) somewhere in the memory:
>
> ----------
> |cd      |
> ----------
>
> The relocation in start.S should achieve this:
>
> ----------
> |      cd|
> ----------
>
> That means code and data should be moved upwards. What
> currently is happening is the following:
>
> ----------
> | d    c |
> ----------
>
> The code is moved upwards, but that code still uses the data at d.
> This results another problem: Some parts in the code are assuming that d
> is cleared (set to zero in start.S). But what start.S does it to clear
> the new location (z in the picture below).

Wait a minute. No parts of the code assume BSS is *cleared*, or at least 
no pat of the should *should ever* assume that. BSS is not "zeroed 
data", it is "uninitialized data".

Which leads to another question: you found an issue according to which 
values put in nand_chip[] were not read back correctly later on, with 
both the writing and reading occurring after relocation.

But -- stop me if I'm wrong -- there is no reason that only one of the 
reading or writing used the "right" address and one used the "wrong" 
address, right? Both use the same address. Even if BSS does not end up 
where it should, it would still be at the same address for all code, so 
that does not explain the issue you're seeing.

> ----------
> | d    cz|
> ----------
>
> Because the code (c) still uses the data (bss) in d and not in z, some
> hard to find errors might occur because the used data isn't set to zero
> as required.

BSS is not *required* to be zero. It is zeroed out as a courtesy, but 
code is expected not to depend on BSS being zeroed. Besides, in your 
case, the fact that it is zeroed out does not matter since you're 
(correctly) trying to read a BSS variable that is assumed to have been 
properly filled in earlier.

> I have almost no knowledge about how gcc and the binutils are handling
> relocation, therfore I can't help much further here. What I think is
> part of the problem, is that -fPIC was removed. Using -pie in LDFLAGS
> might be used to get relocatable code, but the data will not be
> relocated. And I would wonder if that is possible without instructing
> the compiler to build stuff for relocation (-fPIC).
>
> I hope that brings some light into the problem.

Again, when -fPIC was replace with -pie, it was because it actually 
relocated much better that GOT relocation, including on NAND devices IIRC.

Could people with ARM NAND-based boards on the list test their own board 
with Alexander's DEBUG and printf() added, and see what this gives on 
their board?

> Regards,
>
> Alexander

Amicalement,
-- 
Albert.