Does OpenOCD have any plans to support RISC-V trace?

[zhangdujiao]

Currently, GDB + OpenOCD only supports debugging of RISC-V SoC. It should not be able to directly access trace components such as the Trace Encoder and SMEM. Furthermore, it cannot parse trace data. Is there a plan to support trace functionality?

[TommyMurphyTM1234]

A previous issue that may also be relevant here:

• [Q] Parallel TPIU trace on Segger J-Trace Pro? #715

It should not be able to directly access trace components such as the Trace Encoder and SMEM.

Did you mean "it should be able to ..." here?

As far as I recall, OpenOCD has basic support for some trace mechanisms (e.g. Arm ETM) but I think just for collecting and dumping the raw or pre-processed data out for analysis elsewhere. Rather than, for example, doing real time tracing?

• https://github.com/openocd-org/openocd/blob/master/src/target/etm.c

The user manual also mentions different trace mechanisms:

• https://openocd.org/pages/documentation.html

But this means that there may already be some abstract/generalised trace layer in OpenOCD under which support for a (the?) RISC-V trace mechanism could perhaps be added?

• https://github.com/openocd-org/openocd/blob/master/src/target/trace.c

Might be worth asking on the OpenOCD mailing lists for opinions on how adding RISC-V trace support might be approached?

• https://openocd.org/pages/mailing-lists.html

I don't know if anybody else has maybe forked OpenOCD and tried adding RISC-V trace support but I couldn't find anything at a glance...

[zhangdujiao]

As far as I recall, OpenOCD has basic support for some trace mechanisms (e.g. Arm ETM) but I think just for collecting and dumping the raw or pre-processed data out for analysis elsewhere. Rather than, for example, doing real time tracing?

Thanks Tommy,
Just collecting and dumping raw trace data is enough probably, we can develop the decoder by ourselves, since OpenOCD may not be able to decode the RISC-V format trace data, even though the E-Trace spec has already frozen.

Might be worth asking on the OpenOCD mailing lists for opinions on how adding RISC-V trace support might be approached?

will try, thanks

I don't know if anybody else has maybe forked OpenOCD and tried adding RISC-V trace support but I couldn't find anything at a glance...

we will find also

[TommyMurphyTM1234]

It might also be useful to clarify what RISC-V standards are relevant here. For example, I can see two here:

• https://riscv.org/technical/specifications/
  • https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications
    • Efficient Trace for RISC-V
    • Unformatted Trace & Diagnostic Data Packet Encapsulation for RISC-V

But there may be other standardised or proprietary specifications that are also relevant.

And, in relation to the original query - "Does OpenOCD have any plans to support RISC-V trace?" - as ever, what (if anything) happens in this context depends on who might have enough interest, capacity and resources to commit to making progress in terms of implementing this support. This may be interested individuals, companies, other organisations, etc. And, unfortunately, a lot of the time the required resources are simply not (made) available.

[zqb-all]

I've seen some trace support in Nuclei OpenOCD:

• https://github.com/riscv-mcu/riscv-openocd/blob/6d4b4b8d7d1e0a577b7c95cf7ffacf6728c66192/src/target/riscv/etrace.c

We're also interested in trace support, but haven't started making any changes in OpenOCD yet.

[zhangdujiao]

It might also be useful to clarify what RISC-V standards are relevant here

