Hi Albert, On Sun, Oct 30, 2011 at 3:16 AM, Albert ARIBAUD <albert.u.b...@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.b...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot