Reading and Decoding Data From ETB Buffer

Reading and Decoding Data From ETB Buffer

[Ajay Bharadwaj]

Hi,

I'm working on enabling STM and ETB support on Texas Instruments' platforms.

Currently, I can write directly to the STM device in sysfs and read back 
the encoded data from the ETB's buffer. I am using the Trace Packet 
Lister (trc_pkt_lister) from Linaro's OpenCSD [1] to decode the data 
obtained from the ETB. The decoded data matches what was written to the 
STM (Albeit the data is reversed in some cases, this seems to be 
expected according to the ARM specification).

However, when I use the STM Source Console [2] instead of writing 
directly to the STM device, I can still read back the encoded data from 
the ETB buffer but OpenCSD cannot find any trace data in it.

Is there any other tool that I can use instead of OpenCSD or am I doing
something wrong? Here are the commands I am running (I've tried using
the p_sys-t STP policy as well with the same result):

Enabling CoreSight and STM Source Console:
1. mkdir -p /config
2. mount -t configfs none /config
3. mkdir /config/stp-policy/stm0.policy
4. mkdir /config/stp-policy/stm0.policy/console
5. echo 1 > /sys/bus/coresight/devices/etb0/enable_sink
6. echo stm0 > /sys/class/stm_source/console/stm_source_link

Reading decoded data from ETB buffer:
1. dd if=/dev/etb0 of=test.bin

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.

[1] 
https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/source/trc_pkt_lister.cpp
[2] Driver: hwtracing/stm/console.c

Any help or guidance would be much appreciated.

Regards,
Ajay Bharadwaj

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Reading and Decoding Data From ETB Buffer

[Mathieu Poirier]

Adding the coresight mailing list

On Tue, 12 Jan 2021 at 04:17, Ajay Bharadwaj <ajayrbharadwaj@gmail.com> wrote:
>
> Hi,
>
> I'm working on enabling STM and ETB support on Texas Instruments' platforms.
>
> Currently, I can write directly to the STM device in sysfs and read back
> the encoded data from the ETB's buffer. I am using the Trace Packet
> Lister (trc_pkt_lister) from Linaro's OpenCSD [1] to decode the data
> obtained from the ETB. The decoded data matches what was written to the
> STM (Albeit the data is reversed in some cases, this seems to be
> expected according to the ARM specification).
>
> However, when I use the STM Source Console [2] instead of writing
> directly to the STM device, I can still read back the encoded data from
> the ETB buffer but OpenCSD cannot find any trace data in it.
>
> Is there any other tool that I can use instead of OpenCSD or am I doing
> something wrong? Here are the commands I am running (I've tried using
> the p_sys-t STP policy as well with the same result):
>
> Enabling CoreSight and STM Source Console:
> 1. mkdir -p /config
> 2. mount -t configfs none /config
> 3. mkdir /config/stp-policy/stm0.policy
> 4. mkdir /config/stp-policy/stm0.policy/console
> 5. echo 1 > /sys/bus/coresight/devices/etb0/enable_sink
> 6. echo stm0 > /sys/class/stm_source/console/stm_source_link
>
> Reading decoded data from ETB buffer:
> 1. dd if=/dev/etb0 of=test.bin
>
> 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.
>
> [1]
> https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/source/trc_pkt_lister.cpp
> [2] Driver: hwtracing/stm/console.c
>
> Any help or guidance would be much appreciated.
>
> Regards,
> Ajay Bharadwaj

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Reading and Decoding Data From ETB Buffer

[Mike Leach]

Hi Ajay,

On Tue, 12 Jan 2021 at 16:17, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> Adding the coresight mailing list
>
> On Tue, 12 Jan 2021 at 04:17, Ajay Bharadwaj <ajayrbharadwaj@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm working on enabling STM and ETB support on Texas Instruments' platforms.
> >
> > Currently, I can write directly to the STM device in sysfs and read back
> > the encoded data from the ETB's buffer. I am using the Trace Packet
> > Lister (trc_pkt_lister) from Linaro's OpenCSD [1] to decode the data
> > obtained from the ETB. The decoded data matches what was written to the
> > STM (Albeit the data is reversed in some cases, this seems to be
> > expected according to the ARM specification).
> >
> > However, when I use the STM Source Console [2] instead of writing
> > directly to the STM device, I can still read back the encoded data from
> > the ETB buffer but OpenCSD cannot find any trace data in it.
> >
> > Is there any other tool that I can use instead of OpenCSD or am I doing
> > something wrong? Here are the commands I am running (I've tried using
> > the p_sys-t STP policy as well with the same result):
> >
> > Enabling CoreSight and STM Source Console:
> > 1. mkdir -p /config
> > 2. mount -t configfs none /config
> > 3. mkdir /config/stp-policy/stm0.policy
> > 4. mkdir /config/stp-policy/stm0.policy/console
> > 5. echo 1 > /sys/bus/coresight/devices/etb0/enable_sink
> > 6. echo stm0 > /sys/class/stm_source/console/stm_source_link
> >
> > Reading decoded data from ETB buffer:
> > 1. dd if=/dev/etb0 of=test.bin
> >
> > 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

Mike


> > [1]
> > https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/source/trc_pkt_lister.cpp
> > [2] Driver: hwtracing/stm/console.c
> >
> > Any help or guidance would be much appreciated.
> >
> > Regards,
> > Ajay Bharadwaj



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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Reading and Decoding Data From ETB Buffer

[Ajay Bharadwaj]

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?

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.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Reading and Decoding Data From ETB Buffer

[Mike Leach]

Hi Ajay,

On Wed, 13 Jan 2021 at 15:28, Ajay Bharadwaj <ajayrbharadwaj@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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel