Hi Mike,
HI Leo,
Short summary - there is a problem with the trace collected - not the decoder. See below for details
Thanks for quick replying.
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.
I am suspecting this is caused by the barrier insertion in CoreSight driver. When the driver detects the ETB RAM is full, it will do below two things:
- Insert barrier packet 0x7fffffff;
- Due the barrier packet has occupied the buffer space, so the driver will read trace data from TMC_RRD but the trace data is discarded when insert barrier packet.
I read the code [1][2] and the code delibrately discards trace data so can leave the memory for barrier packets; after that it can fill continous seqential trace data.
I think the discarding trace data is incorrect, for most case the buffer is sufficient to store both barrier packets and trace data so we can keep complete trace data; from testing I also can see after save trace data from the beginning of ETB, the decoding error can dismiss.
I am working on minor fixing patches for this and will send out for reviewing.
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.
I think this is related with barrier packet 0x7fffffff which introduced by CoreSight driver [3].
I found there have another important flag for decoding: OCSD_DFRMTR_RESET_ON_4X_FSYNC. I think after set this flag, the decoder can recognize barrier packet and don't take it as normal trace data?
Thanks, Leo Yan
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...