Thanks Antonio. You are correct about the DAP+AP replacing the DTM. We are good with the approach of inferring no-DTM configuration based on the presence of the -dap and -ap-num flags.
Regards, Agnelo ________________________________ From: Antonio Borneo <[email protected]> Sent: Saturday, October 25, 2025 10:04 PM To: Agnelo Dcosta (QUIC) <[email protected]> Cc: Tony Ferranti OS <[email protected]>; OpenOCD <[email protected]>; Ashi Gupta <[email protected]>; Shaik Imran (Temp) <[email protected]>; Daniel Goehring OS <[email protected]>; Tomas Vanek <[email protected]> Subject: Re: OpenOCD support for debug of non-ARM subsystems accessible via ARM ADI DAP WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Thu, Oct 23, 2025 at 7:33 AM Agnelo Dcosta (QUIC) <[email protected]> wrote: > ... > > Qualcomm's implementation of RISC-V does not include the optional DTM (Debug > Transport Module). > The current OpenOCD RISC-V code considers that the DTM is always > implemented/present. Not an expert on riscv but, from what I read in the document "RISC-V External Debug Support Version 0.13.2", DTM is the converter from the external JTAG interface to the internal DMI bus where all the DMs are connected As far as I understand, the Qualcom chip uses an ARM DAP to convert from the external JTAG/SWD to the internal debug bus where there are few APs. One of the APs provides access to the DMI bus; the DMs are accessible through the AP. Practically DAP+AP replaces the DTM. If this is the case, then we don't need an additional flag -dtm <true/false>. When the command 'target create' has the options -dap and -ap-num instead of -tap, then it means no DTM. Or, if you prefer, consider the option -tap as "with DTM" and -dap/-ap-num as "without DTM and with DAP". In the code for rp2350 that Tomas referenced, I can see an implementation that apparently matches what I wrote. The flag alternative_dmi is set when the DAP is selected. I have not checked the whole code. I let Tomas reply if there is anything wrong in my understanding of his code. > IMO, we need to add flexibility to support both these RISC-V configurations - > with DTM and without DTM. > To facilitate this, I suggest that we add another option -dtm <true/false> > to the RISC-V configuration options. Not specifying this option should imply > that the DTM is present. Regards Antonio
