)]}'
{"id":"openocd~master~Icaa8a5d38923f5768e64f00c62058fafe93ab6ed","project":"openocd","branch":"master","hashtags":[],"change_id":"Icaa8a5d38923f5768e64f00c62058fafe93ab6ed","subject":"target/once: Initial support for On Chip Emulator (Power arch, e200 core)","status":"ABANDONED","created":"2021-03-24 16:19:01.000000000","updated":"2021-04-07 19:24:25.000000000","total_comment_count":1,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"3069a8dfed9d0aee64d3e12c8568c62e4952e620","_number":6124,"owner":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},"all":[{"date":"2021-04-05 14:40:17.000000000","_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},{"value":1,"date":"2021-03-29 17:18:54.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},{"date":"2021-04-04 14:17:02.000000000","_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":{"rejected":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},{"value":-2,"date":"2021-03-29 16:14:51.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},{"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,"blocking":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1000014,"name":"jenkins","username":"jenkins","tags":["SERVICE_USER"]},{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2021-03-24 19:07:52.000000000","updated_by":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"reviewer":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"state":"REVIEWER"},{"updated":"2021-03-29 17:18:54.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-04-04 14:17:02.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"}],"messages":[{"id":"0787d073b32cd35ee12539e25ae886d357903d00","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-03-24 16:19:01.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"5bf9220ea10c511cb0afc52ea02c59d6d2dc3e39","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-24 17:57:23.000000000","message":"Patch Set 1: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/14243/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/13505/ : SUCCESS","accounts_in_message":[],"_revision_number":1},{"id":"d716ca9819ec93355e6d487afef3e0f6c6eb04dc","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-24 19:07:52.000000000","message":"Patch Set 1: Code-Review-2\n\n(1 comment)\n\nPlease do not see my -2 as dislike of your work. It is great that some is trying to do this work, but it should be implemented on a different place of OpenOCD :)","accounts_in_message":[],"_revision_number":1},{"id":"d42a31502226a4d9b19e01f3e6cec3b425ad273b","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-03-25 09:44:26.000000000","message":"Patch Set 1:\n\n\u003e (1 comment)\n \u003e \n \u003e Please do not see my -2 as dislike of your work. It is great that\n \u003e some is trying to do this work, but it should be implemented on a\n \u003e different place of OpenOCD :)\n\nThat is fine, it is exactly the reason why I preferred to commit early, to discuss this kind of things. How are ARM, MIPS, etc currently implemented? Is there a common API for this?","accounts_in_message":[],"_revision_number":1},{"id":"a93477f657754a2891f5e52cba6e6cb9a3ed35ba","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-25 11:22:41.000000000","message":"Patch Set 1:\n\n\"struct target_type\" is what you need. For example here are two patches to add MIPS64 support:\nhttp://openocd.zylin.com/#/c/2321\nhttp://openocd.zylin.com/#/c/2322\n\nIf we compare it with MIPS terminology:\n- OnCE is kind of like EJTAG, a TAP with CPU debug functionality\n- OnCE with IR access (register to write CPU opcode for execution), it is something similar to mips64_pracc.c. It means, you have some how generic OnCE which is probably reused with different CPU variants, the processor access code is then CPU variant specific. You generate CPU specific opcodes to read out all CPU registers, do memory access and so on.","accounts_in_message":[],"_revision_number":1},{"id":"164431b45ab5865159cf0a384d3c6bf4f712ef40","author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"real_author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"date":"2021-03-28 18:51:44.000000000","message":"Patch Set 1:\n\n\u003e (1 comment)\n \u003e \n \u003e Please do not see my -2 as dislike of your work. It is great that\n \u003e some is trying to do this work, but it should be implemented on a\n \u003e different place of OpenOCD :)\n\ni agree with oleksij.\nthere is already nexus support for avr \u0027a\u0027 target, which is dead.\n\u0027m\u0027 targets are still manufactured, but for them it is not working.\ni have e200 targets from npx/st. also e300 and e500 from nxp. raspberry pi\u0027s vpu (videcore4) is nexus based too.\n\n \u003e (1 comment)\n \u003e \n \u003e Please do not see my -2 as dislike of your work. It is great that\n \u003e some is trying to do this work, but it should be implemented on a\n \u003e different place of OpenOCD :)\n\ni agree with oleksij. it is great that somebody is interested in once/nexus targets.\nthere are already some patches for ppc microcontrollers:\nhttp://openocd.zylin.com/#/c/4337\nhttp://openocd.zylin.com/#/c/4541\nhttp://openocd.zylin.com/#/c/4542\nhttp://openocd.zylin.com/#/c/4543\nhttp://openocd.zylin.com/#/c/4544\nhttp://openocd.zylin.com/#/c/4545\n\ntargets with nexus state machine are already in src/target/avr32*. but only for obsolete and dead architecture. abstractization of nexus will open doors for following targets:\ndebugging/tracing of ppc microcontrollers and cpus (e5000+)\nvideocore in raspberrypi\navr32 mcus (still in production)","accounts_in_message":[],"_revision_number":1},{"id":"fcc2664f88302f3e935909102250d3c74f256ec1","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-29 07:17:22.000000000","message":"Patch Set 1:\n\n\u003e \u003e (1 comment)\n \u003e \u003e\n \u003e \u003e Please do not see my -2 as dislike of your work. It is great that\n \u003e \u003e some is trying to do this work, but it should be implemented on a\n \u003e \u003e different place of OpenOCD :)\n \u003e \n \u003e i agree with oleksij.\n \u003e there is already nexus support for avr \u0027a\u0027 target, which is dead.\n \u003e \u0027m\u0027 targets are still manufactured, but for them it is not working.\n \u003e i have e200 targets from npx/st. also e300 and e500 from nxp.\n \u003e raspberry pi\u0027s vpu (videcore4) is nexus based too.\n \u003e \n \u003e \u003e (1 comment)\n \u003e \u003e\n \u003e \u003e Please do not see my -2 as dislike of your work. It is great that\n \u003e \u003e some is trying to do this work, but it should be implemented on a\n \u003e \u003e different place of OpenOCD :)\n \u003e \n \u003e i agree with oleksij. it is great that somebody is interested in\n \u003e once/nexus targets.\n \u003e there are already some patches for ppc microcontrollers:\n \u003e http://openocd.zylin.com/#/c/4337\n \u003e http://openocd.zylin.com/#/c/4541\n \u003e http://openocd.zylin.com/#/c/4542\n \u003e http://openocd.zylin.com/#/c/4543\n \u003e http://openocd.zylin.com/#/c/4544\n \u003e http://openocd.zylin.com/#/c/4545\n \u003e \n \u003e targets with nexus state machine are already in src/target/avr32*.\n \u003e but only for obsolete and dead architecture. abstractization of\n \u003e nexus will open doors for following targets:\n \u003e debugging/tracing of ppc microcontrollers and cpus (e5000+)\n \u003e videocore in raspberrypi\n \u003e avr32 mcus (still in production)\n\nThank you for pointing to other use cases. I assume we should think about proper abstraction as early as possible.\nIf I understand correctly, we have a generic JTAG TAP, which provides access OnCE engine and one register for Nexus3 access. The Nexus3 looks like a rabbit hole with lots of other functionality. The ST documentations says something about Nexus1 and 2..\nThis part of terminology is not clear to me, can please some one help to understand it? :)","accounts_in_message":[],"_revision_number":1},{"id":"8be70167149bfc8f767534a4a5b7cb441f01efdf","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-03-29 15:49:59.000000000","message":"Patch Set 1:\n\n\u003e \n \u003e i agree with oleksij. it is great that somebody is interested in\n \u003e once/nexus targets.\n \u003e there are already some patches for ppc microcontrollers:\n \u003e http://openocd.zylin.com/#/c/4337\n \u003e http://openocd.zylin.com/#/c/4541\n \u003e http://openocd.zylin.com/#/c/4542\n \u003e http://openocd.zylin.com/#/c/4543\n \u003e http://openocd.zylin.com/#/c/4544\n \u003e http://openocd.zylin.com/#/c/4545\n \u003e \n\nThis work looks great!\n\nProbably one of the first things is to get some agreement on how to do the DRSCAN in a compatible way, i.e. bypassing the DR-PAUSE state before DR-UPDATE. Your commits:\nhttp://openocd.zylin.com/#/c/4541\nhttp://openocd.zylin.com/#/c/4542\n\nare in the same line to my commit:\nhttp://openocd.zylin.com/#/c/6123\n\n(I avoided adding EXIT1 states to interface.c because interface.c only works with stable JTAG states so far. I don\u0027t know why that choice is done, though)\n\nI wonder if this DRSCAN change has been the blocker so far...","accounts_in_message":[],"_revision_number":1},{"id":"809edb8fb53ba803fceed66b31ab9fec7ba13f09","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-03-29 15:57:05.000000000","message":"Patch Set 1:\n\n\u003e \u003e \u003e (1 comment)\n \u003e \u003e \u003e\n \u003e \u003e \u003e Please do not see my -2 as dislike of your work. It is great\n \u003e that\n \u003e \u003e \u003e some is trying to do this work, but it should be implemented on\n \u003e a\n \u003e \u003e \u003e different place of OpenOCD :)\n \u003e \u003e\n \u003e \u003e i agree with oleksij.\n \u003e \u003e there is already nexus support for avr \u0027a\u0027 target, which is dead.\n \u003e \u003e \u0027m\u0027 targets are still manufactured, but for them it is not\n \u003e working.\n \u003e \u003e i have e200 targets from npx/st. also e300 and e500 from nxp.\n \u003e \u003e raspberry pi\u0027s vpu (videcore4) is nexus based too.\n \u003e \u003e\n \u003e \u003e \u003e (1 comment)\n \u003e \u003e \u003e\n \u003e \u003e \u003e Please do not see my -2 as dislike of your work. It is great\n \u003e that\n \u003e \u003e \u003e some is trying to do this work, but it should be implemented on\n \u003e a\n \u003e \u003e \u003e different place of OpenOCD :)\n \u003e \u003e\n \u003e \u003e i agree with oleksij. it is great that somebody is interested in\n \u003e \u003e once/nexus targets.\n \u003e \u003e there are already some patches for ppc microcontrollers:\n \u003e \u003e http://openocd.zylin.com/#/c/4337\n \u003e \u003e http://openocd.zylin.com/#/c/4541\n \u003e \u003e http://openocd.zylin.com/#/c/4542\n \u003e \u003e http://openocd.zylin.com/#/c/4543\n \u003e \u003e http://openocd.zylin.com/#/c/4544\n \u003e \u003e http://openocd.zylin.com/#/c/4545\n \u003e \u003e\n \u003e \u003e targets with nexus state machine are already in src/target/avr32*.\n \u003e \u003e but only for obsolete and dead architecture. abstractization of\n \u003e \u003e nexus will open doors for following targets:\n \u003e \u003e debugging/tracing of ppc microcontrollers and cpus (e5000+)\n \u003e \u003e videocore in raspberrypi\n \u003e \u003e avr32 mcus (still in production)\n \u003e \n \u003e Thank you for pointing to other use cases. I assume we should think\n \u003e about proper abstraction as early as possible.\n \u003e If I understand correctly, we have a generic JTAG TAP, which\n \u003e provides access OnCE engine and one register for Nexus3 access. The\n \u003e Nexus3 looks like a rabbit hole with lots of other functionality.\n \u003e The ST documentations says something about Nexus1 and 2..\n \u003e This part of terminology is not clear to me, can please some one\n \u003e help to understand it? :)\n\nIn the day, I couldn\u0027t find much more than the aforementioned document.\nThe document seems to be enough for this implementation, but I agree that it would be nice to have all the gory details :)\n\nThe spec of the debug interface accessed by the OnCE TAP can be found on https://www.st.com/resource/en/reference_manual/cd00164807-programmers-reference-manual-for-book-e-processors-stmicroelectronics.pdf\n\n(page 110 onwards)","accounts_in_message":[],"_revision_number":1},{"id":"34d42a3737f3d5c5318768811d319ce61fd13141","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-03-29 16:14:51.000000000","message":"Uploaded patch set 2: Patch Set 1 was rebased.","accounts_in_message":[],"_revision_number":2},{"id":"f25125f4dc17377fe2e796bc16fa0561b9f959bb","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-29 17:15:07.000000000","message":"Patch Set 2:\n\nAVR32 is now owned by microchip, this makes things easier:\nhttps://ww1.microchip.com/downloads/en/DeviceDoc/doc32058.pdf\nSee JTAG chapter","accounts_in_message":[],"_revision_number":2},{"id":"9c794985baedd3b5e29fb371ff0e6bec3f863b9c","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-29 17:18:54.000000000","message":"Patch Set 2: Verified+1\n\nBuild Successful \n\nhttp://build.openocd.org/job/openocd-gerrit/14254/ : SUCCESS\n\nhttp://build.openocd.org/job/openocd-gerrit-build/13516/ : SUCCESS","accounts_in_message":[],"_revision_number":2},{"id":"1ae66210d7ec12cfe79fb0d0e4bafe7b55055de3","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-29 17:30:04.000000000","message":"Patch Set 2:\n\nand with this document it is easier to understand what is behind the nexus TAP register\nhttp://www.arbitrarytechnology.com/files/Download/ieee-5001%20nexus%20protocol.pdf\nBased on this file, i would expect that nexus part should be separately attached on top of jtag tap\nThe nexus driver should read CSC and detect the nexus class. According to the class, we can see which registers and functionality is available","accounts_in_message":[],"_revision_number":2},{"id":"f0c5ad694b378d592efe6edfd3319e3159585c66","author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"real_author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"date":"2021-03-29 18:47:58.000000000","message":"Patch Set 2:\n\n\u003e and with this document it is easier to understand what is behind\n \u003e the nexus TAP register\n \u003e http://www.arbitrarytechnology.com/files/Download/ieee-5001%20nexus%20protocol.pdf\n \u003e Based on this file, i would expect that nexus part should be\n \u003e separately attached on top of jtag tap\n \u003e The nexus driver should read CSC and detect the nexus class.\n \u003e According to the class, we can see which registers and\n \u003e functionality is available\n\nnewer version is accessible directly from nexus site - http://nexus5001.org/wp-content/uploads/2018/05/IEEE-ISTO-5001-2012-v3.0.1-Nexus-Standard.pdf","accounts_in_message":[],"_revision_number":2},{"id":"bcaf3b26fda1cc4907ee61570a651e5135fa6d9f","author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"real_author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"date":"2021-03-29 18:48:46.000000000","message":"Patch Set 2:\n\nadditional resources: \nhttps://github.com/Origen-SDK/origen_nexus","accounts_in_message":[],"_revision_number":2},{"id":"6cfe1052dcde47ccebf1dde1e453b1546b25332e","author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"real_author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"date":"2021-03-29 19:01:12.000000000","message":"Patch Set 2:\n\nhttps://github.com/riscv/tg-nexus-trace","accounts_in_message":[],"_revision_number":2},{"id":"823caf835a2c76407c1966f48fd428340f27ff53","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-30 09:20:27.000000000","message":"Patch Set 2:\n\nOK, so nexus is defining arch agnostic interface. We can single step the CPU, add instruction or data break point, control tracing if implemented and so on. Executing some CPU specific opcodes, reading out CPU registers and so on, are not specified (do i see it correctly?)\nHm, do OnCE implement completely the same functionality as the Nexus do?","accounts_in_message":[],"_revision_number":2},{"id":"a8e858434e8c22be38e38e0edbaecb10fdf26034","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-03-30 09:45:27.000000000","message":"Patch Set 2:\n\n\u003e OK, so nexus is defining arch agnostic interface. We can single\n \u003e step the CPU, add instruction or data break point, control tracing\n \u003e if implemented and so on. Executing some CPU specific opcodes,\n \u003e reading out CPU registers and so on, are not specified (do i see it\n \u003e correctly?)\n \u003e Hm, do OnCE implement completely the same functionality as the\n \u003e Nexus do?\n\nOnCE gives you acces to all debug registers of the core, plus MSR, PC, IR and CTL. You can step any opcode. Reading/writing general purpose registers in the CPU is done by an opcode (they recommend OR instruction). Building on this, you can read/write to any CPU memory location (registers or SRAM). You can also execute code (leave debug mode)\n\nSome of this, however, seems very specific to e200 core. E.g. the debug registers, or the CPU CTL register, I don\u0027t know how much of it is shared with other cores.\n\nThe bare OnCE functionality may be the OCMD (OnCE command register). It gives the ability to read/write registers, plus the GO and EX bits, which gives execution control to the CPU (either for 1 instruction, or permanently)","accounts_in_message":[],"_revision_number":2},{"id":"2f133fb616f4fac63add9e82360688c1fda4f78e","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-03-30 17:22:58.000000000","message":"Patch Set 2:\n\nAfter comparing \"OCD Register Summary\", page 153:\nhttp://ww1.microchip.com/downloads/en/DeviceDoc/doc32002.pdf\n\nwith the nexus specification. I would say that we can\u0027t make completely generic driver covering all types of nexus devices.\n\nComparing all of this with SPC56 anx your xpc56 driver, I would say that we have:\n- shared CPU architecture for SPC56 and XPC56, but different arch for AVR32\n- partially shared nexus infrastructure for all of this chips\n- mostly different TAP structure for all of them\n\nSo, if we register target, it should be arch specific target, for example ppc_e200 or avr32. The target control is done over vendor- or soc- specific dap (debug access point), or On Chip Emulator, or service access bus, or nexus (any other name for same functionality). The dap driver should provide needed callbacks so the target driver can use them.\n\nMay be it will be enough to call the DAP driver \"nexus\" and this driver should do all needed autodetection, to prepare all needed vendor specific callbacks. For autodetection can be used Nexus DID register. If autodetection is not possible, then we will need to provide option to overwrite the autodetection.\n\nFrom TCL config point of view it will be something like:\njtag newtap $_CHIPNAME cpu...\ndap (or sap or nexus) create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu\ntarget create $_TARGETNAME1 ppc_e200 (or avr32)","accounts_in_message":[],"_revision_number":2},{"id":"f6adcf63c9ed37dc523fb62c92b4203c05175809","author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"real_author":{"_account_id":1000637,"name":"Jiri Kastner","display_name":"indy","email":"cz172638@gmail.com","username":"indy"},"date":"2021-04-04 14:17:02.000000000","message":"Patch Set 2:\n\n\u003e \u003e \u003e (1 comment)\n \u003e \u003e \u003e\n \u003e \u003e \u003e Please do not see my -2 as dislike of your work. It is great\n \u003e that\n \u003e \u003e \u003e some is trying to do this work, but it should be implemented on\n \u003e a\n \u003e \u003e \u003e different place of OpenOCD :)\n \u003e \u003e\n \u003e \u003e i agree with oleksij.\n \u003e \u003e there is already nexus support for avr \u0027a\u0027 target, which is dead.\n \u003e \u003e \u0027m\u0027 targets are still manufactured, but for them it is not\n \u003e working.\n \u003e \u003e i have e200 targets from npx/st. also e300 and e500 from nxp.\n \u003e \u003e raspberry pi\u0027s vpu (videcore4) is nexus based too.\n \u003e \u003e\n \u003e \u003e \u003e (1 comment)\n \u003e \u003e \u003e\n \u003e \u003e \u003e Please do not see my -2 as dislike of your work. It is great\n \u003e that\n \u003e \u003e \u003e some is trying to do this work, but it should be implemented on\n \u003e a\n \u003e \u003e \u003e different place of OpenOCD :)\n \u003e \u003e\n \u003e \u003e i agree with oleksij. it is great that somebody is interested in\n \u003e \u003e once/nexus targets.\n \u003e \u003e there are already some patches for ppc microcontrollers:\n \u003e \u003e http://openocd.zylin.com/#/c/4337\n \u003e \u003e http://openocd.zylin.com/#/c/4541\n \u003e \u003e http://openocd.zylin.com/#/c/4542\n \u003e \u003e http://openocd.zylin.com/#/c/4543\n \u003e \u003e http://openocd.zylin.com/#/c/4544\n \u003e \u003e http://openocd.zylin.com/#/c/4545\n \u003e \u003e\n \u003e \u003e targets with nexus state machine are already in src/target/avr32*.\n \u003e \u003e but only for obsolete and dead architecture. abstractization of\n \u003e \u003e nexus will open doors for following targets:\n \u003e \u003e debugging/tracing of ppc microcontrollers and cpus (e5000+)\n \u003e \u003e videocore in raspberrypi\n \u003e \u003e avr32 mcus (still in production)\n \u003e \n \u003e Thank you for pointing to other use cases. I assume we should think\n \u003e about proper abstraction as early as possible.\n \u003e If I understand correctly, we have a generic JTAG TAP, which\n \u003e provides access OnCE engine and one register for Nexus3 access. The\n \u003e Nexus3 looks like a rabbit hole with lots of other functionality.\n \u003e The ST documentations says something about Nexus1 and 2..\n \u003e This part of terminology is not clear to me, can please some one\n \u003e help to understand it? :)\n\nhttps://www.nxp.com/docs/en/application-note/AN4088.pdf\n\nnice tables for nexus classes","accounts_in_message":[],"_revision_number":2},{"id":"33bd8425d44dcdb3e4d0d2c73fa7d5eabcf4a092","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-04-04 16:12:19.000000000","message":"Patch Set 2:\n\nnice!\n\nAs reviewer I have better understanding of this topic now :)\n\nDo any of you still wont to continue on it? Is it clear what and how should be done?","accounts_in_message":[],"_revision_number":2},{"id":"a94706595e7fa1bdcfbd2d2c1a581c9359d1a15c","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-04-05 14:40:17.000000000","message":"Patch Set 2:\n\nI still have all the ONCE related stuff quite fresh, so I\u0027d be happy to help here. But I am afraid it is not 100% clear to me how this should fit in OpenOCD. I see this commit:\n\nhttp://openocd.zylin.com/#/c/4544\n\nhas the target_type implemented for this case (I understand \u0027X\u0027 XPC56 stands for \u0027M\u0027, \u0027S\u0027 and \u0027R\u0027?).\nWould it be a start splitting this target_type in common nexus 1 infrastructure and specific XPC56 stuff? Or inserting this functionality in an interface other than target_type?","accounts_in_message":[],"_revision_number":2},{"id":"3ca3b297b0b9763e8c1cbcd35aa513b2bd5c2919","author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"real_author":{"_account_id":1000410,"name":"Oleksij Rempel","email":"linux@rempel-privat.de","username":"olerem"},"date":"2021-04-05 15:46:15.000000000","message":"Patch Set 2:\n\nGood question. Luis, Jiri, can you please sync with each other? Who of you wont to continue on it?\n\nYes, \u0027X\u0027 XPC56 stands for \u0027M\u0027, \u0027S\u0027 and \u0027R\u0027.","accounts_in_message":[],"_revision_number":2},{"id":"3069a8dfed9d0aee64d3e12c8568c62e4952e620","author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"real_author":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"date":"2021-04-07 19:24:25.000000000","message":"Abandoned\n\nDropped because OnCE functionality will be implemented in C code, not TCL","accounts_in_message":[],"_revision_number":2}],"current_revision":"56506d2ed7a63c64bbe825778c8928102c1969df","revisions":{"a7477408d6880f59abef5d8e5c307a5eb84eb7af":{"kind":"REWORK","_number":1,"created":"2021-03-24 16:19:01.000000000","uploader":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"ref":"refs/changes/24/6124/1","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/24/6124/1","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/1 \u0026\u0026 git checkout -b change-6124 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/24/6124/1","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"33e07f772052284342abf89feca01791fca50d6d","subject":"drivers/ftdi: drscan: Skip DR-PAUSE when endstate \u003d\u003d IDLE"}],"author":{"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","date":"2021-03-24 16:14:40.000000000","tz":60},"committer":{"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","date":"2021-03-24 16:14:40.000000000","tz":60},"subject":"target/once: Initial support for On Chip Emulator (Power arch, e200 core)","message":"target/once: Initial support for On Chip Emulator (Power arch, e200 core)\n\nBasic support for debug control of the Power Architecture e200 core.\nAll of the SPC56x/RPC56x devices from ST (and possibly MPC56x from NXP) should\nbe compatible with this implementation, based on ST Application Note AN4035.\n\nThe following functionality is provided:\n - Read/Write CPU registers\n - Read/Write arbitrary memory location (32-bit)\n - Execute single instruction\n - Load binary file to memory location\n - Execute code at specific memory location, until a breakpoint is reached\n\nTested on ST SPC560D.\n\nbinary.tcl is added as a dependency. It is taken from jimtcl. The full original\nlicense is added on the header, plus an SPDX meta tag, with GPL2 as extra choice\n\nChange-Id: Icaa8a5d38923f5768e64f00c62058fafe93ab6ed\nSigned-off-by: Luis de Arquer \u003cluis.dearquer@inertim.com\u003e\n"}},"56506d2ed7a63c64bbe825778c8928102c1969df":{"kind":"TRIVIAL_REBASE","_number":2,"created":"2021-03-29 16:14:51.000000000","uploader":{"_account_id":1001877,"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","username":"ldearquer"},"ref":"refs/changes/24/6124/2","fetch":{"anonymous http":{"url":"https://review.openocd.org/openocd","ref":"refs/changes/24/6124/2","commands":{"Branch":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/2 \u0026\u0026 git checkout -b change-6124 FETCH_HEAD","Checkout":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.openocd.org/openocd refs/changes/24/6124/2","Reset To":"git fetch https://review.openocd.org/openocd refs/changes/24/6124/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"9eaf71ef3d4f41b0293ac2cd899beaa184ad8d82","subject":"drivers/ftdi: drscan: Skip DR-PAUSE when endstate \u003d\u003d IDLE"}],"author":{"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","date":"2021-03-24 16:14:40.000000000","tz":60},"committer":{"name":"Luis de Arquer","email":"luis.dearquer@inertim.com","date":"2021-03-29 16:14:36.000000000","tz":120},"subject":"target/once: Initial support for On Chip Emulator (Power arch, e200 core)","message":"target/once: Initial support for On Chip Emulator (Power arch, e200 core)\n\nBasic support for debug control of the Power Architecture e200 core.\nAll of the SPC56x/RPC56x devices from ST (and possibly MPC56x from NXP) should\nbe compatible with this implementation, based on ST Application Note AN4035.\n\nThe following functionality is provided:\n - Read/Write CPU registers\n - Read/Write arbitrary memory location (32-bit)\n - Execute single instruction\n - Load binary file to memory location\n - Execute code at specific memory location, until a breakpoint is reached\n\nTested on ST SPC560D.\n\nbinary.tcl is added as a dependency. It is taken from jimtcl. The full original\nlicense is added on the header, plus an SPDX meta tag, with GPL2 as extra choice\n\nChange-Id: Icaa8a5d38923f5768e64f00c62058fafe93ab6ed\nSigned-off-by: Luis de Arquer \u003cluis.dearquer@inertim.com\u003e\n"}}},"requirements":[],"submit_records":[],"submit_requirements":[]}