[U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 21/10/2011 23:54, Simon Glass a ?crit :
> Hi Albert,
>
> On Fri, Oct 21, 2011 at 2:43 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net>  wrote:
>> Le 21/10/2011 23:18, Simon Glass a ?crit :
>>>
>>> Hi Albert,
>>>
>>> On Fri, Oct 21, 2011 at 1:58 PM, Albert ARIBAUD
>>> <albert.u.boot@aribaud.net>    wrote:
>>>>
>>>> Le 13/10/2011 23:05, Simon Glass a ?crit :
>>>>>
>>>>> Some SOCs have do not start up with their 'main' CPU. The first U-Boot
>>>>> code may then be executed with a CPU which does not have a CP15, or not
>>>>> a
>>>>> useful one.
>>>>>
>>>>> Here we split the initialization of CP15 into a separate call, which can
>>>>> be performed later if required.
>>>>>
>>>>> Once the main CPU is running, you should call cpu_init_cp15() to perform
>>>>> this init as early as possible.
>>>>>
>>>>> Existing ARMv7 boards which define CONFIG_SKIP_LOWLEVEL_INIT should not
>>>>> need to change, this CP15 init is still skipped in that case. The only
>>>>> impact for these boards is that the cpu_init_cp15() will be available
>>>>> even if it is never used on these boards.
>>>>
>>>> I'm not too sure I understand how this is working: if you are moving cp15
>>>> init to later, it will still be done by the same core that would have
>>>> done
>>>> it earlier, won't it?
>>>>
>>>> IOW, I would like to better understand how this boot core/main core
>>>> business
>>>> works. How does the main core start execution? At which address? Does it
>>>> go
>>>> through its reset vector? Do the cores share the same location for reset
>>>> vectors? Etc.
>>>
>>> For Tegra is it like this:
>>>
>>> The ARM7 CPU (called AVP for Audio Video Processor) starts up first.
>>> It runs the boot ROM and then U-Boot and gets as far as
>>> arch_cpu_init(). The AVP does not have a CP15 or a cache so cannot run
>>> the CP15 init code. The AVP then starts up the first Cortex-A9 (an
>>> ARMv7 architecture CPU). This CPU (the main core, if you like) starts
>>> from the same address as the first one (i.e. the start of U-Boot). It
>>> is as if this is the core that we really wanted to use, but it wasn't
>>> available initially. This main core runs through arch_cpu_init() and
>>> sails into board_init_f(). At this point no CP15 init has been done.
>>
>> Thanks. So what this amounts to is, both cores will run the same binary, and
>> I assume the AVP will shut itself off once the A9 runs. But what I don't get
>
> Yes
>
>> is, if A9 goes through the same sequence of code as AVP, then it will
>> execute cp15 where is is not, won't it?
>
> On Tegra we have CONFIG_SKIP_LOWLEVEL_INIT set to avoid this. That
> much is already supported by U-Boot.

I still don't get it: if you have lowlevel init skipped for one core, it 
will be for the other as well.

>> Anyway: your patch moves cp15 init far enough that the AVP won't execute it,
>> but the A9 will.
>
> Well, on Tegra we call the cp15 init directly when it is safe to do so, later.
>
>>
>> Only, what will happen when another multiple-core ARM SoC gets U-Boot
>> support but the location you chose for cp15 init is inadequate for it? Shall
>> we move cp15 init again, and where?
>
> If CONFIG_SKIP_LOWLEVEL_INIT is not defined, then the low level init
> will operate exactly as now. My patch effectively just allows you to
> have CONFIG_SKIP_LOWLEVEL_INIT but later call part of that lowlevel
> init. In my view, the cp15 init should not be lumped in with the
> 'memory init' or whatever else it expected to be done in the lowlevel
> init.

I think I get the point: due to the fact that both cores run the same 
starup code path, and due to the fact that they run it one after the 
other and share a lot of devices, at mots one of them shoud perform low 
level inits (e.g. RAM init), and some low-level inits can only be 
performed by one of them (e.g., cp15).

>> I'd prefer the cp15 init to stay where it is but execute only for A9, for
>> instance by checking some core identification register.
>
> Well I actually haven't moved it! It is just that previously it was
> impossible to call cp15_init from anywhere later.

It is moved, in that it belongs to low level init... of A9.

> What you say can be done, it would involve some assembler though and
> would need to be another CONFIG option. Was trying to avoid adding new
> assembler.

Low level init is about assembler and, well, low level. :)

But I don't see why there should be another CONFIG option. IIUC, you 
should be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low 
level init code under it, you would do the equivalent of a switch, with 
one branch for AVM (and DDR init etc) and one branch for A9 (with cp15 
init etc).

> Regards,
> Simon

Amicalement,
-- 
Albert.