[PATCH 2/3] coresight etm4x: Early clear TRCOSLAR.OSLK prior to TRCIDR1 read

Steve Clevenger scclevenger at os.amperecomputing.com
Fri Mar 17 13:53:32 PDT 2023


Hi Suzuki,

I don't need to test this explicitly provided the TRCIDR1 access is
removed in etm4_init_iomem_access. When I first encountered this, I
substituted a hard coded value for the TRCIDR1 read. This hack
eliminated the initialization problem. I later submitted a patch to
clear TRCOSLAR.OSLK before the access. I didn't have visibility to other
implementations which could rely on the fallback.

Thanks,
Steve

On 3/17/2023 4:58 AM, Suzuki K Poulose wrote:
> 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-device-documentation
>>
>> Signed-off-by: Steve Clevenger <scclevenger at 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



More information about the linux-arm-kernel mailing list