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

[Simon Glass]

Hi Albert,

On Fri, Oct 21, 2011 at 3:24 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> 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 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.
>
> I still don't get it: if you have lowlevel init skipped for one core, it
> will be for the other as well.

OK so let's run through the U-Boot code in order for each of the two CPUs:

First AVP:
_start
skips lowlevel init (so no CP15)
board_init_f
arch_cpu_init
(at this point it starts up the A9 and halts)

A9:
_start
skips lowlevel init (so no CP15)
board_init_f
arch_cpu_init
cpu_init_cp15

The call to cpu_init_cp15() is performed in arch_cpu_init() when we
detect that we are the A9.

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

Well on Tegra the RAM init is down by the boot ROM. There is no low
level init bar the cp15 stuff.

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

OK, I see - you mean moved in order if not in source code file.

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

Yes but it's yuck. Part of the clean-up is to remove most of the
assembler - really very little is needed.

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

Yes I can, but I need to be able to call cp15_init. And I can't do
that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is
compiled out! So I need to move that cp15_init code outside the
CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do,
honest!

Regards,
Simon

>
> Amicalement,
> --
> Albert.
>