Hi,
I thought about my initial question, and I think this current limitation is not an issue for my purposes because I am trying to evaluate the effect on performance of turning trace on, both with sysFS and with perf. This means I am not that interested about the trace data itself, but for my measurements to make sense I have to be sure that I am tracing the correct program.
So I have been running short programs, that should generate a small enough amount of trace that it fits in the ETR buffer. The problem is, when I look at the raw trace data and try to decode it manually using the ETM Architecture Spec, the data quickly stops making sense.
I have attached an example trace data that I generated, (and the script I am using to run it/ configure the CoreSight components). If I follow the description of the encoding of Instruction trace packets, this sample starts with the following packets: At 0x0, a Numbered Data Sync Mark (numbered 5) At 0x1, an A-Sync packet At 0xd, a Trace Info packet. The next byte is 0, so that means there is no more info after that At 0xf, a context packet, with no payload Which means that starting at 0x10, I have an undefined sequence: 00 04 is not one of the known extension packets.
I have the feeling that there is more than one instruction stream in this file, because at 0x1218 I can see a sequence that looks at lot like an A-Sync packet with a 0e byte mixed in.
As I have checked that other ETMs and the STM all have 'enable_source' set to 0, I don't know where do these stray bytes come from.
Is there something that I am missing? Is this behaviour expected?
Additionally, is there an easy way to decode the trace from the raw binary data? I do have the OpenCSD library installed, and perf uses it when displaying ETM trace data. The documentation mentions a 'ptm2human' program, but I haven't found it (and don't know if it is still up to date). This last part is not vital, but if there is a simple wrapper for the decoder around, it would make checking the validity of the trace easier.
Best regards,
Thierry
-----Original Message----- From: Mike Leach Sent: 29 June 2017 17:17 To: Thierry Laviron Thierry.Laviron@arm.com Cc: Mathieu Poirier (mathieu.poirier@linaro.org) mathieu.poirier@linaro.org; 'coresight@lists.linaro.org' coresight@lists.linaro.org Subject: RE: Using Coresight in SysFS mode on Juno board
Hi Thierry,
I see you have also sent this mail to Mathieu who has answered some of the points and cc:ed the linaro coresight mailing list.
I'll give you my spin on a couple of things here.....
-----Original Message----- From: Thierry Laviron Sent: 29 June 2017 15:45 To: Mike Leach Subject: Using Coresight in SysFS mode on Juno board
Hi Mike,
I am currently trying to get trace data using the CoreSight system in SysFS mode on my Juno r2 board.
I found some documentation on how to use it in the Documentation/trace/coresight.txt file of the perf-opencsd-4.11 branch of the OpenCSD repository.
This document says that I can retrieve the trace data from /dev/ using dd, for example in my case that would be
root@juno-debian:~# dd if=/dev/20070000.etr of=~/cstrace.bin
However, I am assuming this produces a dump of the memory buffer as it was when I stopped trace collection,
And that I do not have the full trace data generated (because it does not fit on the buffer).
I would like to be able to capture a continuous stream of data from the ETR, but did not find how should I do that.
It is not possible to read trace while still collecting it - the process you are tracing must be stopped while trace is saved. Perf can achieve this as it is integrated into the kernel, but this is difficult to achieve from the sysfs interface.
As Mathieu says, you need to limit the amount of trace to the application you are tracing - but even so, the rate of trace collection can easily overflow buffers.
I am writing a C program. Can I open a read access to the ETR buffer like this?
open("/dev/20070000.etr", O_RDONLY);and then read its content, to write somewhere else? (e.g. to a file on the disc)?
As a second step, I am also trying to filter the trace generated. I found some useful documentation in
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
However, while this is very useful to understand what are the purpose of the different files that appear in the
/sys/bus/coresight/devices/<mmap>.etm/ folders, I am not sure of the format to put stuff in.
For example, I want to use the Context ID comparator, so the ETM traces only the process I am interested in.
I assume I need to write the PID of my process in ctxid_pid, probably write 0x1 in ctxid_idx to activate it, and leave 0x0 in ctxid_mask
according to the ETM v4.3 architecture specification.
But I feel that I am missing something else, as it seems the ETM is not taking the filter into account.
i) you will need to have enabled PID=>context idr tracking in your kernel. ii) you need to set up the ViewInst event resource selector to select a context ID event to start and stop the trace, in addition to setting the context ID comparators. Additionally you will need some address range enabled as well - though by default the etm drivers set up the full address range under sysfs. The hardware registers needed for all this are described in the ETM TRM, but at present I don't know of any docs that map the sysfs names onto the relevant HW registers.
Regards
Mike
If there is more relevant documentation on this that I have not found, I would appreciate if you could point me to it.
If not, and what I am trying to do will not work, I would welcome some advice on how to do it properly.
Thanks in advance.
Best regards,
Thierry Laviron
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.