)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"7548a980686815a517567db42faf8efbd005b03a","unresolved":true,"context_lines":[{"line_number":34,"context_line":"definitely or indirectly lost."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Origin: https://github.com/tricore-oss/openocd (branch aurix_support)"},{"line_number":37,"context_line":"Imported-from: 4e3afa90f349bef44444008f03bbebebdda1af71"},{"line_number":38,"context_line":"Signed-off-by: Christoph Seitz \u003cchristoph.seitz@infineon.com\u003e"},{"line_number":39,"context_line":"Signed-off-by: Rafael J. Cruz \u003crafa.junio@hardenedlinux.org\u003e"},{"line_number":40,"context_line":"Change-Id: I054378ee4863c47dae0709c35dd0797071065602"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"6a36e7e1_8e3d7212","line":37,"updated":"2026-08-30 14:49:25.000000000","message":"I\u0027ve missed this.\nThese tags `Origin:` and `Imported-from:` are not standard. Strange, they have not triggered some error by checkpatch.\nPlease use instead the tag:\nLink: https://github.com/tricore-oss/openocd/tree/4e3afa90f349bef44444008f03bbebebdda1af71 [1]\nand add above some text explaining that the code is derived from the current Infineon code available in [1].","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"83cd1b91ed7127f26a07ccdf8b598fdd713f216d","unresolved":false,"context_lines":[{"line_number":34,"context_line":"definitely or indirectly lost."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Origin: https://github.com/tricore-oss/openocd (branch aurix_support)"},{"line_number":37,"context_line":"Imported-from: 4e3afa90f349bef44444008f03bbebebdda1af71"},{"line_number":38,"context_line":"Signed-off-by: Christoph Seitz \u003cchristoph.seitz@infineon.com\u003e"},{"line_number":39,"context_line":"Signed-off-by: Rafael J. Cruz \u003crafa.junio@hardenedlinux.org\u003e"},{"line_number":40,"context_line":"Change-Id: I054378ee4863c47dae0709c35dd0797071065602"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7dd9c614_b4f97778","line":37,"in_reply_to":"6a36e7e1_8e3d7212","updated":"2026-08-30 22:55:40.000000000","message":"Done, I also did the same in all the commits series.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"9f8f434a8f03cf9f037b8f670c25fb834ee00c21","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"40ccd84f_2cf0a483","updated":"2026-08-30 14:41:31.000000000","message":"Only a minor point int the documentation, otherwise looks ok","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"c01c3a57c9c79703be386c721e3dd62cd25f7bd2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f99e9b71_12b18596","updated":"2026-08-28 14:00:24.000000000","message":"This series adds support for Infineon AURIX TriCore microcontrollers to\nOpenOCD: the Infineon DAP transport, the TriCore target, the on-chip\nprogram flash driver, the on-board miniWiggler V3 adapter, device and\nboard configurations, offline tests and a hardware example.\n\nEverything runs against the chip\u0027s native Infineon DAP protocol over a\nplain FTDI probe. No vendor tooling is required: the Infineon DAS\nruntime and its tas_server are not used, not linked and not needed at\nany point. To our knowledge this is the first fully open debug and\nflash path for AURIX.\n\nThis is a new feature, not a bugfix. It adds support for a device family\nand a debug transport that OpenOCD did not support before, so no\npre-existing behaviour changes.\n\nProvenance\n----------\n\nThe bulk of the target, transport and flash code originates from\nChristoph Seitz\u0027s downstream AURIX fork at\nhttps://github.com/tricore-oss/openocd. Christoph is an Infineon\nengineer and the original author; his authorship, copyright and\nSigned-off-by lines are preserved on the commits that carry his work.\nHe has explicitly agreed to this code being upstreamed, asking only\nthat the licence and copyright stay intact and that he is credited as\nthe original author. He has also asked not to be involved in the\nupstream review itself, so please do not wait on him for acks.\n\nThe remaining commits are new work: the miniWiggler V3 adapter driver,\nthe board configuration, the tests and the example. The original fork\ndrives the probe through DAS; this series replaces that with a direct\nFTDI/MPSSE implementation, which is what makes the DAS-free path\npossible.\n\nTwo flash loader binaries in the original fork were shipped only as\ngenerated .inc blobs. The assembly sources in this series were\nreconstructed from those blobs and are byte-for-byte reproducible: the\nin-tree Makefiles regenerate the committed .inc files with no diff.\n\nWhat is in the series\n---------------------\n\n  1  transport   Infineon DAP (ifxdap) transport\n       https://review.openocd.org/c/openocd/+/9904\n  2  target      OCMTS memory transaction service\n       https://review.openocd.org/c/openocd/+/9905\n  3  target      AURIX TriCore target\n       https://review.openocd.org/c/openocd/+/9906\n  4  flash/nor   AURIX eflash driver (tc3x_eflash, tc4x_eflash)\n       https://review.openocd.org/c/openocd/+/9907\n  5  jtag        miniWiggler V3 adapter driver\n       https://review.openocd.org/c/openocd/+/9908\n  6  tcl/target  TC3xx/TC4xx device configurations\n       https://review.openocd.org/c/openocd/+/9909\n  7  tcl/board   AURIX TC375 Lite Kit V2 board configuration\n       https://review.openocd.org/c/openocd/+/9910\n  8  testing     offline config tests and a TC375 blinky example\n       https://review.openocd.org/c/openocd/+/9911\n\n55 files changed, 7691 insertions(+), 8 deletions(-).\n\nTesting\n-------\n\nHardware used is an AURIX TC375 Lite Kit V2 with its on-board\nminiWiggler V3, on x86_64 and aarch64 Linux, with no DAS installed.\n\nAn on-target regression suite of 71 assertions is run as a single\nOpenOCD script against the board. All 71 pass. It covers:\n\n  - erase, program and verify of program flash, through both the\n    algorithm path and the work-area-less fallback path\n  - a failed program is reported as a failure and not as success, and\n    the core recovers from an aborted flash algorithm with reset halt\n  - reset halt, resume, halt, single step, and that resume and step\n    honour an explicit start address rather than the stale PC\n  - hardware breakpoints, data watchpoints, and range watchpoints\n    allocating a free even/odd trigger pair alongside armed triggers\n  - GDB attach, register and memory access\n  - sustained 2048-word memory round-trips exercising the DAP response\n    decoder\n  - the shipped example is programmed with\n    \"program tc375-blinky.elf verify reset exit\" and the LEDs then\n    alternate as intended, confirmed by sampling the port register\n\nVerified offline:\n\n  - checkpatch clean on all eight commits\n  - builds with no new warnings, including with -Werror\n  - make -C testing check passes, including new AURIX config tests\n  - doc/openocd.texi builds clean\n  - both flash loaders regenerate byte-identically from source\n  - Clang Static Analyzer (scan-build, clang 18.1.3) over a full build\n    reports no warnings in any file added by this series; the ten\n    reports it does produce are all in pre-existing files the series\n    does not touch\n  - the full 71-assertion hardware suite was also run under Valgrind\n    Memcheck on the target host: no memcheck record originates in the\n    added code, and nothing is definitely or indirectly lost\n\nTC4x support is inherited from the original fork and is not covered by\nthe hardware testing above; no TC4x device was available.\n\nNotes for reviewers\n-------------------\n\nProgram flash on TC3xx is visible twice, as a cached alias in segment 8\nand a non-cached alias in segment A. The reset vector lives in the\nnon-cached alias, so images are commonly linked there. The board\nconfiguration declares the physical banks once and exposes the second\nview with the existing \"virtual\" flash driver, in the same way the\nPIC32MX configurations handle kseg0/kseg1. Declaring the same physical\nflash twice would give each bank a private sector array, and the erase\nstate of the two views would then diverge.\n\nThe Infineon DAP support is deliberately scoped to what this hardware\nneeds. The original author notes that the protocol integration is not\nfinished and that features such as sleep mode and password protection\nare still being worked on downstream, so the internal API should not be\ntreated as settled yet.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"change_message_id":"6725a5106636b4a53d168a33936d2a3a9e540c62","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ce6270e6_4a516c3c","in_reply_to":"0669324f_41a0a94b","updated":"2026-09-08 10:56:15.000000000","message":"Thanks for the nice contribution! I will probably get access to some boards and will test the patches.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"83cd1b91ed7127f26a07ccdf8b598fdd713f216d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7cdb4800_bd45c4af","in_reply_to":"40ccd84f_2cf0a483","updated":"2026-08-30 22:55:40.000000000","message":"Ack","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"83cd1b91ed7127f26a07ccdf8b598fdd713f216d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4452d0f4_d4fcef87","in_reply_to":"5650c66e_fd5fa4e9","updated":"2026-08-30 22:55:40.000000000","message":"Ack","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"04ea81a7dcd22d087a1781c0716027030cf54a0f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0669324f_41a0a94b","in_reply_to":"58a26d55_71a53471","updated":"2026-08-31 14:59:58.000000000","message":"I do not have any relation with Infineon, except that in my project I run under STM, NXP and Infineon. I made it this work for my current project and I am available to push this to the open source, I do not have board at home but I already buy one for me to be able to also progress from home.\n\nI do not receive any money to push this further, this is literally my free time to collaborate with openocd. I will maintain this code until Infineon take over, until there I will be more than happy to test it any modification with limited board available in my side.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"9f8f434a8f03cf9f037b8f670c25fb834ee00c21","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"5650c66e_fd5fa4e9","in_reply_to":"6bb8a760_84772daf","updated":"2026-08-30 14:41:31.000000000","message":"Let\u0027s see how the review goes on before planning any rework. I\u0027m quite busy and slow, recently. Sorry for that.\n\nIf you I see the reply in\nhttps://community.infineon.com/t5/AURIX/DAP-Transmission-Protocol/td-p/1139898\n\"... data format and protocol specification are not publicly available and require special access from Infineon ...\"\nApparently the spec is available under NDA. You could try querying them.\nPersonally, I\u0027m not going to ask them. Being employed by one of Infineon competitor would make my NDA process much more complex, even if my contribution to OpenOCD is mostly for personal interest.\n\nI see that you can require some free sample board on Infineon website.\nBut they automatically drop requests coming from @google.com accounts, so I\u0027m not going to waste my time contacting them.\n\nFor my future rework of the transport layer, I will eventually ask for your help to validate the functionality my code.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"dd8ee1bc6479960d12f4b11cbc534eff3d0ff280","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d995dc77_b270cce8","in_reply_to":"c36256d9_5ec93fcb","updated":"2026-08-28 16:44:29.000000000","message":"Hi Rafael,\nthanks for this interesting series. I have run a quick check at its content and I appreciate the clean split in (almost) simple patches. I will soon look better at them.\nIt looks like you are not in Infineon.\nChristophe, the maintainer of  https://github.com/tricore-oss , doesn\u0027t want to get involved and I respect that.\nIf this pull request is not sponsored by Infineon, who would be our contact for any future maintenance issues related to this code? What would be your future involvement?\n\nI\u0027m preparing a rework for the way we handle the different transports and the addition of ifxdap will clearly add extra effort to such rework.\nI\u0027m not familiar with Infineon documentation, but I haven\u0027t found a spec of ifxdap. Can you point to some public documentation?\nHow to get one entry level board to validate further reworks at ifxdap transport and target level?","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"8159edb2a1f01828a7945a5d4b63a50f292388f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"58a26d55_71a53471","in_reply_to":"d05eb70e_c7ddc9c1","updated":"2026-08-31 13:45:56.000000000","message":"Hello Christphe,\nthanks for the clarifications.\nIt\u0027s a fact that big companies try to over-protect info on internal implementations. I have similar issue while providing support for ST-Link in OpenOCD.\nAnyway it would be nice to see this series merged in OpenOCD.\nI don\u0027t know how you and Rafael will split the activity, but I would really appreciate your supervision on the code review to spot any eventual error or modification that could prevent further evolution of the code for the devices not yet addressed.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"351bb64d3c28dfb5584c9578ab7ce8c2cc20a072","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6bb8a760_84772daf","in_reply_to":"d995dc77_b270cce8","updated":"2026-08-28 21:25:22.000000000","message":"First, sorry. If you want I can split the patches even more.\n\nHere is a summary for your questions:\n\n- target/aurix/tricore.c\n  - Is public: Yes\n  - TriCore TC1.6.2 Core Architecture Manual Vol 1 documents DBGSR, the trigger event unit (TRnADR/TRnEVT) behind breakpoints/watchpoints, and CSA\n\n- flash/nor/aurix_eflash.c\n  - Is public: Yes\n  - AURIX TC3xx User Manual, flash/PMU chapter, command sequences and the FSI timings your code already cites.\n\n- transport/ifxdap.c + DAP wire protocol\n  - Is public: No\n  - No standalone public spec. My ifxdap knowledge is inherited from Christoph\u0027s fork.\n\nThis is the board that I made it the tests: https://www.ehitex.de/en/starter-kits/for-aurix/2705/kit-a2g-tc375-lite\n\nI add in the test commit a test-aurix-hardware.cfg (with 71 tests). I can also be a point of contact for this code, I will buy an entry level TC4 as well (but I do not have one yet).\n\nThis is a personal effort to be able to flash tricore on arm64 linux and I think is a nice for the community. (you can see that jenkins failed on the windows build this is how much I use windows)","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002515,"name":"Christoph Seitz","email":"christoph.seitz@infineon.com","username":"go2sh"},"change_message_id":"5b40c909b22d8d76fd068eae402b3f1e4ec16739","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d05eb70e_c7ddc9c1","in_reply_to":"d995dc77_b270cce8","updated":"2026-08-31 12:24:26.000000000","message":"Hello Antonio,\n\nI’m the original author of the tricore support and owner of the tricore-oss org.\n\nI just want to comment here for transparency.\nRafael contacted me and I agreed to the upstream efforts.\n\nBut I haven’t done any effort till now due to two reasons:\n- My role at IFX is not to maintain openocd. I spent the effort to create it during my spare time and use it regularly for Zephyr development.\n- Part of the debug core and the Infineon DAP protocol is under NDA and I’m not comfortable working on this portion of the code. There are multiple sources available wit reverse engineered portions and the IFX TAS server is publicly available. this encapsulates the ifx DAP protocol to a highlevel API, which I used in my original port.\n\nI asked our internal team if we can publish the DAP spec, there is also internal discussion to use openocd more. maybe the can lead to some maintainer from IFX and a board for openocd to test. the boards are publicly available to buy, though.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"5d3c2b90168c32f112a52116d3a93977657ae21c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c36256d9_5ec93fcb","in_reply_to":"f99e9b71_12b18596","updated":"2026-08-28 14:10:38.000000000","message":"Done","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"}],"doc/openocd.texi":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"9f8f434a8f03cf9f037b8f670c25fb834ee00c21","unresolved":true,"context_lines":[{"line_number":4035,"context_line":"@cindex Infineon DAP"},{"line_number":4036,"context_line":"@cindex DAP, Infineon"},{"line_number":4037,"context_line":"The Device Access Port (DAP) is the debug protocol used by the Infineon AURIX"},{"line_number":4038,"context_line":"family of automotive microcontrollers. It is a two-wire protocol and is"},{"line_number":4039,"context_line":"unrelated to the ARM ADIv5 Debug Access Port that shares the same acronym."},{"line_number":4040,"context_line":""},{"line_number":4041,"context_line":"Debug transactions are not carried by a JTAG scan chain but by the On-Chip"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"09cd6054_54f1e1dd","line":4038,"updated":"2026-08-30 14:41:31.000000000","message":"Reading in Infineon documentation, beside the clock wire, DAP can support 1, 2 or 3 data wires. So it\u0027s a two/three/four-wires protocol, while the current driver supports only the simpler two-wire mode.\nMaybe good to mention it here.\n\nMaybe also good to mention that the protocol is proprietary.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"},{"author":{"_account_id":1002562,"name":"Rafael J. Cruz","display_name":"Rafael J. Cruz","email":"rafa.junio@hardenedlinux.org","username":"rafajunio","status":"hardenedlinux"},"change_message_id":"83cd1b91ed7127f26a07ccdf8b598fdd713f216d","unresolved":false,"context_lines":[{"line_number":4035,"context_line":"@cindex Infineon DAP"},{"line_number":4036,"context_line":"@cindex DAP, Infineon"},{"line_number":4037,"context_line":"The Device Access Port (DAP) is the debug protocol used by the Infineon AURIX"},{"line_number":4038,"context_line":"family of automotive microcontrollers. It is a two-wire protocol and is"},{"line_number":4039,"context_line":"unrelated to the ARM ADIv5 Debug Access Port that shares the same acronym."},{"line_number":4040,"context_line":""},{"line_number":4041,"context_line":"Debug transactions are not carried by a JTAG scan chain but by the On-Chip"}],"source_content_type":"text/x-texinfo","patch_set":1,"id":"21ab5a50_6c2f26d2","line":4038,"in_reply_to":"09cd6054_54f1e1dd","updated":"2026-08-30 22:55:40.000000000","message":"Done, thanks.","commit_id":"2384627f986dc9aed3aa5015719a7e33be602a1b"}]}