Add support for Smdbltrp. #998
Conversation
|
We can't merge this until ARC also reviews the change. |
There was a problem hiding this comment.
I went back and forth about whether we should proactively reserve more bits. In the end, I think that this is fine for the foreseeable future and any Debug 1.0 follow-on extensions like double trap or secure debug. Debug 2.0 (which would have a different tinfo.version) can consider the two cause fields to be a unified 6-bit field with 64 encodings rather than the current 7+8 encodings.
|
Ved requested those specific bits, to match something he's already written.
I don't really care which bits so I went with it.
…On Mon, Apr 1, 2024, 9:44 AM Paul Donahue ***@***.***> wrote:
***@***.**** commented on this pull request.
I just saw your latest change. Why 26:24 rather than left-justifying or
right-justifying in that reserved area?
—
Reply to this email directly, view it on GitHub
<#998 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXVPX2LY3QMSDD7QTMJW73Y3GFFBAVCNFSM6AAAAABFR2BYS2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNZRGY4DMNRUHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
This will make space for Sddbltrp, and possibly other extensions that need more causes.
Based on feedback from Ved.
|
@ved-rivos: Why bit 19 instead of 18? |
|
@pdonahue-ventana - bit 18 has been allocated for previous ELP - |
|
OK. That's from a while ago so I forgot about it. |
xml/core_registers.xml
Outdated
| more specific halt reason than "other." Otherwise it contains 0. | ||
|
|
||
| <value v="0" name="dbltrp"> | ||
| An exception or interrupt occurred while the trap handler was in |
There was a problem hiding this comment.
| An exception or interrupt occurred while the trap handler was in | |
| The hart entered a critical error state. Part of the ((Smdbltrp)) extension. |
Reworded to:
- Use the critical error term to tie it back to the
cetrig - Such an exception/interrupt may not always lead to a critical error (e.g., at S-mode or VS-mode it does not) and in M-mode it does not if it was not the RNMI handler and RNMI was implemented. So this would avoid needing to put all conditions in here.
xml/core_registers.xml
Outdated
| When {dcsr-cause} is 7, this optional field contains the value of a | ||
| more specific halt reason than "other." Otherwise it contains 0. | ||
|
|
||
| <value v="0" name="dbltrp"> |
There was a problem hiding this comment.
Could we call it critical error.
|
@rtwfroody Thanks. LGTM. |
xml/core_registers.xml
Outdated
| more specific halt reason than "other." Otherwise it contains 0. | ||
|
|
||
| <value v="0" name="critical error"> | ||
| The hart entered a critical error state. Part of the |
There was a problem hiding this comment.
| The hart entered a critical error state. Part of the | |
| The hart entered a critical error state, as defined in the ((Smdbltrp)) extension. |
| ==== | ||
| When {dcsr-cetrig} is enabled, resuming from Debug Mode | ||
| following an entry due to a critical error will result in an | ||
| immediate re-entry into Debug Mode due to the critical error. |
There was a problem hiding this comment.
The debugger may resume with cetrig set to 0 to allow the platform defined actions on critical-error signal to occur. Other possible actions include initiating a hart or platform reset using the Debug Module reset control.
From Ved's feedback on the PR.
|
Per https://lists.riscv.org/g/tech-chairs/message/1898 this was approved by ARC. |
2 changes:
We expect this to be approved together with #988, but I want to keep them separate so we can easily have one approved/merged without the other.