[U-Boot] Trying to understand ARM926EJS/start.S

[Reinhard Meyer]

On 30.10.2010 20:54, Albert ARIBAUD wrote:
> Le 30/10/2010 20:09, Reinhard Meyer a écrit :
>
>> %%% both yield constants that are in TEXT and can be accessed
>> %%% PC relative, right?
>
> Constants, yes; in .text, yes; can be accessed pc-relative, yes, as any other location in .text actually. But you probably meant "expected to be accessed PC relative", in which case: yes.
Yes, I meant the latter.
>
>> %%% adr reg, label sets reg to the address of label?
>> %%% ldr reg, label sets reg to the content of mem at label?
>
> Correct.
>
>> ldr r2, _TEXT_BASE
>> $$$ r2 is overwritten two lines below, right?
So this line is some remnant of earlier code and can be removed
>> ldr r3, _bss_start_ofs
>> add r2, r0, r3 /* r2<- source end address */
>
> Correct.
>
>> ldr r0, _TEXT_BASE /* r0<- Text base */
>> %%% why are we using _TEXT_BASE here and not _start?
>
> Because we're accessing the relocation tables in the FLASH (or freshly NAND-loaded) "source" copy of u-boot, not in the RAM "target" copy (in which the relocation tables won't exist).
Which, by definition, is at TEXT_BASE, so _start should be identical and
adr r0, _start should have the same result?
>
>> ldr r3, _TEXT_BASE /* Text base */
>> $$$ r3 is not used below this
>
> If it is useless then it can be removed (but would not cause any issue). Note that it may be used implicitly as the 3rd argument to a C function call... But I don't think it is, no function called below uses 3 arguments I think.
That would be bad style. Sure it is not used later.
>
>> mov r4, r7 /* reloc addr */
>> %%% why move it to r4? could we not add r7 in the next 2 lines?
>
> We could indeed -- actually, we could probably otimize register usage in other places too.
>
>> bne clbss_l
>> %%% this should better be blo, just in case _end is not aligned?
>
> Correct. I thinought I'd sent a patch to fix all these... Seems I missed some.

I'm still thinking of the idea to move the general, non specific bits of
relocation and bss clearing to a general file; or even better to do most
of it in C. We should just need a small asm helper function to change stack
and branch to the relocated code.

>
>> %%% I cannot see anything here that would prevent BSS being cleared.
>
> Neither do I -- if you think of Alexander's issue, I think it is not related to BSS initialization.

No, since everything works fine here (though I cannot confirm BSS gets cleared,
maybe none of the code active here assumes cleared BSS:) ), but I am sure ALL
code and vars is really accessed at the final, high end RAM location. I filled
all RAM upto 2MB below the end with garbage and nothing crashed and u-boot
still behaved proper.

Alexander's issue cannot be related to a general u-boot problem, it must be
SoC or board specific or handling specific. As to what we can only speculate.

I can only advise again to check for static vars that are used before relocation
(which need not lead to a crash), but their values will be lost during
relocation. This made timers fail here because clock frequencies calculated
in timer init before relocation and stored in static vars were gone after
relocation.

Oh, and u-boot did not work here when compiled with gcc 4.4.5 - I almost forgot
about that... I think I even mentioned that in some message a while ago, but I
can't find it right now.

Best Regards, Reinhard