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

Hi Mohamad,

What exactly was too difficult? Really the only thing that needs to be changed about the software is the setting of the SDER register so that SUIDEN and SUNIDEN are enabled. There's quite a lot of discussion in the aforementioned thread, but the real meat of it is that sequence that is in the "Correct Answer":

1. +        val = 0b11; 
2. +        asm volatile("mcr p15, 0, %0, c1, c1, 1" : : "r" (val));

Your compiler may disagree about the encoding of the value, "val = 0x3" is the same thing. Note you may need an "isb" instruction after the write for the authentication controls to synchronize to be correct.

If the purpose of your using Streamline is that PMU counters will count while in Secure PL0 (i.e. while applications are running, not just the kernel), then SUNIDEN needs to be set, at the very least, by at least some part of the system software stack while in a Secure Privileged mode. On i.MX6Q the entire stack runs in Secure state, so you have a choice of U-Boot or the Linux kernel -- including modifying gator.ko to do the work for you. While in Secure state, those two bits are relevant.

Ta,

Matt

Hi Mohamad,

What exactly was too difficult? Really the only thing that needs to be changed about the software is the setting of the SDER register so that SUIDEN and SUNIDEN are enabled. There's quite a lot of discussion in the aforementioned thread, but the real meat of it is that sequence that is in the "Correct Answer":

1. +        val = 0b11; 
2. +        asm volatile("mcr p15, 0, %0, c1, c1, 1" : : "r" (val));

Your compiler may disagree about the encoding of the value, "val = 0x3" is the same thing. Note you may need an "isb" instruction after the write for the authentication controls to synchronize to be correct.

If the purpose of your using Streamline is that PMU counters will count while in Secure PL0 (i.e. while applications are running, not just the kernel), then SUNIDEN needs to be set, at the very least, by at least some part of the system software stack while in a Secure Privileged mode. On i.MX6Q the entire stack runs in Secure state, so you have a choice of U-Boot or the Linux kernel -- including modifying gator.ko to do the work for you. While in Secure state, those two bits are relevant.

Ta,

Matt

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