Reading and Decoding Data From ETB Buffer

[Mike Leach]

Hi Ajay,

On Wed, 13 Jan 2021 at 15:28, Ajay Bharadwaj <ajayrbharadwaj at gmail.com> wrote:
>
> Hi Mike,
>
> Thanks for the quick reply!
>
> On 12/01/21 11:37 pm, Mike Leach wrote:
> [...]
> >>>
> >>> OpenCSD Output:
> >>> Trace Packet Lister: CS Decode library testing
> >>> -----------------------------------------------
> >>>
> >>> ** Library Version : 0.14.4
> >>>
> >>> Test Command Line:-
> >>> ./tests/bin/linux64/dbg/trc_pkt_lister   -ss_dir
> >>> tests/snapshots/stm_only/  -src_name  ETB_1
> >>>
> >>> Trace Packet Lister : reading snapshot from path tests/snapshots/stm_only/
> >>> Using ETB_1 as trace source
> >>> Trace Packet Lister : Protocol printer STM on Trace ID 0x1
> >>> ID:1    END OF TRACE DATA
> >>> Trace Packet Lister : Trace buffer done, processed 16384 bytes.
> >>>
> >
> > In general, if the trc_pkt_lister program doesn't find trace then
> > there is none for the ID you have assigned to the STM in the snapshot
> > .ini files.
> > Try adding -o_raw_unpacked to your command line. Your will then see
> > some output of raw bytes and associated trace ID as below..
> >
> > Frame Data; Index  32704;   ID_DATA[0x20]; 83 01 6f ff ff ff 0c 01 06
> > 10 7b 2b 6c ff
>
> The problem was that the ETB buffer was overflowing and the initial
> portion of the buffer was being overwritten. This was happening because
> as soon as STM Source Console was enabled, the backlog of kernel
> messages was being written to the STM_Console and flowing down to the ETB.
>
> Reading from the ETB, and then writing to the STM_Console and reading
> from the ETB again leads to this output while decoding:
>
> Trace Packet Lister: CS Decode library testing
> -----------------------------------------------
>
> ** Library Version : 0.14.4
>
> Test Command Line:-
> ./tests/bin/linux64/dbg/trc_pkt_lister   -ss_dir
> tests/snapshots/stm_only/  -src_name  ETB_1
>
> Trace Packet Lister : reading snapshot from path tests/snapshots/stm_only/
> Using ETB_1 as trace source
> Trace Packet Lister : Protocol printer STM on Trace ID 0x1
> Idx:0; ID:1;    NOTSYNC:STM not synchronised
> Idx:16; ID:1;   NOTSYNC:STM not synchronised
> Idx:32; ID:1;   NOTSYNC:STM not synchronised
> Idx:48; ID:1;   NOTSYNC:STM not synchronised
> Idx:64; ID:1;   NOTSYNC:STM not synchronised
> Idx:80; ID:1;   NOTSYNC:STM not synchronised
> Idx:96; ID:1;   NOTSYNC:STM not synchronised
> Idx:112; ID:1;  NOTSYNC:STM not synchronised
> ID:1    END OF TRACE DATA
> Trace Packet Lister : Trace buffer done, processed 16384 bytes.
>
> Is there any way to get around this and force the STM to send a
> synchronization packet again without re-enabling the STM?
>

Unfortunately the sync period appears to be hardcoded into the driver
at 4096 bytes - which is written to SYNCR each time the STM is
enabled.
According to STM TRM, writing SYNCR will force an immediate sync -
which may be possible using sysfs under
coresight/devices/stm0/mgmt/syncr, but any value here will be
overwritten on each enable.

> Is there already another tool or some setting for the Trace Packet
> Lister that reverses the data and outputs it in a more human readable
> format so that the decoded data is shown in the same way as the data
> being written to the STM? This would make it much easier to use and
> parse ftrace data, which is my end goal. Writing a script to do this
> would be simple but a well maintained tool would be much better.
>

trc_pkt_lister was designed purely as a debug tool to list trace
packets - for the OpenCSD decode library mainly, but is also useful in
debugging hardware trace issues.
The intention is that other clients of OpenCSD provide the more user
friendly tooling.

I do not know of anything relating to STM - but the protocol is STP2 -
which is a standard. I did think that the linux software trace module
- that can interface with both CoreSight hardware STM and the Intel
equivalent, was intended to allow standardised client tooling - but I
am not sure if anything happened in this area

Regards

Mike


> Input Data:
> [   55.991806] printk: console [stm_console0] enabled
> [   70.452733] AAAAAAAAAAAAAA
>
> This what the output currently looks like:
>
> Trace Packet Lister: CS Decode library testing
> -----------------------------------------------
>
> ** Library Version : 0.14.4
>
> Test Command Line:-
> ./tests/bin/linux64/dbg/trc_pkt_lister   -ss_dir
> tests/snapshots/stm_only/  -src_name  ETB_1
>
> Trace Packet Lister : reading snapshot from path tests/snapshots/stm_only/
> Using ETB_1 as trace source
> Trace Packet Lister : Protocol printer STM on Trace ID 0x1
> Idx:0; ID:1;    ASYNC:Alignment synchronisation packet
> Idx:11; ID:1;   VERSION:Version packet; Ver=3
> Idx:13; ID:1;   FREQ:Frequency packet; Freq=0Hz
> Idx:21; ID:1;   M8:Set current master; Master=0x44
> Idx:22; ID:1;   D64TS:64 bit data + timestamp; Data=0x392e35352020205b;
> TS=0x00000002E5004F22 ~[0x2E5004F22]
> Idx:41; ID:1;   D64:64 bit data; Data=0x70205d3630383139
> Idx:50; ID:1;   D64:64 bit data; Data=0x63203a6b746e6972
> Idx:59; ID:1;   D64:64 bit data; Data=0x5b20656c6f736e6f
> Idx:68; ID:1;   D64:64 bit data; Data=0x736e6f635f6d7473
> Idx:77; ID:1;   D64:64 bit data; Data=0x6e65205d30656c6f
> Idx:86; ID:1;   D32:32 bit data; Data=0x656c6261
> Idx:91; ID:1;   D16:16 bit data; Data=0x0a64
> Idx:93; ID:1;   FLAG:Flag packet
> Idx:94; ID:1;   M8:Set current master; Master=0x43
> Idx:97; ID:1;   D64TS:64 bit data + timestamp; Data=0x342e30372020205b;
> TS=0x00000003915D477A ~[0x3915D477A]
> Idx:113; ID:1;  D64:64 bit data; Data=0x41205d3333373235
> Idx:122; ID:1;  D64:64 bit data; Data=0x4141414141414141
> Idx:131; ID:1;  D32:32 bit data; Data=0x41414141
> Idx:136; ID:1;  D16:16 bit data; Data=0x0a41
> Idx:138; ID:1;  FLAG:Flag packet
> ID:1    END OF TRACE DATA
> Trace Packet Lister : Trace buffer done, processed 16384 bytes.
>
> Regards,
> Ajay



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK