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

[Simon Glass]

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.

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