I am currently trying to extract the performance events information from the sabrelite i.mx6q (https://boundarydevices.com/product/sabre-lite-imx6-sbc/ )
I have successfully integrated the gator daemon - driver after kernel compiling in order to enable the recording data on the ds5 streamline analyzer (Streamline Performance Analyzer – DS-5 Development Studio – ARM Developer ).
The ARM energy probe is connected. on the DS-5 GUI after a test record, I can see the percentage of the CPU activity, the clock frequency/cycles and also othe informations (please see the attached figure). But the problem that is there are any information from the available events related to the cores-events or to the cache-events. all the values of these events are zero knowing that the cores execute applications during the records.
I would like to know what is the problem.
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:
i.MX6 does not support PMU (Performance Monitoring Unit) hence this ARM errata is not applicable.
(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
I had the same problem. To make sure that the PL310 counters were correctly programmed in the gator.ko module, I stepped through the gator.ko module with the DS-5 kernel debugger and DSTREAM unit. That accidentally made the PL310 performance counters come to life.
This is actually described in i.MX6 errata ERR006259, although not very clear:
When JTAG_TCK is not toggling after power-on reset (POR), the ARM PMU, PTM, and ETB stayin their disabled states so various debug and trace functions are not available.
Provide at least 4 JTAG_TCK clock cycles following POR if the PMU, PTM and ETB functionswill be used. A free-running JTAG_TCK can also be used.
It looks like the Cortex-A9 PMU counters are not affected by the presence or absence of a JTAG clock, but the PL310 counters are.