Hi,

On 21 December 2016 at 02:40, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:

On 19 December 2016 at 07:45, Yehuda Yitschak <yehuday@marvell.com> wrote:
> Hi Mathieu
>
>
>
> After some more debug I was able to resolve the trace issue I had on
> Linux-4.9-rc1
>
> If you remember I only got trace for CPU2 out of 4 CPUs which was really
> strange
>
>
>
> Turns out the issue comes from some quirk in our busses
>
> Our internal fabric is not able to write 64bit data to registers, only to
> memory
>
> So the address comparators in the ETM got corrupted values and there wasn’t
> any match on address for most CPUs.
>
> For some cryptic reason only CPU2 got somewhat reasonable comparator value
> (still not the intended, but a working one) and so it could generate trace
>
>
>
> Now I am able to generate proper trace consistently.
>

Very good.

>
>
> I was wondering how can I add latency or timing information to the trace
>
> I noticed the cs_etm event can accept an option of “cycacc” and “timestamp“
>
> How can I view this information later ?
>
> Should I use perf script –f ?

That information, when configured on the cmd line, will end up in the
perf.data file. From there it will be decoded and rendered by the
openCSD library.

Mike, can you comment on the format of the information that will be
found in the packet? Perhaps you have an example somewhere of traces
generated by the "cycacc" and "timestamp" option?

In principle the cycle counts are generated according to the cycle_count threshold - which means you will not ordinarily get a cycle count per instruction on ETMv4. This is to avoid flooding the trace data with lots of cycle count packets. The threshold is programmable but I am not sure what value is used by the etmv4 driver.

Timestamps are generated periodically at useful events such as trace synchronisation points, exception entry and return etc.

I tested the cycacc and timestamp options on Juno this morning and found that cycle accurate tracing did not seem to be enabled at all and timestamps appeared to all be 0x0 (from the packet printing in perf report --dump). These are probably two separate issues that require further investigation. My initial check on the perf cs-etm-decoder.c file showed that an incorrect value of TRCCONFIGR appeared to be passed to the decoder - matching the correct configuration for ETMv3 with CC and TS enabled rather than ETMv4.

Finally, again reading the code in cs-etm-decoder.c, even if we get correct timestamp and cycle count packets, the processing appears to be ignoring them - focussing on instruction ranges and exceptions to enable the trace disassembly. So I cannot see how these packets are used or transmitted to the output of perf script / report.

I am not familiar with this area of the code so I could be mis-reading it - the relevant code could be elsewhere?

Regards

Mike

You will definitely need to create your own scripts as nothing we have
done so far uses those configuration parameters.

Thanks,
Mathieu

>
>
>
> Thanks a lot
>
>
>
> -------------------
>
> Yehuda Yitschak
>
> Marvell Semiconductor Ltd.
>
>

Mike Leach

Principal Engineer, ARM Ltd.

Blackburn Design Centre. UK