Hi,

Looking at the file, and the end portion you mention, I would say that the configuration for the decoder is not correctly set up. The very high cycle numbers between E atoms and the errors such as invalid header and bad async would suggest this. trc_pkt_lister works off a snapshot directory which I am assuming you have found out. The contents of this directory set up the decode parameters for the program - so ensure that all the accompanying .ini files match your system correctly.

To get full decode you need to add in the -decode command line option., This also requires providing the program images / memory dumps containing the executed code so that the decode can take place. The process for decode takes the waypoint addresses in the PTM data and reads the instructions from the memory image from that address, The output will be executed instruction ranges - not disassembly - see the example below. This - from one of the shipped examples with the library - shows a decode output from an a15 running PTM. The memory images loaded for decode are listed as well.

The lines from the example: Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

shows a packet with 5 atoms, and the decode of each of those atoms into instruction executed ranges. This is achieved by walking the memory images looking for the relevant waypoint instructions corresponding to the atoms. This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) instruction range format is the final output from the library. It is up to the client of the OpenCSD library to convert these ranges into whatever the desired output is (disassmbly / statistical analysis etc.)

You can get more information on this from the library documentation - explaining the snapshot format and the operation of the library.

Regards

Mike

-------------------------------- e.g. ** Library Version : 0.14.2

Test Command Line:- ./bin/linux64/rel/trc_pkt_lister -ss_dir ./snapshots/trace_cov_a15 -decode -logfilename ./results/trace_cov_a15.ppl

Trace Packet Lister : reading snapshot from path ./snapshots/trace_cov_a15 Using PTM_0_2 as trace source Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 Trace Packet Lister : Set trace element decode printer Gen_Info : Mapped Memory Accessors Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin Gen_Info : ======================== Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment Synchronisation Packet; Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x80000504; excep num (0x01) ) Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000504; S; ISA=ARM(32); Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Hi Mike, We are trying to make open CSD working in our silicon sample. It is very much required for our debug as we cannot attach DS5 early enough. We were able to generate the trace.bin and generate the trace decode file(attached) I have few questions [image: image.png] The end portion of teh trace looks something like this.

I know PTM only takes the branch address. Is there any way we can make it more readable by filling the missing instructions between branches? or is this the final output.

Also can you check the attached file and see if anything else is missing in our setup?

Ajith K Issac Broadcom DCSG

So I'm not exactly sure how or what I'm setting up, but the only things that appear to have values is cpu_0.ini and device_1.ini.

MegaRAID provided an initial sample dump, I pulled up their ini files and made modifications to match our app.axf. I added only a few regions (that I felt were applicable) in the app.axf. (Comments in *bold red*).

The rest of the ini files are just references to configuring the names of the ini.

When I run the trc_pkt_lister I don't see any difference to my output (from before I made the changes).

*cpu_0.ini* [device] name=cpu_0 class=core type=Cortex-A15

*ajh - There are 17 sections in the app.axf, but only a few regions that contain code. I just copied 3 of those sections into the dump regions. Do I need more? Also, this seems like it can be pulled from the axf using the fromelf app. Do I need to write a script to do this or does something already exist?* [dump0] file=app.axf address=0x70004194 length=0x3077d4 offset=0x41c8

[dump1] file=app.axf address=0x7f100000 length=0x8e0 offset=0x34

[dump2] file=app.axf address=0x7f1008e0 length=0x4a0 offset=0x914

*ajh - I don't know what to provide in regs? What is this needed for and what registers are pertinent?* [regs] R15=0 CPSR=0x4000003F

*device_1.ini* *ajh - I didn't make any changes to this file, are these the coresight registers at 0x06180_0000 (Avengers CPU0 coresight block).* [device] name=PTM_0 class=trace_source type=PTM1.1

[regs] ETMCR(0x0)=0x3000D400 ETMIDR(0x79)=0x411CF314 ETMCCER(0x7A)=0x34C01AC2 ETMTRACEIDR(0x80)=0x0000001A

On Wed, Jul 29, 2020 at 9:03 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Thanks Mike, We will fix our snapshot files. Thanks for your quick repsonse.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 4:58 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

Looking at the file, and the end portion you mention, I would say that the configuration for the decoder is not correctly set up. The very high cycle numbers between E atoms and the errors such as invalid header and bad async would suggest this. trc_pkt_lister works off a snapshot directory which I am assuming you have found out. The contents of this directory set up the decode parameters for the program - so ensure that all the accompanying .ini files match your system correctly.

To get full decode you need to add in the -decode command line option., This also requires providing the program images / memory dumps containing the executed code so that the decode can take place. The process for decode takes the waypoint addresses in the PTM data and reads the instructions from the memory image from that address, The output will be executed instruction ranges - not disassembly - see the example below. This - from one of the shipped examples with the library - shows a decode output from an a15 running PTM. The memory images loaded for decode are listed as well.

The lines from the example: Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

shows a packet with 5 atoms, and the decode of each of those atoms into instruction executed ranges. This is achieved by walking the memory images looking for the relevant waypoint instructions corresponding to the atoms. This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) instruction range format is the final output from the library. It is up to the client of the OpenCSD library to convert these ranges into whatever the desired output is (disassmbly / statistical analysis etc.)

You can get more information on this from the library documentation - explaining the snapshot format and the operation of the library.

Regards

Mike

---

e.g. ** Library Version : 0.14.2

Test Command Line:- ./bin/linux64/rel/trc_pkt_lister -ss_dir ./snapshots/trace_cov_a15 -decode -logfilename ./results/trace_cov_a15.ppl

Trace Packet Lister : reading snapshot from path ./snapshots/trace_cov_a15 Using PTM_0_2 as trace source Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 Trace Packet Lister : Set trace element decode printer Gen_Info : Mapped Memory Accessors Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin Gen_Info : ======================== Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment Synchronisation Packet; Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x80000504; excep num (0x01) ) Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000504; S; ISA=ARM(32); Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Hi Mike, We are trying to make open CSD working in our silicon sample. It is very much required for our debug as we cannot attach DS5 early enough. We were able to generate the trace.bin and generate the trace decode file(attached) I have few questions [image: image.png] The end portion of teh trace looks something like this.

I know PTM only takes the branch address. Is there any way we can make it more readable by filling the missing instructions between branches? or is this the final output.

Also can you check the attached file and see if anything else is missing in our setup?

Ajith K Issac Broadcom DCSG

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

Hi,

On Wed, 29 Jul 2020 at 16:15, Andrew Hadley andrew.hadley@broadcom.com wrote:

So I'm not exactly sure how or what I'm setting up, but the only things that appear to have values is cpu_0.ini and device_1.ini.

MegaRAID provided an initial sample dump, I pulled up their ini files and made modifications to match our app.axf. I added only a few regions (that I felt were applicable) in the app.axf. (Comments in *bold red*).

The rest of the ini files are just references to configuring the names of the ini.

When I run the trc_pkt_lister I don't see any difference to my output (from before I made the changes).

Did you add the -decode option to the command line?

*cpu_0.ini* [device] name=cpu_0 class=core type=Cortex-A15

*ajh - There are 17 sections in the app.axf, but only a few regions that contain code. I just copied 3 of those sections into the dump regions. Do I need more? Also, this seems like it can be pulled from the axf using the fromelf app. Do I need to write a script to do this or does something already exist?*

Hard to say if these areas will completely cover the area traced - however, the decoder will output partial trace range packets when the addresses match the dump files. If trace goes out of range for the memory dumps then NACC packets will be output for the unknown addresses. I would start with these and see how far the decoder gets. Looking at a few of the addresses in the dump file they do seem to be in the range of the dump files you specify.

[dump0] file=app.axf address=0x70004194 length=0x3077d4 offset=0x41c8

[dump1] file=app.axf address=0x7f100000 length=0x8e0 offset=0x34

[dump2] file=app.axf address=0x7f1008e0 length=0x4a0 offset=0x914

