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_snapshot.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.
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.
The output you see from trc_pkt_lister is likely due to the TRCTRACEIDR in the .ini files for the ETM devices not matching the values actually used when collecting the trace.
This output:- Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x10 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x12 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x14 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x16 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x17 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x18 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x1a Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x1c
indicates the expected Trace IDs to look for when processing your raw trace file. If data associated with these IDs is not present in the file, then it will be skipped. As I have mentioned before, decode requires accurate information on the configuration of the ETMs at trace capture time.
Try adding -o_raw_unpacked and you should see additional output of the raw unpacket trace frames. e.g.
Frame Data; Index 32656; ID_DATA[0x20]; ff ff db 9a 3f 10 e1 10 f7 00 00 00 00 00 00 Frame Data; Index 32672; ID_DATA[0x20]; 00 00 00 00 00 80 01 01 00 04 85 3c 10 e1 10 Frame Data; Index 32688; ID_DATA[0x20]; 00 80 ff ff 32 f7 9d 04 43 be 10 00 80 ff ff Frame Data; Index 32704; ID_DATA[0x20]; db 9a 3f 10 e1 10 f7 04 85 3c 10 e1 10 00 80 Frame Data; Index 32720; ID_DATA[0x20]; ff ff 32 06 03 9d 3d 10 e1 10 00 80 ff ff 81 Frame Data; Index 32736; ID_DATA[0x20]; 13 Frame Data; Index 32736; ID_DATA[0x00]; 00 00 00 00 00 00 00 00 00 00 00 00 00 Frame Data; Index 32752; ID_DATA[0x00]; 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Idx:0; ID:60; OCSD_GEN_TRC_ELEM_EO_TRACE( [end-of-trace]) ID:60 END OF TRACE DATA
Regards
Mike
I've read in the discovery.md from CSAL that they can be extracted by reading the ROM table of my Cortex-A53, but I'm doing/understanding something wrong. I cross-compiled the CSAL library and the csinfo-folder (which btw only compiled after inserting "MODULE_LICENSE("");" into the csinfo.c file). Then I copied the resulting csinfo.ko to my Hikey620 where I tried "sudo make" and it returned: Load CoreSight reporting module... expect "Resource temporarily unavailable" insmod csinfo.ko insmod: ERROR: could not insert module csinfo.ko: Resource temporarily unavailable Makefile:17: recipe for target 'load' failed make: *** [load] Error 1 If I understood correctly, that is intended, but should also give me the base address of the ROM-table afterward. But there was no other output. I do have CONFIG_DEVMEM enabled. I tried "sudo insmod csinfo.ko". directly as well, with the same result.
Looking at the code it appears that the output is printk(KERN_INFO ... ) Check the printk level is correct on your system.
It's good to use "dmesg" to check the kernel log, so it might give more hints for why fails to load kernel module. The compiling faiure with "MODULE_LICENSE" is weird, it's better to go back to check if have specified correctly for the kernel path?
Oh, of course, csinfo is a module, using printk, therefore the output also appears only on dmesg. There is indeed output. I've attached the dmesg output (load_csinfo_dmesg_output.txt), could you maybe take a quick glance at it, whether it looks as expected? Using the address from the MPIDR register ROM table ("sudo ./csscan.py 0x00000000f6400000") causes the board to hang until I replug the power supply (see csscan_output.txt).
Besides Mike's suggestion, I'd like to strongly suggest to disable CPUIdle when you debug CoreSight stuffs on Hikey620. So please add "nohlt" in the kernel command line.
I'm already using "nohlt", but thanks for the reminder.
Thanks, Leo
Thanks,
Dominik