On Thursday 16 July 2009, Spencer Oliver wrote: > > > 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.
I unfortunately deleted my rev0 M3 TRM. :( > 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. Good, that will promote saner code on our end. :) I'll plan on removing the version check, but I want to do that in conjunction with some yet-to-be-written test code to let me trigger the various processor modes. So it'll be a few days yet. > > 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. I didn't see anything to morph the "real" register into four "virtual" ones though... the code was treating it as having for unique DCRSR identifiers, which is incorrect. > (20) (null) (/32): 0x00000000 (dirty: 0, valid: 1) <==================== I see: (18) psp (/32): 0x00000000 (dirty: 0, valid: 0) (19) spec20 (/32): 0x00000000 (dirty: 0, valid: 0) (20) GDB dummy floating-point register (/32): 0x00000000 (dirty: 0, valid: 0) Which is a different type of bug. There *IS* no floating point... > 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. Agreed that would be nicer. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