*ajh - I don't know what to provide in regs? What is this needed for and what registers are pertinent?* [regs] R15=0 CPSR=0x4000003F

For trace - these regs are not needed. They are used if loading the snapshot into other tools.

*device_1.ini* *ajh - I didn't make any changes to this file, are these the coresight registers at 0x06180_0000 (Avengers CPU0 coresight block).*

Can't comment on your specific system but these are the CoreSight PFT registers as defined in the PFT specification.

[device] name=PTM_0 class=trace_source type=PTM1.1

[regs] ETMCR(0x0)=0x3000D400

This value indicates that cycle accurate trace is being generated - if this does not match your system then this could explain the strange cycle counts. Also return stack and timestamp tracing are active & a 32 bit context ID are being traced.

All these parameters affect how the decoder interprets the trace packets. This value must reflect the value of this register at the time trace was collected.

Regards

Mike

ETMIDR(0x79)=0x411CF314 ETMCCER(0x7A)=0x34C01AC2 ETMTRACEIDR(0x80)=0x0000001A

On Wed, Jul 29, 2020 at 9:03 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike, We will fix our snapshot files. Thanks for your quick repsonse.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 4:58 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

Looking at the file, and the end portion you mention, I would say that the configuration for the decoder is not correctly set up. The very high cycle numbers between E atoms and the errors such as invalid header and bad async would suggest this. trc_pkt_lister works off a snapshot directory which I am assuming you have found out. The contents of this directory set up the decode parameters for the program - so ensure that all the accompanying .ini files match your system correctly.

To get full decode you need to add in the -decode command line option., This also requires providing the program images / memory dumps containing the executed code so that the decode can take place. The process for decode takes the waypoint addresses in the PTM data and reads the instructions from the memory image from that address, The output will be executed instruction ranges - not disassembly - see the example below. This - from one of the shipped examples with the library - shows a decode output from an a15 running PTM. The memory images loaded for decode are listed as well.

The lines from the example: Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

shows a packet with 5 atoms, and the decode of each of those atoms into instruction executed ranges. This is achieved by walking the memory images looking for the relevant waypoint instructions corresponding to the atoms. This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) instruction range format is the final output from the library. It is up to the client of the OpenCSD library to convert these ranges into whatever the desired output is (disassmbly / statistical analysis etc.)

You can get more information on this from the library documentation - explaining the snapshot format and the operation of the library.

Regards

Mike

---

e.g. ** Library Version : 0.14.2

Test Command Line:- ./bin/linux64/rel/trc_pkt_lister -ss_dir ./snapshots/trace_cov_a15 -decode -logfilename ./results/trace_cov_a15.ppl

Trace Packet Lister : reading snapshot from path ./snapshots/trace_cov_a15 Using PTM_0_2 as trace source Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 Trace Packet Lister : Set trace element decode printer Gen_Info : Mapped Memory Accessors Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin Gen_Info : ======================== Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment Synchronisation Packet; Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x80000504; excep num (0x01) ) Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000504; S; ISA=ARM(32); Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Hi Mike, We are trying to make open CSD working in our silicon sample. It is very much required for our debug as we cannot attach DS5 early enough. We were able to generate the trace.bin and generate the trace decode file(attached) I have few questions [image: image.png] The end portion of teh trace looks something like this.

I know PTM only takes the branch address. Is there any way we can make it more readable by filling the missing instructions between branches? or is this the final output.

Also can you check the attached file and see if anything else is missing in our setup?

Ajith K Issac Broadcom DCSG

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

Hi Ajith

On Wed, 29 Jul 2020 at 17:23, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Thanks Mike, Do you have a demo video or something which shows how it's done from beginning to trace decode ? Just want to make sure it's done correctly.

No - mostly snapshot generation is automated - registers are read off the system and written to the .ini files. DS-5 used to do this , and there was a utiltiy in the Coresight access library for doing something similar.

I have manually played with snapshot directories in the past when low level debugging trace generation issues, but that does get quite complex.

The trc_pkt_lister tool was designed primarily to test the library, using the snapshots in the tests directory in the source tree. It can be used for looking at trace the way you are to verify functionality - but you have to get the input right.

Regards

Mike

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 10:20 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

On Wed, 29 Jul 2020 at 16:15, Andrew Hadley andrew.hadley@broadcom.com wrote:

...

So I'm not exactly sure how or what I'm setting up, but the only things that appear to have values is cpu_0.ini and device_1.ini.

MegaRAID provided an initial sample dump, I pulled up their ini files and made modifications to match our app.axf. I added only a few regions (that I felt were applicable) in the app.axf. (Comments in *bold red*).

The rest of the ini files are just references to configuring the names of the ini.

When I run the trc_pkt_lister I don't see any difference to my output (from before I made the changes).

Did you add the -decode option to the command line?

...

*cpu_0.ini* [device] name=cpu_0 class=core type=Cortex-A15

*ajh - There are 17 sections in the app.axf, but only a few regions that contain code. I just copied 3 of those sections into the dump regions. Do I need more? Also, this seems like it can be pulled from the axf using the fromelf app. Do I need to write a script to do this or does something already exist?*

Hard to say if these areas will completely cover the area traced - however, the decoder will output partial trace range packets when the addresses match the dump files. If trace goes out of range for the memory dumps then NACC packets will be output for the unknown addresses. I would start with these and see how far the decoder gets. Looking at a few of the addresses in the dump file they do seem to be in the range of the dump files you specify.

...

[dump0] file=app.axf address=0x70004194 length=0x3077d4 offset=0x41c8

[dump1] file=app.axf address=0x7f100000 length=0x8e0 offset=0x34

[dump2] file=app.axf address=0x7f1008e0 length=0x4a0 offset=0x914

*ajh - I don't know what to provide in regs? What is this needed for and what registers are pertinent?* [regs] R15=0 CPSR=0x4000003F

For trace - these regs are not needed. They are used if loading the snapshot into other tools.

...

*device_1.ini* *ajh - I didn't make any changes to this file, are these the coresight registers at 0x06180_0000 (Avengers CPU0 coresight block).*

Can't comment on your specific system but these are the CoreSight PFT registers as defined in the PFT specification.

...

[device] name=PTM_0 class=trace_source type=PTM1.1

[regs] ETMCR(0x0)=0x3000D400

This value indicates that cycle accurate trace is being generated - if this does not match your system then this could explain the strange cycle counts. Also return stack and timestamp tracing are active & a 32 bit context ID are being traced.

All these parameters affect how the decoder interprets the trace packets. This value must reflect the value of this register at the time trace was collected.

Regards

Mike

...

ETMIDR(0x79)=0x411CF314 ETMCCER(0x7A)=0x34C01AC2 ETMTRACEIDR(0x80)=0x0000001A

On Wed, Jul 29, 2020 at 9:03 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike, We will fix our snapshot files. Thanks for your quick repsonse.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 4:58 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

Looking at the file, and the end portion you mention, I would say that the configuration for the decoder is not correctly set up. The very high cycle numbers between E atoms and the errors such as invalid header and bad async would suggest this. trc_pkt_lister works off a snapshot directory which I am assuming you have found out. The contents of this directory set up the decode parameters for the program - so ensure that all the accompanying .ini files match your system correctly.

To get full decode you need to add in the -decode command line option., This also requires providing the program images / memory dumps containing the executed code so that the decode can take place. The process for decode takes the waypoint addresses in the PTM data and reads the instructions from the memory image from that address, The output will be executed instruction ranges - not disassembly - see the example below. This

• from one of the shipped examples with the library - shows a decode output

from an a15 running PTM. The memory images loaded for decode are listed as well.

The lines from the example: Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

shows a packet with 5 atoms, and the decode of each of those atoms into instruction executed ranges. This is achieved by walking the memory images looking for the relevant waypoint instructions corresponding to the atoms. This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) instruction range format is the final output from the library. It is up to the client of the OpenCSD library to convert these ranges into whatever the desired output is (disassmbly / statistical analysis etc.)

