Hi Albert,

On Tue, Feb 28, 2012 at 1:20 PM, Albert ARIBAUD albert.u.boot@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 Russgraeme.russ@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@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.