)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"5a2a4e60eb6e66f4dac7b21f0bf0d3aab6d57ce5","unresolved":true,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"target/riscv: don\u0027t finish reset until allunavail clears"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This used to be our behavior, but it regressed in commit 1c168242e9f5"},{"line_number":10,"context_line":"(\"target/riscv: simplify reset\"), which was intended purely as a code"},{"line_number":11,"context_line":"cleanup. On some chips, like the GD32VF103, anyhavereset/allhavereset"},{"line_number":12,"context_line":"assert before anyunavail/allunavail deassert, causing us to leave this"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"718b9174_09b31649","line":9,"range":{"start_line":9,"start_character":57,"end_line":9,"end_character":69},"updated":"2025-12-12 09:24:34.000000000","message":"Please see https://review.openocd.org/c/openocd/+/9176/comment/520d79f4_413d77b1/","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"87d5ad77cf6a5e11e09729cce4de4661891cfeef","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"target/riscv: don\u0027t finish reset until allunavail clears"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This used to be our behavior, but it regressed in commit 1c168242e9f5"},{"line_number":10,"context_line":"(\"target/riscv: simplify reset\"), which was intended purely as a code"},{"line_number":11,"context_line":"cleanup. On some chips, like the GD32VF103, anyhavereset/allhavereset"},{"line_number":12,"context_line":"assert before anyunavail/allunavail deassert, causing us to leave this"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"e9ef62fd_3439de8b","line":9,"range":{"start_line":9,"start_character":57,"end_line":9,"end_character":69},"in_reply_to":"718b9174_09b31649","updated":"2025-12-12 23:02:36.000000000","message":"Fixed in new version which hopefully also satisfies checkpatch.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"ff91835fab92eec47f30b55a6a24bf8e7a9ac4a3","unresolved":true,"context_lines":[{"line_number":12,"context_line":"assert before anyunavail/allunavail deassert, causing us to leave this"},{"line_number":13,"context_line":"routine before the reset finishes."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"That behavior is arguably a violation of the debug spec, which says that"},{"line_number":16,"context_line":"havereset should be set \"when harts have been reset\". But the spec also"},{"line_number":17,"context_line":"says that the system coming out of reset is \"reported by allunavail,"},{"line_number":18,"context_line":"anyunavail\", which makes me believe it\u0027s more correct to check only"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"8f06ada5_80efcc12","line":15,"updated":"2025-12-12 10:36:46.000000000","message":"Can you please describe the behavior in more detail?\nAFAIU:\n1. Once the reset is asserted, the hart is reported as unavailable and halted or running.\n2. `havereset` becomes high but `unavailable` is still high.\n3. `unavailable` lowers.\n\nWy understanding is -- the described behavior is compliant, but it\u0027s not a reset. It just means after each reset the hart becomes unavailable for a moment.\n\nWe can try to mask this behavior to avoid the annoying logging.\nAFAIU, this can be done by waiting until `dmstatus.allunavailable` lowers in the `deassert_reset` handler.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"2c0f011b13ee250e62b257bd318fad755d379a09","unresolved":false,"context_lines":[{"line_number":12,"context_line":"assert before anyunavail/allunavail deassert, causing us to leave this"},{"line_number":13,"context_line":"routine before the reset finishes."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"That behavior is arguably a violation of the debug spec, which says that"},{"line_number":16,"context_line":"havereset should be set \"when harts have been reset\". But the spec also"},{"line_number":17,"context_line":"says that the system coming out of reset is \"reported by allunavail,"},{"line_number":18,"context_line":"anyunavail\", which makes me believe it\u0027s more correct to check only"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"d0800511_29447490","line":15,"in_reply_to":"8f06ada5_80efcc12","updated":"2025-12-12 18:52:41.000000000","message":"Yes, that\u0027s what happens. I\u0027ll post the exact register states later today when I\u0027m back with my hardware.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"f20ae74aef515265a0828e7b811e4c1d6d73e7d1","unresolved":false,"context_lines":[{"line_number":12,"context_line":"assert before anyunavail/allunavail deassert, causing us to leave this"},{"line_number":13,"context_line":"routine before the reset finishes."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"That behavior is arguably a violation of the debug spec, which says that"},{"line_number":16,"context_line":"havereset should be set \"when harts have been reset\". But the spec also"},{"line_number":17,"context_line":"says that the system coming out of reset is \"reported by allunavail,"},{"line_number":18,"context_line":"anyunavail\", which makes me believe it\u0027s more correct to check only"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"65f26195_9cad7252","line":15,"in_reply_to":"d0800511_29447490","updated":"2025-12-12 22:57:03.000000000","message":"While resetting (immediately after reset assert):\n```\nbatch.c:199 log_dmi_decoded(): read: dmstatus\u003d0x4f3ca2 {version\u003d0_13 anyrunning\u003d1 allrunning\u003d1 anyunavail\u003d1 allunavail\u003d1 anyresumeack\u003d1 allresumeack\u003d1 anyhavereset\u003d1 allhavereset\u003d1 impebreak\u003d1 hasresethaltreq\u003d1 authenticated\u003dtrue}\n```\n\nAfter reset done:\n```\nbatch.c:199 log_dmi_decoded(): read: dmstatus\u003d0x4f0ca2 {version\u003d0_13 anyrunning\u003d1 allrunning\u003d1 anyresumeack\u003d1 allresumeack\u003d1 anyhavereset\u003d1 allhavereset\u003d1 impebreak\u003d1 hasresethaltreq\u003d1 authenticated\u003dtrue}\n```","commit_id":"d66254b75776c445133d3d301e962b60ac840876"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"203a0c95600a2e123f9b2c37150de9ad24535fc5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f537dab2_19aa242b","updated":"2025-12-11 23:40:13.000000000","message":"Incidentally, it seems more correct to be testing anyunavail and anyhavereset. Could the current code cause problems on multi-core systems where different harts come out of reset at different times (or where some aren\u0027t reset at all)? I can post that as a separate change if so.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"7fc06c87cf62782c2e3409a86c227f538169c17a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"42bb3398_e9f3fd75","updated":"2025-12-11 23:37:53.000000000","message":"Noticed this regression when testing the rebased https://review.openocd.org/c/openocd/+/6959.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"ff91835fab92eec47f30b55a6a24bf8e7a9ac4a3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6ae6104b_009d4976","in_reply_to":"67200a30_c1bee7f7","updated":"2025-12-12 10:36:46.000000000","message":"\u003e My concern is if the patch doesn\u0027t break the reset on other RISC-V machine.\n\nIt will. Please see [3.2. Reset Control]:\n\u003e While the reset is on-going, harts are either in the running state, indicating it’s possible to perform some abstract commands during this time...\n\nOn such harts the proposed `deassert_reset()` procedure will finish early, due to the absence `allunavailable`.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"2c0f011b13ee250e62b257bd318fad755d379a09","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6243e88f_fdbf6f63","in_reply_to":"6ae6104b_009d4976","updated":"2025-12-12 18:52:41.000000000","message":"\u003e It will. Please see [3.2. Reset Control]:\n\nThanks for pointing out this text from the 1.0 Debug Specification. Given that, and assuming the GD32VF103 is the only chip with this behavior, I agree this probably doesn\u0027t belong in core code.\n\nHowever, you are wrong that this change will break other RISC-V chips. The issue that you describe,\n\n\u003e On such harts the proposed deassert_reset() procedure will finish early, due to the absence allunavailable.\n\nis exactly what happens now because the current code only waits while allhavereset is clear *and* allunavail is set. It will not wait if allunavail is not set during reset. https://review.openocd.org/c/openocd/+/9314 will change that. So it seems like the current behavior is the worst of both worlds and at least one of our changes needs to land.","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"5a2a4e60eb6e66f4dac7b21f0bf0d3aab6d57ce5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"67200a30_c1bee7f7","in_reply_to":"f537dab2_19aa242b","updated":"2025-12-12 09:24:34.000000000","message":"Thanks for reporting the problem!\n\nAFAIK just one hart is selected at a time so allxxx is mostly equal to anyxxx\n\nI confirm that the patch fixes annoying noise around gd32vf103 reset in the current git master\n```\n\u003e reset\nJTAG tap: gd32vf103.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)\nJTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)\ngd32vf103.cpu halted due to debug-request.\n[gd32vf103.cpu] Hart unexpectedly reset!\n[gd32vf103.cpu] became unavailable.\n[gd32vf103.cpu] Register fp is dirty!\n[gd32vf103.cpu] Register s1 is dirty!\n[gd32vf103.cpu] Discarding values of dirty registers (due to target becoming unavailable).\n[gd32vf103.cpu] Hart unexpectedly reset!\n[gd32vf103.cpu] became available (running)\n```\n\nMy concern is if the patch doesn\u0027t break the reset on other RISC-V machine.\nAs the GD32VF103 debug module is known not to conform the debug spec we should better try to fix the problem in pluggable reset events (however I\u0027m not sure if it\u0027s possible at all)","commit_id":"d66254b75776c445133d3d301e962b60ac840876"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"f20ae74aef515265a0828e7b811e4c1d6d73e7d1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1289d9fb_1989149f","updated":"2025-12-12 22:57:03.000000000","message":"Evgeniy, your workaround doesn\u0027t seem effective on real hardware, I\u0027m guessing because it happens too late. See my comment on https://review.openocd.org/c/openocd/+/9316.\n\nI can investigate further if needed, but I realized that we\u0027re probably overcomplicating this: we can just wait both for havereset to assert and for unavail to deassert. That ought to bring us into compliance with the spec without regressing noncompliant devices, right? See my latest patchset.","commit_id":"269e827fa95d13edf554d9f087d37a6de3d34ba1"}],"src/target/riscv/riscv-013.c":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"529c03ba70efaf7910a37c13dc366403617c3cc6","unresolved":true,"context_lines":[{"line_number":3008,"context_line":"\t\t * halted/running. To work around this, we check for"},{"line_number":3009,"context_line":"\t\t * the absence of the unavailable state rather than"},{"line_number":3010,"context_line":"\t\t * the presence of any other state. */"},{"line_number":3011,"context_line":"\t} while (get_field(dmstatus, DM_DMSTATUS_ALLUNAVAIL) ||"},{"line_number":3012,"context_line":"\t\t\t!get_field(dmstatus, DM_DMSTATUS_ALLHAVERESET));"},{"line_number":3013,"context_line":""},{"line_number":3014,"context_line":"\triscv_scan_set_delay(\u0026info-\u003elearned_delays, RISCV_DELAY_BASE,"}],"source_content_type":"text/x-csrc","patch_set":4,"id":"fe17d642_6e5cdc96","line":3011,"range":{"start_line":3011,"start_character":10,"end_line":3011,"end_character":56},"updated":"2025-12-13 02:29:55.000000000","message":"Certainly not correct.\nThe hart of a multicore device may keep unavailable state over reset or become unavailable during reset. In both cases this patch blocks until timeout.\nThe first case is easy to simulate with spike:\n```\n\u003e riscv dm_write 0x1f 1\n[c1] became unavailable.\n\u003e reset\nJTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (Fabric of Truth In\nc), part: 0xeadb, ver: 0xd)\n[c1] Hart didn\u0027t leave reset in 5s; dmstatus\u003d0x4f3082 (allunavail\u003dtrue, allhaver\neset\u003dtrue); Increase the timeout with riscv set_command_timeout_sec.\n \n[c1] Hart unexpectedly reset!\n[c1] became unavailable.\n```","commit_id":"d905ff9ab5cf161351222d981c910cfe8dd54fc3"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"f123b4c7f19ca023e93aabe59d9e4339a3a46d85","unresolved":false,"context_lines":[{"line_number":3008,"context_line":"\t\t * halted/running. To work around this, we check for"},{"line_number":3009,"context_line":"\t\t * the absence of the unavailable state rather than"},{"line_number":3010,"context_line":"\t\t * the presence of any other state. */"},{"line_number":3011,"context_line":"\t} while (get_field(dmstatus, DM_DMSTATUS_ALLUNAVAIL) ||"},{"line_number":3012,"context_line":"\t\t\t!get_field(dmstatus, DM_DMSTATUS_ALLHAVERESET));"},{"line_number":3013,"context_line":""},{"line_number":3014,"context_line":"\triscv_scan_set_delay(\u0026info-\u003elearned_delays, RISCV_DELAY_BASE,"}],"source_content_type":"text/x-csrc","patch_set":4,"id":"af4e5d9f_332352cb","line":3011,"range":{"start_line":3011,"start_character":10,"end_line":3011,"end_character":56},"in_reply_to":"fe17d642_6e5cdc96","updated":"2025-12-13 17:34:33.000000000","message":"Right, I forgot that ndmreset is system-wide but we\u0027re looking at just one (arbitrary) hart. My only other idea would be to select all the harts and wait for allunavail to clear, but that seems like a can of worms and far too complex to work around one buggy chip. This patch is probably unworkable. I\u0027ll see if I have time to investigate why the workaround isn\u0027t working in the next few days, then I\u0027ll abandon it.","commit_id":"d905ff9ab5cf161351222d981c910cfe8dd54fc3"}]}