unfortunately I cannot use the csscan tool on my device, as it seems to use a compiler for getting the syscalls, which I do not have on my platform. Is there any other way to get the configuration?
It's using the C preprocessor to extract some syscall numbers from system headers. You probably need to patch iommap.py and find the line "[SYS_mmap, SYS_munmap] = ..." and put in the numbers directly. On my system this would be "[SYS_mmap, SYS_munmap] = [222,215]", but numbers on your system may vary. You might find them in /usr/include/asm/unistd.h or /usr/include/asm-generic/unistd.h under something like __NR_mmap or __NR3264_mmap. Or, if you've got 'strace' you could trace some commands and find them that way.
I'll look to see if there's any way to make iommap.py get these without relying on the C preprocessor.
iommap.py is now fixed to call libc.mmap - the direct syscall turned out to be unnecessary. csscan.py also has some tweaks to show older ETMs.
Looking at your trace data, the first frame starts by indicating trace stream 0x10, and then the address packet immediately follows. That suggests it's the first frame that the formatter has seen. If there were earlier frames (that you might be missing because of an ETF readout problem) the indicator would likely have been in those.
So it would appear the formatter never saw the A-sync. Are you able to double-check the order of enabling, and check that the buffer is enabled first, then the funnels, then the ETM last, so that when the ETM puts out its initial A-sync, it's not going to get lost? It's supposed to work like that already, but possibly it's gone wrong.
Al
Al
CoreSight mailing list -- coresight@lists.linaro.org To unsubscribe send an email to coresight-leave@lists.linaro.org
CoreSight mailing list -- coresight@lists.linaro.org To unsubscribe send an email to coresight-leave@lists.linaro.org