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

Albert ARIBAUD
2011-10-30T10:16:09Z

Hi Simon,

Le 29/10/2011 02:36, Simon Glass a ?crit :
> Hi Albert,
>
> On Thu, Oct 27, 2011 at 10:09 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
>> Le 28/10/2011 03:43, Simon Glass a ?crit :
>>
>>> The test was
>>>
>>> mrc p15, 0, r0, c0, c0, 0 @ get ID register
>>> and r0, r0, #0xf0000 @ get architecture
>>> cmp r0, #0xf0000 @ check for> ARMv6
>>> movne pc, lr @ else skip cache init
>>>
>>> Unfortunately I think it is a plain ARM7TDMI with no CP15.
>>
>> What about other fields in r0 right after mrc?
>
> I don't really understand that sentence, sorry.
>
> The ARM7TDMI does not have a CP15 and aborts if I try to access it.
> Just in case there is something odd going on I checked with DSTREAM /
> RVdebug and it definitely doesn't have a CP15. [as Ford Prefect would
> say, I counted them twice]

Ok, so debug tools do not show cp15. But tools can be tailored to what
tool makes think is needed -- I could tell about some debugging tools
that will not let me see all I want a core because the debug designers
had finite resources and what I wanted was not a priority to them.

OTOH, according to ARM, ARM7DTMI is an ARMv4T architecture, and indeed
cp15 is mandatory only for ARMv6 and up, but ARM also states cp15
support was a de facto standard already for ARMv4.

So I am left with the question: would the Tegra2 AVP be the only ARM
implementation supported by U-Boot that does not have a cp15? That is
possible, but I want direct testimony from Nividia.

This is why I asked about the Tegra2 TRM, or whatever Nvidia calls it,
in case it would explicitely state if AVP has cp15 support or not.
Failing that, I'd be ok with experimenting but through the AVP, not
through debugging tools -- encoding a cp15 MIDR read in the U-Boot
startup code, step through it with the debugger and see if it causes an
UND or not, and if not, what is the hex value of r0 -- maybe that is
exactly what you did, but I am not 100% sure it is, hence my insistence.

I am especially surprised that a recent core be synthesized without a
means for run-time core identification, especially in a design with two
ARM cores.

> The simplest thing I have been able to think of that does not involve
> exceptions, differing instruction behaviour, doing the init later or
> putting in some Tegra-specific code is to check for the existence of
> the Q bit in the CPSR (actually APSR on ARMv7). This does seem to work
> and I have verified both in my old 1996 ARM ARM DDI 0100B and the
> ARMv7-A one (DDI 0406B) that from an architecture point of view this
> should work. The Q bit is RAZ on ARMv4T.

This could hep if we really cannot access the Main ID Register on the AVP.

> I believe this will cope with the Cortex-A7 / A-15 combinations and
> possibly even Cortex-R4 / A-15 although I have not tested this. I
> suppose we can deal with this when it becomes an issue.
>
> So I have redone this one patch with that in mind, and adjusted the
> series slightly to fit with this. I will resend it when it completes
> MAKEALL.
>
> I hope that this resolves the matter, but if not(!), I would very much
> appreciate it if you could send through some actual pseudo code
> showing what you are looking for, to avoid any confusion.

Well, I just want to see if the MIDR is accessible and what its value
is, so I want the AVP to execute

mrc p15, 0, r0, c0, c0, 0

The ending 0 is what selects MIDR rather than other cp15 registers --
other values can cause UND (and I would gladly understand that AVP goes
UND for reading cp15 CTR for instance).

The simplest test would be to insert the exact instruction above in the
reset sequence in start.S right after SVC32 switch, debug the reset
execution path, see if the mrc above goes UND or else check r0's
contents after mrc is done.

> Thanks,
> Simon

Amicalement,
--
Albert.