Yes, there are two RV trace standards, E-Trace (https://github.com/riscv-non-isa/riscv-trace-spec) and N-Trace (https://github.com/riscv-non-isa/tg-nexus-trace). There is no unified protocol standard, which also poses a challenge to the trace support of OpenOCD.

[zhangdujiao]

We're also interested in trace support, but haven't started making any changes in OpenOCD yet.

Many thanks! very useful information.
We will continue to find a way for trace support by OpenOCD.

[TommyMurphyTM1234]

Yes, there are two RV trace standards, E-Trace (https://github.com/riscv-non-isa/riscv-trace-spec) and N-Trace (https://github.com/riscv-non-isa/tg-nexus-trace). There is no unified protocol standard, which also poses a challenge to the trace support of OpenOCD.

Why doesn't the second one (N-Trace) appear here or is it a proprietary rather than an "official" RISC-V International spec?

It might also be useful to clarify what RISC-V standards are relevant here. For example, I can see two here:

• https://riscv.org/technical/specifications/

  • https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications

    • Efficient Trace for RISC-V
    • Unformatted Trace & Diagnostic Data Packet Encapsulation for RISC-V

But there may be other standardised or proprietary specifications that are also relevant.

Edit - oh, Nexus Trace appears here:

• https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154861/RISC-V+Specification+Status

but not here:

• https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications

because it is not ratified yet.

As ever, the preponderance of RISC-V related specifications/extensions causes me no end of confusion when trying to find the master source of authoritative info. :-(

[zhangdujiao]

because it is not ratified yet.

Yes, exactly. As far as I know, N-Trace is proposed by SiFive, and this N-trace encoder is only strongly bound to the SiFive core. E-trace is proposed by UltraSoc (SIEMENS now), which can be supported by a trace IP independently.

As ever, the preponderance of RISC-V related specifications/extensions causes me no end of confusion when trying to find the master source of authoritative info. :-(
yeah... openness and uncertainty coexist, that's RV :)

[aap-sc]

@zqb-all , @zhangdujiao , @TommyMurphyTM1234

I don't think that support for RISC-V trace decoding and collection belong to OpenOCD project. To me it seems probable that we could support some support for tracing controls, however (see below).

There are indeed two different versions of trace spec. However, they both have common functionality described in a separate documents:

• Ingress port (Hart to encoder interface). Defined in chapter 4 of E-trace spec (what a mess...)
• RISC V Trace Control Interface (https://github.com/riscv-non-isa/tg-nexus-trace/blob/main/docs/RISC-V-Trace-Control-Interface.adoc)

The latter is deemed to be shared between E-Trace and N-Trace specifciations. So the it somewhat renders the concern raised @zhangdujiao as mostly obsolete:

There is no unified protocol standard, which also poses a challenge to the trace support of OpenOCD.

Since there is a common control interface, then this can be supported.

Moreover, I see that we have a MR (riscv-software-src/riscv-isa-sim#1824) that implements some initial support n-trace encoder in spike and looks like we have a rudimentary implementation of trace control device here (ucb-bar/spike-devices#8). So probably, it would not hurt to keep tabs on the relevant updates.

However, regarding this request from @zhangdujiao :

Furthermore, it cannot parse trace data. Is there a plan to support trace functionality

I don't think it is the task of OpenOCD to parse trace data. There are few issues:

1. Typically trace data is sent to a dedicated sync and is expected to be read via separate interface like trace port. OpenOCD focuses on JTAG/swd and does not provide support for interaction with other interfaces.
2. Even if memory sync is used - the amount of data generated by trace is way too much to transfer over JTAG. Looks like for this task a specialized SW is needed anyway. So having support of trace decoder in openocd codebase seems impractical to me.

@en-sc , @JanMatCodasip FYI.

[zqb-all]

I don't think that support for RISC-V trace decoding and collection belong to OpenOCD project.

Agree. ARM coresight decoder is supported by a separate project at https://github.com/Linaro/OpenCSD. Perhaps riscv will have a similar project in the future, but this is beyond the scope of OpenOCD.

[JanMatCodasip]

I share @aap-sc's opinion on the trace data transfer issues:

• OpenOCD is JTAG-centric but RISC-V N-Trace defines other interfaces that OpenOCD does not support. Like the "pins" interface (PIB - Pin interface block).
• JTAG typically will not have sufficient throughput for trace data transmission.

[zhangdujiao]

I don't think that support for RISC-V trace decoding and collection belong to OpenOCD project. To me it seems probable that we could support some support for tracing controls

Yes, agree. It seems the proper and only way for OpenOCD to support RISC-V trace control, i.e. to access TE, SMEM components as RISC-V trace spec defined. Now, the OpenOCD could only access DM (Debug Module), right?

However, they both have common functionality described in a separate documents:

• Ingress port (Hart to encoder interface). Defined in chapter 4 of E-trace spec (what a mess...)
• RISC V Trace Control Interface (https://github.com/riscv-non-isa/tg-nexus-trace/blob/main/docs/RISC-V-Trace-Control-Interface.adoc)

Yes, Both E-Trace and N-Trace share the same ingress port and control registers. The difference is the principle of trace data encoding and encapsulation.