Stuart Watt

I am trying to get the ARM performance assessment setup working (I'm trying to get Mali profiling for OpenCL code) on the Rock 5B+, and I've hit a blocker. The main component to this is some kernel configuration (CONFIG_ARM_SPE_PMU) and a loadable module. Oddly, those work fine in a custom kernel build. What I am hitting appears to be some missing interrupt setup that renders all those components inert. (It has to be a custom build to get CONFIG_ARM_SPE_PMU set. The issue is that even with the kernel configured and the module loaded, the SPE component remains inactive. ARM has its own system report tool which analyzes a setup, and that tool is reporting an issue: And indeed, nothing seems to show in cat /proc/interrupts. The man page for the module suggests this is the issue: It says: KPTI is definitely disabled and the SPE PMU loads (it's in lsmod) but it still doesn’t show in /sys/bus/event_source/devices/. Nothing relevant seemed to show in dmesg either. Frankly, I have no idea where to look for the SPE interrupt, or how to set it up. If anybody has any pointers or suggestions, I'd be extremely grateful.

So I'm fairly new to Armbian (although I have already managed to successfully create a custom build with most of what I need). Sadly, I've very much hit a blocker. I really need to use linux-tools/perf on an RK3588 board with a vendor kernel (I'm using the Mali OpenCL, and the ARM packages are mostly locked) and I need to do some performance tuning. I cannot figure out how to get these tools deployed. 1. There are no linux-tools packages build -- which is fair enough, I'm probably in a minority. Some parts of the tools directories are culled during a cleaning process for the headers, I can see that 2. I am happy to copy over the kernel source and build on the device, but this is a patched vendor kernel. Can I just rsync across `cache/sources/linux-kernel-worktree`? Is that the patched kernel source tree? 3. There are some old allusions in the forums to using armbian-config to get sources -- I'm guessing that's long deprecated 4. Would it be appropriate at some point to create a .deb for the actual kernel sources, just in case -- or even, ideally, the linux-tools packages themselves? I am very happy to invest effort into helping make this happen, but I am starting from cold into this fairly complex build infrastructure, so any help or pointers I'd be extremely grateful.