You can get more information on this from the library documentation - explaining the snapshot format and the operation of the library.

Regards

Mike

---

e.g. ** Library Version : 0.14.2

Test Command Line:- ./bin/linux64/rel/trc_pkt_lister -ss_dir ./snapshots/trace_cov_a15 -decode -logfilename ./results/trace_cov_a15.ppl

Trace Packet Lister : reading snapshot from path ./snapshots/trace_cov_a15 Using PTM_0_2 as trace source Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 Trace Packet Lister : Set trace element decode printer Gen_Info : Mapped Memory Accessors Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin Gen_Info : ======================== Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment Synchronisation Packet; Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x80000504; excep num (0x01) ) Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000504; S; ISA=ARM(32); Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Hi Mike, We are trying to make open CSD working in our silicon sample. It is very much required for our debug as we cannot attach DS5 early enough. We were able to generate the trace.bin and generate the trace decode file(attached) I have few questions [image: image.png] The end portion of teh trace looks something like this.

I know PTM only takes the branch address. Is there any way we can make it more readable by filling the missing instructions between branches? or is this the final output.

Also can you check the attached file and see if anything else is missing in our setup?

Ajith K Issac Broadcom DCSG

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

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

I did, and I got data, but again I don't believe it is setup correctly, so I'm working on that first.

Here's an excerpt from the axf - but this does not seem to be matching up to the decode output unless I'm misunderstanding how the address work. 0x7003a090: e8bd88f0 .... POP {r4-r7,r11,pc} 0x7003a094: e2844001 .@.. ADD r4,r4,#1 0x7003a098: e3540c01 ..T. CMP r4,#0x100 0x7003a09c: baffffeb .... BLT 0x7003a050 ; _Z6LookupPKc + 20 0x7003a0a0: e51f0724 $... LDR r0,[pc,#-1828] ; [0x70039984] = 0x7030c204 0x7003a0a4: e1a01005 .... MOV r1,r5 0x7003a0a8: e590200c . .. LDR r2,[r0,#0xc] 0x7003a0ac: e28f0f8f .... ADR r0,{pc}+0x244 ; 0x7003a2f0 0x7003a0b0: e12fff32 2./. BLX r2 0x7003a0b4: e51f072c ,... LDR r0,[pc,#-1836] ; [0x70039990] = 0x7030c1c4 0x7003a0b8: e30031db .1.. MOV r3,#0x1db 0x7003a0bc: e59f2254 T".. LDR r2,[pc,#596] ; [0x7003a318] = 0x702bc282 0x7003a0c0: e59f1254 T... LDR r1,[pc,#596] ; [0x7003a31c] = 0x70039998 0x7003a0c4: e590600c .`.. LDR r6,[r0,#0xc] 0x7003a0c8: e28f0e25 %... ADR r0,{pc}+0x258 ; 0x7003a320 0x7003a0cc: e12fff36 6./. BLX r6 0x7003a0d0: e3a00000 .... MOV r0,#0 0x7003a0d4: eaffffec .... B 0x7003a08c ; _Z6LookupPKc + 80 _Z14GicSyncMaskInt11_IRQ_NUMBER 0x7003a0d8: e92d48f0 .H-. PUSH {r4-r7,r11,lr} 0x7003a0dc: e28db014 .... ADD r11,sp,#0x14

Here's the tail output from trc_pkt_lister -decode [...] Idx:16453; ID:1a; [0xe1 0xf9 0x03 0x88 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7001F9C0 ~[0x1F9C0]; Cycles=2; Idx:16457; ID:1a; [0xe9 0xa7 0x07 0xd1 0xd2 0x01 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7003A7D0 ~[0x3A7D0]; Cycles=3364; Idx:16464; ID:1a; [0xd2 0xd0 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431492; Idx:16469; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16474; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16480; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16485; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16490; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16496; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16501; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16506; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16512; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16517; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16522; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16528; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16533; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16538; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16545; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16550; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16555; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16561; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16566; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16571; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16577; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16582; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16587; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16593; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16598; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16603; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16609; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16614; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16619; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16625; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16630; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16635; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16641; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16646; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16651; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16657; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16662; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16667; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16674; ID:1a; [0xd4 0xe0 0xea 0x00 ]; ATOM : Atom packet; E; Cycles=218629; Idx:16678; ID:1a; [0x00 0x00 0x00 0x00 0x80 ]; BAD_SEQUENCE : Invalid sequence in packet; [ASYNC]; Idx:16683; ID:1a; [0xa0 ]; ATOM : Atom packet; E; Cycles=8; Idx:16684; ID:1a; [0x08 0x50 0xa0 0x03 0x70 0x01 0x00 0x00 0x00 0x00 ]; ISYNC : Instruction Synchronisation packet; (Periodic); Addr=0x7003a050; S; CtxtID=00000000; ISA=ARM(32); Idx:16684; ID:1a; OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) Idx:16684; ID:1a; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; VMID=0x0; CTXTID=0x0; ) Idx:16695; ID:1a; [0x3c 0x00 ]; VMID : VM ID packet; VMID=0x0; Idx:16697; ID:1a; [0x8c ]; ATOM : Atom packet; E; Cycles=3; Idx:16697; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a050:[0x7003a068] num_i(6) last_sz(4) (ISA=A32) E BR <cond> [CC=3]; ) Idx:16698; ID:1a; [0x42 0xfe 0x9c 0xb6 0xa3 0x80 0x80 0x80 0x80 0x00 0xe8 0xca 0xd0 0xd4 0xe0 ]; TIMESTAMP : Timestamp packet; TS=0x00000000046D8E7E ~[0x46D8E7E](74288766); Cycles=3243410602; Idx:16698; ID:1a; OCSD_GEN_TRC_ELEM_TIMESTAMP( [ TS=0x0000046d8e7e]; [CC=3243410602]; ) Idx:16714; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16714; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range= 0x7003a094:[0x7003a0a0] num_i(3) last_sz(4) (ISA=A32) N BR <cond> [CC=3507659818]; ) Idx:16720; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16720; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0a0:[0x7003a0b4] num_i(5) last_sz(4) (ISA=A32) N iBR b+link [CC=3582108930]; ) Idx:16725; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16725; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0b4:[0x7003a0d0] num_i(7) last_sz(4) (ISA=A32) N iBR b+link [CC=2510431552]; ) Idx:16730; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16730; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0d0:[0x7003a0d8] num_i(2) last_sz(4) (ISA=A32) E BR [CC=2242577732]; ) Idx:16736; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; DCD_PTM_0026 : 0x001c (OCSD_ERR_RET_STACK_OVERFLOW) [Internal return stack overflow checks failed - popped more than we pushed.]; TrcIdx=16736; CS ID=1a; Return stack error processing atom packet.Trace Packet Lister : Data Path fatal error 0x001c (OCSD_ERR_RET_STACK_OVERFLOW) [Internal return stack overflow checks failed - popped more than we pushed.]; TrcIdx=16736; CS ID=1a; Return stack error processing atom packet.Trace Packet Lister : Trace buffer done, processed 16752 bytes.

On Wed, Jul 29, 2020 at 10:23 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Thanks Mike, Do you have a demo video or something which shows how it's done from beginning to trace decode ? Just want to make sure it's done correctly.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 10:20 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

On Wed, 29 Jul 2020 at 16:15, Andrew Hadley andrew.hadley@broadcom.com wrote:

...

So I'm not exactly sure how or what I'm setting up, but the only things that appear to have values is cpu_0.ini and device_1.ini.

MegaRAID provided an initial sample dump, I pulled up their ini files and made modifications to match our app.axf. I added only a few regions (that I felt were applicable) in the app.axf. (Comments in *bold red*).

The rest of the ini files are just references to configuring the names of the ini.

When I run the trc_pkt_lister I don't see any difference to my output (from before I made the changes).

Did you add the -decode option to the command line?

...

