Based on the the build system I don't think what the hardware supports matters that much. We've always only built the ETM4 driver on Arm64 and only build the ETM3 driver on Arm32.
ETMv3/PTM don't support Arm64, so a trace driver in an Arm64 kernel will only need to drive ETMv4 (or ETE). There's no need to build ETMv3/PTM in 64-bit kernels.
But a 32-bit kernel could be running on a CPU with ETMv4 - this could be a legacy 32-bit kernel on a 64-bit-capable CPU, but there are pure 32-bit CPUs with ETMv4: Cortex-A32 is a 32-bit-only Armv8-A CPU with ETMv4 and all kernels on this CPU will be 32-bit. If the 32-bit kernel only builds the ETMv3/PTM driver, then it won't support trace on this CPU.
Al
I just found another bug which I think makes sense to log here. We've pretty much always turned on timestamps automatically in Perf, but for some reason the option validator in Perf thinks they're not supported in ETM3. The driver has always accepted it as an option so I'm not sure why. The end result is that the command will always fail, and you couldn't even undo it with "timestamp=0" until more recently when I fixed that.
Sysfs or per-thread Perf mode would be working, but it's one more bit of evidence to take in.
CoreSight mailing list -- coresight@lists.linaro.org To unsubscribe send an email to coresight-leave@lists.linaro.org