)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"48fe9fe6f41a7f1c6f9cf8cc7df46e03ef00cde7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"4b9837f7_0976e364","updated":"2024-02-04 04:16:27.000000000","message":"Nice, thanks. IMO we can merge it now (it\u0027s a doc fix) and eventually update later","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"ced6eb14aaca6d8e4d08ad0fad7abcf698d407f1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"708dcf41_9b3c58b5","updated":"2024-02-04 14:07:52.000000000","message":"thanks for the review","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"}],"doc/openocd.texi":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"804bff94fbe13bd9821000cfe4cd9b1eec3ce3ff","unresolved":true,"context_lines":[{"line_number":5160,"context_line":"OpenOCD can parse the ROM table in the DAP access port to identify this"},{"line_number":5161,"context_line":"base address, but the parsing can be slow on devices with big ROM tables."},{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"671d9384_b833e829","line":5163,"updated":"2024-02-03 20:05:52.000000000","message":"Might be also a solution for a SoC where the cores are switched off by default and parts of ROM table are therefore unreadable?","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"48fe9fe6f41a7f1c6f9cf8cc7df46e03ef00cde7","unresolved":false,"context_lines":[{"line_number":5160,"context_line":"OpenOCD can parse the ROM table in the DAP access port to identify this"},{"line_number":5161,"context_line":"base address, but the parsing can be slow on devices with big ROM tables."},{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"e1babb42_10badb8e","line":5163,"in_reply_to":"4538daab_687eba83","updated":"2024-02-04 04:16:27.000000000","message":"Done","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"2a08944d5d3e9c2f3ea2d4fd6a6d4227ecc57280","unresolved":true,"context_lines":[{"line_number":5160,"context_line":"OpenOCD can parse the ROM table in the DAP access port to identify this"},{"line_number":5161,"context_line":"base address, but the parsing can be slow on devices with big ROM tables."},{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"4538daab_687eba83","line":5163,"in_reply_to":"671d9384_b833e829","updated":"2024-02-03 23:23:39.000000000","message":"Yes, there could be cases where the ROM is not readable, or one of the devices pointed by the ROM is not readable, so -dbgbase prevents a fault.\nI will change it","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"804bff94fbe13bd9821000cfe4cd9b1eec3ce3ff","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"7d37d177_2ed61e7b","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"updated":"2024-02-03 20:05:52.000000000","message":"Seems me too DAP centric. RISC-V DM hartsel is also driven by this number.\nOr are you going to remove this use? I\u0027m getting lost then...\n\nWhat if we really define `coreid` as a general index used to identify a CPU in a multicore SoC and then list the target specific usages bound to this index?","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"9adfeefd442d94a45bfc4bc2853d186c33a1c1d1","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"8dd04d98_8d843730","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"514361cd_5d7043aa","updated":"2024-02-08 15:57:12.000000000","message":"This complicates the picture.\nIn the example above of 4 harts in 2 DMs, without ```-dbgbase```, a coreid\u003d3 selects the last hart.\nBut if I use dbgbase\u003daddress_of_DM_1, the same hart would be selected with coreid\u003d1\nI don\u0027t really like this duality, but I don\u0027t have a cleaner way.\nAdding another flag for hartid?\nIf we have to change something, I prefer it\u0027s done asap, before we break user config files","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"cdc885e52dccfadcd3b5b21b9ed84ef853114263","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"c7dfe97c_3b023958","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"75070c52_a9239a97","updated":"2024-02-07 16:45:57.000000000","message":"I would like to clarify the usage in current RISC-V specific codebase (https://github.com/riscv/riscv-openocd).\nEach AP (not sure about the terminology, since only JTAG is supported for RISC-V targets maybe TAP is more appropriate here) can have multiple Debug Modules (DMs) on it. Each DM can have multiple harts on it.\nCurrently `dbgbase` is used to specify base address of a DM on the AP. As correctly stated in the patch, `coreid` is used to specify the index of the hart on the DM.","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"2a08944d5d3e9c2f3ea2d4fd6a6d4227ecc57280","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"75070c52_a9239a97","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"7d37d177_2ed61e7b","updated":"2024-02-03 23:23:39.000000000","message":"Actually I forgot about riscv!\nBut I see something confusing there in the riscv code, maybe just some confusing name of variables... I\u0027ll check again after SMP code get split from the coreid, or after a re-alignment with riscv fork.\n\nIn mean time I went to check about arm SMT devices, like Cortex-A65AE, to understand if there could be a clash between using coreid for hart-id and DAP \u0027helper\u0027. Even if Cortex-A65AE is architecturally SMT, from debug point of view it presents a completely independent set of debug registers per each hart, like they were independent core or in a SMP node. So coreid can be used on SMT as DAP \u0027helper\u0027 as for current SMP. Good.","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"39abd97ebc1097def9126a8fd4791fb8df1551f9","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"a8b1b1fc_108d0c58","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"84abe506_b2b96ab5","updated":"2024-02-18 17:37:36.000000000","message":"Ok, anyway it would be good to have the doc updated when the handling of ```-dbgbase``` in RISC-V fork would be merged upstream.\n\nI\u0027m quite confused by the RISC-V code.\nThe ```struct riscv_info```, taken from ```target-\u003earch_info``` has a field ```current_hartid``` that is re-assigned at runtime.\nIs there a 1:1 mapping between OpenOCD target and RISC-V hart?\nWhy this ```current_hartid``` changes?\n\nIf each hart is associated with a single OpenOCD target, then I think it could be good to restrict the use of ```target-\u003ecoreid``` during target create and copy it\u0027s value in a RISC-V specific field in ```struct riscv_info``` maybe simply named hartid.","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"9be666542ce76bd213413f3b9fe6ea074321efa6","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"84abe506_b2b96ab5","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"8dd04d98_8d843730","updated":"2024-02-08 18:55:43.000000000","message":"It seems there is some confusion. What I mean is:\n* `-dbgbase` is not used in RISC-V codebase in the mainline (this) repo. Currently, it is used only in RISC-V fork. Hence, multiple DMs on single DMI are not yet supported in the mainline.\n* The behavior described in my previous comment is not yet implemented anywhere. Implementing it as described will already break user configs for such configurations. The functionality is quite recent (https://github.com/riscv/riscv-openocd/pull/875 -- Jul 27, 2023) and it\u0027s not documented in the fork either. I will create an issue in the fork and notify the author.\n\nRegarding current state of RISC-V related codebase in the mainline -- the documentation you propose is correct. It won\u0027t be broken in the future, since the configuration in question is not yet supported. So maybe it\u0027s not an issue?","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"217738d45cda821aafb8780fb68510b213f4ed74","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"514361cd_5d7043aa","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"9984fdfe_1d8f63d1","updated":"2024-02-08 14:15:28.000000000","message":"The thing is, RISC-V also provides such mechanism.\nIt is guaranteed that DM registers of the first DM are accessable with offset zero to it\u0027s DMI address.\nThe debugger can discover if there is more DMs on the TAP by reading `nextdm` register of the DM. It provides the offset for the next DM (if `nextdm` is zero -- this is the last DM).\nMoreover, since hart indexes are contiguous and start from zero, it is easy to find out how many harts are on each DM.\nSo, if `-coreid` was to specify an index of the hart on the TAP, like so (2 DMs on a TAP, each with 2 harts):\n\n| DM index | hartid | `-coreid` |\n|----------|--------|-----------|\n| 0 | 0 | 0 |\n| 0 | 1 | 1 |\n| 1 | 0 | 2 |\n| 1 | 1 | 3 |\n\nThis would eliminate the need for the user to specify `-dbgbase`.\n\nI think this would be preferable. However, the designs with multiple DMs on single DMI bus are rare and were only recently supported in OpenOCD. The Spike simulator used in OpenOCD CI does not support such configurations. So proper implementation/testing will require significant work and, IMHO, there are more pressing issues for now.","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6802cb0c446c5874f0b8c2f5b04b6b414f342388","unresolved":true,"context_lines":[{"line_number":5162,"context_line":"Either to speed up the target examination and to address devices with"},{"line_number":5163,"context_line":"incorrect ROM table content, it\u0027s suggested to use @code{-dbgbase}."},{"line_number":5164,"context_line":""},{"line_number":5165,"context_line":"@item @code{-coreid} @var{coreid} -- set the position of target in DAP access port"},{"line_number":5166,"context_line":"For devices with multiple CPUs on the same DAP access port (e.g. @code{cortex_a},"},{"line_number":5167,"context_line":"@code{cortex_r4}, @code{aarch64} and @code{armv8r}), specify that the ROM table"},{"line_number":5168,"context_line":"parsing should select the CPU in position @var{coreid}."}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"9984fdfe_1d8f63d1","line":5165,"range":{"start_line":5165,"start_character":67,"end_line":5165,"end_character":82},"in_reply_to":"c7dfe97c_3b023958","updated":"2024-02-08 08:57:34.000000000","message":"Thanks for the review and for the hint. I didn\u0027t know about -dbgbase used for RISC-V too.\n\nThe name AP is used here following ARM specifications ADIv5 and ADIv6, which applies mainly to Cortex type CPUs.\nI don\u0027t see AP term applicable in RISC-V.\n\nLooking at the picture in\nhttps://five-embeddev.com/riscv-debug-spec/latest/overview.html#overview\nand comparing it with ARM ADIv5, the access port (AP) is comparable to the DMI access to the \u0027debug\u0027 bus between DMI and DM.\nARM allows to have multiple independent debug busses selected by the index ap-num in ADIv5. Each AP controls one of the debug busses, and several debug peripherals or controllers are placed on one debug bus. All the AP are accessible from the JTAG/SWD port (DAP).\nOn current RISC-V implementation there is a single bus between DMI and DM, equivalent to a single AP (maybe could change in future).\n\nOn the debug bus, both ARM ADIv5 and RISC-V address the debug controller through the address specified with -dbgbase.\nOn ARM, one debug controller controls a single CPU; -coreid is not used here.\nBut ARM provide a mechanism to scan the bus, so OpenOCD can detect all the debug controllers when -dbgbase is not specified, and -coreid was initially introduced to select the N\u0027th debug controller.\nRISC-V instead, beside the value -dbgbase, also needs the hart index. In this case -coreid works well too, no need to introduce a dedicated -hartid flag.","commit_id":"de9e12bc3df696b236161c319ebf82b81d2e1b80"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"cdc885e52dccfadcd3b5b21b9ed84ef853114263","unresolved":true,"context_lines":[{"line_number":5165,"context_line":"content or with ROM table partially not accessible due to clock gating or"},{"line_number":5166,"context_line":"power management."},{"line_number":5167,"context_line":""},{"line_number":5168,"context_line":"@item @code{-coreid} @var{coreid} -- set an index to identify the CPU or its"},{"line_number":5169,"context_line":"debug controller."},{"line_number":5170,"context_line":""},{"line_number":5171,"context_line":"@itemize @minus"}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"2d0602dc_17c8d039","line":5168,"updated":"2024-02-07 16:45:57.000000000","message":"I don\u0027t quite understand the definition.\nAm I correct that for ARM targets should always enumerate all the CPUs on a DAP?\nSo when is it used to enumerate debug controllers?","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"d95dec59ed45b6a185b6d6d5993c01489c3f1665","unresolved":false,"context_lines":[{"line_number":5165,"context_line":"content or with ROM table partially not accessible due to clock gating or"},{"line_number":5166,"context_line":"power management."},{"line_number":5167,"context_line":""},{"line_number":5168,"context_line":"@item @code{-coreid} @var{coreid} -- set an index to identify the CPU or its"},{"line_number":5169,"context_line":"debug controller."},{"line_number":5170,"context_line":""},{"line_number":5171,"context_line":"@itemize @minus"}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"808a2dda_8a797adb","line":5168,"in_reply_to":"15cbe775_c3418c73","updated":"2024-02-08 14:16:41.000000000","message":"Resolved","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6802cb0c446c5874f0b8c2f5b04b6b414f342388","unresolved":true,"context_lines":[{"line_number":5165,"context_line":"content or with ROM table partially not accessible due to clock gating or"},{"line_number":5166,"context_line":"power management."},{"line_number":5167,"context_line":""},{"line_number":5168,"context_line":"@item @code{-coreid} @var{coreid} -- set an index to identify the CPU or its"},{"line_number":5169,"context_line":"debug controller."},{"line_number":5170,"context_line":""},{"line_number":5171,"context_line":"@itemize @minus"}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"919aa144_9e941e4e","line":5168,"in_reply_to":"2d0602dc_17c8d039","updated":"2024-02-08 08:57:34.000000000","message":"As written above, when -dbgbase is NOT provided, OpenOCD uses ap-num to scan the bus behind the AP and selects the base address of the N\u0027th debug controller. The value \u0027N\u0027 is passed through -coreid.","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"217738d45cda821aafb8780fb68510b213f4ed74","unresolved":true,"context_lines":[{"line_number":5165,"context_line":"content or with ROM table partially not accessible due to clock gating or"},{"line_number":5166,"context_line":"power management."},{"line_number":5167,"context_line":""},{"line_number":5168,"context_line":"@item @code{-coreid} @var{coreid} -- set an index to identify the CPU or its"},{"line_number":5169,"context_line":"debug controller."},{"line_number":5170,"context_line":""},{"line_number":5171,"context_line":"@itemize @minus"}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"15cbe775_c3418c73","line":5168,"in_reply_to":"919aa144_9e941e4e","updated":"2024-02-08 14:15:28.000000000","message":"Sorry for my misunderstanding. I think I understand it now. Thank you for the great explanation!","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"cdc885e52dccfadcd3b5b21b9ed84ef853114263","unresolved":true,"context_lines":[{"line_number":5175,"context_line":"this option specifies that the ROM table parsing should select the CPU in"},{"line_number":5176,"context_line":"position @var{coreid}."},{"line_number":5177,"context_line":""},{"line_number":5178,"context_line":"@item On target type @code{riscv} with multiple hart (HARdware Threads), a"},{"line_number":5179,"context_line":"single debug unit controls more than one CPU; @var{coreid} specifies the"},{"line_number":5180,"context_line":"index of the CPU in the debug controller."},{"line_number":5181,"context_line":""}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"b9bd4798_845840d5","line":5178,"updated":"2024-02-07 16:45:57.000000000","message":"This is not necessarily the case. One can have multiple debug controllers (DMs), one per TAP, one per hart. In that case, there is no need for `coreid`. I would suggest to add an `if`:\n```\n@item On target type @code{riscv} with multiple harts (HARdware Threads), if a\n...\n```","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"217738d45cda821aafb8780fb68510b213f4ed74","unresolved":true,"context_lines":[{"line_number":5175,"context_line":"this option specifies that the ROM table parsing should select the CPU in"},{"line_number":5176,"context_line":"position @var{coreid}."},{"line_number":5177,"context_line":""},{"line_number":5178,"context_line":"@item On target type @code{riscv} with multiple hart (HARdware Threads), a"},{"line_number":5179,"context_line":"single debug unit controls more than one CPU; @var{coreid} specifies the"},{"line_number":5180,"context_line":"index of the CPU in the debug controller."},{"line_number":5181,"context_line":""}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"b225e0f9_4a68eb1d","line":5178,"in_reply_to":"8bc55292_c39ff4a6","updated":"2024-02-08 14:15:28.000000000","message":"Oh, I didn\u0027t think about this.\nHowever, RISC-V debug spec (3.3.1 Selecting a Single Hart)(regardless of the version) states the following:\n\u003e Hart indexes start at 0 and are contiguous until the final index.\n\nSo the single hart should be at index zero.","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"39abd97ebc1097def9126a8fd4791fb8df1551f9","unresolved":true,"context_lines":[{"line_number":5175,"context_line":"this option specifies that the ROM table parsing should select the CPU in"},{"line_number":5176,"context_line":"position @var{coreid}."},{"line_number":5177,"context_line":""},{"line_number":5178,"context_line":"@item On target type @code{riscv} with multiple hart (HARdware Threads), a"},{"line_number":5179,"context_line":"single debug unit controls more than one CPU; @var{coreid} specifies the"},{"line_number":5180,"context_line":"index of the CPU in the debug controller."},{"line_number":5181,"context_line":""}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"5b04d4f7_2d1cada8","line":5178,"in_reply_to":"b225e0f9_4a68eb1d","updated":"2024-02-18 17:37:36.000000000","message":"Independently from the RISC-V debug spec, a user could be interested at debugging only hart N and ignoring the hart\u0027s {0...N-1}. User can write an OpenOCD script with a single target for the hart N.\nOne of such example could be a 2 hart SoC where one runs the proprietary wireless stack and has debug disabled, while the second hart is available for user application.\nIf OpenOCD mandates that hartid must always start from 0, we could miss such corner cases.\nWhat about:\n```\n@item On target type @code{riscv}, @var{coreid} specifies the hart\n(HARdware Threads) on the DM (Debug Module). It is used on\nmulti-hart devices to index a specific hart ID.\nWhen not present, it\u0027s default value is zero.\n```","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6802cb0c446c5874f0b8c2f5b04b6b414f342388","unresolved":true,"context_lines":[{"line_number":5175,"context_line":"this option specifies that the ROM table parsing should select the CPU in"},{"line_number":5176,"context_line":"position @var{coreid}."},{"line_number":5177,"context_line":""},{"line_number":5178,"context_line":"@item On target type @code{riscv} with multiple hart (HARdware Threads), a"},{"line_number":5179,"context_line":"single debug unit controls more than one CPU; @var{coreid} specifies the"},{"line_number":5180,"context_line":"index of the CPU in the debug controller."},{"line_number":5181,"context_line":""}],"source_content_type":"text/x-texinfo","patch_set":2,"id":"8bc55292_c39ff4a6","line":5178,"in_reply_to":"b9bd4798_845840d5","updated":"2024-02-08 08:57:34.000000000","message":"Maybe it should be re-written as this?\n```\n@item On target type @code{riscv}, @var{coreid} specifies the hart\n(HARdware Threads) on the DM (Debug Module). It is used either on\nmulti-hart devices to index the hart, or on single-hart devices when\nthe hart is not placed at the default index zero.\n```","commit_id":"879fb24a6f84c3c88f7a7909aa6b2ae3185b9024"}]}