*cpu_0.ini* [device] name=cpu_0 class=core type=Cortex-A15

*ajh - There are 17 sections in the app.axf, but only a few regions that contain code. I just copied 3 of those sections into the dump regions. Do I need more? Also, this seems like it can be pulled from the axf using the fromelf app. Do I need to write a script to do this or does something already exist?*

Hard to say if these areas will completely cover the area traced - however, the decoder will output partial trace range packets when the addresses match the dump files. If trace goes out of range for the memory dumps then NACC packets will be output for the unknown addresses. I would start with these and see how far the decoder gets. Looking at a few of the addresses in the dump file they do seem to be in the range of the dump files you specify.

...

[dump0] file=app.axf address=0x70004194 length=0x3077d4 offset=0x41c8

[dump1] file=app.axf address=0x7f100000 length=0x8e0 offset=0x34

[dump2] file=app.axf address=0x7f1008e0 length=0x4a0 offset=0x914

*ajh - I don't know what to provide in regs? What is this needed for and what registers are pertinent?* [regs] R15=0 CPSR=0x4000003F

For trace - these regs are not needed. They are used if loading the snapshot into other tools.

...

*device_1.ini* *ajh - I didn't make any changes to this file, are these the coresight registers at 0x06180_0000 (Avengers CPU0 coresight block).*

Can't comment on your specific system but these are the CoreSight PFT registers as defined in the PFT specification.

...

[device] name=PTM_0 class=trace_source type=PTM1.1

[regs] ETMCR(0x0)=0x3000D400

This value indicates that cycle accurate trace is being generated - if this does not match your system then this could explain the strange cycle counts. Also return stack and timestamp tracing are active & a 32 bit context ID are being traced.

All these parameters affect how the decoder interprets the trace packets. This value must reflect the value of this register at the time trace was collected.

Regards

Mike

...

ETMIDR(0x79)=0x411CF314 ETMCCER(0x7A)=0x34C01AC2 ETMTRACEIDR(0x80)=0x0000001A

On Wed, Jul 29, 2020 at 9:03 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike, We will fix our snapshot files. Thanks for your quick repsonse.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 4:58 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

Looking at the file, and the end portion you mention, I would say that the configuration for the decoder is not correctly set up. The very high cycle numbers between E atoms and the errors such as invalid header and bad async would suggest this. trc_pkt_lister works off a snapshot directory which I am assuming you have found out. The contents of this directory set up the decode parameters for the program - so ensure that all the accompanying .ini files match your system correctly.

To get full decode you need to add in the -decode command line option., This also requires providing the program images / memory dumps containing the executed code so that the decode can take place. The process for decode takes the waypoint addresses in the PTM data and reads the instructions from the memory image from that address, The output will be executed instruction ranges - not disassembly - see the example below. This

• from one of the shipped examples with the library - shows a decode output

from an a15 running PTM. The memory images loaded for decode are listed as well.

The lines from the example: Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

shows a packet with 5 atoms, and the decode of each of those atoms into instruction executed ranges. This is achieved by walking the memory images looking for the relevant waypoint instructions corresponding to the atoms. This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) instruction range format is the final output from the library. It is up to the client of the OpenCSD library to convert these ranges into whatever the desired output is (disassmbly / statistical analysis etc.)

You can get more information on this from the library documentation - explaining the snapshot format and the operation of the library.

Regards

Mike

---

e.g. ** Library Version : 0.14.2

Test Command Line:- ./bin/linux64/rel/trc_pkt_lister -ss_dir ./snapshots/trace_cov_a15 -decode -logfilename ./results/trace_cov_a15.ppl

Trace Packet Lister : reading snapshot from path ./snapshots/trace_cov_a15 Using PTM_0_2 as trace source Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 Trace Packet Lister : Set trace element decode printer Gen_Info : Mapped Memory Accessors Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin Gen_Info : ======================== Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment Synchronisation Packet; Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x80000504; excep num (0x01) ) Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction Synchronisation packet; (Debug Exit); Addr=0x80000504; S; ISA=ARM(32); Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link )

On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Hi Mike, We are trying to make open CSD working in our silicon sample. It is very much required for our debug as we cannot attach DS5 early enough. We were able to generate the trace.bin and generate the trace decode file(attached) I have few questions [image: image.png] The end portion of teh trace looks something like this.

I know PTM only takes the branch address. Is there any way we can make it more readable by filling the missing instructions between branches? or is this the final output.

Also can you check the attached file and see if anything else is missing in our setup?

Ajith K Issac Broadcom DCSG

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

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

Thanks Mike it all starting to make sense. Another question in the below highlighted section is what does that branch address packet mean . Does it mean it was not a conditional jump but an exception jump?

Idx:16692; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x70013794:[0x700137b8] num_i(9) last_sz(4) (ISA=A32) N BR <cond>) Idx:16692; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x700137b8:[0x700137cc] num_i(5) last_sz(4) (ISA=A32) E BR <cond>) Idx:16693; ID:1a; [0xc1 0xa0 0x07 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7003A080 ~[0x3A080]; Idx:16693; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x700137ec:[0x700137f4] num_i(2) last_sz(4) (ISA=A32) E iBR V7:impl ret) Idx:16696; ID:1a; [0xca ]; ATOM : Atom packet; EENEN;

another question

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 11:29 AM Mike Leach mike.leach@linaro.org wrote:

Hi Andrew,

Given the incorrect input information I would say that the output is consistent with the .axf you provide.

On Wed, 29 Jul 2020 at 17:51, Andrew Hadley andrew.hadley@broadcom.com wrote:

...

I did, and I got data, but again I don't believe it is setup correctly, so I'm working on that first.

Here's an excerpt from the axf - but this does not seem to be matching up to the decode output unless I'm misunderstanding how the address work. 0x7003a090: e8bd88f0 .... POP {r4-r7,r11,pc} 0x7003a094: e2844001 .@.. ADD r4,r4,#1 0x7003a098: e3540c01 ..T. CMP r4,#0x100 0x7003a09c: baffffeb .... BLT 0x7003a050 ; _Z6LookupPKc + 20 0x7003a0a0: e51f0724 $... LDR r0,[pc,#-1828] ; [0x70039984] = 0x7030c204 0x7003a0a4: e1a01005 .... MOV r1,r5 0x7003a0a8: e590200c . .. LDR r2,[r0,#0xc] 0x7003a0ac: e28f0f8f .... ADR r0,{pc}+0x244 ; 0x7003a2f0 0x7003a0b0: e12fff32 2./. BLX r2 0x7003a0b4: e51f072c ,... LDR r0,[pc,#-1836] ; [0x70039990] = 0x7030c1c4 0x7003a0b8: e30031db .1.. MOV r3,#0x1db 0x7003a0bc: e59f2254 T".. LDR r2,[pc,#596] ; [0x7003a318] = 0x702bc282 0x7003a0c0: e59f1254 T... LDR r1,[pc,#596] ; [0x7003a31c] = 0x70039998 0x7003a0c4: e590600c .`.. LDR r6,[r0,#0xc] 0x7003a0c8: e28f0e25 %... ADR r0,{pc}+0x258 ; 0x7003a320 0x7003a0cc: e12fff36 6./. BLX r6 0x7003a0d0: e3a00000 .... MOV r0,#0 0x7003a0d4: eaffffec .... B 0x7003a08c ; _Z6LookupPKc + 80 _Z14GicSyncMaskInt11_IRQ_NUMBER 0x7003a0d8: e92d48f0 .H-. PUSH {r4-r7,r11,lr} 0x7003a0dc: e28db014 .... ADD r11,sp,#0x14

