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

[Albert ARIBAUD]

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.

> 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

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

> Regards,
> Simon

Amicalement,
-- 
Albert.