Hi Yabin

On 26/08/2023 01:30, Yabin Cui wrote:

Hi Suzuki,

When I saw the crash, the kernel log stopped immediately before "devarch = read_etm4x_sysreg_const_offset(TRCDEVARCH);". And then the device rebooted. The reason for the reboot is watchdog crash.

Isn't there any way to collect information from your hypervisor ?

If EL2 doesn't allow accessing the TRC* registers via system instruction interface, why can't I find any description in the ARM manual?

Please look at the description for HDFGRTR_EL2/HDFGWTR_EL2 for more information on this.

e.g., HDFGRTR_EL2:TRCID controls read access to TRCDEVARCH, which is where you hit the crash.

And from my understanding, ETE is still powered on even when the cpu is idle. Can it not be powered? There is extra clock enabling work when using the iomem interface, I will try if it matters.

As I mentioned, this is very unlikely. Most likely, your hypervisor is at fault.

Suzuki

Thanks, Yabin

On Fri, Aug 18, 2023 at 1:47 AM Suzuki K Poulose <suzuki.poulose@arm.com mailto:suzuki.poulose@arm.com> wrote:

Hi Yabin

On 17/08/2023 22:06, Yabin Cui wrote:
 > Hi coresight driver maintainers,
 >
 > I am from the Android toolchain team. I am trying to use ETE
(Embedded
 > Trace Extension). But on my device, the system crashes when the ETM
 > driver is trying to read TRCDEVARCH via sysreg interface.

When you say crashes, what exactly is reported ? Does the kernel
get an exception ? Or system hangs completely ?

I suspect :

1) You are running some hyp at EL2, which doesn't allow
     accessing the TRC* registers and injects a Illegal instruction ?
2) If not the above, the ETE is not powered (very unlikely)


Suzuki


 > In
 >
https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1045 <https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1045> <https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1045 <https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1045>> :
 >
 > static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata,
 >     struct csdev_access *csa)
 > {
 > u32 devarch;
 >
 > if (!cpu_supports_sysreg_trace())   <- this returns true
 > return false;
 >
 > /*
 > * ETMs implementing sysreg access must implement TRCDEVARCH.
 > */
 > devarch = read_etm4x_sysreg_const_offset(TRCDEVARCH);  <- never
see the
 > message logged immediately after this line, so should abort here.
 >    ...
 > }
 >
 > Do you have any suggestions on how I can debug the problem? Is
there any
 > other place making sysreg interface to ETE not accessible? Or can
the
 > ETE sysreg interface not be implemented?
 > I tried the memory mapped register interface of ETE, it works
fine. The
 > only change I need is to bypass the devarch version check
 > in etm4_init_iomem_access, in in
 >
https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1082 <https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1082> <https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1082 <https://github.com/torvalds/linux/blob/master/drivers/hwtracing/coresight/coresight-etm4x-core.c#L1082>>
 > I wonder if we can allow iomem access for ETE if the sysreg access
 > doesn't work on some devices.
 >
 > Thanks,
 > Yabin