Hardware can ignore some bits during abstract command

This is a clean way to let a debugger reset a DM without having to know
what hartsel is first. It can simply write 0 then 1 to dmactive.

These new rules resolve the issue raised in #1021, that if the DM is
executing an abstract command when the debugger wants to reset it, the
debugger should not be expected to preserve hartsel.

debug_module.adoc

@@ -369,8 +369,11 @@ of {dm-data0}) or hart (e.g. contents of a register modified by a Program Buffe
 Before starting an abstract command, a debugger must ensure that {dmcontrol-haltreq}, {dmcontrol-resumereq}, and {dmcontrol-ackhavereset} are all 0.
 
 While an abstract command is executing ({abstractcs-busy} in {dm-abstractcs} is high), a debugger must not change {hartsel}, and must not write 1 to {dmcontrol-haltreq}, {dmcontrol-resumereq}, {dmcontrol-ackhavereset}, {dmcontrol-setresethaltreq}, or {dmcontrol-clrresethaltreq}.
-The exception to this rule is when 0 is written to {dmcontrol-dmactive}, in
-which case the DM may ignore all bits other than {dmcontrol-dmactive}.
+The exception to this rule is when the debugger writes 0 to
+{dmcontrol-dmactive}. In that case {hartsel} may be written with a new value
+(which the hardware should ignore).
+The hardware should not rely on this debugger behavior, but enforce it by
+ignoring writes to these bits while {abstractcs-busy} is high.
 
 If an abstract command does not complete in the expected time and
 appears to be hung, the debugger can try to reset the hart (using {dmcontrol-hartreset} or {dmcontrol-ndmreset}).

xml/dm_registers.xml

@@ -177,7 +177,8 @@ same project unless stated otherwise.
         and at most 20. A debugger should discover `HARTSELLEN` by writing
         all ones to {hartsel} (assuming the maximum size) and reading back the
         value to see which bits were actually set. Debuggers must not change
-        {hartsel} while an abstract command is executing.
+        {hartsel} while an abstract command is executing. Hardware should enforce
+        this by ignoring changes to {hartsel} while {abstractcs-busy} is set.
 
         [NOTE]
         ====
@@ -219,6 +220,9 @@ same project unless stated otherwise.
             set.
 
             Writes apply to the new value of {hartsel} and {dmcontrol-hasel}.
+
+            Writes to this bit should be ignored while an abstract command is
+            executing.
         </field>
         <field name="resumereq" bits="30" access="W1" reset="-">
             Writing 1 causes the currently selected harts to resume once, if
@@ -228,6 +232,9 @@ same project unless stated otherwise.
             {dmcontrol-resumereq} is ignored if {dmcontrol-haltreq} is set.
 
             Writes apply to the new value of {hartsel} and {dmcontrol-hasel}.
+
+            Writes to this bit should be ignored while an abstract command is
+            executing.
         </field>
         <field name="hartreset" bits="29" access="WARL" reset="0">
             This optional field writes the reset bit for all the currently
@@ -253,6 +260,9 @@ same project unless stated otherwise.
             </value>
 
             Writes apply to the new value of {hartsel} and {dmcontrol-hasel}.
+
+            Writes to this bit should be ignored while an abstract command is
+            executing.
         </field>
         <field name="ackunavail" bits="27" access="W1" reset="-">
             <value v="0" name="nop">
@@ -315,12 +325,18 @@ same project unless stated otherwise.
             Writes apply to the new value of {hartsel} and {dmcontrol-hasel}.
 
             If {dmstatus-hasresethaltreq} is 0, this field is not implemented.
+
+            Writes to this bit should be ignored while an abstract command is
+            executing.
         </field>
         <field name="clrresethaltreq" bits="2" access="W1" reset="-">
             This optional field clears the halt-on-reset request bit for all
             currently selected harts.
 
             Writes apply to the new value of {hartsel} and {dmcontrol-hasel}.
+
+            Writes to this bit should be ignored while an abstract command is
+            executing.
         </field>
         <!-- Fields that apply to the entire DM. -->
         <field name="ndmreset" bits="1" access="R/W" reset="0">