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

Hi Mohamad,

I am not sure why the CPU cycles information isn't valid anymore. The NXP forum suggests there is some software (a github repository) providing some kernel module code. Please don't run this module, we don't actually need it (we just need the SDER configuration).

L2C-310 events are a different thing entirely, there shouldn't be any issue in counting these as long as software knows to read them. In gator.ko source code there's a file driver/gator_events_l2c-310.c -- and a function contained called "gator_events_l2c310_probe" -- but the function isn't instrumented to report whether it has successfully found the L2C-310, what the base address might be, and whether it is available to count these events. Is there a way you can add some kprintf() or pr_info() statements to tell whether it was successful or not? Note that some of the probe functionality relies on correct information in the platform Flattened Device Tree, if it does not find this information it will invariably fail since i.MX6Q is not one of the supplied known variants.

Again, at the top left of your Streamline window is a black-and-yellow bar with a warning symbol in it - there should be an informative tooltip. Does it say anything about the issue?

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