On Thu, Aug 8, 2024 at 5:30 AM Ray Zhang <eggplant...@gmail.com> wrote: > > Hello everyone: > I'm new here and not familiar with the ways of how work is done here. > I want to discuss a new kind of way of improving the performance of > openocd. Currently, all JTAG/SWD low-level communication is done in > openocd, on the PC side. The debugger hardware is only a message > carrier. Many complex operations require long read-judge-write > operation in JTAG/SWD and require openocd to send plunty of low-level > data sequences through debugger, where latency from USB communication > reduces debug performance.
Hello Ray Zhang, what you say is true. The round-trip-time of the USB communication slows down the overall performance. In OpenOCD we try to 'queue' independent transfers to send them in a single shot over USB, but this is not always possible. Plus, some adapter's protocol has not been designed for such queuing, adding extra latency. > I am considering splitting openocd into two parts, one part on PC > handling GDB messages and high-level debug operations, the other part > on debug probes handling low-level communications so debug probes can > do lots of things, reducing time delay and bringing better > performance. That sounds clever, but for debugging only! Many extra commands and functionalities in OpenOCD have no corresponding command in GDB. Personally I work more at system debug, not at SW dev/debug, so I often use OpenOCD+telnet only. Quite a few times GDB is attached! But I don't expect this way of working to be too common. We already support in OpenOCD some 'high-level' adapters that try to do what you propose, but the overall result is disappointing. Each has its own protocol and limitations, and OpenOCD has to balance benefits and drawbacks to support them all. Here is the list, as far as I can remember: - STMicroelectronics STLink It was initially designed for Cortex-M debug/control, including for example a single command for reading all registers. To integrate it in OpenOCD was added the virtual 'HLA' target that carries plenty of limitations either in performance and in functionalities. At the end a USB2.0 FTDI chip FT232H runs debugging at almost the same speed! Later on, STLink implemented some lower lever commands, useful for debugging other CPUs, like Cortex-A, supported in OpenOCD by the 'dap-direct' backend. We are discussing dropping the support for HLA on STLink in OpenOCD and using 'dap-direct' only. - TI IDCI As far as I understand, this was a direct GDB server over USB. No need for any OpenOCD in between. But GDB commands are limited, so support for OpenOCD was added in the IDCI FW; again, Cortex-M only, again using HLA virtual target. I don't see it used anymore in new TI boards; now they use either ARM CMSIS-DAP or TI xds110. - Nu-Micro NuLink Another adapter using the HLA virtual target. Then, outside OpenOCD implementation, there is the 'Black Magic Debug' project. It implements a complete GDB server inside the adapter. The FW is open-source GPL-v3 and can also be flashed on several existing MCU boards. http://black-magic.org I never had time to test it, but sounds almost what you want to achieve. You could give it a try! Best Regards, Antonio > The preliminary idea is to remove all 'target' layers into the > embedded world and reduce 'jtag drivers' into one device since this > new software would only run on a specific hardware. The new hardware > would also be open source and the MCU inside is powerful enough to > handle target specific processings. > I have some knowledge in e&e and programming, both on PC and embedded > world, but before working on this I want to know other expert's > opinions and suggestions, and know if someone would join. > Thanks a lot. > Ray Zhang >
