Hi Raphael,

On Thu, 13 Aug 2020 at 13:20, Raphael GALLAIS-POU raphael.gallais-pou@st.com wrote:

Hi all,

I am trying to enable Coresight framework on STM32MP1 (ARMv7). More specifically on CPU-wide kernel trace collection with perf.

I recently came across a decoding error from OpenCSD, which prevent the proper trace decoding :

...

perf report --stdio

DCD_ETMV3_0018 : 0x0013 (OCSD_ERR_BAD_PACKET_SEQ) [Bad packet sequence];

TrcIdx=6969; CS ID=12; Bad Packet sequence. 0x27438 [0x8]: failed to process type: 68 [Invalid argument]

...

perf report --dump

[...] Idx:6961; ID:12; P_HDR : Atom P-header.; Idx:6962; ID:12; BRANCH_ADDRESS : Branch address.; Addr=0x6C67BD40 ~[0x6C67BD40]; Exception=Jazelle; Idx:6967; ID:12; P_HDR : Atom P-header.; EE Idx:6968; ID:12; P_HDR : Atom P-header.; PKTP_ETMV3_0018 : 0x0013 (OCSD_ERR_BAD_PACKET_SEQ) [Bad packet sequence]; TrcIdx=6969; CS ID=12; A-Sync ? : Unexpected byte in sequence Idx:6969; ID:12; BAD_SEQUENCE : Invalid sequence for packet type.[A_SYNC] Idx:6970; ID:12; P_HDR : Atom P-header.; EEEEEEEEEEEEEEE

Looking at the dump, I would say that the trace is in some way corrupted. This does not necessarily mean that it is a problem with the hardware, but some issue is causing the trace as recorded in the file to be incorrect / misaligned which will cause issues with the decoder. For example in the excerpt above - the Jazelle exception is worrying.

Secondly the decoder relies on correct configuration information at the input to get good trace at the output. Check that these values reported in the trace file are what is being used in your system. On my system with ETMv4 I see:- 0x188 [0x148]: PERF_RECORD_AUXTRACE_INFO type: 3 Header version 0 PMU type/num cpus 800000004 Snapshot 0 Magic number 4040404040404040 CPU 0 TRCCONFIGR 810 TRCTRACEIDR 10 TRCIDR0 28000ea1 TRCIDR1 4100f400 TRCIDR2 488 TRCIDR8 0 TRCAUTHSTATUS cc

Ensure you are using the latest version of OpenCSD, and perf tools - or at least have relevant perf / cs_etm updates backported to the kernel you are using.

Try building with the CSTRACE_RAW=1 option on the make command line:- make -C tools/perf CORESIGHT=1 CSTRACE_RAW=1

This will cause the raw trace bytes to appear as part of the dump, which may make the issues more obvious. Note that the first error may occur after any actual corruption. Often a mis-alignment will go unnoticed as many trace packets are single bytes. So a misalignment can cause the bytes from an address to be P_header packets for example.

One issue that did cause mis-alignment was the fact that perf would concantenate captures from multiple reads of the trace sink into a single auxtrace record. This was especially problematic if the sink had wrapped before being read. To combat this we insert barrier packets into the stream as the trace is saved into the file. Check the drivers versions you have contain this code.

coresight.c LL53-57 /* * When losing synchronisation a new barrier packet needs to be inserted at the * beginning of the data collected in a buffer. That way the decoder knows that * it needs to look for another sync sequence. */ const u32 barrier_pkt[4] = {0x7fffffff, 0x7fffffff, 0x7fffffff, 0x7fffffff};

Regards

Mike

What could explain this behavior ?

Thanks, Raphaël _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight