+CoreSight ML and Mathieu
---------- Forwarded message ---------- From: Mike Leach mike.leach@linaro.org Date: 3 September 2018 at 17:39 Subject: Re: Failed for ETM decoding with db410c snapshot mode To: Leo Yan leo.yan@linaro.org
HI Leo,
Short summary - there is a problem with the trace collected - not the decoder. See below for details
On 3 September 2018 at 08:06, leo.yan@linaro.org wrote:
Hi Mike, Mathieu,
[ + CoreSight ML ]
When I work on the CoreSight + perf tool and used crash extension program to extract the tracing data from perf aux buffer, finally I can get the trace data for about 1.6MB from ETF sink from DB410c board.
To verify the extracted trace data, I used 'snapshot' mode under OpenCSD code base, you could see the tar file for this [1]. After you download this file, you could place it under OpenCSD folder:
$ cp db410c_snapshot_kdump.tgz my_opencsd/decoder/tests/snapshots $ cd my_opencsd/decoder/tests/snapshots $ tar zxvf db410c_snapshot_kdump.tgz $ cd db410c_snapshot_kdump
$ ../../bin/builddir/trc_pkt_lister
This will print raw trace packets as it finds them without attempting any sort of interpretation.
$ ../../bin/builddir/trc_pkt_lister -decode
This will try to decode the raw trace packets into a sequence of instructions executed (alongside the raw packets)
This is where the packets are being flagged as incorrect.
If I use the command 'trc_pkt_lister' without any extra options, it can print out trace packets successfully; but if I add the extra option '-decode' it uses 'decode all' mode and it reports the errors as:
483710 Idx:53086; ID:10; [0xf8 ]; I_ATOM_F3 : Atom format 3.; NNN 483711 Idx:53086; ID:10; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0xffff000008abc9f0 ) 483712 Idx:53088; ID:10; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE 483713 Idx:53194; ID:10; [0x6b 0x8c 0x08 0xfa 0xdc 0x95 0x5c ]; I_COND_RES_F1 : Conditional Result, format 1.
This is a conditional result trace packet - however as far as I am aware the trace unit on an A53 (i.e. DB410 core) cannot produce these.
Additionally in the entire file I see 2 I_COND packets and 1 I_NUM_DS_MKR - a data synchronisation marker packet.
Now Data sync can only ever occur if data trace is supported and enabled. Data trace is architecturally prohibited for A class v8 cores (and unimplemented on most A class v7 cores).
If there were tracing of conditional elements occurring, and it were enabled, then the packets should match up - a cond instruction should match with one cond result element.
But in the end - event without these inconsistencies - the TRACE_INFO element at the top of the listing tells me that conditional instruction trace is disabled.
Thus you are seeing what I believe is the effect of concatenating trace data buffers together (you mention you have 1.6MB of data from the ETF - which is not that large), without inserting barrier packets in between. The decoder cannot spot the boundaries, and will carry on and be out of sync so can mis-read trace packet payload data as header data which will throw off the decode process.
When I look at the raw byte data I am seeing this at the top of the listing:-
Frame Data; Index 0; ID_DATA[????]; ff Frame Data; Index 0; ID_DATA[0x7f]; 7f ff 7f ff 7f ff
This does not look valid at all to me.
483714 DCD_ETMV4_0016 : 0x0018 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; Unsupported packet type.Trace Packet Lister : Data Path fatal error 483715 0x0018 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; Unsupported packet type.Trace Packet Lister : Trace buffer done, processed 53216 bytes.
You also could check detailed log trc_pkt_lister.ppl in the shared tar packet; After searched for the OpenCSD code and found this error is due it cannot support some types of packets [2].
So want to check what's the best for this issue; seems to me we need to fix this so it can support well to complete the decoding?
The reason we have not implemented support for these packets, is that we have never seen an implementation that generates them.
regards
Mike
Thanks in advance for suggestion. Leo Yan
[1] http://people.linaro.org/~leo.yan/opencsd_db410c/db410c_snapshot_kdump.tgz [2] https://github.com/Linaro/OpenCSD/blob/master/decoder/source/etmv4/trc_pkt_d...
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK