Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rv_dm] dmcontrol.haltreq should always read as 0 #23204

Open
bcstrongx opened this issue May 20, 2024 · 4 comments
Open

[rv_dm] dmcontrol.haltreq should always read as 0 #23204

bcstrongx opened this issue May 20, 2024 · 4 comments

Comments

@bcstrongx
Copy link

desc

The RISC-V spec (v0.13.2) defines the dmcontrol.haltreq bit with access "W" (Section 3.12.2), which is defined as "Write-only. When read this field returns 0" (Table 1.2). However, the current implementation allows this bit to be read as 1 after a write sets it to 1.

@rswarbrick
Copy link
Contributor

rswarbrick commented May 21, 2024

I'm looking at the RISC-V external debug support spec, version 0.13.2 (e.g. here).

I think you're right about this behaviour. Looking at the code, the behaviour comes from dm_csrs.sv, where a read of DMControl is handled like this:

        dm::DMControl:    resp_queue_inp.data = dmcontrol_q;

(picking up all the bits of dmcontrol_q, including the halt request).

This code actually comes from the pulp project. I suspect we won't fix it locally (because it doesn't feel very important) and will take a fix by getting it fixed upstream and then vendoring in the change. Would you be happy to file a report there?

@bcstrongx
Copy link
Author

Sure, I can file an issue there. Feel free to close this issue if there's no need for it.

@bcstrongx
Copy link
Author

Filed, see pulp-platform/riscv-dbg#161

@andreaskurth andreaskurth changed the title [top_darjeeling] dmcontrol.haltreq should always read as 0 [rv_dm] dmcontrol.haltreq should always read as 0 May 21, 2024
@andreaskurth andreaskurth added this to the Earlgrey-PROD.M4 milestone May 21, 2024
@andreaskurth andreaskurth added the Triage Priority Issue to be discussed with priority in the next triage meeting label May 21, 2024
@andreaskurth
Copy link
Contributor

discussed in triage meeting: future release because we don't expect SW to depend on this

@andreaskurth andreaskurth removed the Triage Priority Issue to be discussed with priority in the next triage meeting label May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants