[qemu] Fix unreliable RV_DM halt on reset behaviour

[AlexJones0]

Description

Many provisioning flows depend on the fact that we can reset the Ibex core and halt it coming out of reset using the Debug Module via the RV_DM JTAG TAP. Through testing it has been seen that this feature is unreliable and only works in approximately half of the cases that it is used.

After debugging, it appears that the issue is the non-conformance of QEMU's RV_DM to the RISC-V debug specification, which states in various places - though most notably in the relevant bug fix related to this behaviour:

C.1.4 Hart reset behavior when haltreq is set
When a hart comes out of reset and haltreq is set, the hart will immediately enter Debug Mode.

Currently QEMU has no notion of latching halt requests against unresponsive harts and this case is not implemented at all. In unlucky emulations where the boot sequence takes too long, the incoming halt requests occur while the core is unresponsive (disabled) and are lost.

Furthermore, such a feature seems to be non-trivial to implement, due to the lack of reconciliation between QEMU's reset flow and OpenTitan's boot flow. The current QEMU implementation resets each device on a system reset and disables the hart until the Pwrmgr directly enables Ibex's instruction fetch and execution. An ideal implementation of the debug module would hook into the RISC-V hart reset exit, but this will currently occur at reset time and not at instruction fetch enablement time for OpenTitan. To fix this issue would require a rework of reset management for all OpenTitan devices, which is already quite complex.

With regards to potential workarounds/patches that could be carried, I have prototyped two WIP patches (1, 2) which vary in terms of correctness and impact. We need to figure out if these patches can be accepted, should be maintained on a separate branch, or if there is a more appropriate solution to fix this problem.