No events data on the ARM DS-5 streamline with the sabrelite i.mx6 quad core

Hi elahmad,

L2C-310 shouldn't be affected at all by the contents of SDER, you're right. It must be some other problem.

If you're using "userspace perf" via Streamline, then this will be 100% the problem you have. There is no perf driver for the L2C-310 performance counters.

For that you would needfully be using the gator.ko module which implements the support via a slightly obscure method (remapping the L2C-310 registers that are already mapped by the kernel to effect cache operations) -- are you using gator.ko module or just the daemon alone?

Ta,

Matt

Hi elahmad,

L2C-310 shouldn't be affected at all by the contents of SDER, you're right. It must be some other problem.

If you're using "userspace perf" via Streamline, then this will be 100% the problem you have. There is no perf driver for the L2C-310 performance counters.

For that you would needfully be using the gator.ko module which implements the support via a slightly obscure method (remapping the L2C-310 registers that are already mapped by the kernel to effect cache operations) -- are you using gator.ko module or just the daemon alone?

Ta,

Matt

hi mwsealey,

Yes, I am using the gator.ko module with the daemon, from my first steps in this work I use gator.ko + daemon.

I don't know if the version of the used gator.ko is the main cause, but normally it's recommended to use gator.ko who has the same version like the installed DS-5.

regards,

Mohamad

Hi Mohamad,

Can you tell if driver/gator_events_l2c-310.c code "gator_events_l2c310_probe" or "gator_events_l2c310_init" actually ran, and whether the event interface actually got installed? A few kprintfs just to see it initialize and load and whether it worked at all might be prudent.

Once we confirm it installed and that the registers react the only other possibility that comes to mind is that the debug authentication signal SPNIDEN is not asserted, although this would be extremely strange for CPU counters to increment without this, SDER overrides it for non-privileged modes (you may be seeing some drops in counts when entering the kernel and going back to the application they might start up again). The L2C-310 implements a debug register (at offset 0xF40) and bit 2 should report the value of SPNIDEN input to the cache controller. If it's 0, this would be down to some kind of security infrastructure within the SoC, however - I did recall this note in the i.MX6SX Chip Errata documentation though related to a PMU erratum:

(My emphasis). I do not know if that actually means anything, and in any case would be a question for NXP what "not support[ed]" means. As above there is a somewhat slim chance that SPNIDEN is not integrated in a configurable way and would always be disabled, or it could just be a statement of support of the standard BSP package.

We really think you may have to talk to your local NXP Support on this issue as we've somewhat exhausted possibilities for changing this from the ARM side of the equation if SPNIDEN is 0. If it's 1, then we have something more esoteric going on.

Ta,

Matt