)]}'
{"id":"openocd~master~I6f285e304d29cf291f13accfb030062b968cc714","project":"openocd","branch":"master","hashtags":[],"change_id":"I6f285e304d29cf291f13accfb030062b968cc714","subject":"swd: Add support for SWD multi-drop","status":"NEW","created":"2019-02-22 19:56:57.000000000","updated":"2022-02-11 18:55:48.000000000","submit_type":"CHERRY_PICK","mergeable":false,"submittable":false,"total_comment_count":6,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"0b81c5edc7d324e0f4cc71994ef04c0943d681ac","_number":4935,"owner":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"all":[{"date":"2021-04-15 20:29:57.000000000","_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},{"date":"2021-03-19 14:36:25.000000000","_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},{"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},{"date":"2021-03-19 14:24:23.000000000","_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},{"value":1,"date":"2021-03-19 14:27:27.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"}],"values":{"-1":"Fails"," 0":"No score","+1":"Verified"},"description":"","default_value":0},"Code-Review":{"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},{"value":0,"date":"2021-04-19 05:09:44.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"}],"values":{"-2":"This shall not be merged","-1":"I would prefer this is not merged as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"description":"","default_value":0}},"removable_reviewers":[],"reviewers":{"CC":[{"_account_id":1001876,"name":"Rene Kita","username":"rkta"}],"REVIEWER":[{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},{"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},{"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2019-02-24 12:08:40.000000000","updated_by":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"reviewer":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"state":"REVIEWER"},{"updated":"2019-05-15 14:55:48.000000000","updated_by":{"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},"reviewer":{"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},"state":"REVIEWER"},{"updated":"2019-06-07 09:53:15.000000000","updated_by":{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},"reviewer":{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},"state":"REVIEWER"},{"updated":"2020-07-15 09:33:27.000000000","updated_by":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"reviewer":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"state":"REVIEWER"},{"updated":"2021-03-19 14:24:23.000000000","updated_by":{"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},"reviewer":{"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},"state":"REVIEWER"},{"updated":"2021-03-19 14:27:27.000000000","updated_by":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"reviewer":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2021-03-19 14:36:25.000000000","updated_by":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"reviewer":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"state":"REVIEWER"},{"updated":"2021-04-19 05:09:44.000000000","updated_by":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"reviewer":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"state":"REVIEWER"},{"updated":"2022-02-11 18:55:48.000000000","updated_by":{"_account_id":1001876,"name":"Rene Kita","username":"rkta"},"reviewer":{"_account_id":1001876,"name":"Rene Kita","username":"rkta"},"state":"CC"}],"messages":[{"id":"88353a026abbd1ce57576d9eebeadae1db18b2d6","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-02-22 19:56:57.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"4d997eb6649324f3592aa5e5e40637e04910bc26","author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"real_author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"date":"2019-02-22 20:17:25.000000000","message":"Patch Set 1: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/11208/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/10550/ : SUCCESS","accounts_in_message":[],"_revision_number":1},{"id":"312e3b0115151f77ab4053b1f36c89f07344e757","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-02-23 15:42:04.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"268675ef0cae88f6e30061b8b446165ff3dfe49f","author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"real_author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"date":"2019-02-23 16:19:54.000000000","message":"Patch Set 2: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/11213/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/10555/ : SUCCESS","accounts_in_message":[],"_revision_number":2},{"id":"9e2a7c918e49f7eb1da9be99d231b088d2a3ce82","author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"real_author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"date":"2019-02-24 12:08:40.000000000","message":"Patch Set 2:\n\nWhat devices support SWD multi-drop? Can you please modify the commit message to ~72 chars per line? It is hard to read otherwise.","accounts_in_message":[],"_revision_number":2},{"id":"1ce2b12f41513a9105656bdbcb2add6bcbedafed","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-02-24 15:13:23.000000000","message":"Uploaded patch set 3: Commit message was updated.","accounts_in_message":[],"_revision_number":3},{"id":"973fa6b9da004bbfb6cbe476ebc7b9df8de47cd3","author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"real_author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"date":"2019-02-24 15:33:33.000000000","message":"Patch Set 3: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/11216/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/10558/ : SUCCESS","accounts_in_message":[],"_revision_number":3},{"id":"333c2f263ebd772ef76935ad12d72e9fea83a1d0","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-02-27 13:10:37.000000000","message":"Patch Set 3:\n\nThe one I have been using is currently undisclosed.","accounts_in_message":[],"_revision_number":3},{"id":"22a5fed71ddc06ced0954eec56bab9d7c24abfd0","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-03-12 15:19:29.000000000","message":"Patch Set 3:\n\nThat said, I would like to get feedback on this patch, so I can make changes, add documentation etc.","accounts_in_message":[],"_revision_number":3},{"id":"4b603296677c9abd390f08934a23e7d28e225571","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-03-13 23:55:37.000000000","message":"Patch Set 3:\n\n(1 comment)\n\nI have some concern about this proposal, but I have to admit I did not entered in the details. Please feel free to complain if I missed something.\nMulti-drop, specified by ARM for DPv2, is somehow the equivalent in SWD for the device-chain in JTAG:\n- in JTAG several devices can be connected in a single chain and identified/selected by their position in the chain;\n- in SWD multi-drop several devices can be connected to the same SWD bus and selected by a unique DP_TARGETSEL.\nI would expect that an implementation of multi-drop should reuse the same code of JTAG:\n- each device is on a separated DAP;\n- when using a target, it automatically uses the DAP it is belongs to.\n\nIn this implementation, instead, there is a new transport, which doesn\u0027t seams to me really needed.\nPlus, \"coreid\" is already used to select the core in a SMP node, cores that are supposed to be inside a single DAP. Doesn\u0027t seams correct reusing \"coreid\" for selecting a DAP in a multi-drop configuration.\nThe selection should be at DAP level, not at target. Multi-drop has to select a DAP (which can contain several targets).\nFor me the extra field should be in the DAP configuration, beside expected-id.\n\nI investigated how I could test this change. I share here, maybe somebody else is interested.\nWe need devices with DPv2.\nFrom ST documentation seams present only in STM32H7, STM32F7, STM32L5 and STM32MP1; all other STM32 are not compatible.\nOther vendors to be checked.\n\nThen we need to be able to select one of the N devices on the SWD. From what I read on ST documentation, the field DP_DLPIDR.TINSTANCE is not programmable on their devices, so two devices of the same family (e.g. two STM32L5) cannot be discriminated and cannot be used in the same multi-drop connection.\nOnly way to test multi-drop with ST devices is to use to different DP_TARGETID, e.g. one STM32L5 together with one STM32F7.\n\nActually I miss a second DPv2 device for this test. I will look for it...","accounts_in_message":[],"_revision_number":3},{"id":"1d27577dfe40d7798fb3b45ccf3d7f3b7aea8b55","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-03-19 13:07:29.000000000","message":"Patch Set 3:\n\nThanks for the detailed comments. It is certainly possible I have the abstraction wrong, as I’m no expert on the domain or the openocd code. I tried to make informed decisions though based on existing code history and the ARM docs.\n\n* w.r.t using a separate “transport” for SWD multidrop: JTAG, SWD, and SWD can coexist, but whilst SWD protocol v2 is nominally backward compatible, the need to leave dormant state, and the extra work of selecting targets seemed to suggest making the user explicitly choose. Perhaps it is possible to combine the two still, but I was erring on the side of caution initially as I didn’t have a non multidrop device.\n\n* w.r.t. DAP: terminology is a bit confusing, as openocd has both “newdap” and “dap create” as of recent changes http://openocd.zylin.com/#/c/4468/\n\nThis is an exerpt my config (My device is a microcontroller with two cortex-m cores accessed via SWD multidrop)\n\nswd newdap $_CHIPNAME cpu -expected-id $_CPUTAPID\n\n #core 0\n set _TARGETNAME_0 $_CHIPNAME.core0\n dap create $_TARGETNAME_0.dap -chain-position $_CHIPNAME.cpu\n target create $_TARGETNAME_0 cortex_m -endian $_ENDIAN -coreid 0 -dap $_TARGETNAME_0.dap -rtos hwthread\n $_TARGETNAME_0 configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0\n\n #core 1\n set _TARGETNAME_1 $_CHIPNAME.core1\n dap create $_TARGETNAME_1.dap -chain-position $_CHIPNAME.cpu\n target create $_TARGETNAME_1 cortex_m -endian $_ENDIAN -coreid 1 -dap $_TARGETNAME_1.dap -rtos hwthread\n\ni.e., I have one DAP (equivalent of JTAG TAP - at least in the code) and then one dap (struct adiv5_dap) per core.\n\n\u003e The selection should be at DAP level, not at target. Multi-drop has to select a DAP (which can contain several targets).\n\nmultidrop selects a (struct adiv5_dap) dap (one DP and one or more APs); the DAP (swd newdap) may have multiple targets (each with one dap)\n\n* w.r.t. cored: yeah - I thought I had commented on this in the commit, but apparently not. In general I wanted feedback on the config because I didn’t know what else used multidrop… in my case the target’s coreid matches, but its not clear this is always true. The TARGETSEL value is combined from the instance id and the IDCODE. The latter is coming from the target today. Perhaps both should be explicitly specified on the “dap create”, however at that point perhaps this gets more confusing than helpful. I haven’t played with enough devices to know when expected-id may have multiple values etc. As I say for my purposes the core-id worked well as an instance id, so we should definitely at least decide that is indeed incorrect in general.\n\n* w.r.t. to the implementation in general: one thing perhaps peculiar to the SWD multidrop is that targetsel based switching existing at the SWD level not below it, which makes the doing it at the driver level undesirable. (I’m not sure anyone was suggesting this, but I haven’t studied the JTAG code in detail to know if it does). I did however consider a bunch o different places to handle the multiplexing of many logical connections to one physical connections, and this seemed most appropriate.\n\n* w.r.t. unrelated code change: Yes I will move this to another patch - actually there was more than one, and I had just fixed the one for core-id in passing!","accounts_in_message":[],"_revision_number":3},{"id":"34a4cc2ec613fcd98c1bb7fe7c203de134c39a3b","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-03-19 17:56:27.000000000","message":"Patch Set 3:\n\nIf you focus at SWD only then, yes, there is some redundancy in the script syntax.\nSo let\u0027s start looking at JTAG, then move to SWD.\n\nIn JTAG you can have several TAPs in a chain, and not all of them are connected to an ARM DAP. E.g. you can have non-ARM based chips, or TAP for boundary scan, and so on.\nThis first part on the JTAG chain is described with a set of commands\n    jtag newtap \u003ctap-name\u003e tap \u003cparameters\u003e\nor the macro equivalent (but formally correct for SWJ-DPs only)\n    swj_newdap \u003ctap-name\u003e tap \u003cparameters\u003e\nThen, if one or more TAP has an associated DAP, these are described by specifying with \"-chain-position\" which TAP contains this DAP\n    dap create \u003cdap-name\u003e -chain-position \u003ctap-name\u003e.tap \u003cparameters\u003e\nAt last, targets are connected to their DAP\n    target create \u003ctarget-name\u003e \u003ctarget-type\u003e -dap \u003cdap-name\u003e \u003cparameters\u003e\n\nOpenOCD try to keep the same organization for SWD, but in this case we suppose to have a single TAP associated with a single DAP.\nMaybe looks a little redundant, but here it is:\n    swd newdap \u003ctap-name\u003e tap \u003cparameters\u003e; # parameters ignored, can use macro swj_newdap\n    dap create \u003cdap-name\u003e -chain-position \u003ctap-name\u003e.tap \u003cparameters\u003e\n    target create \u003ctarget-name\u003e \u003ctarget-type\u003e -dap \u003cdap-name\u003e \u003cparameters\u003e\nToday the struct jtag_tap is not used in SWD case.\nIf you define several TAPs, OpenOCD does not complain, but also doesn\u0027t really manage them.\n\n\nNow, what I see as a clean implementation for SWD multi-drop (but again, don\u0027t consider this as written in stone).\nIt is similar to the case of two chips in a single JTAG chain.\nThe two DAP in the multi-drop should have associated a TAP each, so it should be:\n    swj_newdap \u003ctap1-name\u003e tap \u003cparameters\u003e \u003cextra-param-for-DAP-select\u003e\n    swj_newdap \u003ctap2-name\u003e tap \u003cparameters\u003e \u003cextra-param-for-DAP-select\u003e\n    dap create \u003cdap1-name\u003e -chain-position \u003ctap1-name\u003e.tap \u003cparameters\u003e\n    dap create \u003cdap2-name\u003e -chain-position \u003ctap2-name\u003e.tap \u003cparameters\u003e\n    target create \u003ctarget1-name\u003e \u003ctarget-type\u003e -dap \u003cdap1-name\u003e \u003cparameters\u003e\n    target create \u003ctarget2-name\u003e \u003ctarget-type\u003e -dap \u003cdap2-name\u003e \u003cparameters\u003e\n\nThe code should detect that there are two or more TAP and only in this case it should use the dormant mode on the TAP not used.\nEvery time a target is accessed it refers to its DAP. To access the DAP, OpenOCD should first check which is the last DAP used, eventually put it in dormant and turn on the right one, then access the target.\nThis would be backward compatible with the current single DAP SWD mode.\n\nComments are welcome\n\nSide story, I am surprised you will have multi-drop implemented inside a single chip. Multi-drop seams specified for board selection.\nNormally two cores are on separate AP of the same DAP.\nOpenOCD does a periodical poll on all the cores. Polling two cores on the same DAP is trivial. Polling cores in multi-drop DAPs require putting the DAPs alternatively in dormant mode, which is a long sequence...\nMaybe your chip is a \"multi-chip in a single package\", and there were no better alternatives.\nAnyway, this is not an important point.","accounts_in_message":[],"_revision_number":3},{"id":"f1f86e2aa62a0ecb2d30ed23b21c4912525aeb27","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-03-20 00:50:02.000000000","message":"Patch Set 3:\n\n\u003e Now, what I see as a clean implementation for SWD multi-drop (but\n \u003e again, don\u0027t consider this as written in stone).\n \u003e It is similar to the case of two chips in a single JTAG chain.\n \u003e The two DAP in the multi-drop should have associated a TAP each, so\n \u003e it should be:\n \u003e swj_newdap \u003ctap1-name\u003e tap \u003cparameters\u003e \u003cextra-param-for-DAP-select\u003e\n \u003e swj_newdap \u003ctap2-name\u003e tap \u003cparameters\u003e \u003cextra-param-for-DAP-select\u003e\n \u003e dap create \u003cdap1-name\u003e -chain-position \u003ctap1-name\u003e.tap \u003cparameters\u003e\n \u003e dap create \u003cdap2-name\u003e -chain-position \u003ctap2-name\u003e.tap \u003cparameters\u003e\n \u003e target create \u003ctarget1-name\u003e \u003ctarget-type\u003e -dap \u003cdap1-name\u003e\n \u003e \u003cparameters\u003e\n \u003e target create \u003ctarget2-name\u003e \u003ctarget-type\u003e -dap \u003cdap2-name\u003e\n \u003e \u003cparameters\u003e\n \u003e \n\nOK - I\u0027ll try an extra swj_newdap and see how that looks\n\n \u003e The code should detect that there are two or more TAP and only in\n \u003e this case it should use the dormant mode on the TAP not used.\n \u003e Every time a target is accessed it refers to its DAP. To access the\n \u003e DAP, OpenOCD should first check which is the last DAP used,\n \u003e eventually put it in dormant and turn on the right one, then access\n \u003e the target.\n \u003e This would be backward compatible with the current single DAP SWD\n \u003e mode.\nThe only things this misses is the ability to configure only one core out of many (perhaps just disabling one is ok) - not sure how useful this is anyway\n \u003e \n \u003e Side story, I am surprised you will have multi-drop implemented\n \u003e inside a single chip. Multi-drop seams specified for board\n \u003e selection.\n \u003e Normally two cores are on separate AP of the same DAP.\n \u003e OpenOCD does a periodical poll on all the cores. Polling two cores\n \u003e on the same DAP is trivial. Polling cores in multi-drop DAPs\n \u003e require putting the DAPs alternatively in dormant mode, which is a\n \u003e long sequence...\n \u003e Maybe your chip is a \"multi-chip in a single package\", and there\n \u003e were no better alternatives.\n \nYeah it falls into this category, I wasn\u0027t involved at that stage tho, so I don\u0027t know much about any tradeoffs.\n\nw.r.t. dormant, right now I am not switching back to dormant mode between selecting DAPs... (this is suggested by the spec, but seemed like\nSomething we’d at least want the ability to configure to off - right now there is a static const Boolean variable!)","accounts_in_message":[],"_revision_number":3},{"id":"6d107c01751fed7965e8914034943428cfc4fca9","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-03-20 08:30:56.000000000","message":"Patch Set 3:\n\n\u003e The only things this misses is the ability to configure only one\n \u003e core out of many (perhaps just disabling one is ok) - not sure how\n \u003e useful this is anyway\n\nUseful, for sure!\nRequired if you want to describe only one element in your config file, element that is within a complex multi-drop implementation.\n\nHere we need to separate at least two cases:\n\na) select only one core, but describe the whole multi-drop system (e.g. two TAP, two DAP, only one target in one of the two DAP). In this case the multi-drop is fully described and accessing the target means enabling the TAP+DAP where the core is attached, keep dormant the other one(s).\n\nb) describe only the TAP+DAP where the core is connected. To tell OpenOCD that it has to use multi-drop (put everything in dormant apart the good one) it should be enough to specify the extra parameter for multi-drop in swj_newdap. Value that is anyway needed for the selection. Maybe it could be named \"-multi-drop-sel\" and we pass a hex number that specifies the extra value for selection.\nThis should work also when the device is physically alone and multi drop is not necessary at all.\n\n \u003e w.r.t. dormant, right now I am not switching back to dormant mode\n \u003e between selecting DAPs... (this is suggested by the spec, but\n \u003e seemed like\n \u003e Something we’d at least want the ability to configure to off -\n \u003e right now there is a static const Boolean variable!)\n\nI\u0027m not sure I catch what you mean.\nMy understanding is that there is no need to put back \"all\" the DAPs in dormant if you do not use them. So it is ok to keep one enable.\nOnly when you need to switch to a new DAP you have to put all in dormant and select the one you plan to use.\nDo you mean you do not put all in dormant but switch from one DAP to another just by selecting the new one? Surprising it works, but I do not have any experience in this.","accounts_in_message":[],"_revision_number":3},{"id":"abe7d56a3589a40bc677531430d06e46c776c652","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-03-20 13:38:12.000000000","message":"Patch Set 3:\n\n\u003e Useful, for sure!\n \u003e Required if you want to describe only one element in your config\n \u003e file, element that is within a complex multi-drop implementation.\n \u003e \n \u003e Here we need to separate at least two cases:\n \u003e \n \u003e a) select only one core, but describe the whole multi-drop system\n \u003e (e.g. two TAP, two DAP, only one target in one of the two DAP). In\n \u003e this case the multi-drop is fully described and accessing the\n \u003e target means enabling the TAP+DAP where the core is attached, keep\n \u003e dormant the other one(s).\n \u003e \n \u003e b) describe only the TAP+DAP where the core is connected. To tell\n \u003e OpenOCD that it has to use multi-drop (put everything in dormant\n \u003e apart the good one) it should be enough to specify the extra\n \u003e parameter for multi-drop in swj_newdap. Value that is anyway needed\n \u003e for the selection. Maybe it could be named \"-multi-drop-sel\" and we\n \u003e pass a hex number that specifies the extra value for selection.\n \u003e This should work also when the device is physically alone and multi\n \u003e drop is not necessary at all.\n \u003e \nThis all makes sense, thx.\n \u003e \u003e w.r.t. dormant, right now I am not switching back to dormant mode\n \u003e \u003e between selecting DAPs... (this is suggested by the spec, but\n \u003e \u003e seemed like\n \u003e \u003e Something we’d at least want the ability to configure to off -\n \u003e \u003e right now there is a static const Boolean variable!)\n \u003e \n \u003e I\u0027m not sure I catch what you mean.\n \u003e My understanding is that there is no need to put back \"all\" the\n \u003e DAPs in dormant if you do not use them. So it is ok to keep one\n \u003e enable.\nSorry, I misspoke; I was thinking of deselecting all targets... the spec says \"Writing any other value deselects the target. Debug tools must write 0xFFFFFFFF to deselect all targets. This is an invalid TARGETID value. It is unclear when you might want to do this as any line reset should deselect the target (perhaps it doesn\u0027t I can check - again the spec is a little vague see section 4.4.3 in ADIv5).\n \u003e Only when you need to switch to a new DAP you have to put all in\n \u003e dormant and select the one you plan to use.\n \u003e Do you mean you do not put all in dormant but switch from one DAP\n \u003e to another just by selecting the new one? Surprising it works, but\n \u003e I do not have any experience in this.\nI myself am a bit confused by this (and it goes back to the multiple swj_newdap issue). A switch to dormant would deselect anything on the wire that understanding it. This is required b4 communicating with JTAG or perhaps non v2 SWD on the same wire. Is this something that is done within the scope of OpenOCD given that you have transport select?\n\nTARGETSEL is the only selection mechanism. If this is what you mean by \"switch from one DAP to another\" then there is no need for dormant state. If you mean more what I said in the previous paragraph, then that is OK I guess, but would suggest to me that in my use case I wouldn\u0027t want more than one swj_newdap DAP.","accounts_in_message":[],"_revision_number":3},{"id":"2682744edaf66b04868836c8bca478670cd79384","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-03-20 16:42:29.000000000","message":"Patch Set 3:\n\nGraham, I went back reading the ARM spec. You are right, no need to go in dormant to switch between DAPs. It\u0027s enough selecting the new DAP, and this will automatically deselect the previous one.\nSorry for the confusion.\nThis also means fast switch between DAPs when OpenOCD polls all the targets.","accounts_in_message":[],"_revision_number":3},{"id":"c021c22fcbca6b4191ba4967387746dba4ca42e6","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-03-22 17:12:50.000000000","message":"Patch Set 3:\n\n\u003e This also means fast switch between DAPs when OpenOCD polls all the\n \u003e targets.\n\nIndeed... that is how it is currently running.\n\nI will make the changes suggested so far in terms of DAP topology and removing the separate transport.\n\nI think you had alluded to maybe sharing some code with JTAG in terms of switching. I will have to investigate this given that JTAG appears to allow targeting of packets rather than a stateful ownership of the wire.\n\nThat said, I do have a question which requires more domain expertise than I have... Is there a reason not to queue commands at the adi5_v5_swd level until run for both multidrop and non multidrop. I see what appears to be a lot of somehwat-duplication at the swd_driver implementation level around queueing, however I do understand the need there to make sure that adjacent commands are indeed adjacent on the wire.","accounts_in_message":[],"_revision_number":3},{"id":"8a9657a11bc50f6ad094d077b8326ad7d4971b08","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-12 00:10:49.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"ef00c5c2c1082adb0939ea7aabaf8c10866bfa00","author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"real_author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"date":"2019-05-12 00:30:47.000000000","message":"Patch Set 4: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/11700/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/11016/ : SUCCESS","accounts_in_message":[],"_revision_number":4},{"id":"b4453a406183f2dac214a672a0671d087fa0c28e","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-12 03:13:06.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"442a29025d254238e7db6d019dd3b83b733056b4","author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"real_author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"date":"2019-05-12 03:32:41.000000000","message":"Patch Set 5: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/11701/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/11017/ : SUCCESS","accounts_in_message":[],"_revision_number":5},{"id":"10b4026efdc18dbec27f81737f464e0c595c1714","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-05-13 21:06:07.000000000","message":"Patch Set 5:\n\nGraham, questions about the queuing mechanism in this patch.\nIs queuing mandatory for the SWD multi-drop?\nCan be re-used for the normal SWD (without multi-drop)?","accounts_in_message":[],"_revision_number":5},{"id":"0217c2ee65aeee52fa892473f4bda09613b83e2b","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-13 21:39:32.000000000","message":"Patch Set 5:\n\n\u003e Graham, questions about the queuing mechanism in this patch.\n \u003e Is queuing mandatory for the SWD multi-drop?\n\nYes; we need to queue because switching the active DAP includes a line reset, so you\u0027d lose state from previous DP/AP cmds\n\n \u003e Can be re-used for the normal SWD (without multi-drop)?\n\nYes... I was hoping to re-use it perhaps in place of all the disparate queuing in the SWD driver layer, howver the latter is there to keep the bits next to eachother on the wire, and works to batch commands together. Perhaps the two concerns can be combined (i.e. we always send a command batch which is placed in a single bit stream onto the \"wire\") but I didn\u0027t feel I had enough context to know whether this was a good idea.","accounts_in_message":[],"_revision_number":5},{"id":"6f56f0ac4e6133da153d14d7b362faec56e71cac","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-13 21:52:28.000000000","message":"Patch Set 5:\n\nI will say I\u0027m not 100% sure it is needed now i think about it :-)\n\nI\u0027ll try without!","accounts_in_message":[],"_revision_number":5},{"id":"d887088d62aa91517c9492e360fd0a77d96c127e","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-13 21:55:20.000000000","message":"Patch Set 5:\n\n\u003e I will say I\u0027m not 100% sure it is needed now i think about it :-)\n \u003e \n \u003e I\u0027ll try without!\n\nWhat am i talking about; sorry it\u0027s been a long time since I wrote this code! The problem without queuing aside from line reset is that the driver would end up intermingling commands for different targets. The only way to do that safely would be to push the multidrop coordination down into each driver. The way I did it seems a lot simpler and safer","accounts_in_message":[],"_revision_number":5},{"id":"0b3e45cf21873cc3987f70116681117318b4069c","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-05-14 10:37:38.000000000","message":"Patch Set 5:\n\nI\u0027m not sure I got the point.\nToday\u0027s SWD implementation does not queue, but \"pipelines\" the read.\nEvery sequence of read/write should be terminated by a dap_run().\nOf course there could be some error in the code and dap_run() get miss somewhere.\nIt would be interesting to catch and fix such error.\n\nAt the same time, in your code, to guarantee there is nothing pending on the old DAP, should be enough to call dap_run() before switching DAP.\n\nPersonally I\u0027m interested in adding a queue mechanism in SWD to improve commit http://openocd.zylin.com/4484 but I\u0027m willing to understand if queue is really needed by multi-drop.","accounts_in_message":[],"_revision_number":5},{"id":"4fa2f2463a45c31e276049a42ca29a4675dba672","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-14 12:14:38.000000000","message":"Patch Set 5:\n\n\u003e I\u0027m not sure I got the point.\n \u003e Today\u0027s SWD implementation does not queue, but \"pipelines\" the\n \u003e read.\n \u003e Every sequence of read/write should be terminated by a dap_run().\n \u003e Of course there could be some error in the code and dap_run() get\n \u003e miss somewhere.\n \u003e It would be interesting to catch and fix such error.\n \u003e \n \u003e At the same time, in your code, to guarantee there is nothing\n \u003e pending on the old DAP, should be enough to call dap_run() before\n \u003e switching DAP.\n \u003e \n \u003e Personally I\u0027m interested in adding a queue mechanism in SWD to\n \u003e improve commit http://openocd.zylin.com/4484 but I\u0027m willing to\n \u003e understand if queue is really needed by multi-drop.\n\nI suspect you are right, flushing is probably sufficient (absent anything which doesn\u0027t call dap_run() where necessary).\n\nI can try taking it out, though as discussed there may be reasons to keep it here anyway; what do you think?","accounts_in_message":[],"_revision_number":5},{"id":"85e21f2f988670259f68c85db4d5bc69d96ff24d","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-14 15:48:18.000000000","message":"Patch Set 5:\n\nNote also on further recollection, I decided to queue based on the fact that dap_ops is public and does not currently indicate that run must be called immediately; indeed it specifies the opposite\n\n/**\n * Transport-neutral representation of queued DAP transactions, supporting\n * both JTAG and SWD transports.  All submitted transactions are logically\n * queued, until the queue is executed by run().  Some implementations might\n * execute transactions as soon as they\u0027re submitted, but no status is made\n * available until run().\n */","accounts_in_message":[],"_revision_number":5},{"id":"e0fdb5d75982cf6ff970fe49d1721712fd1fb071","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2019-05-14 16:21:51.000000000","message":"Patch Set 5:\n\nTrue, but current SWD code does not queue the transactions (so comment is incorrect).\nAnd your code adds the queue only in SWD multi-drop, keeping SWD as is today.\n\nI\u0027m just trying to understand if splitting this patch in queue + multi-drop can give some benefit.\nI\u0027m not asking you to do any rework right away, just trying to understand if it can make sense.\nFor sure a split would make this code easier to review.\nThen we could get queue for SWD too.\nAnd maybe SWD with and without multi-drop could be better merged.\n\nI\u0027m still trying to have a setup to test the multi-drop connection between two SWD devices.","accounts_in_message":[],"_revision_number":5},{"id":"0bcd68149401edba1002791bf4190347a247a29a","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-14 18:26:31.000000000","message":"Patch Set 5:\n\nwell there is (or at least maybe - I didn\u0027t check them all) queuing at the swd_driver level pending a run() at that level (seems to be very driver specific though, and sometimes limited).\n\nIt is pretty trivial to add queuing to both multidrop and non multidrop, so let me know.","accounts_in_message":[],"_revision_number":5},{"id":"aad305a48f8806c106120569ddaaf1c7ede001ce","author":{"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},"real_author":{"_account_id":1001013,"name":"Matthias Welwarsky","email":"matthias@welwarsky.de","username":"thinkfat"},"date":"2019-05-15 14:55:48.000000000","message":"Patch Set 5:\n\nQueuing for SWD would allow implementing WAIT support in the same fashion as for JTAG. Right now we have WAIT support only with high-level adapters and CMSIS-DAP.","accounts_in_message":[],"_revision_number":5},{"id":"d052702fe0f664cf2ce854142e555be0c1db622f","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-05-16 17:53:12.000000000","message":"Patch Set 5:\n\n\u003e Queuing for SWD would allow implementing WAIT support in the same\n \u003e fashion as for JTAG. Right now we have WAIT support only with\n \u003e high-level adapters and CMSIS-DAP.\n\nI can split this defect into a queuing one and a multidrop one if that is helpful, or we can factor it out later","accounts_in_message":[],"_revision_number":5},{"id":"c3a5109875ecbc37bae6bac11b479cc1e982d547","author":{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},"real_author":{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},"date":"2019-06-07 09:53:15.000000000","message":"Patch Set 5:\n\nI don\u0027t know about this queuing thing. A major feature and design goal of the SWD API was to NOT have a queue in the path between target code and the driver.\n\nI wouldn\u0027t look at the JTAG queue as a model of good architecture. Granted, a queue makes it easier to implement replay after WAIT but even that is a sign that it doesn\u0027t belong above the driver layer. Some adapters handle WAIT internally, e.g. CMSIS-DAP, and passing all data to that driver through a queue is just an obstacle. A GPIO bitbanging adapter driver has zero need for a queue in all cases.\n\nThe idea was that drivers that do need queuing for performance and that should support WAIT or other conditions that require replay, a generic SWD queue helper could be added. As a service to the drivers, not as the interface to it.","accounts_in_message":[],"_revision_number":5},{"id":"626d39fa1de47918bbb411b30f76cc1a597632d8","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2019-06-10 12:51:35.000000000","message":"Patch Set 5:\n\n\u003e I don\u0027t know about this queuing thing. A major feature and design\n \u003e goal of the SWD API was to NOT have a queue in the path between\n \u003e target code and the driver.\n \u003e \n \u003e I wouldn\u0027t look at the JTAG queue as a model of good architecture.\n \u003e Granted, a queue makes it easier to implement replay after WAIT but\n \u003e even that is a sign that it doesn\u0027t belong above the driver layer.\n \u003e Some adapters handle WAIT internally, e.g. CMSIS-DAP, and passing\n \u003e all data to that driver through a queue is just an obstacle. A GPIO\n \u003e bitbanging adapter driver has zero need for a queue in all cases.\n \u003e \n \u003e The idea was that drivers that do need queuing for performance and\n \u003e that should support WAIT or other conditions that require replay, a\n \u003e generic SWD queue helper could be added. As a service to the\n \u003e drivers, not as the interface to it.\n\nOK... it sounds like we should probably not pile on queuing use cases into this issue.... can we get an up/down vote on this issue as is?","accounts_in_message":[],"_revision_number":5},{"id":"839972ca85c4932b61e48db53834bd53ddbc5e2e","author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"real_author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"date":"2021-03-19 13:54:20.000000000","message":"Uploaded patch set 6.","accounts_in_message":[],"_revision_number":6},{"id":"a3e5c186d1a21dd28ca99e45a644c6fef194cceb","author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"real_author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"date":"2021-03-19 13:56:46.000000000","message":"Patch Set 6:\n\nI rebased the patch to 0.11 master","accounts_in_message":[],"_revision_number":6},{"id":"c97e22bdceea8b6adc620a9a702bda67d5840c5e","author":{"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},"real_author":{"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},"date":"2021-03-19 14:24:23.000000000","message":"Patch Set 6:\n\nTomas, apart of code review, how we can test the change ?\n\ncould it be tested with one single core MCU having the multidrop feature ?\n\nAFAICT, this change was mainly for RP2040 having two symmetric M0+ cores (for instance we debug STM32H7 multicore using SWD without the need of the multidrop)\n\ndo you think that I can chain two MCUs with multi-drop to test this feature ?","accounts_in_message":[],"_revision_number":6},{"id":"82fccee93c4261e38fa1d6bceb4f3e245f3b4cca","author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"real_author":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"date":"2021-03-19 14:27:27.000000000","message":"Patch Set 6: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/14211/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/13473/ : SUCCESS","accounts_in_message":[],"_revision_number":6},{"id":"20ed7ac2d076a685063f6b01871a875e508aed6d","author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"real_author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"date":"2021-03-19 14:36:25.000000000","message":"Patch Set 6:\n\n\u003e Tomas, apart of code review, how we can test the change ?\n \u003e \n \u003e could it be tested with one single core MCU having the multidrop\n \u003e feature ?\n \u003e \n \u003e AFAICT, this change was mainly for RP2040 having two symmetric M0+\n \u003e cores (for instance we debug STM32H7 multicore using SWD without\n \u003e the need of the multidrop)\n \u003e \n \u003e do you think that I can chain two MCUs with multi-drop to test this\n \u003e feature ?\n\nTarek, check my comment on patch series 3\nYou can put in parallel (not in chain) one STM32H7 and one L5 or one MP1. Not two devices of the same family","accounts_in_message":[],"_revision_number":6},{"id":"da553a821c6e69e5813682d84549a916a0a0a076","author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"real_author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"date":"2021-03-19 14:43:01.000000000","message":"Patch Set 6:\n\n(5 comments)\n\nI played a little bit with STM32H745 and STM32H7A3 on multidrop SWD.\nAfter adding JTAG_TO_DORMANT works as expected.\nTested on ftdi and after some changes it also works on CMSIS-DAP.\nAs the next step I\u0027ll try to remove queuing.","accounts_in_message":[],"_revision_number":6},{"id":"702abadf66a56f604b16074511be6332c97229b3","author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"real_author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"date":"2021-03-20 10:40:05.000000000","message":"Patch Set 6:\n\nI tested swd multidrop operation without queuing and add some logs.\nIt looks like it works very similar way as it does with the queue.\n\nHere are statistics after manually dumping memory from both chips, halting and resuming one core from each chip and getting flash info:\n\nWith q:\nInfo : Target polls 471\nInfo : Multidrop switches: 920\n\nw/o q:\nInfo : Target polls 460\nInfo : Multidrop switches: 898\n\nEach target poll needs 2 switches, so number of switches converges to 2*polls.\n\nDropping the queue makes the multidrop support much simpler and much closer to single swd operation, so I prefer going this way.","accounts_in_message":[],"_revision_number":6},{"id":"42639f706aec8df7feed604f5dc78f1cd2f0a6ae","author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"real_author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"date":"2021-04-07 08:52:49.000000000","message":"Patch Set 6:\n\nGraham, I reworked your SWD multidrop code to run without additional queueing. Please see http://openocd.zylin.com/6141 and related. A review would be highly appreciated.\n\nI have not extracted ftdi driver changes as they don\u0027t need any rework. Please, could you resubmit them in a separate patch? I recommend to include just multidrop related changes, not the \"Defensive cleanup\" which is unrelated and should go into another patch.\n\nThanks","accounts_in_message":[],"_revision_number":6},{"id":"23c299cbd8ee6c98bde4c1036d511fea7d140c7f","author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"real_author":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"date":"2021-04-15 20:29:57.000000000","message":"Patch Set 6:\n\n\u003e Graham, I reworked your SWD multidrop code to run without\n \u003e additional queueing. Please see http://openocd.zylin.com/6141 and\n \u003e related. A review would be highly appreciated.\n \u003e \n \u003e I have not extracted ftdi driver changes as they don\u0027t need any\n \u003e rework. Please, could you resubmit them in a separate patch? I\n \u003e recommend to include just multidrop related changes, not the\n \u003e \"Defensive cleanup\" which is unrelated and should go into another\n \u003e patch.\n \u003e \n \u003e Thanks\n\nI will take a look, but have very little time at the moment - can you tell me which set of new patches should be combined to get the SWD functionality? Is the FTDI stuff now out of date or can it be used as is.\n\nNote I think the whole reason for the queuing in the first place, is that the _queue method names and the _run seemed to imply that some _queue methods must follow other ones without interruption. It is certainly the case that if you insert a targetsel switch between some DAP state setup and another command, you will lose that state.\n\nI\u0027m assuming based on your change that this is not actually a practical concern in the actual usage of the swd_dap_ops functions?","accounts_in_message":[],"_revision_number":6},{"id":"fa848be4c8753ce0b48f34e71a13751080105d60","author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"real_author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"date":"2021-04-19 05:09:44.000000000","message":"Patch Set 6:\n\n\u003e \u003e I have not extracted ftdi driver changes as they don\u0027t need any\n \u003e \u003e rework. Please, could you resubmit them in a separate patch? I\n \u003e \u003e recommend to include just multidrop related changes, not the\n \u003e \u003e \"Defensive cleanup\" which is unrelated and should go into another\n \u003e \u003e patch.\n \u003e \n \u003e ... can\n \u003e you tell me which set of new patches should be combined to get the\n \u003e SWD functionality?\n\nThe simplest way is a checkout of\nhttp://openocd.zylin.com/6142\n\n \u003e Is the FTDI stuff now out of date or can it be used as is.\nAs I wrote, no change required.\n\n \u003e Note I think the whole reason for the queuing in the first place,\n \u003e is that the _queue method names and the _run seemed to imply that\n \u003e some _queue methods must follow other ones without interruption. It\n \u003e is certainly the case that if you insert a targetsel switch between\n \u003e some DAP state setup and another command, you will lose that state.\n\nThe goal of queueing concept is to maximize throughput by minimising required\nturnarounds in the path OpenOCD \u003c--\u003e adapter. So the queue holds all\noperations we can process without knowing the result of them.\nAFAIK there is no implication that all ops in the queue must run\nwithout interruption.\n\nBut you\u0027re right that my non-queued version has some possible problems.\nI\u0027d comment them at http://openocd.zylin.com/6141\n\n \u003e I\u0027m assuming based on your change that this is not actually a\n \u003e practical concern in the actual usage of the swd_dap_ops functions?\n\nSpeed. As I wrote above.","accounts_in_message":[],"_revision_number":6}],"current_revision":"7b44b4beee034f8b5820a31e94eb5ca8e9af6b4a","revisions":{"b0ec31dc65c28734368c920ac0f2b31df9c4e68d":{"kind":"NO_CODE_CHANGE","_number":3,"created":"2019-02-24 15:13:23.000000000","uploader":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"ref":"refs/changes/35/4935/3","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/35/4935/3","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/3 \u0026\u0026 git checkout -b change-4935 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/35/4935/3","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6f66267f853b6c65f47ba686da562c95f0482714","subject":"server: fix small mem leak of bindto_name"}],"author":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:22:09.000000000","tz":-360},"committer":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-24 15:12:33.000000000","tz":-360},"subject":"swd: Add support for SWD multi-drop","message":"swd: Add support for SWD multi-drop\n\n* A new transport type \"swd-multidrop\" is added in addition to \"swd\"\n  and \"jtag\" for FTDI\n* Configuration currently uses the \"coreid\" specified for the target,\n  and a single \"exoected-id\" off the ADI5_DAP to form the target id\n  for DP_TARGETSEL. It is probably worth clearing this up some, but I\n  didn\u0027t want the user to have to specify twice.\n* Multiplexing is handled via specialized (swd_multidrop_dap_ops)\n  dap_ops, which encapsulate the queuing and switching behavior\n  required for multiple targets sharing the same wire\n\nThe design choices were made in spirit with other SWD changes that\nI saw; I picked what seemed like the best abstraction (new transport\nseparate from SWD vs some abstraction above SWD vs something at the\nthe driver level) based on that.\n\nThis patch does not include changes to any drivers other than FTDI\nas I don\u0027t know to what extent SWD multidrop is available, and this\nis the only connection I have to test with.\n\nThe changes to other drivers would be fairly trivial however,\nand can be made in another patch as desired.\n\nChange-Id: I6f285e304d29cf291f13accfb030062b968cc714\nSigned-off-by: graham sanderson \u003cgraham.sanderson@gmail.com\u003e\n"}},"cccd263e6650808206a0fe422d416159a2cfa696":{"kind":"REWORK","_number":2,"created":"2019-02-23 15:42:04.000000000","uploader":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"ref":"refs/changes/35/4935/2","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/35/4935/2","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/2 \u0026\u0026 git checkout -b change-4935 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/35/4935/2","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6f66267f853b6c65f47ba686da562c95f0482714","subject":"server: fix small mem leak of bindto_name"}],"author":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:22:09.000000000","tz":-360},"committer":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-23 15:37:46.000000000","tz":-360},"subject":"swd: Add support for SWD multi-drop","message":"swd: Add support for SWD multi-drop\n\n* A new transport type \"swd-multidrop\" is added in addition to \"swd\" and \"jtag\" for FTDI\n* Configuration currently uses the \"coreid\" specified for the target, and a single \"exoected-id\" off the ADI5_DAP to form the target id for DP_TARGETSEL. It is probably worth clearing this up some, but I didn\u0027t want the user to have to specify twice.\n* Multiplexing is handled via specialized dap_ops (swd_multidrop_dap_ops), which encapsulate the queuing and switching behavior required for multiple targets sharing the same wire\n\nClearly this work was done in parallel with other changes to SWD support, however I picked what seemed like the best abstraction (new transport separate from SWD vs some abstraction above SWD vs something at the driver level) based on the activity I saw.\n\nI have not made changes to drivers other than FTDI pending review, and also I only have FTDI connected h/w to test. I figure the changes can be ported as necessary.\n\nChange-Id: I6f285e304d29cf291f13accfb030062b968cc714\nSigned-off-by: graham sanderson \u003cgraham.sanderson@gmail.com\u003e\n"}},"b1dc9e0beeb663d8e7d5fd09515911b4a71bf966":{"kind":"REWORK","_number":1,"created":"2019-02-22 19:56:57.000000000","uploader":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"ref":"refs/changes/35/4935/1","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/35/4935/1","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/1 \u0026\u0026 git checkout -b change-4935 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/35/4935/1","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6f66267f853b6c65f47ba686da562c95f0482714","subject":"server: fix small mem leak of bindto_name"}],"author":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:22:09.000000000","tz":-360},"committer":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:49:12.000000000","tz":-360},"subject":"topic: Add support for SWD multi-drop","message":"topic: Add support for SWD multi-drop\n\n* A new transport type \"swd-multidrop\" is added in addition to \"swd\" and \"jtag\" for FTDI\n* Configuration currently uses the \"coreid\" specified for the target, and a single \"exoected-id\" off the ADI5_DAP to form the target id for DP_TARGETSEL. It is probably worth clearing this up some, but I didn\u0027t the user to have to specify twice.\n* Multiplexing is handled via specialized dap_ops (swd_multidrop_dap_ops), which encapsulate the queuing and switching behavior required for multiple targets sharing the same wire\n\nClearly this work was done in parallel with other changes to SWD support, however I picked what seemed like the best abstraction (new transport separate from SWD vs some abstraction above SWD vs something at the driver level) based on the activity I saw.\n\nI have not made changes to drivers other than FTDI pending review, and as I don\u0027t have anything appropraite h/w to test. I figure the changes can be ported as necessary.\n\nChange-Id: I6f285e304d29cf291f13accfb030062b968cc714\nSigned-off-by: graham sanderson \u003cgraham.sanderson@gmail.com\u003e\n"}},"7b44b4beee034f8b5820a31e94eb5ca8e9af6b4a":{"kind":"REWORK","_number":6,"created":"2021-03-19 13:54:20.000000000","uploader":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"ref":"refs/changes/35/4935/6","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/35/4935/6","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/6 \u0026\u0026 git checkout -b change-4935 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/35/4935/6","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"8d6f7c92239a54ce77d7a268f51b49445470fe00","subject":"flash/stm32l4x: zero init stm32l4_flash_bank struct on flash bank initialization"}],"author":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:22:09.000000000","tz":-360},"committer":{"name":"Tomas Vanek","email":"vanekt@fbl.cz","date":"2021-03-19 13:52:09.000000000","tz":60},"subject":"swd: Add support for SWD multi-drop","message":"swd: Add support for SWD multi-drop\n\n* Enabled by specifying a dp-id and an instance-id with swj_newdap; e.g.\n\n  transport select swd\n  swj_newdap $_CHIPNAME.core0 cpu -dp-id $_CPUTAPID -instance-id 0\n  swj_newdap $_CHIPNAME.core1 cpu -dp-id $_CPUTAPID -instance-id 1\n\n* Multiplexing is handled via specialized dap_ops (swd_multidrop_dap_ops),\n  which encapsulate the queuing and switching behavior required for multiple\n  targets sharing the same wire\n\n* I have not made changes to drivers other than FTDI pending review, and also\n  because I only have FTDI connected h/w to test. I figure the minimal changes\n  for DP_TARGETSEL (which has no ACK) can be ported as necessary.\n\n* Currently mixing multidrop with non multidrop is not supported, and\n  generates a configuration error\n\nChange-Id: I6f285e304d29cf291f13accfb030062b968cc714\nSigned-off-by: graham sanderson \u003cgraham.sanderson@gmail.com\u003e\nSigned-off-by: Tomas Vanek \u003cvanekt@fbl.cz\u003e\n"}},"82bf01264b0e3c8445435645d71bfaf397271467":{"kind":"REWORK","_number":5,"created":"2019-05-12 03:13:06.000000000","uploader":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"ref":"refs/changes/35/4935/5","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/35/4935/5","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/5 \u0026\u0026 git checkout -b change-4935 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/35/4935/5","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"7ee618692f56b0efea864890da45d73d28e393d9","subject":"flash/nor/stm32h7x: use of wait queue flag instead of the busy flag"}],"author":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:22:09.000000000","tz":-360},"committer":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-05-12 03:09:01.000000000","tz":-300},"subject":"swd: Add support for SWD multi-drop","message":"swd: Add support for SWD multi-drop\n\n* Enabled by specifying a dp-id and an instance-id with swj_newdap; e.g.\n\n  transport select swd\n  swj_newdap $_CHIPNAME.core0 cpu -dp-id $_CPUTAPID -instance-id 0\n  swj_newdap $_CHIPNAME.core1 cpu -dp-id $_CPUTAPID -instance-id 1\n\n* Multiplexing is handled via specialized dap_ops (swd_multidrop_dap_ops),\n  which encapsulate the queuing and switching behavior required for multiple\n  targets sharing the same wire\n\n* I have not made changes to drivers other than FTDI pending review, and also\n  because I only have FTDI connected h/w to test. I figure the minimal changes\n  for DP_TARGETSEL (which has no ACK) can be ported as necessary.\n\n* Currently mixing multidrop with non multidrop is not supported, and\n  generates a configuration error\n\nChange-Id: I6f285e304d29cf291f13accfb030062b968cc714\nSigned-off-by: graham sanderson \u003cgraham.sanderson@gmail.com\u003e\n"}},"5e8af180d65e246b739337c7b4779f859d4b5e55":{"kind":"REWORK","_number":4,"created":"2019-05-12 00:10:49.000000000","uploader":{"_account_id":1001632,"name":"Graham Sanderson","email":"graham.sanderson@gmail.com","username":"graham.sanderson"},"ref":"refs/changes/35/4935/4","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/35/4935/4","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/4 \u0026\u0026 git checkout -b change-4935 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/35/4935/4","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/35/4935/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"7ee618692f56b0efea864890da45d73d28e393d9","subject":"flash/nor/stm32h7x: use of wait queue flag instead of the busy flag"}],"author":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-02-22 19:22:09.000000000","tz":-360},"committer":{"name":"graham sanderson","email":"graham.sanderson@gmail.com","date":"2019-05-12 00:10:32.000000000","tz":-300},"subject":"swd: Add support for SWD multi-drop","message":"swd: Add support for SWD multi-drop\n\n* Enabled by specifying a dp-id and an instance-id with swj_newdap; e.g.\n\n  transport select swd\n  swj_newdap $_CHIPNAME.core0 cpu -dp-id $_CPUTAPID -instance-id 0\n  swj_newdap $_CHIPNAME.core1 cpu -dp-id $_CPUTAPID -instance-id 1\n\n* Multiplexing is handled via specialized dap_ops (swd_multidrop_dap_ops),\n  which encapsulate the queuing and switching behavior required for multiple\n  targets sharing the same wire\n\n* I have not made changes to drivers other than FTDI pending review, and also\n  because I only have FTDI connected h/w to test. I figure the minimal changes\n  for DP_TARGETSEL (which has no ACK) can be ported as necessary.\n\n* Currently mixing multidrop with non multidrop is not supported, and\n  generates a configuration error\n\nChange-Id: I6f285e304d29cf291f13accfb030062b968cc714\nSigned-off-by: graham sanderson \u003cgraham.sanderson@gmail.com\u003e\n"}}},"requirements":[],"submit_records":[{"rule_name":"gerrit~DefaultSubmitRule","status":"NOT_READY","labels":[{"label":"Verified","status":"OK","applied_by":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]}},{"label":"Code-Review","status":"NEED"}]}],"submit_requirements":[{"name":"Verified","status":"SATISFIED","is_legacy":true,"submittability_expression_result":{"expression":"label:Verified\u003dMAX -label:Verified\u003dMIN","fulfilled":true,"status":"PASS","passing_atoms":["label:Verified\u003dMAX","-label:Verified\u003dMIN"],"failing_atoms":[]}},{"name":"Code-Review","status":"UNSATISFIED","is_legacy":true,"submittability_expression_result":{"expression":"label:Code-Review\u003dMAX -label:Code-Review\u003dMIN","fulfilled":false,"status":"FAIL","passing_atoms":[],"failing_atoms":["label:Code-Review\u003dMAX","-label:Code-Review\u003dMIN"]}}]}