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

Simon Glass sjg at chromium.org
Fri Oct 28 00:46:26 CEST 2011


Hi Albert,

On Thu, Oct 27, 2011 at 3:39 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Le 27/10/2011 22:17, Simon Glass a écrit :
>>
>> Hi Albert,
>>
>> On Thu, Oct 27, 2011 at 1:05 PM, Albert ARIBAUD
>> <albert.u.boot at aribaud.net>  wrote:
>>>
>>> Hi Simon,
>>>
>>> Le 25/10/2011 23:16, Simon Glass a écrit :
>>>
>>>>> But please think about what you actually want in start.S. Do you
>>>>> really want an #ifdef TEGRA2 with a check of a SOC register, followed
>>>>> by a branch around the cp15_init code?
>>>>
>>>> ^^^^
>>>> This is the bit we need to sort out.
>>>
>>> Indeed, but I dont want a '#ifdef TEGRA2'. In the worst case I want a 'if
>>> (!core_is_avp())' by way of an identification register, and in the best
>>> case, I just want cp15 to be set unconditionally.
>>
>> You already have #ifdef TEGRA2 (look at the top of start.S). That is
>> what I am trying to remove.
>>
>> How can I call core_is_avp() on an SOC that isn't Tegra? Can you
>> please write a little code fragment that I should use in start.S, so
>> that I can understand what is required here.
>>
>>>
>>>>>>>> According to ARM, coprocessors 14 and 15 should always be supported
>>>>>>>> from
>>>>>>>> ARMv6 up. Are you sure the AVP does not have it? If there is a Tegra
>>>>>>>> specification available, I'd like to have a look at it.
>>>>>>>
>>>>>>> Sorry I meant caches/MMU, etc. I should try doing the CP15 cache/MMU
>>>>>>> init on the AVP and see what happens.
>>>>>>
>>>>>> Please do check this. It may be that you can actually write to it from
>>>>>> AVP
>>>>>> even though it has no or not all expected effect; and if that is
>>>>>> confirmed,
>>>>>> then you don't have to separate the boot paths any more,
>>>>>
>>>>> Yes I'm tempted to go with this even if the ARM ARM is silent on the
>>>>> matter. I will try it out today.
>>>>
>>>> Silly me of course it doesn't work - since if the CP15 doesn't have
>>>> those features then you get undef instruction exception. Please see
>>>> ^^^ above!
>>>
>>> Are you stating a reasoning here or the results of an actual test? What
>>> causes an undefined instruction exception is the absence of a coprocessor
>>> to
>>> handle the instruction, not the presence of a coprocessor which
>>> incidentally
>>> cannot perform all of what"s being asked.
>>
>> Yes I did test it - it hangs. Would you like me to spend some time to
>> debug exactly why? I suspect it is an undef instruction, since
>> executing cache instructions on an ARM7TDMI is dodgy, but I could
>> check if it would help. But let's assume for now we can't do that!
>
> What was the test exactly? Depending on which register of CP15 you try to
> access, things could be different. Can you test MRC p15,0,<Rt>,c0,c0,0 ?
> That's the MIDR and it should be always accessible, plus it should have a
> unique value for each type of core, so it could be used to not write cp15
> for caches etc from the AVP.

I'm sure that is fine. So do you want me to add a check that the ID
shows architecture ARMv7, and then skip the cache code if not? It
should be safe enough since it is a clear signal that something is not
right. It would also handle the case where an Cortex-A7 (with a cache)
is attached.

Regards,
Simon

>
>> Regards,
>> Simon
>
> Amicalement,
> --
> Albert.
>


More information about the U-Boot mailing list