A few comments as i have not had time to look over the original patch.

>      * What the Core Debug facility exposes is 
> *implementation-specific*
>        not architectural.  These values aren't fully 
> portable.  They match
>        Cortex-M3 ... so no current implementation will make 
> trouble, but
>        the next v7m implementation might.
> 
>      * 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.

>  - Update the CM3 code to report when that one register is available,
>    and not try to access it when it isn't.  Also declare the register
>    numbers that an eventual MRS/MSR solution will need to be using.
> 

Not required - see above.

>
>

Also a note regarding the new handling of the reg20

This sort of breaks cortex_m3 support
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.

so now cortex_m3 is a register out, eg. reg cmd.

(18) psp (/32): 0xB1805920 (dirty: 0, valid: 1)
(19) spec20 (/32): 0x00000000 (dirty: 0, valid: 1)
(20) (null) (/32): 0x00000000 (dirty: 0, valid: 1)

spec20 should be reg20, not 19.
previous reg comd printed:

(18) psp (/32): 0xB1805920 (dirty: 0, valid: 1)
(19) primask (/32): 0x00000000 (dirty: 0, valid: 1)
(20) basepri (/32): 0x00000000 (dirty: 0, valid: 1)
(21) faultmask (/32): 0x00000000 (dirty: 0, valid: 1)
(22) control (/32): 0x00000000 (dirty: 0, valid: 1)

I am in favour of reverting to individual reg names - easier for the end
user.
Is spec20 a arm name - i can find no info anywhere?

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

Reply via email to