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

[Simon Glass]

Hi Albert.

On Mon, Oct 31, 2011 at 3:54 PM, Tom Warren <TWarren at nvidia.com> wrote:
> From one of our HW engineers:
>
> The AVP does not have a CP15.
> As this thread speculates, it is an ARM7TDMI which is a basic ARM V4 core with no ARM co-processors or MMU.
>
> Also, ARM app note 99 (DAI0099C_core_type_rev_id.pdf) says the same thing.
>
> HTH,
>
> Tom
>
>> -----Original Message-----
>> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
>> Sent: Monday, October 31, 2011 2:44 PM
>> To: Albert ARIBAUD
>> Cc: U-Boot Mailing List; Tom Warren; Stephen Warren
>> Subject: Re: [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
>>
>> 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!

Have you had a chance to look at the revised patch that I sent?

Regards,
Simon

>>
>> Regards,
>> Simon
>>
>> >
>> >> Thanks,
>> >> Simon
>> >
>> > Amicalement,
>> > --
>> > Albert.
>> >
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information.  Any unauthorized review, use, disclosure or distribution
> is prohibited.  If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
>