)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"5c58006f55171733d4c836a0daff34682fb1fa5f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"9b9286c5_0b976576","updated":"2021-11-14 07:35:28.000000000","message":"Antonio, I have another concern:\nGraham\u0027s #4935 puts multidrop targetsel to tap configuration. I believed that there is (or will be in a future ARM ADI versions) some use of targetsel in JTAG. However there in no clue of any use of targetsel value for JTAG in IHI0031F and C. You work with the new ADIv6. Can you confirm that we can move targetsel config to struct adiv5_dap and its setting to dap create?","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"a3a34de8c3ce6434428078f2b4478701f7661f02","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"74b1f8c4_c6b40e4a","updated":"2021-11-10 08:00:11.000000000","message":"Rebased to current master, mixed case names converted to lcase.\nNo code changes","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"7f8b1d7fcd6095ab80432e5c6502ffbcd73f64a3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f730a99c_ee5a6c6a","in_reply_to":"279fca7f_63443728","updated":"2021-11-14 17:09:08.000000000","message":"\u003e \u003e Maybe the logic should be that: whatever user set with -instance-id and -dp-id, openocd doesn\u0027t matter and uses standard SWD. Only if there are 2 or more SWD devices, then multidrop is required...\n\u003e \n\u003e It would be sort of limiting. User may want access only one target from a board where more devices are connected to a multidrop SWD bus. He just doesn\u0027t want to debug other devices or he even doesn\u0027t have OpenOCD configs for other devices.\n\nYou are right! We may want to use a single target in a multidrop \"board\"!\n\n\u003e Anyway we may need a \"main switch\" for multidrop to avoid unwanted effects caused by configuration. What about config only tcl command:\n\u003e \n\u003e   dap swd (single | multidrop)\n\nWhat about switching to multidrop when \"all\" the DAPs have -dp-id and -instance-id?\nThey are required also in the above case of single target in a multidrop board.\n\n- one target without -instance-id (-dp-id ignored) \u003d\u003d\u003e SWD\n- one target with -dp-id and -instance-id \u003d\u003d\u003e SWD multidrop\n- one target with -instance-id without -dp-id \u003d\u003d\u003e error\n- multiple targets all with -dp-id and -instance-id \u003d\u003d\u003e SWD multidrop\n- multiple targets with at least one missing -dp-id or -instance-id \u003d\u003d\u003e error\n\nFor me the SoC config file should only have -dp-id, if any, and -instance-id should either be in board file or command line.\nSpecial multi-SoC config, like stm32h7x.cfg, should require the -dp-id externally like for $CHIPNAME.\nI think we could avoid adding a new command, but in case I think it should be in the \"transport\" area, not in \"dap\".","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6a960a934fe148c30a75be190613a806cd80e702","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b2836b00_2f647ad7","in_reply_to":"9b9286c5_0b976576","updated":"2021-11-14 14:20:06.000000000","message":"On ADIv6 document, the description of TARGETSEL is practically a copy-paste from ADIv5 IHI0031F. The only difference is that in ADIv5 this register is implemented in DPv2 only, while for ADIv6 it is \"included in all implementations\".\nThey both report that accessing this register in JTAG is unpredictable.\nhttps://developer.arm.com/documentation/ihi0074/latest/\nIt must be set at DAP create, there is no other way to set it later, not to autodetect it.\n\nMaybe the logic should be that: whatever user set with -instance-id and -dp-id, openocd doesn\u0027t matter and uses standard SWD. Only if there are 2 or more SWD devices, then multidrop is required and -instance-id and -dp-id \"must\" be set on all devices.\nIn this way a config file can include these values, but them get used only in a multidrop connection.","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"f04f73acf789ea536ef161ebac7bbd88cfc84b05","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"279fca7f_63443728","in_reply_to":"b2836b00_2f647ad7","updated":"2021-11-14 16:02:02.000000000","message":"Thanks for reply!\n\n\u003e It must be set at DAP create, there is no other way to set it later, not to autodetect it.\n\nSo I\u0027ll move multidrop cfg from tap to dap.\n \n\u003e Maybe the logic should be that: whatever user set with -instance-id and -dp-id, openocd doesn\u0027t matter and uses standard SWD. Only if there are 2 or more SWD devices, then multidrop is required...\n\nIt would be sort of limiting. User may want access only one target from a board where more devices are connected to a multidrop SWD bus. He just doesn\u0027t want to debug other devices or he even doesn\u0027t have OpenOCD configs for other devices.\n\nAnd if the device is single on SWD lines and OpenOCD knows -dp-id and -instance-id there is very little difference whether multidrop or plain SWD is used for debugging.\n\nAnyway we may need a \"main switch\" for multidrop to avoid unwanted effects caused by configuration. What about config only tcl command:\n\n  dap swd (single | multidrop)\n\n?\nIn the default \u0027dap swd single\u0027 OpenOCD would ignore -dp-id and -instance-id\nand dap_check_config() would fail if more than one dap exists.\nWhen set to \u0027multidrop\u0027 dap_check_config() enures all daps have -dp-id (and eventually -instance-id) and there is no duplicity. Multidrop select takes place then no matter how many daps we have.\n\nAs a bonus it would allow -instance-id to be optional, defaulting to 0 - what makes sense at least for STM32H7/L5","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"52853082371b7749f7b4a2497967bd52eb9a2ece","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"dcd7e791_df076b7c","in_reply_to":"f730a99c_ee5a6c6a","updated":"2021-11-14 19:43:50.000000000","message":"\u003e \u003e   dap swd (single | multidrop)\n\u003e \n\u003e What about switching to multidrop when \"all\" the DAPs have -dp-id and -instance-id?\n\u003e They are required also in the above case of single target in a multidrop board.\n\u003e \n\u003e - one target without -instance-id (-dp-id ignored) \u003d\u003d\u003e SWD\n\u003e - one target with -dp-id and -instance-id \u003d\u003d\u003e SWD multidrop\n\u003e - one target with -instance-id without -dp-id \u003d\u003d\u003e error\n\u003e - multiple targets all with -dp-id and -instance-id \u003d\u003d\u003e SWD multidrop\n\u003e - multiple targets with at least one missing -dp-id or -instance-id \u003d\u003d\u003e error\n\nThis is almost exactly how the current patch works :)\n\n\u003e - one target with -instance-id without -dp-id \u003d\u003d\u003e error\n\nI\u0027m going to relax this check and run plain SWD. It will ease target config\nof devices with fixed ID instance.\n\n\u003e For me the SoC config file should only have -dp-id, if any, and -instance-id should either be in board file or command line.\n\nAgreed\n\n\u003e I think we could avoid adding a new command, but in case I think it should be in the \"transport\" area, not in \"dap\".\n\nYes, from the users point of view it belongs to transport (I thought about dap because it\u0027s all ARM ADI stuff).","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"abde3728c8864df139a5b351ac59e609f00c5c3b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0b781320_755317a9","updated":"2021-11-15 09:40:28.000000000","message":"Multidrop configuration moved to dap","commit_id":"06eecba6567dad96ec9c1af900631ff90f6bbc11"}],"src/jtag/tcl.c":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"1de94a70dadd4d7240b850dc7a43c9c4b87a6336","unresolved":true,"context_lines":[{"line_number":662,"context_line":"\t}\t/* while (goi-\u003eargc) */"},{"line_number":663,"context_line":""},{"line_number":664,"context_line":"\tif (instance_id_specified \u0026\u0026 !target_id_specified) {"},{"line_number":665,"context_line":"\t\tLOG_ERROR(\"%s: If -instance-id is set -dp-id must be specified\", tap-\u003edotted_name);"},{"line_number":666,"context_line":"\t\tfree(cp);"},{"line_number":667,"context_line":"\t\tfree(tap);"},{"line_number":668,"context_line":"\t\treturn JIM_ERR;"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"741fdf09_ee68aa95","line":665,"updated":"2021-11-12 21:37:05.000000000","message":"I have doubts on this!\nThe target DP_ID is fixed for all the SoC with the same P/N. It should be reported in tcl/target/whatever.cfg, as we do for the TAP_ID.\nThe instance ID is supposed to be programmed, through OTP, flash, external resistors, ... and must be provided outside the file tcl/target/whatever.cfg, either on command line or in the board file that lists the targets in multidrop.\nMaybe this check should be run when it\u0027s clear we want to use multidrop, not here at TAP declaration.","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"6e407a4b9c8220ddeee5c92bac18ce6074445d69","unresolved":true,"context_lines":[{"line_number":662,"context_line":"\t}\t/* while (goi-\u003eargc) */"},{"line_number":663,"context_line":""},{"line_number":664,"context_line":"\tif (instance_id_specified \u0026\u0026 !target_id_specified) {"},{"line_number":665,"context_line":"\t\tLOG_ERROR(\"%s: If -instance-id is set -dp-id must be specified\", tap-\u003edotted_name);"},{"line_number":666,"context_line":"\t\tfree(cp);"},{"line_number":667,"context_line":"\t\tfree(tap);"},{"line_number":668,"context_line":"\t\treturn JIM_ERR;"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"da8222c3_bdadb5dd","line":665,"in_reply_to":"741fdf09_ee68aa95","updated":"2021-11-13 06:46:05.000000000","message":"\u003e I have doubts on this!\n\nGood point. I remember I had similar feeling when I modified the Graham\u0027s code (this is the only test present in original 4935: swd: Add support for SWD multi-drop | https://review.openocd.org/c/openocd/+/4935\nI decided for easiest way, to leave it as is.\n\n\u003e The target DP_ID is fixed for all the SoC with the same P/N. It should be reported in tcl/target/whatever.cfg, as we do for the TAP_ID.\n\u003e The instance ID is supposed to be programmed, through OTP, flash, external resistors, ... and must be provided outside the file tcl/target/whatever.cfg, either on command line or in the board file that lists the targets in multidrop.\n\nUnfortunately it\u0027s not so easy. E.g. stm32h7x.cfg serves devices with 3 distinct DP_IDs, so we would have to create 3 new configs for stm32h72x/73x, stm32h74x/75x and stm32h7ax/7bx to provide DP_ID.\nI don\u0027t expect mass use of multidrop SWD. So at this stage creating per DP_ID configs seems me as an overkill.\nMy idea is that target cfg will look for MULTIDROP variable and if it exists, it is added as swj_newdap parameter. And board cfg sets MULTIDROP to contain both -instance-id and -dp-ip before sourcing target cfgs.\n\n\u003e Maybe this check should be run when it\u0027s clear we want to use multidrop, not here at TAP declaration.\n\nYes, we can do that. We just need to store -dp-id to tap in its own variable with possible invalid state. And check in dap init. I feel more comfortable to do it later, not before 0.12","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"8b0684b4a0f5a781cb3804bc4e2f7aa39e1f837d","unresolved":false,"context_lines":[{"line_number":662,"context_line":"\t}\t/* while (goi-\u003eargc) */"},{"line_number":663,"context_line":""},{"line_number":664,"context_line":"\tif (instance_id_specified \u0026\u0026 !target_id_specified) {"},{"line_number":665,"context_line":"\t\tLOG_ERROR(\"%s: If -instance-id is set -dp-id must be specified\", tap-\u003edotted_name);"},{"line_number":666,"context_line":"\t\tfree(cp);"},{"line_number":667,"context_line":"\t\tfree(tap);"},{"line_number":668,"context_line":"\t\treturn JIM_ERR;"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"2ef33df9_919240b7","line":665,"in_reply_to":"bc4ac644_b052fe17","updated":"2021-11-14 00:40:02.000000000","message":"Finally I understand how I mentioned this error:\nI somebody sets -instance-id only he most likely wants multidrop but it will not work without -dp-id. If target cfg sets -dp-id only, no error issued!\n\nUnfortunately there is bug: as soon as -dp-id is set, tap-\u003emultidrop_targetsel is no more DP_TARGETSEL_INVALID. Even without setting -instance-id the target gets selected as multidrop. Will submit fix","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"a1551ac75fbcea72de1b62ec19d37c91aed2ce8a","unresolved":false,"context_lines":[{"line_number":662,"context_line":"\t}\t/* while (goi-\u003eargc) */"},{"line_number":663,"context_line":""},{"line_number":664,"context_line":"\tif (instance_id_specified \u0026\u0026 !target_id_specified) {"},{"line_number":665,"context_line":"\t\tLOG_ERROR(\"%s: If -instance-id is set -dp-id must be specified\", tap-\u003edotted_name);"},{"line_number":666,"context_line":"\t\tfree(cp);"},{"line_number":667,"context_line":"\t\tfree(tap);"},{"line_number":668,"context_line":"\t\treturn JIM_ERR;"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"bc4ac644_b052fe17","line":665,"in_reply_to":"da8222c3_bdadb5dd","updated":"2021-11-13 09:41:25.000000000","message":"\u003e Unfortunately it\u0027s not so easy. E.g. stm32h7x.cfg serves devices with 3 distinct DP_IDs, so we would have to create 3 new configs for stm32h72x/73x, stm32h74x/75x and stm32h7ax/7bx to provide DP_ID.\n\nTrue, there are at least 3 different SoC STM32H7, with different ID, but in OpenOCD we use a single config file!\n\n\u003e \u003e Maybe this check should be run when it\u0027s clear we want to use multidrop, not here at TAP declaration.\n\u003e \n\u003e Yes, we can do that. We just need to store -dp-id to tap in its own variable with possible invalid state. And check in dap init. I feel more comfortable to do it later, not before 0.12\n\nOk! Let\u0027s get in merged and see later on how it evolves","commit_id":"a9b35572939c9fc639611d5722bfb6830a915c8a"}],"src/target/arm_dap.c":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"a3a1486458c2e680bc5777585201e0d6077c58b9","unresolved":false,"context_lines":[{"line_number":255,"context_line":"\t\t\t| ((instance_id \u003c\u003c DP_TARGETSEL_INSTANCEID_SHIFT) \u0026 DP_TARGETSEL_INSTANCEID_MASK);"},{"line_number":256,"context_line":"\telse"},{"line_number":257,"context_line":"\t\tdap-\u003edap.multidrop_targetsel \u003d DP_TARGETSEL_INVALID;"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"\treturn JIM_OK;"},{"line_number":260,"context_line":"}"},{"line_number":261,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":3,"id":"ed1b69cb_a71bd670","line":258,"updated":"2021-11-15 11:01:45.000000000","message":"ok. but a future evolution here would be to add \"configure\" and \"cget\" sub-commands to the dap. In that context the two parameters could be set in separate executions and this part would need rework too. Anyway, not to be addressed now.","commit_id":"06eecba6567dad96ec9c1af900631ff90f6bbc11"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"15a8cdb921020066819c26192e96d5e0a2bde992","unresolved":false,"context_lines":[{"line_number":255,"context_line":"\t\t\t| ((instance_id \u003c\u003c DP_TARGETSEL_INSTANCEID_SHIFT) \u0026 DP_TARGETSEL_INSTANCEID_MASK);"},{"line_number":256,"context_line":"\telse"},{"line_number":257,"context_line":"\t\tdap-\u003edap.multidrop_targetsel \u003d DP_TARGETSEL_INVALID;"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"\treturn JIM_OK;"},{"line_number":260,"context_line":"}"},{"line_number":261,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":3,"id":"83886e75_54b76a4b","line":258,"in_reply_to":"b9060b58_c623e858","updated":"2021-11-15 13:57:55.000000000","message":"dap configure, as target configure, is not for changing something after init but to split the configuration in 2 or more commands before init:\n1) in config file:\n   dap create my.dap ...\n2) on command line\n   my.dap configure -instance-id 3\n\nopenocd -f board/something.cfg -c \u0027my.dap configure -instance-id 3\u0027\n\nAgain, not to be addressed now.","commit_id":"06eecba6567dad96ec9c1af900631ff90f6bbc11"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"2f40679ecc68bbf2b3457d442b0ee89548d0b795","unresolved":false,"context_lines":[{"line_number":255,"context_line":"\t\t\t| ((instance_id \u003c\u003c DP_TARGETSEL_INSTANCEID_SHIFT) \u0026 DP_TARGETSEL_INSTANCEID_MASK);"},{"line_number":256,"context_line":"\telse"},{"line_number":257,"context_line":"\t\tdap-\u003edap.multidrop_targetsel \u003d DP_TARGETSEL_INVALID;"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"\treturn JIM_OK;"},{"line_number":260,"context_line":"}"},{"line_number":261,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":3,"id":"b9060b58_c623e858","line":258,"in_reply_to":"ed1b69cb_a71bd670","updated":"2021-11-15 13:21:49.000000000","message":"Actually I have a never-submitted version which keeps separate bool multidrop_dp_id_valid and multidrop_instance_id_valid in struct adiv5_dap.\nIt would suit better for stand-alone dap configure. But it would also require not to check multidrop config at creation time (when an error msg points to offending config file) but postpone it to dap_init_all() when the cfg context isn\u0027t available.\nLooking at current dap parameters I don\u0027t see much potential for dap configure: all parameters should stay fixed after init.","commit_id":"06eecba6567dad96ec9c1af900631ff90f6bbc11"}]}