> -----Original Message----- > From: David Brownell [mailto:[email protected]] > Sent: 16 July 2009 17:29 > To: Spencer Oliver > Cc: [email protected]; [email protected] > Subject: Re: [Openocd-development] [Openocd-svn] r2543 - > trunk/src/target > > On Thursday 16 July 2009, Spencer Oliver wrote: > > A few comments as i have not had time to look over the > original patch. > > > > > * Four of the registers are actually not exposed > that way. Before > > > Cortex-M3 r2p0 they are read/written through > MRS/MSR instructions. > > > In that newest silicon, they are four bytes in one > register, not > > > four separate registers. > > > > Even though the early trm's still say this i queried arm and they > > confirmed that all revisions use this register 20. This is why I > > changed magnus's original code (using MRS/MSR) over a year ago. > > Did they tell you why they didn't document this? Was it a > case of the mechanism not working reliably? If it works > reliably in earlier cores, the most that would mean is that > the revision check can go. > But usually such stuff is left undocumented for good reasons... >
It was in the rev0 docs, but got removed in the rev1 - added back in rev2. It has been sent to the documentation team but is yet to be released - this was over a year ago. The info came from the cortex_m3 design team, and i have validated it on all cortex_m3 revisions that this reg does indeed exist. This was the reason i removed the original implementation. > Regardless, "four bytes in one register" is a *BIG* > difference from "four registers". The existing code can't > have worked. And I looked at the revision history for the > armv7m.c file, and nothing mentioned any changes to register > handling. Plus, just now I looked at the diffs not just the > comments -- same. Maybe that happened before this code left > the M3 branch. > The code is in cortex_m3.c. The original code used 4 virtual regs to let the user see each special register. All that has changed in the patch is this is now hidden - it still works the same. > > > Also a note regarding the new handling of the reg20 > > > > This sort of breaks cortex_m3 support > > In what way? It worked just fine in my testing... that is, > no worse than before, where access to those registers was > broken, even though it claimed to work. > It works, just a visual thing - an array bug may be lurking. reg produces: (18) psp (/32): 0xB1805920 (dirty: 0, valid: 1) (19) spec20 (/32): 0x00000000 (dirty: 0, valid: 1) (20) (null) (/32): 0x00000000 (dirty: 0, valid: 1) <==================== invalid reg > > Due to the way the original code was written the order was very > > important for armv7m core register cache - consecutive reg numbers > > only allowed in the array. > > That's broken-as-designed then. The register number is 0x14, > and nothing is at 0x13. See table 10-3 in the r2p0 TRM (DDI 0337G). > It is, i am just pointing it out. > What code uses register *index* instead of register *number* > to access things through DCRSR though? That I didn't fix? > > > > I am in favour of reverting to individual reg names - > easier for the > > end user. > > But completely incorrect in technical terms. See table 10-3. > They are fields in *ONE* register as identified using DCRSR. > > I agree that the info comes from a single reg, perhaps we need some tcl magic to help the user decipher the info. For info most vendors split this regster up into the seperate 8bit regs. Cheers Spen _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
