[U-Boot] [PATCH v4 0/13] Introduce generic relocation feature

[Simon Glass]

Hi Albert,

On Tue, Feb 28, 2012 at 1:20 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Simon,
>
> Le 21/02/2012 21:16, Simon Glass a écrit :
>
>> Hi Graeme,
>>
>> On Tue, Feb 21, 2012 at 12:10 PM, Graeme Russ<graeme.russ at gmail.com>
>>  wrote:
>>>
>>> Hi Simon, Albert.
>>>
>>> On 02/22/2012 07:07 AM, Simon Glass wrote:
>>>>
>>>> Hi Albert,
>>>>
>>>> On Tue, Feb 21, 2012 at 11:40 AM, Albert ARIBAUD
>>>> <albert.u.boot at aribaud.net>  wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> One general question: am I right in saying that in the current
>>>>> implementation, relocate_code executes mostly on the final stack,
>>>>> whereas in
>>>>> your proposal, it runs on the initial stack?
>>>>
>>>>
>>>> Well the current relocation code is all in assembler and I don't
>>>> believe it uses the stack at all. It does set up the stack pointer at
>>>> the beginning if that's what you mean.
>>>>
>>>> Yes this series uses the initial stack for all processing until it
>>>> reaches board_init_r().
>>>
>>>
>>> <broken record>
>>>
>>> See what x86 does - Code copy and relocation in C using final stack and
>>> full cache enabled...
>>>
>>> </broken record>  :)
>>
>>
>> Heading there, but we can't enable dcache prior to relocation on ARM
>> yet. Generic relocation gives me something to work with that isn't
>> just for one architecture,
>
>
> I'm not sure what is the relation between stack and caches exactly -- nor
> why we could not have caches enabled before relocation, for that matter.

Well here are my thoughts...

To enable the dcache on ARM we need an MMU page table. The position of
this table is calculated in board_init_f() and it is set up by the
dcache_enable in board_init_r().

The stack and caches are only related in the sense that they both need
DRAM to be ready. So in principle I don't see any reason why we cannot
enable the dcache during board_init_f().

What I suggested is that we tackle this once the generic board series
goes in. I am happy to do this work. That way we only need to do one
framework and all the archs can use it.

Regards,
Simon

> Amicalement,
> --
> Albert.