I get an error when calling the dm_write befor init

[Alan-19950616]

openocd.cfg

......
riscv set_mem_access sysbus
riscv dm_write 0x38 0x40000
riscv dm_write 0x39 0x80000000
riscv dm_write 0x3c 0x1234

init
......

The error log

Error: [riscv0.cpu] dmi_write is not implemented.
Error: [riscv0.cpu] Unsupported DTM version: -1
Error: [riscv0.cpu] Could not identify target type.

[en-sc]

@Alan-19950616, to access Debug Module Interface one needs to know it's version first (dtmcs.version) and the length of DMI address (dtmcs.abits). dtmcs is read during target examination (part of init). This is why you observe these error messages.

[Alan-19950616]

@en-sc The CORE that is currently being debugged needs to be configured with the soc component using sysbus before it can be halted. how should this be handled at the moment?

[aap-sc]

@Alan-19950616

The CORE that is currently being debugged needs to be configured with the soc component using sysbus before it can be halted

See here: #1172 and here #1038

[Alan-19950616]

@aap-sc I was using dm_write to implement this function, after updating the code I realized that it doesn't work like that anymore, if you can confirm that all subsequent openocd will be modified in this direction, I will change to irscan/drscan to implement it!

By the way, in that case do commands like dm_write no longer apply “.mode = COMMAND_ANY”
https://github.com/riscv-collab/riscv-openocd/blob/riscv/src/target/riscv/riscv.c#L5437

[aap-sc]

@Alan-19950616

if you can confirm that all subsequent openocd will be modified in this direction,

Hm...

For now we'd better to stick with irscan/drscan. Currently, reply by @en-sc provides a reason for that: #1180 (comment)

That being said I'd like to get some additional clarification from @en-sc first.

@en-sc I have a theoretical question, though. Do we really require to perform an invasive examine on a targets to figure out DM properties and relevant topology? I mean can we implement some command to figure out only DM properties without halting/resuming the target (we could mark targets as -defer-examine to avoid a full-blown examination procedure)?

By the way, in that case do commands like dm_write no longer apply “.mode = COMMAND_ANY”

yep. Currently this looks like a bug.

[en-sc]

Do we really require to perform an invasive examine on a targets to figure out DM properties and relevant topology?

No. Examining the DM can be done without affecting harts.

I mean can we implement some command to figure out only DM properties without halting/resuming the target (we could mark targets as -defer-examine to avoid a full-blown examination procedure)?

Yes, this is achievable, but I'd first prefer to better expose Debug Module. To be able to configure anything related to the DM we need to first be able to configure at least the Debug Transport Module's version.

I'd prefer if there were an explicit DM configuration and target-DM assignment, similar to how it's done for ARM DAPs.

[Alan-19950616]

@en-sc @aap-sc

So you guys still recommend the irscan/drscan command?

[aap-sc]

So you guys still recommend the irscan/drscan command?

Right now - yes. Looks like (according to answer from @en-sc) access to DM could be implemented in future - but this requires additional changes and may take some time