Re: OpenOCD support for debug of non-ARM subsystems accessible via ARM ADI DAP

[Agnelo D. (QUIC) <qui...@qu...>]

Thanks for your response Antonio!

>  What kind of configuration do you have? MEM-AP or JTAG-AP?
It is a MEM-AP configuration that is present.
 And with respect to ADIv6 - No, we are not using Nested APs

As I mentioned in my previous mail. we have some implementation that is working for us for RISC-V core debug via the ARM DAP. But it needs to be made more generic. With guidance and inputs from you guys we would be glad to contribute towards adding the MEM-AP debug support in a proper manner.

Regards,
Agnelo


________________________________
From: Antonio Borneo <bor...@gm...>
Sent: Thursday, October 2, 2025 3:57 PM
To: Agnelo Dcosta <ag...@qt...>
Cc: OpenOCD <ope...@li...>; Ashi Gupta <as...@qt...>
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 Wed, Oct 1, 2025 at 12:53 PM Agnelo Dcosta <ag...@qt...> wrote:
>
> Hi Antonio,
>
> On Qualcomm SoCs, along with the main ARMv8 CPU there exist several other subsystems/cores based on RISC-V, Xtensa and Qualcomm's own Hexagon DSP.  Debug access to these cores is provisioned via the main ARM ADIv5/v6 DAP.
> It appears, currently that there is no provision in the OpenOCD mainline to be able to debug non-ARM sub-systems accessible through the ARM DAP.
>
> For enabling debug of RISC-V cores on QCOM SoCs, we have experimented by making some hacks to the existing OpenOCD code and it is working for us.  We, however, are not quite sure whether our approach is right.
>
> Would like to get your perspective on
>     (a) whether such configurations for debug of non-ARM cores via the ARM DAP should/would be supported and
>     (b) if yes, what should the approach be

Hi Agnelo,

such mixed SoCs are getting common.
Also the new RPi2050 MCU should have both Cortex-M and RISC-V cores,
but I ignore the details.
So far there is no dev in OpenOCD for supporting such a mix, but any
contribution is welcome.

There are actually two ways to put a non-Arm core behind an Arm DAP:
- using a standard Arm memory Access Port (MEM-AP) to access the debug
bus of the non-Arm core;
- using an Arm JTAG-AP and then implement in the SoC a JTAG chain that
accesses the JTAG debug of the non-Arm core.

The first case should require:
- to provide the needed flags '-dap' and '-ap-num' to the command
'target create' (easy stuff)
- decouple the R/W access on the debug bus of the core from the
currently supported interface; there could be some JTAG API mixed in
the target's code
- check the presence of '-dap' info to switch between direct JTAG and
DAP (in case of DAP we already manage SWD/JTAG cases).

The second case is more tricky. While a preliminary support for
JTAG-AP has been proposed in gerrit, I rejected it as not properly
done.
I want to have OpenOCD supporting multiple interfaces, at first. I
mean handling two or more independent interfaces that connect to
independent SoCs
Once this is in place, the JTAG-AP should be added as a new interface,
driven by its parent DAP and by the parent interface.
This would allow addressing any possible core behind the JTAG-AP, with
minor modifications to the target's code.

What kind of configuration do you have? MEM-AP or JTAG-AP?

You also mention ADIv5/v6 DAP.
There is the ADIv6 feature of "nested APs" that is not supported yet
in OpenOCD (I should work on it in the next months).
It's possible to have in ADIv6 one AP that is mapped in the memory
space of a parent MEM-AP. This nesting can be multiple, with an AP
behind another AP that is behind another AP ...
If this is your case, keep in mind that it's not addressed yet.

Best Regards,
Antonio