[U-Boot] [PATCH v3 0/6] Introduce generic relocation feature

[Simon Glass]

Hi Albert,

On Wed, Mar 28, 2012 at 11:41 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Simon,
>
> Le 20/02/2012 23:38, Simon Glass a écrit :
>
>
>>> You should keep the code that jumps to board_init_r as it is.
>>
>>
>> I have had a look at this and I don't believe that I can. I need to
>> call it from C and so it needs to conform to the C calling standard. I
>> will send a new series showing what I mean.
>
>
> No need to call it from C. The most correct flow should be that the start.S
> code would call board_init_f, relocate_code() and board_init_r, so that no C
> code should call assembly language code, and setting the C environment or
> modifying it would only happen outside of C code.

(sorry what follows is pretty hard to follow, but I think it is
correct, and shows how I got to where I am with this)

That has a certain elegance about it, but it means that I need to
access global_data structure members from assembly. I need relocaddr,
start_addr_sp and the new gd pointer. These are all calculated in
board_init_f() and passed to relocate_code() as parameters at present.
I know it is possible to access global data from assembly using the
offsets header or similar, but I think we currently avoiding this on
ARM at present, to my delight.

It also means that board_init_f() would need to return, which puts ARM
at odds with every other architecture (it will have to have its own
prototype for board_init_f()). Even sandbox uses this no-return
prototype.

So to recap the reason for my change to the code that calls
board_init_r() is that relocate_code() used to be an assembly routine.
It did the relocation and then called board_init_r() in the new
location with the new stack.

Now relocate_code() is entirely written in C, but we still need to
call board_init_r() with a new stack when relocation is done. So the
grubby stack change stuff is no longer at the end of relocate_code()
but in the new pivot_to_board_init_r(), although still in start.S.
It's actually quite a minor change.

Part of the reason for this change is that there is no need for
relocate_code() to be written in assembly (in any architecture I
think). The pivot stack thing is all that remains.

>
>
>> Are you saying that you want a start.S in arch/arm/cpu and each
>> arch/arch/cpu/*/ ? I would prefer there was only one file named
>> start.S.
>
>
>> OK and I hope that file is not arch/arm/cpu/start.S which would
>> introduce confusion I think.
>
>
> I don't want multiple homonym files either. I want a start.S file
> responsible for the generic ARM startup and another asm or include file
> responsible for the ARM-architecture specifics (i.e. ARM1176, ARM926EJS etc)
> if required. The name of that second file I'll think over, but it won't be
> start.S

That was the idea behind my original proc.S, but it's not exactly an
inspiring name.

>
>
>>> What is the code size increase of using arch-specific mem ops?
>>
>>
>> About 800 bytes for me:
>>
>>    text           data     bss     dec     hex filename
>>  177653           3932  218240  399825   619d1 u-boot
>>  178429           3932  218240  400601   61cd9 u-boot
>
>
> Thanks.
>
>
>>>>>> One problem remains which causes mx31pdk to fail to build. It doesn't
>>>>>> have string.c in its SPL code and the architecture-specific versions
>>>>>> of
>>>>>> memset()/memcpy() are too large. I propose to add a local change to
>>>>>> reloc.c that uses inline code for boards that use the old legacy SPL
>>>>>> framework. We can remove it later. This is not included in v2 but I am
>>>>>> interested in comments on this approach. An alternative would be just
>>>>>> to add simple memset()/memcpy() functions just for this board (and one
>>>>>> other affected MX31 board).
>>>>>
>>>>>
>>>>>
>>>>> I am not too fond of the "later removal" approach. In my experience,
>>>>> this
>>>>> invariably tends to the "old bloat in the code no one knows the reason
>>>>> of"
>>>>> situations.
>>>>
>>>>
>>>>
>>>> Me neither. The only board affected is the tx25. We could let the
>>>> maintainer fix it up, I suppose. I have no way of testing it.
>>>
>>>
>>> John: ping?
>>
>>
>> Since I didn't hear anything I have elected to patch this up a
>> different way - basically splitting out memcpy() and memset() from
>> string.c. See what you think of the new series. It introduces no
>> breakages now, at least.
>
>
> I'll look this up today.
>

Thanks.

>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.

Regards,
Simon