RFC: add an interface to support collecting ETM traces from a TPIU

[gzied]

Hi
GDB is now being extended to support using ETM traces in branch tracing. and the remote protocol is also extended accordingly. to enable PyOcd or OpenOcd to support this feature, the interface to the debugger needs to be extended, more precisely, the commands protocol over usb.
this extension is to enable

• getting the capabilities of the debugger (if it supports collecting the traces)

• getting infos about the tracing mechanism (supported port sizes, buffer size)

• start and stop collecting the traces

• get the status of traces collection

• get collected traces.
  here is a proposal for the extension, a reference dummy implementation can also be provided.

• Modified: Response to DAP_Info capabilities: add 2 bits to the capabilities response to indicate if "Trace Port Analyzer" is present or not and to indicate if "TPA Streaming" is supported or not. the size can now be 1 or 2 bytes.

• New: DAP_Info ID: TPA Port Sizes to get the list of supported port sizes, and its response

• New: DAP_Info ID: TPA Trace Buffer Size to get the size of the TPA buffer used to collect the traces, and its response
  see Dap_info.pdf for more details
  DAP_Info.pdf

• New: DAP_TPA_PortSize: command to set the size of TPA port
  see TAP_Port_size.pdf for more details
  TAP_Port_size.pdf

• New: DAP_TPA_Transport: to select the transport used for the traces (DAP_TPA_Data or separate WinUSB endpoint)
  see TPA_Transport.pdf for more details
  TPA__Transport.pdf

• New: DAP_TPA_Control: command to start/stop collecting traces
  see TPA_control.pdf for more details
  TAP_Control.pdf

• New: DAP_TPA_Status: get the status of traces collection.
  see TPA_status.pdf for more details
  TPA__Status.pdf

• New: DAP_TPA_Data: retreive collected ETM data.
  see TPA_Data.pdf for more details
  TAP_Data.pdf

Kind Regrads
Zied Guermazi

[flit]

Hi @gzied, I love the idea! It will take some time to review all the details you provided. Please give me some time to get back to you.

Btw, are you building a debug probe that will support ETM trace?

[gzied]

hi flit,
yes, I have developed a hardware prototype for a debug probe with support for ETM, and I have tested the interface using it with openocd.
you can also have a look on the changes in GDB for supporting btraces in gdb in the git https://github.com/gzied/binutils-gdb/tree/delivery_btrace_cs_etm.

I am attaching a video showing gdb extension to use ETM trace to do instructions history, function-calls history and process record and replay in forwards and backwards direction for a Linux process running on arm cortex A. the target of this RFC is to reach the same for cortex M

vokoscreenNG-2021-02-16_20-50-49.mp4

/Zied

[flit]

Really awesome work! 💯 I've been wanting to get trace support added to pyocd (primarily for Cortex-M) for some time, if I ever find time; this would be perfect to base that on.

[gzied]

for extending PyOcd to use coresight ETM for branch tracing you will need to implement the remote protocol extension specified in attached document
gdb_remote_protocol_extensions_etm_btrace.pdf
a reference implementation for gdb server can be found in the above mentioned git.

[flit]

Update: I am actually reviewing this, it's just taking time. 😄 My goal is actually that we'd see standard ETM/TPIU support added to CMSIS-DAP rather than a DAPLink-specific implementation. That will take a long time to make happen, but imo is the best possible outcome.

I will also make your gdb additions known to the Arm gdb team. So ideally the GNU Arm Embedded toolchain would include your changes. I have no idea how likely this is to happen, but it's certainly more likely if your changes are added to mainline gdb. Have you started the process of upstreaming your changes to mainline gdb?

Finally, do you have any more info on your debug probe? Is it open source hardware?

Thanks!

[gzied]

hi,
it will be nice if the ETM/TPUI can be added to CMSIS DAP this will make controlling the IP from within the MCU much easier. In between, you can have a look at:

• opencsal (https://github.com/ARM-software/CSAL).
• the Linux kernel sources (https://elixir.bootlin.com/linux/latest/source/drivers/hwtracing/coresight/coresight-etm.h),
• openocd (https://sourceforge.net/p/openocd/code/ci/master/tree/src/target/etm.c and etb.c.). Even though they are outdated or intended for Cortex-A, much of the implementation is still valid for Cortex M.

For getting the whole System running for Cortex M, GDB needs to be modified to collect, decode and process the traces, PyOcd needs to be modified to

• activate/deactivate tracing. ie configure ETM IP for starting and stopping traces generation and TPIU IP to get the trace out of the MCU
• drive a debugger able to collect the traces from TPIU
• exchange the traces and their configurations/parameters with GDB through the remote protocol.

here is an overview of the whole system.
https://lists.linaro.org/pipermail/coresight/2019-July/003021.html.

the process of upstreaming the change in GDB is already started, patches are already in the review process.

[ReinhardKeil]

Hi Zied,

this extensions are interesting, however the conflict already with extensions that we have in the works.
Please note that DAP-Link uses CMSIS-DAP as the the foundation project. This project is under https://github.com/ARM-software/CMSIS_5 and the relevant part is under
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/DoxyGen/DAP/src/dap_USB_cmds.txt.

Would you consider to re-arrange the command-ID of your extension and the bits for DAP_Info?

Reinhard

[gzied]

hi Reinhard,
thanks for pointing me to the specs. I based the extension on the available implementation (source code in git), and didn't notice the conflicts with the specs.
I spotted following conflicts in the command IDs:
CMD_ID (0x20) : DAP_UART_Configure / DAP_TPA_Transport
CMD_ID (0x21) : DAP_UART_Transfer / DAP_TPA_PortSize

Will it be fine to reserve the IDs (0x30)-(0x34) for the TPA related commands? This will reserve few IDs if you want to add another bridge (I2C or SPI...) in addition to the UART one. Please advise.

For DAP_Info, three sub commands were added:

• ID (0xF4) DAP_ID_TPA_PORT_SIZES
• ID (0xF5) DAP_ID_TPA_BUFFER_SIZE
• ID (0xF6) DAP_ID_TPA_FORMATTER // not yet published
  and they are not conflicting with any documented sub-command

the response to the DAP_Info capabilities sub-command (DAP_ID_CAPABILITIES) was extended with a second byte holding following info
byte 1 - Bit 0: 1 = Trace Port Analyzer Trace Port Analyzer is implemented (0 = not implemented).
byte 1 - Bit 1: 1 = TPA Streaming Trace is implemented (0 = not implemented).
and they are not conflicting with any existing bits in the response.

can you please give further details on the conflicts in the bits DAP_Info?
/Zied

[gzied]

Hi Reinhard,
I would like to reserve bits 1 and 2 of the second byte of DAP_Info Response (for ID=0xF0): for tpa. Will this be fine?
Kind Regards
Zied