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

[Albert ARIBAUD]

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 at 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 is, if A9 goes through the same sequence of code as AVP, then 
it will execute cp15 where is is not, won't it?

Anyway: your patch moves cp15 init far enough that the AVP won't execute 
it, but the A9 will.

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?

I'd prefer the cp15 init to stay where it is but execute only for A9, 
for instance by checking some core identification register.

> Basically there is now an assumption in start.S that the current CPU
> has a CP15 and that it is useful to fiddle with it. By splitting out
> that code into a separate function we can:
>
> 1. Avoid the AVP fiddling with CP15
> 2. Have the Cotex-A9 (the intended target of the code) get its CP15
> init when needed
>
> Note that all the cores have a unified view of memory, peripherals, etc.
>
> Regards,
> Simon
>
>>
>> Amicalement,
>> --
>> Albert.
>>
>
>


Amicalement,
-- 
Albert.