search

ARMmbed / DAPLink

https://daplink.io
Apache License 2.0
2.32k stars 977 forks source link

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

Open gzied opened 3 years ago

gzied commented 3 years ago

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

Kind Regrads Zied Guermazi

flit commented 3 years ago

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 commented 3 years ago

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

https://user-images.githubusercontent.com/44730148/108120370-73379480-70a1-11eb-992d-7905e8769a19.mp4

/Zied

flit commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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

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 commented 3 years ago

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 commented 3 years ago

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:

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 commented 2 years ago

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