Debug and Trace Support on the Orion O6

#1

Hi,

please, is there support for any of the following on the O6?

  1. JTAG/SWD-based debug (if yes: on which connector/pins?)
  2. ETM instruction tracing to a memory buffer (e.g. to be used with the Linux perf tool)

Regards,
Mircea

#2

TRBE would probably work if it was described in the DT/ACPI tables. So for now, the answer is a resounding no. Same for SPE, by the way.

It is amusing that the very functionalities that would help bringing up this machine are not available…

#3

JTAG/SWD is available on the SoC, but it is not clear from the schematics if it is easily user accessible. I have already asked Radxa about this in the Debug Party thread but got no answer.

We live in an era where 99% of companies and users think that Debug == UART, it’[s infuriating. Almost no vendor cares about exposing proper connectivity for those that need it.

2 Likes
#4

We live in an era where 99% of companies and users think that Debug == UART, it’[s infuriating. Almost no vendor cares about exposing proper connectivity for those that need it.

I read you. But, on the other hand, in an ecosystem full of BSPs, private repos and minimal-if-at-all upstreaming, I can see why vendors see close-to-zero ROI in opening up interfaces that are meant (mostly) for system bring-up use-cases (e.g. bootloader/firmware and OS kernel debug/trace).

TRBE would probably work if it was described in the DT/ACPI tables. So for now, the answer is a resounding no . Same for SPE, by the way.

So all the silicon/RTL/RDL is in place, we’re missing “just” the DT/ACPI entries? It’s a bit sad because this is no longer about system bring-up, as this (instruction tracing) goes into pure user-space app debugging.

1 Like
#5

Well, it affects all the stack (I have zero interest in userspace, but very much interested in kernel-side tracing and profiling).

But the reality is that unless you want a feature that is supported out of the box without any requirement for firmware support, I would definitely recommend against buying this board.

#6

Are there any public ARMv8 (or even ARMv9) boards that you would recommend for ETMv4/ETE support (especially in the light of GDB btrace support)?

#7

None. I discount ETMv4 off the bat, since you need external HW to get the trace.ETE+TRBE is what is important for SW. And as far as I can see, there is none available to the mere mortal.

The sad state of affairs that if you want to optimize SW, use an x86 box and pray that your arm64 machine is going to give you a similar execution profile.