On 02/10/2025 12:27, Antonio Borneo wrote:
On Wed, Oct 1, 2025 at 12:53 PM Agnelo Dcosta <[email protected]> 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
Hi Angelo,
actually there is a working RISC-V DM over ADI MEM-AP support in OpenOCD
forks
https://github.com/tom-van/openocd-rp2350-riscv (my development)
https://github.com/raspberrypi/openocd
The work was sponsored by Raspberry Pi Ltd.
It supports RISC-V cores in RP2350 chip and was also successfully tested
with
RISC-V coprocessor in nRF54L.
The new code was not upstreamed yet because it is based on the newer
RISC-V fork
https://github.com/riscv-collab/riscv-openocd
and we are currently working on syncing RISC-V updates to the upstream repo.
Regards
Tomas