Here's the tail output from trc_pkt_lister -decode [...] Idx:16453; ID:1a; [0xe1 0xf9 0x03 0x88 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7001F9C0 ~[0x1F9C0]; Cycles=2; Idx:16457; ID:1a; [0xe9 0xa7 0x07 0xd1 0xd2 0x01 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7003A7D0 ~[0x3A7D0]; Cycles=3364; Idx:16464; ID:1a; [0xd2 0xd0 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431492; Idx:16469; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16474; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16480; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16485; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16490; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16496; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16501; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16506; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16512; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16517; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16522; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16528; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16533; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16538; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16545; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16550; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16555; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16561; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16566; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16571; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16577; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16582; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16587; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16593; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16598; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16603; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16609; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16614; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16619; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16625; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16630; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16635; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16641; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16646; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16651; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16657; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16662; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16667; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16674; ID:1a; [0xd4 0xe0 0xea 0x00 ]; ATOM : Atom packet; E; Cycles=218629; Idx:16678; ID:1a; [0x00 0x00 0x00 0x00 0x80 ]; BAD_SEQUENCE : Invalid sequence in packet; [ASYNC];

This would not be a bad sequence if the last byte (0x00) of the previous packet was really part of this packet!

...

Idx:16683; ID:1a; [0xa0 ]; ATOM : Atom packet; E; Cycles=8; Idx:16684; ID:1a; [0x08 0x50 0xa0 0x03 0x70 0x01 0x00 0x00 0x00 0x00 ]; ISYNC : Instruction Synchronisation packet; (Periodic); Addr=0x7003a050; S; CtxtID=00000000; ISA=ARM(32); Idx:16684; ID:1a; OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) Idx:16684; ID:1a; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; VMID=0x0; CTXTID=0x0; ) Idx:16695; ID:1a; [0x3c 0x00 ]; VMID : VM ID packet; VMID=0x0; Idx:16697; ID:1a; [0x8c ]; ATOM : Atom packet; E; Cycles=3; Idx:16697; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a050:[0x7003a068] num_i(6) last_sz(4) (ISA=A32) E BR <cond> [CC=3]; ) Idx:16698; ID:1a; [0x42 0xfe 0x9c 0xb6 0xa3 0x80 0x80 0x80 0x80 0x00 0xe8 0xca 0xd0 0xd4 0xe0 ]; TIMESTAMP : Timestamp packet; TS=0x00000000046D8E7E ~[0x46D8E7E](74288766); Cycles=3243410602; Idx:16698; ID:1a; OCSD_GEN_TRC_ELEM_TIMESTAMP( [ TS=0x0000046d8e7e]; [CC=3243410602]; ) Idx:16714; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16714; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range= 0x7003a094:[0x7003a0a0] num_i(3) last_sz(4) (ISA=A32) N BR <cond> [CC=3507659818]; )

One of the facts about the range output I did not mention was that the range is inclusive -> exclusive. That is the last address is the next address we would expect instruction trace to continue from in the event of a branch not being taken / exception return etc.. (this is largely an artifact of the decode process that walks the memory image).

So the range above represents 3 instructions (num_i(3) executed starting at the instruction @0x7003a094, and ending at the instruction @0x7003a0a0 - last_sz(4) => 0x7003a09. The additional information tells us that the last instruction was a conditional branch (BR <cond>), the N atom means it is not taken:- 0x7003a094: e2844001 .@.. ADD r4,r4,#1 0x7003a098: e3540c01 ..T. CMP r4,#0x100 0x7003a09c: baffffeb .... BLT 0x7003a050 ; _Z6LookupPKc + 20

The next instruction to be executed will be @0x7004a0a0....

Idx:16720; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N;

...

Cycles=3582108930; Idx:16720; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0a0:[0x7003a0b4] num_i(5) last_sz(4) (ISA=A32) N iBR b+link [CC=3582108930]; )

And here it is.

However - a work of caution - I do not beleive that the cycle count packets are real (if for no better reason than I do not think it takes 3582108930 cycles to execute 5 instructions)

...

Idx:16725; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552;

If we assume there is no cycle counting going on then this 5 byte sequence is:- 0xc2 - atom EEEEN 0xd4 -atom ENENE 0xc4 atom EEENE 0xe8 atom NENEE 0xca atom EENEN

So while the decode is consistent ,it cannot be correct if the input data is faulty.

...

Idx:16725; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0b4:[0x7003a0d0] num_i(7) last_sz(4) (ISA=A32) N iBR b+link [CC=2510431552]; ) Idx:16730; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16730; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0d0:[0x7003a0d8] num_i(2) last_sz(4) (ISA=A32) E BR [CC=2242577732]; ) Idx:16736; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; DCD_PTM_0026 : 0x001c (OCSD_ERR_RET_STACK_OVERFLOW) [Internal return stack overflow checks failed - popped more than we pushed.]; TrcIdx=16736; CS ID=1a; Return stack error processing atom packet.Trace Packet Lister : Data Path fatal error 0x001c (OCSD_ERR_RET_STACK_OVERFLOW) [Internal return stack overflow checks failed - popped more than we pushed.]; TrcIdx=16736; CS ID=1a; Return stack error processing atom packet.Trace Packet Lister : Trace buffer done, processed 16752 bytes.

Here we have a problem with the return stack overflowing - this could be caused if the return stack is not actually active within the trace, or the fact that the packets are not being correctly interpreted throwing off the return stack functionality

...

so - ETMCR is probably wrong. Try changing it so cycle count is not active.

Regards

Mike

...

On Wed, Jul 29, 2020 at 10:23 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike, Do you have a demo video or something which shows how it's done from beginning to trace decode ? Just want to make sure it's done correctly.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 10:20 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

On Wed, 29 Jul 2020 at 16:15, Andrew Hadley andrew.hadley@broadcom.com wrote:

...

So I'm not exactly sure how or what I'm setting up, but the only things that appear to have values is cpu_0.ini and device_1.ini.

MegaRAID provided an initial sample dump, I pulled up their ini files and made modifications to match our app.axf. I added only a few regions (that I felt were applicable) in the app.axf. (Comments in *bold red*).

The rest of the ini files are just references to configuring the names of the ini.

When I run the trc_pkt_lister I don't see any difference to my output (from before I made the changes).

Did you add the -decode option to the command line?

...

*cpu_0.ini* [device] name=cpu_0 class=core type=Cortex-A15

*ajh - There are 17 sections in the app.axf, but only a few regions that contain code. I just copied 3 of those sections into the dump regions. Do I need more? Also, this seems like it can be pulled from the axf using the fromelf app. Do I need to write a script to do this or does something already exist?*

Hard to say if these areas will completely cover the area traced - however, the decoder will output partial trace range packets when the addresses match the dump files. If trace goes out of range for the memory dumps then NACC packets will be output for the unknown addresses. I would start with these and see how far the decoder gets. Looking at a few of the addresses in the dump file they do seem to be in the range of the dump files you specify.

...

[dump0] file=app.axf address=0x70004194 length=0x3077d4 offset=0x41c8

[dump1] file=app.axf address=0x7f100000 length=0x8e0 offset=0x34

[dump2] file=app.axf address=0x7f1008e0 length=0x4a0 offset=0x914

*ajh - I don't know what to provide in regs? What is this needed for and what registers are pertinent?* [regs] R15=0 CPSR=0x4000003F

For trace - these regs are not needed. They are used if loading the snapshot into other tools.

...

*device_1.ini* *ajh - I didn't make any changes to this file, are these the coresight registers at 0x06180_0000 (Avengers CPU0 coresight block).*

Can't comment on your specific system but these are the CoreSight PFT registers as defined in the PFT specification.

...

[device] name=PTM_0 class=trace_source type=PTM1.1

[regs] ETMCR(0x0)=0x3000D400

This value indicates that cycle accurate trace is being generated - if this does not match your system then this could explain the strange cycle counts. Also return stack and timestamp tracing are active & a 32 bit context ID are being traced.

All these parameters affect how the decoder interprets the trace packets. This value must reflect the value of this register at the time trace was collected.

Regards

Mike

...

ETMIDR(0x79)=0x411CF314 ETMCCER(0x7A)=0x34C01AC2 ETMTRACEIDR(0x80)=0x0000001A

