Hi Steve
On 06/03/2023 05:54, Steve Clevenger wrote:
An Ampere Computing design decision is MMIO reads are considered the same as an external debug access. If TRCOSLAR.OSLK is left set, the TRCIDR1 access results in a bus fault followed by a kernel panic. A TRCIDR1 read should be valid regardless of TRCOSLAR.OSLK provided MMIO access (now deprecated) is supported.
The Ampere work around is to early clear ETM TRCOSLAR.OSLK prior to TRCIDR1 access. Do not distinguish between manufacturers. AC03_DEBUG_06 is described in the AmpereOne Developer Errata:
Add Ampere ETM PID required for Coresight ETM driver support.
https://solutions.amperecomputing.com/customer-connect/products/AmpereOne-de...
Signed-off-by: Steve Clevenger scclevenger@os.amperecomputing.com
I went back to the CoreSight ETM4x architecture and this is not an erratum at your end. This is actually a bug in the ETMv4 driver.
TRCIDR1 is part of the "Trace" and not "Management" registers of ETMv4. Access to "Trace" registers without OSLK is going to cause issues. (Un)Fortunately, we never hit this on existing systems, but that doesn't mean it can stay there.
So we should really fix our detection and only rely on accessing the TRCDEVARCH to detect the device to be ETMv4.
I have a sent out the fix here [0], are you able to test it :
[0] https://lkml.kernel.org/r/20230317115728.1358368-1-suzuki.poulose@arm.com
Suzuki