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

[Simon Glass]

Hi Albert,

On Sun, Oct 30, 2011 at 3:16 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> 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.

Ye of little faith...

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

Yes it is de facto when you have a core with that support - typically
an MMU and caches. But in that case it would have three digits, as in
ARM720T, rather than ARM7TDMI. It is definitely an ARM7TDMI (actually
-S) core in the datasheet, and there is no external CP15 block shown,
etc. (Although I can see a cache!)

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

No there are lots and lots of ARM7TDMIs out there, just not that many
that run U-Boot - and Linux is hard without an MMU. But even in the
U-Boot tree we have the s3c44b0 cpu which seems to be a plain
ARM7TDMI.

In terms of direct testimony, two engineers are on this thread and may
wish to chime in. The datasheet is pretty clear to me...

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

See above, it clearly states ARM7TDMI-S.

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

OK I have done this, and yes the AVP definitely takes the undef
exception when you execute:

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

>
> 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 -S means synthesized. It does have its own method of
identification as I mentioned. There is a Tegra-specific register that
I can read.

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

OK, well I will send a patch set up with this change.

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

OK see above, I have done this. What I meant was for you to provide a
code sequence that you want in start.S. Hopefully my patch will fit
the bill.

I am very happy for this to be rewritten/changed down the track. But
for now, and assuming you don't want to call a function to find out
whether or not CP15 exists, I have created something which seems to
solve the problem. There are many other problems to solve. I feel that
this one has had its fair share of attention!

Regards,
Simon

>
>> Thanks,
>> Simon
>
> Amicalement,
> --
> Albert.
>