On Wed, Jul 29, 2020 at 9:03 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike, We will fix our snapshot files. Thanks for your quick repsonse.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 4:58 AM Mike Leach mike.leach@linaro.org wrote:

> Hi, > > Looking at the file, and the end portion you mention, I would say > that the configuration for the decoder is not correctly set up. The very > high cycle numbers between E atoms and the errors such as invalid header > and bad async would suggest this. > trc_pkt_lister works off a snapshot directory which I am assuming > you have found out. The contents of this directory set up the decode > parameters for the program - so ensure that all the accompanying .ini files > match your system correctly. > > To get full decode you need to add in the -decode command line > option., This also requires providing the program images / memory dumps > containing the executed code so that the decode can take place. The process > for decode takes the waypoint addresses in the PTM data and reads the > instructions from the memory image from that address, The output will be > executed instruction ranges - not disassembly - see the example below. This > - from one of the shipped examples with the library - shows a decode output > from an a15 running PTM. The memory images loaded for decode are listed as > well. > > The lines from the example: > Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl > ret) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link ) > > shows a packet with 5 atoms, and the decode of each of those atoms > into instruction executed ranges. This is achieved by walking the memory > images looking for the relevant waypoint instructions corresponding to the > atoms. > This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) > instruction range format is the final output from the library. It is up to > the client of the OpenCSD library to convert these ranges into whatever the > desired output is (disassmbly / statistical analysis etc.) > > You can get more information on this from the library documentation > - explaining the snapshot format and the operation of the library. > > Regards > > Mike > > -------------------------------- > e.g. > ** Library Version : 0.14.2 > > Test Command Line:- > ./bin/linux64/rel/trc_pkt_lister -ss_dir > ./snapshots/trace_cov_a15 -decode -logfilename > ./results/trace_cov_a15.ppl > > Trace Packet Lister : reading snapshot from path > ./snapshots/trace_cov_a15 > Using PTM_0_2 as trace source > Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 > Trace Packet Lister : Set trace element decode printer > Gen_Info : Mapped Memory Accessors > Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin > Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin > Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin > Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin > Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin > Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any > > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin > Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any > > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin > Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin > Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any > Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin > Gen_Info : ======================== > Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment > Synchronisation Packet; > Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) > Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction > Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); > Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) > Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) > Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; > Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) > Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : > Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; > Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x80000504; > excep num (0x01) ) > Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction > Synchronisation packet; (Debug Exit); Addr=0x80000504; S; ISA=ARM(32); > Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) > Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl > ret) > Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link ) > > On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < > ajith-kurian.issac@broadcom.com> wrote: > >> Hi Mike, >> We are trying to make open CSD working in our silicon sample. It >> is very much required for our debug as we cannot attach DS5 early enough. >> We were able to generate the trace.bin and generate the trace >> decode file(attached) >> I have few questions >> [image: image.png] >> The end portion of teh trace looks something like this. >> >> I know PTM only takes the branch address. Is there any way we can >> make it more readable by filling the missing instructions between branches? >> or is this the final output. >> >> Also can you check the attached file and see if anything else is >> missing in our setup? >> >> >> >> Ajith K Issac >> Broadcom DCSG >> > > > -- > Mike Leach > Principal Engineer, ARM Ltd. > Manchester Design Centre. UK >

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

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

Thanks Mike once again We were able to make it work and got a successful decode . Thanks for all the support Ajith K Issac Broadcom DCSG

On Thu, Jul 30, 2020 at 2:56 AM Mike Leach mike.leach@linaro.org wrote:

Hi Ajith,

On Wed, 29 Jul 2020 at 21:08, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike it all starting to make sense. Another question in the below highlighted section is what does that branch address packet mean . Does it mean it was not a conditional jump but an exception jump?

Idx:16692; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x70013794:[0x700137b8] num_i(9) last_sz(4) (ISA=A32) N BR <cond>) Idx:16692; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x700137b8:[0x700137cc] num_i(5) last_sz(4) (ISA=A32) E BR <cond>) Idx:16693; ID:1a; [0xc1 0xa0 0x07 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7003A080 ~[0x3A080];

For a fuller explanation see 4.5.4 of the PFT spec - but essentially branch packets are emitted whenever it is not possible to deduce a branch target / flow change from the code - i.e. exception, indirect branch, security state change.

Idx:16693; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec

...

range=0x700137ec:[0x700137f4] num_i(2) last_sz(4) (ISA=A32) E iBR V7:impl ret)

In this case it would appear to be the target for the indirect branch here.

Mike

...

Idx:16696; ID:1a; [0xca ]; ATOM : Atom packet; EENEN;

another question

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 11:29 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi Andrew,

Given the incorrect input information I would say that the output is consistent with the .axf you provide.

On Wed, 29 Jul 2020 at 17:51, Andrew Hadley andrew.hadley@broadcom.com wrote:

...

I did, and I got data, but again I don't believe it is setup correctly, so I'm working on that first.

Here's an excerpt from the axf - but this does not seem to be matching up to the decode output unless I'm misunderstanding how the address work. 0x7003a090: e8bd88f0 .... POP {r4-r7,r11,pc} 0x7003a094: e2844001 .@.. ADD r4,r4,#1 0x7003a098: e3540c01 ..T. CMP r4,#0x100 0x7003a09c: baffffeb .... BLT 0x7003a050 ; _Z6LookupPKc + 20 0x7003a0a0: e51f0724 $... LDR r0,[pc,#-1828] ; [0x70039984] = 0x7030c204 0x7003a0a4: e1a01005 .... MOV r1,r5 0x7003a0a8: e590200c . .. LDR r2,[r0,#0xc] 0x7003a0ac: e28f0f8f .... ADR r0,{pc}+0x244 ; 0x7003a2f0 0x7003a0b0: e12fff32 2./. BLX r2 0x7003a0b4: e51f072c ,... LDR r0,[pc,#-1836] ; [0x70039990] = 0x7030c1c4 0x7003a0b8: e30031db .1.. MOV r3,#0x1db 0x7003a0bc: e59f2254 T".. LDR r2,[pc,#596] ; [0x7003a318] = 0x702bc282 0x7003a0c0: e59f1254 T... LDR r1,[pc,#596] ; [0x7003a31c] = 0x70039998 0x7003a0c4: e590600c .`.. LDR r6,[r0,#0xc] 0x7003a0c8: e28f0e25 %... ADR r0,{pc}+0x258 ; 0x7003a320 0x7003a0cc: e12fff36 6./. BLX r6 0x7003a0d0: e3a00000 .... MOV r0,#0 0x7003a0d4: eaffffec .... B 0x7003a08c ; _Z6LookupPKc + 80 _Z14GicSyncMaskInt11_IRQ_NUMBER 0x7003a0d8: e92d48f0 .H-. PUSH {r4-r7,r11,lr} 0x7003a0dc: e28db014 .... ADD r11,sp,#0x14

Here's the tail output from trc_pkt_lister -decode [...] Idx:16453; ID:1a; [0xe1 0xf9 0x03 0x88 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7001F9C0 ~[0x1F9C0]; Cycles=2; Idx:16457; ID:1a; [0xe9 0xa7 0x07 0xd1 0xd2 0x01 ]; BRANCH_ADDRESS : Branch address packet; Addr=0x7003A7D0 ~[0x3A7D0]; Cycles=3364; Idx:16464; ID:1a; [0xd2 0xd0 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431492; Idx:16469; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16474; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16480; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16485; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16490; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16496; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16501; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16506; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16512; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16517; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16522; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16528; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16533; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16538; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16545; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16550; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16555; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16561; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16566; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16571; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16577; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16582; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16587; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16593; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16598; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16603; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16609; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16614; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16619; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16625; ID:1a; [0xd4 0xe0 0xea 0xc2 0xd4 ]; ATOM : Atom packet; E; Cycles=2836092421; Idx:16630; ID:1a; [0xc4 0xe8 0xca 0xd0 0xd4 ]; ATOM : Atom packet; E; Cycles=2839697025; Idx:16635; ID:1a; [0xe0 0xea 0xc2 0xd4 0xc4 ]; ATOM : Atom packet; E; Cycles=2303858344; Idx:16641; ID:1a; [0xe8 0xca 0xd0 0xd4 0xe0 ]; ATOM : Atom packet; E; Cycles=3243410602; Idx:16646; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16651; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N; Cycles=3582108930; Idx:16657; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552; Idx:16662; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16667; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; Idx:16674; ID:1a; [0xd4 0xe0 0xea 0x00 ]; ATOM : Atom packet; E; Cycles=218629; Idx:16678; ID:1a; [0x00 0x00 0x00 0x00 0x80 ]; BAD_SEQUENCE : Invalid sequence in packet; [ASYNC];

