[prev in list] [next in list] [prev in thread] [next in thread] 

List:       u-boot
Subject:    Re: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From:       Tom Warren <TWarren () nvidia ! com>
Date:       2011-10-31 22:54:51
Message-ID: 7E91C59574E9954FA075F8D8CCDF78DB38FDD3E963 () HQMAIL04 ! nvidia ! com
[Download RAW message or body]

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 w=
ith 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@google.com [mailto:sjg@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@aribaud.net> wrote:
> > Hi Simon,
> >
> > Le 29/10/2011 02:36, Simon Glass a =E9crit :
> >>
> >> Hi Albert,
> >>
> >> On Thu, Oct 27, 2011 at 10:09 PM, Albert ARIBAUD
> >> <albert.u.boot@aribaud.net> =A0wrote:
> >>>
> >>> Le 28/10/2011 03:43, Simon Glass a =E9crit :
> >>>
> >>>> The test was
> >>>>
> >>>> =A0 =A0 =A0 =A0mrc =A0 =A0 p15, 0, r0, c0, c0, 0 =A0 @ get ID regist=
er
> >>>> =A0 =A0 =A0 =A0and =A0 =A0 r0, r0, #0xf0000 =A0 =A0 =A0 =A0@ get arc=
hitecture
> >>>> =A0 =A0 =A0 =A0cmp =A0 =A0 r0, #0xf0000 =A0 =A0 =A0 =A0 =A0 =A0@ che=
ck for> =A0 =A0ARMv6
> >>>> =A0 =A0 =A0 =A0movne =A0 pc, lr =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0@=
 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 w=
ill
> > 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 wa=
s 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, a=
nd
> 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 A=
VP.
> =

> 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 i=
s,
> so
> > I want the AVP to execute
> >
> > =A0 =A0 =A0 =A0mrc =A0 =A0 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 f=
or
> > 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 conten=
ts
> > 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.
> >
---------------------------------------------------------------------------=
--------
This email message is for the sole use of the intended recipient(s) and may=
 contain
confidential information.  Any unauthorized review, use, disclosure or dist=
ribution
is prohibited.  If you are not the intended recipient, please contact the s=
ender by
reply email and destroy all copies of the original message.
---------------------------------------------------------------------------=
--------
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[prev in list] [next in list] [prev in thread] [next in thread]