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...

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.


> 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.


> 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).

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.


> Is spec20 a arm name - i can find no info anywhere?

The register has no name that I could find, so I had to make
one up.  Table 10-3 just lists the fields, no name.

- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to