This would not be a bad sequence if the last byte (0x00) of the previous packet was really part of this packet!

...

Idx:16683; ID:1a; [0xa0 ]; ATOM : Atom packet; E; Cycles=8; Idx:16684; ID:1a; [0x08 0x50 0xa0 0x03 0x70 0x01 0x00 0x00 0x00 0x00 ]; ISYNC : Instruction Synchronisation packet; (Periodic); Addr=0x7003a050; S; CtxtID=00000000; ISA=ARM(32); Idx:16684; ID:1a; OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) Idx:16684; ID:1a; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; VMID=0x0; CTXTID=0x0; ) Idx:16695; ID:1a; [0x3c 0x00 ]; VMID : VM ID packet; VMID=0x0; Idx:16697; ID:1a; [0x8c ]; ATOM : Atom packet; E; Cycles=3; Idx:16697; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a050:[0x7003a068] num_i(6) last_sz(4) (ISA=A32) E BR <cond> [CC=3]; ) Idx:16698; ID:1a; [0x42 0xfe 0x9c 0xb6 0xa3 0x80 0x80 0x80 0x80 0x00 0xe8 0xca 0xd0 0xd4 0xe0 ]; TIMESTAMP : Timestamp packet; TS=0x00000000046D8E7E ~[0x46D8E7E](74288766); Cycles=3243410602; Idx:16698; ID:1a; OCSD_GEN_TRC_ELEM_TIMESTAMP( [ TS=0x0000046d8e7e]; [CC=3243410602]; ) Idx:16714; ID:1a; [0xea 0xc2 0xd4 0xc4 0xe8 ]; ATOM : Atom packet; N; Cycles=3507659818; Idx:16714; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range= 0x7003a094:[0x7003a0a0] num_i(3) last_sz(4) (ISA=A32) N BR <cond> [CC=3507659818]; )

One of the facts about the range output I did not mention was that the range is inclusive -> exclusive. That is the last address is the next address we would expect instruction trace to continue from in the event of a branch not being taken / exception return etc.. (this is largely an artifact of the decode process that walks the memory image).

So the range above represents 3 instructions (num_i(3) executed starting at the instruction @0x7003a094, and ending at the instruction @0x7003a0a0 - last_sz(4) => 0x7003a09. The additional information tells us that the last instruction was a conditional branch (BR <cond>), the N atom means it is not taken:- 0x7003a094: e2844001 .@.. ADD r4,r4,#1 0x7003a098: e3540c01 ..T. CMP r4,#0x100 0x7003a09c: baffffeb .... BLT 0x7003a050 ; _Z6LookupPKc + 20

The next instruction to be executed will be @0x7004a0a0....

Idx:16720; ID:1a; [0xca 0xd0 0xd4 0xe0 0xea ]; ATOM : Atom packet; N;

...

Cycles=3582108930; Idx:16720; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0a0:[0x7003a0b4] num_i(5) last_sz(4) (ISA=A32) N iBR b+link [CC=3582108930]; )

And here it is.

However - a work of caution - I do not beleive that the cycle count packets are real (if for no better reason than I do not think it takes 3582108930 cycles to execute 5 instructions)

...

Idx:16725; ID:1a; [0xc2 0xd4 0xc4 0xe8 0xca ]; ATOM : Atom packet; N; Cycles=2510431552;

If we assume there is no cycle counting going on then this 5 byte sequence is:- 0xc2 - atom EEEEN 0xd4 -atom ENENE 0xc4 atom EEENE 0xe8 atom NENEE 0xca atom EENEN

So while the decode is consistent ,it cannot be correct if the input data is faulty.

...

Idx:16725; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0b4:[0x7003a0d0] num_i(7) last_sz(4) (ISA=A32) N iBR b+link [CC=2510431552]; ) Idx:16730; ID:1a; [0xd0 0xd4 0xe0 0xea 0xc2 ]; ATOM : Atom packet; E; Cycles=2242577732; Idx:16730; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x7003a0d0:[0x7003a0d8] num_i(2) last_sz(4) (ISA=A32) E BR [CC=2242577732]; ) Idx:16736; ID:1a; [0xd4 0xc4 0xe8 0xca 0xd0 ]; ATOM : Atom packet; E; Cycles=2703967301; DCD_PTM_0026 : 0x001c (OCSD_ERR_RET_STACK_OVERFLOW) [Internal return stack overflow checks failed - popped more than we pushed.]; TrcIdx=16736; CS ID=1a; Return stack error processing atom packet.Trace Packet Lister : Data Path fatal error 0x001c (OCSD_ERR_RET_STACK_OVERFLOW) [Internal return stack overflow checks failed - popped more than we pushed.]; TrcIdx=16736; CS ID=1a; Return stack error processing atom packet.Trace Packet Lister : Trace buffer done, processed 16752 bytes.

Here we have a problem with the return stack overflowing - this could be caused if the return stack is not actually active within the trace, or the fact that the packets are not being correctly interpreted throwing off the return stack functionality

...

so - ETMCR is probably wrong. Try changing it so cycle count is not active.

Regards

Mike

...

On Wed, Jul 29, 2020 at 10:23 AM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Thanks Mike, Do you have a demo video or something which shows how it's done from beginning to trace decode ? Just want to make sure it's done correctly.

Ajith K Issac Broadcom DCSG

On Wed, Jul 29, 2020 at 10:20 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi,

On Wed, 29 Jul 2020 at 16:15, Andrew Hadley < andrew.hadley@broadcom.com> wrote:

> So I'm not exactly sure how or what I'm setting up, but the only > things that appear to have values is cpu_0.ini and device_1.ini. > > MegaRAID provided an initial sample dump, I pulled up their ini > files and made modifications to match our app.axf. > I added only a few regions (that I felt were applicable) in the > app.axf. (Comments in *bold red*). > > The rest of the ini files are just references to configuring the > names of the ini. > > When I run the trc_pkt_lister I don't see any difference to my > output (from before I made the changes). > > Did you add the -decode option to the command line?

> *cpu_0.ini* > [device] > name=cpu_0 > class=core > type=Cortex-A15 > > *ajh - There are 17 sections in the app.axf, but only a few regions > that contain code. I just copied 3 of those sections into the dump regions. > Do I need more? Also, this seems like it can be pulled from the axf using > the fromelf app. Do I need to write a script to do this or does something > already exist?* >

Hard to say if these areas will completely cover the area traced - however, the decoder will output partial trace range packets when the addresses match the dump files. If trace goes out of range for the memory dumps then NACC packets will be output for the unknown addresses. I would start with these and see how far the decoder gets. Looking at a few of the addresses in the dump file they do seem to be in the range of the dump files you specify.

> > [dump0] > file=app.axf > address=0x70004194 > length=0x3077d4 > offset=0x41c8 > > [dump1] > file=app.axf > address=0x7f100000 > length=0x8e0 > offset=0x34 > > [dump2] > file=app.axf > address=0x7f1008e0 > length=0x4a0 > offset=0x914 > > *ajh - I don't know what to provide in regs? What is this needed for > and what registers are pertinent?* > [regs] > R15=0 > CPSR=0x4000003F > > For trace - these regs are not needed. They are used if loading the snapshot into other tools.

