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

[Simon Glass]

Hi Albert,

On Fri, Oct 21, 2011 at 2:43 PM, Albert ARIBAUD
<albert.u.boot at 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 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

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.

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

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.

Regards,
Simon

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