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

[Albert ARIBAUD]

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