> *device_1.ini* > *ajh - I didn't make any changes to this file, are these the > coresight registers at 0x06180_0000 (Avengers CPU0 coresight block).* >

Can't comment on your specific system but these are the CoreSight PFT registers as defined in the PFT specification.

> [device] > name=PTM_0 > class=trace_source > type=PTM1.1 > > [regs] > ETMCR(0x0)=0x3000D400 >

This value indicates that cycle accurate trace is being generated - if this does not match your system then this could explain the strange cycle counts. Also return stack and timestamp tracing are active & a 32 bit context ID are being traced.

All these parameters affect how the decoder interprets the trace packets. This value must reflect the value of this register at the time trace was collected.

Regards

Mike

> ETMIDR(0x79)=0x411CF314 > ETMCCER(0x7A)=0x34C01AC2 > ETMTRACEIDR(0x80)=0x0000001A > > > > On Wed, Jul 29, 2020 at 9:03 AM Ajith Kurian Issac < > ajith-kurian.issac@broadcom.com> wrote: > >> Thanks Mike, >> We will fix our snapshot files. Thanks for your quick repsonse. >> >> >> >> Ajith K Issac >> Broadcom DCSG >> >> >> On Wed, Jul 29, 2020 at 4:58 AM Mike Leach mike.leach@linaro.org >> wrote: >> >>> Hi, >>> >>> Looking at the file, and the end portion you mention, I would say >>> that the configuration for the decoder is not correctly set up. The very >>> high cycle numbers between E atoms and the errors such as invalid header >>> and bad async would suggest this. >>> trc_pkt_lister works off a snapshot directory which I am assuming >>> you have found out. The contents of this directory set up the decode >>> parameters for the program - so ensure that all the accompanying .ini files >>> match your system correctly. >>> >>> To get full decode you need to add in the -decode command line >>> option., This also requires providing the program images / memory dumps >>> containing the executed code so that the decode can take place. The process >>> for decode takes the waypoint addresses in the PTM data and reads the >>> instructions from the memory image from that address, The output will be >>> executed instruction ranges - not disassembly - see the example below. This >>> - from one of the shipped examples with the library - shows a decode output >>> from an a15 running PTM. The memory images loaded for decode are listed as >>> well. >>> >>> The lines from the example: >>> Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl >>> ret) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link ) >>> >>> shows a packet with 5 atoms, and the decode of each of those atoms >>> into instruction executed ranges. This is achieved by walking the memory >>> images looking for the relevant waypoint instructions corresponding to the >>> atoms. >>> This OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) >>> instruction range format is the final output from the library. It is up to >>> the client of the OpenCSD library to convert these ranges into whatever the >>> desired output is (disassmbly / statistical analysis etc.) >>> >>> You can get more information on this from the library >>> documentation - explaining the snapshot format and the operation of the >>> library. >>> >>> Regards >>> >>> Mike >>> >>> -------------------------------- >>> e.g. >>> ** Library Version : 0.14.2 >>> >>> Test Command Line:- >>> ./bin/linux64/rel/trc_pkt_lister -ss_dir >>> ./snapshots/trace_cov_a15 -decode -logfilename >>> ./results/trace_cov_a15.ppl >>> >>> Trace Packet Lister : reading snapshot from path >>> ./snapshots/trace_cov_a15 >>> Using PTM_0_2 as trace source >>> Trace Packet Lister : Protocol printer PTM on Trace ID 0x0 >>> Trace Packet Lister : Set trace element decode printer >>> Gen_Info : Mapped Memory Accessors >>> Gen_Info : FileAcc; Range::0x80000000:80000277; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_0_VECTORS.bin >>> Gen_Info : FileAcc; Range::0x80000278:80001c27; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_1_RO_CODE.bin >>> Gen_Info : FileAcc; Range::0x80001c28:80001d57; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_2_RO_DATA.bin >>> Gen_Info : FileAcc; Range::0x80001d58:80001d67; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_3_RW_DATA.bin >>> Gen_Info : FileAcc; Range::0x80001d68:80001fa7; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_4_ZI_DATA.bin >>> Gen_Info : FileAcc; Range::0x80040000:8007ffff; Mem Space::Any >>> >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_5_ARM_LIB_HEAP.bin >>> Gen_Info : FileAcc; Range::0x80080000:8008ffff; Mem Space::Any >>> >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_6_ARM_LIB_STACK.bin >>> Gen_Info : FileAcc; Range::0x80090000:8009ffff; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_7_IRQ_STACK.bin >>> Gen_Info : FileAcc; Range::0x80100000:80103fff; Mem Space::Any >>> Filename=./snapshots/trace_cov_a15/mem_Cortex-A15_0_8_TTB.bin >>> Gen_Info : ======================== >>> Idx:0; ID:0; [0x00 0x00 0x00 0x00 0x00 0x80 ]; ASYNC : Alignment >>> Synchronisation Packet; >>> Idx:0; ID:2; OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) >>> Idx:6; ID:0; [0x08 0x58 0x05 0x00 0x80 0x61 ]; ISYNC : Instruction >>> Synchronisation packet; (Debug Exit); Addr=0x80000558; S; ISA=ARM(32); >>> Idx:6; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) >>> Idx:6; ID:2; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A32) S; 32-bit; ) >>> Idx:12; ID:0; [0x84 ]; ATOM : Atom packet; E; >>> Idx:12; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000558:[0x8000055c] num_i(1) last_sz(4) (ISA=A32) E BR b+link ) >>> Idx:13; ID:0; [0x81 0x80 0x80 0x80 0x48 0x02 ]; BRANCH_ADDRESS : >>> Branch address packet; Addr=0x00000000 ~[0x0]; S; Excep=Debug Halt [01]; >>> Idx:13; ID:2; OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret >>> addr:0x80000504; excep num (0x01) ) >>> Idx:19; ID:0; [0x08 0x04 0x05 0x00 0x80 0x61 ]; ISYNC : >>> Instruction Synchronisation packet; (Debug Exit); Addr=0x80000504; S; >>> ISA=ARM(32); >>> Idx:19; ID:2; OCSD_GEN_TRC_ELEM_TRACE_ON( [debug restart]) >>> Idx:25; ID:0; [0xd0 ]; ATOM : Atom packet; ENEEE; >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000504:[0x80000518] num_i(5) last_sz(4) (ISA=A32) E BR b+link ) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x800004d8:[0x800004ec] num_i(5) last_sz(4) (ISA=A32) N BR <cond>) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x800004ec:[0x800004f4] num_i(2) last_sz(4) (ISA=A32) E BR <cond>) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000500:[0x80000504] num_i(1) last_sz(4) (ISA=A32) E iBR V7:impl >>> ret) >>> Idx:25; ID:2; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec >>> range=0x80000518:[0x80000528] num_i(4) last_sz(4) (ISA=A32) E BR b+link ) >>> >>> On Tue, 28 Jul 2020 at 20:22, Ajith Kurian Issac < >>> ajith-kurian.issac@broadcom.com> wrote: >>> >>>> Hi Mike, >>>> We are trying to make open CSD working in our silicon sample. >>>> It is very much required for our debug as we cannot attach DS5 early enough. >>>> We were able to generate the trace.bin and generate the trace >>>> decode file(attached) >>>> I have few questions >>>> [image: image.png] >>>> The end portion of teh trace looks something like this. >>>> >>>> I know PTM only takes the branch address. Is there any way we can >>>> make it more readable by filling the missing instructions between branches? >>>> or is this the final output. >>>> >>>> Also can you check the attached file and see if anything else is >>>> missing in our setup? >>>> >>>> >>>> >>>> Ajith K Issac >>>> Broadcom DCSG >>>> >>> >>> >>> -- >>> Mike Leach >>> Principal Engineer, ARM Ltd. >>> Manchester Design Centre. UK >>> >>

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

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

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