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:
- mkdir -p /config
- mount -t configfs none /config
- mkdir /config/stp-policy/stm0.policy
- mkdir /config/stp-policy/stm0.policy/console
- echo 1 > /sys/bus/coresight/devices/etb0/enable_sink
- echo stm0 > /sys/class/stm_source/console/stm_source_link
Reading decoded data from ETB buffer:
- 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_l... [2] Driver: hwtracing/stm/console.c
Any help or guidance would be much appreciated.
Regards, Ajay Bharadwaj
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:
- mkdir -p /config
- mount -t configfs none /config
- mkdir /config/stp-policy/stm0.policy
- mkdir /config/stp-policy/stm0.policy/console
- echo 1 > /sys/bus/coresight/devices/etb0/enable_sink
- echo stm0 > /sys/class/stm_source/console/stm_source_link
Reading decoded data from ETB buffer:
- 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_l... [2] Driver: hwtracing/stm/console.c
Any help or guidance would be much appreciated.
Regards, 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
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
-
Ajay Bharadwaj -
Mathieu Poirier -
Mike Leach