progbuf issue
stineje opened this issue · 7 comments
Sorry to bother everyone. We are implementing the debug spec for RISC-V and have an issue when using riscv-openocd and getting an issue with progbuf. I don't believe we have it as it's optional. I remember that this wasn't implemented but thought it had options or was being modified to handle it if it's not implemented. Is this still an issue? Ours works okay with the traditional openocd. I appreciate the help and, again, we are sorry for bothering everyone. Thank you everyone for any help or guidance.
Info : clock speed 1000 kHz
Info : JTAG tap: cvw.cpu tap/device found: 0x1002a005 (mfg: 0x002 (AMI), part: 0x002a, ver: 0x1)
Info : [cvw.cpu] datacount=2 progbufsize=0
Warn : [cvw.cpu] We won't be able to execute fence instructions on this target. Memory may not always appear consistent. (progbufsize=0, impebreak=0)
Error: [cvw.cpu] Unable to insert program into progbuf, capacity would be exceeded (progbufsize=0).
Error: [cvw.cpu] Unable to insert program into progbuf, capacity would be exceeded (progbufsize=0).
Error: [cvw.cpu] Unable to insert program into progbuf, capacity would be exceeded (progbufsize=0).
Error: [cvw.cpu] Examination failed
Warn : target cvw.cpu examination failed
@stineje would you kindly share the whole OpenOCD log with debugging messages enabled? You need to pass "-d3" to OpenOCD command line to get one. It would not hurt to pass an additional "-l openocd.log" to save the log into a file.
It looks like you've replied via email. I don't believe github allows file attachments in this case. Could you you please attach the file using github web interface?
So sorry for that - my mistake. attaching here. Thank you once again for helping. I know I probably made a simple mistake.
If I'm not mistaken @en-sc could you double-check, please? This is the reason for the issue:
Debug: 274 26 riscv-013.c:1841 set_dcsr_ebreak(): [cvw.cpu] Set dcsr.ebreak*
Debug: 275 26 riscv.c:5802 riscv_get_register(): [cvw.cpu] Reading dcsr from target
Debug: 276 26 riscv-013.c:5167 riscv013_get_register(): [cvw.cpu] reading register dcsr
Debug: 277 26 riscv-013.c:1791 register_read_direct(): [cvw.cpu] Reading dcsr
Debug: 278 26 riscv-013.c:939 execute_abstract_command(): [cvw.cpu] access register=0x2207b0 {regno=0x7b0 write=arg0 transfer=enabled postexec=disabled aarpostincrement=disabled aarsize=32bit}
Debug: 279 26 riscv-013.c:409 riscv_log_dmi_scan(): 41b w 002207b0 @17 -> + 00000802 @16; 0i
Debug: 280 26 riscv-013.c:432 riscv_log_dmi_scan(): write: command=0x2207b0 {control=0x2207b0}
Debug: 281 26 riscv-013.c:409 riscv_log_dmi_scan(): 41b r 00000000 @16 -> + 00000802 @17; 0i
Debug: 282 26 riscv-013.c:409 riscv_log_dmi_scan(): 41b - 00000000 @16 -> + 00000b02 @16; 0i
Debug: 283 26 riscv-013.c:422 riscv_log_dmi_scan(): read: abstractcs=0xb02 {datacount=2 relaxedpriv=relaxed_checks cmderr=exception}
Debug: 284 26 riscv-013.c:962 execute_abstract_command(): [cvw.cpu] command 0x2207b0 failed; abstractcs=0xb02
Debug: 285 26 riscv-013.c:409 riscv_log_dmi_scan(): 41b w 00000700 @16 -> + 00000b02 @16; 0i
Debug: 286 26 riscv-013.c:432 riscv_log_dmi_scan(): write: abstractcs=0x700 {cmderr=other}
Debug: 287 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b - 00000000 @16 -> + 00000b02 @16; 0i
Debug: 288 27 riscv.c:5842 riscv_save_register(): [cvw.cpu] Saving fp
Debug: 289 27 riscv.c:5802 riscv_get_register(): [cvw.cpu] Reading fp from target
Debug: 290 27 riscv-013.c:5167 riscv013_get_register(): [cvw.cpu] reading register fp
Debug: 291 27 riscv-013.c:1791 register_read_direct(): [cvw.cpu] Reading fp
Debug: 292 27 riscv-013.c:939 execute_abstract_command(): [cvw.cpu] access register=0x321008 {regno=0x1008 write=arg0 transfer=enabled postexec=disabled aarpostincrement=disabled aarsize=64bit}
Debug: 293 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b w 00321008 @17 -> + 00000b02 @16; 0i
Debug: 294 27 riscv-013.c:432 riscv_log_dmi_scan(): write: command=0x321008 {control=0x321008}
Debug: 295 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b r 00000000 @16 -> + 00000b02 @17; 0i
Debug: 296 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b - 00000000 @16 -> + 00000802 @16; 0i
Debug: 297 27 riscv-013.c:422 riscv_log_dmi_scan(): read: abstractcs=0x802 {datacount=2 relaxedpriv=relaxed_checks}
Debug: 298 27 batch.c:127 riscv_batch_run_from(): [cvw.cpu] Running batch of scans [0, 3)
Debug: 299 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b r 00000000 @04 -> + 00000802 @16; 0i
Debug: 300 27 riscv-013.c:422 riscv_log_dmi_scan(): read: abstractcs=0x802 {datacount=2 relaxedpriv=relaxed_checks}
Debug: 301 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b r 00000000 @05 -> + 00038220 @04; 0i
Debug: 302 27 riscv-013.c:422 riscv_log_dmi_scan(): read:
Debug: 303 27 riscv-013.c:409 riscv_log_dmi_scan(): 41b - 00000000 @00 -> + ffff8f80 @05; 0i
Debug: 304 27 riscv-013.c:422 riscv_log_dmi_scan(): read:
Debug: 305 27 riscv-013.c:1810 register_read_direct(): [cvw.cpu] fp = 0xffff8f8000038220
Debug: 306 27 riscv.c:5811 riscv_get_register(): [cvw.cpu] Read fp: 0xffff8f8000038220
Error: 307 27 program.c:201 riscv_program_insert(): [cvw.cpu] Unable to insert program into progbuf, capacity would be exceeded (progbufsize=0).
Error: 308 27 target.c:681 target_examine_one(): [cvw.cpu] Examination failed
Debug: 309 27 target.c:682 target_examine_one(): [cvw.cpu] examine() returned error code -4
Diagnostics could be better, to avoid potential confusion... The issue does not look like related to progbuf directly.
If I read this log right - OpenOCD attempts to read DCSR register using "abstract access" command. It fails. Then OpenOCD tries to access this register using progbuf (I don't think that it should in the first place, but this is what it does at the moment) - that fails too.
We are implementing the debug spec for RISC-V and have an issue when using riscv-openocd and getting an issue with progbuf
@stineje do you have DCSR impemented in your design? Do you allow "abstract access" command to read it? If not - this is the issue.
I'd like to add a bit to the analysis by @aap-sc.
As correctly pointed out, the root cause is the failure to read dcsr during register examination.
However, abstractcs.cmderr is equal to 3 (exception).
Do you allow "abstract access" command to read it?
If this was the case, abstractcs.cmderr should have been equal to 2 (not supported).
AFAIU, the only case abstract read of dcsr would fail with abstractcs.cmderr equal to 3 (exception) is dcsr being not implemented (which does not make much sense, since it should be implemented for all harts that support external debug).
Note that reads of mstatus and mtopi fail similarly.
Thank you very much for all your help! I am truly indebted - I realized the dcsr is not doing what it should and so going to try to fix and try again. Thank you!!!!!!!!!