From: Dominik Huber dominik.huber@fau.de Sent: 30 April 2021 22:34 To: Mike Leach mike.leach@linaro.org; leo.yan@linaro.org Cc: coresight@lists.linaro.org; Al Grant Al.Grant@arm.com Subject: Re: Help sought on which approach to take for tracing with CoreSight
Hi Mike, Hi Leo,
On 28/04/2021 21:41, Mike Leach wrote:
HI Dominik,
On Wed, 28 Apr 2021 at 14:50, Dominik Huber dominik.huber@fau.de wrote:
On 23/04/2021 02:10, Leo Yan wrote:
Hi Dominik,
On Thu, Apr 22, 2021 at 04:24:26PM +0100, Mike Leach wrote:
[...]
> For now, I am going to try implementing the sysfs tracing, since > it seemed easier at first glance. I found the documentation for the .ini files within the snapshots, and am now trying to create my own version of them. But I'm struggling to get the addresses for all the devices, e.g. within cpu_0.ini.
You could download the snapshot .ini files for Hikey from: https://people.linaro.org/~leo.yan/opencsd/opencsd_hikey/hikey_snaps hot.tgz
Just clarify:
- The hikey_snapshot.tgz contains the configuration files which were manually edited by myself and I tested it can work with OpenCSD's snapshot tool;
- I think you could continue to use CSAL tool to continue to retrieve the registers, so that can use the dumping registers to double check the settings in .ini.
I might have found an easier way to figure out the register addresses than building a csinfo and running csinfo.py. Perf script -D prints a lot of extra information, among others:
... Magic number 4040404040404040 CPU 7 TRCCONFIGR 0 TRCTRACEIDR 1e TRCIDR0 28000ea1 TRCIDR1 4100f403 TRCIDR2 488 TRCIDR8 0 TRCAUTHSTATUS cc
This is printing out the values that were captured in whatever perf.data file you are looking at. If you want the actual values on the current machine, you can find them in e.g. /sys/bus/coresight/devices/etm0/trcidr/trcidr9.
Compared to Leo's snapshot the TRCIDR9 - 13 are missing, the TRCCONFIGR value changed from 0x1 to 0x0, the TRCTRACEIDR of ETM_7 changed from 0x17 to 0x1e and the (optional) IDs are missing. But I compared this with Leo's configuration using trc_pkt_lister, and the output was basically the same. Could it be, that the TRCIDR9 - 13 are not used for the Hikey620? Also, what does the last TRCCONFIGR-bit do? The ARM ETMv4 spec just says it is "RES1". Does "RES1" mean, that it's supposed to be 1, but does not really matter? Anyway, I think it would be really nice to add this usage of Perf to the documentation, maybe into the CSAL/.../coresight-tools/discovery.md. Since Al is the one who wrote csscan, I CC'ed you. Thanks for your nice explanation the other day.
You're welcome! I could add that to the docs, though as a way to find the id registers if your kernel is already set up for CoreSight, it's more direct to go to sysfs as mentioned above. csscan is really aimed at people who have an unknown board in front of them. If you do want to see what Linux thinks CoreSight looks like, cs_topology_sysfs.py might be useful.
Al
Thank you, these snapshot files are a huge help! I've added my binary and its .so files to the "cpu_0.ini", but it doesn't work quite yet. When using the traced data from my own binary with the trc_pkt_lister program, it just says "END OF TRACE DATA" (see attachment "trc_pkt_lister-decode_output.txt"). Weirdly enough, when using the cstrace.bin from Leo's snapshot, I get lots of decoded trace. Of course, the streams aren't synchronized and it is not informative, but it has content. This made me wonder, whether I'm collecting the trace correctly, but I believe there's not much I can do wrong. I attached my simpletrace.sh, which enables trace, runs the binary on CPU-core 0, stops trace, and collects it. I also tried a variant, where I filter only the relevant address ranges, but with the same result. Did I understand correctly, that I need the code segment addresses for the binary and .so files? (the entries from "/proc/<pid>/maps" with the "x" executable flag)? I think my .ini files should be correct, but I've attached my "cpu_0.ini" and the output of "/proc/<pid>/maps" of my binary just in case. I also deactivated ASLR, to ensure the addresses stay constant.
As indicated earlier, tracing and decoding works now on my end. I was lucky and I've found the error. After every time I traced my test program, I ran
$ echo 1 > /sys/bus/coresight/devices/etm0/reset
to reset any address range filters I might have configured for this specific trace session. According to older documentation [1] I thought that this would set everything back to its boot configuration. But after my first trace any trace data I gathered was useless until I rebooted. In the newer doc [2] it is stated that it "Reset[s] all programming to trace nothing", which in hindsight is exactly what happened - nothing was traced. From my subjective point of view, the old purpose of this register seems more practical and better.
[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-coresight- devices-etm4x [2] https://www.kernel.org/doc/html/latest/trace/coresight/coresight-etm4x- reference.html
I've got a question regarding this mailing list. I noticed, that the subject (which approach to take for tracing) no longer suits the content of this mail. Should I write a "new" mail for every new topic? Or should I just hit "reply all", so that it's easy to see that it's still me with my Hikey620? Or should I maybe mix both, and reply adjusting the subject?
Thank you for all the help you've given me until now. Without it I probably would not have gotten this far.
Dominik