Hi Ajith,

Can you give me a bit more context on your system - core in use, trace protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N atoms - which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address outputs? I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the app is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

Hi Mike,

We tried using Open CSD and we got something like this after decoding the trace . Does the output makes sense for you? The branch address mentioned in the trace is actually valid. Could you please help

Thanks Ajith

On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

OpenCSD is a trace decode library that is designed to be integrated into a tool to decode trace. It is not a trace decode tool itself.

You have two choices:-

1. Write a program to use the library and decode the trace. The

'trc_pkt_lister' test program and source [decoder/tests/source/trc_pkt_lister.cpp] is a good example of how to use the library. Use the decode tree object / api to build a decoder for your configured system.

2. Limited decode can be obtained if your data is presented as a trace

snapshot to the 'trc_pkt_lister' program - this will then do some decoding of your trace. The format specification is defined in decoder/docs/specs/"ARM Trace and Debug Sanpshot file format 0v2.pdf" Example snapshots are seen in decoder/tests/snapshots. The decode from this program is limited to outputting either raw trace packets, or executed instruction ranges. Additional work will be required to provide disassembly / source code attribution of the decoded trace.

Either way you will need the following:- a) Trace data in a binary file. b) configuration information for the ETM hardware at the time of trace capture. c) Any memory images of programs executed while capturing the trace data.

I advise building the documentation for the library using the doxygen file in decoder/docs for additional information.

Regards

Mike

On 15 February 2018 at 00:51, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi,

We are trying to us the Open CSD for decoding a onchip trace in our ETB. The trace was enabled and is captured in the ETB. We read the trace back and dumped it into a text file. I am attaching it.

How can I use the CSD tool to decode it?

Thanks Ajith

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

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

Hi Mike,

We rea using an A15 dual-core processor with trace enabled only for Core0 We use PTM protocol from ARM. We rea running bare metal code no OS . We are trying to validate the trace by inducing an abort in the code .

The config details Vinu can share

Thanks Ajith

On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Hi Vinu, Mike can help us to clear our basic doubts on this. Could you please answer his queries?

On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

Can you give me a bit more context on your system - core in use, trace protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N atoms - which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address outputs? I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the app is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

We tried using Open CSD and we got something like this after decoding

the trace .

...

Does the output makes sense for you? The branch address mentioned in

the trace is actually valid.

...

Could you please help

Thanks Ajith

On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach mike.leach@linaro.org

wrote:

...

...

Hi Ajith,

OpenCSD is a trace decode library that is designed to be integrated into a tool to decode trace. It is not a trace decode tool itself.

You have two choices:-

1. Write a program to use the library and decode the trace. The

'trc_pkt_lister' test program and source [decoder/tests/source/trc_pkt_lister.cpp] is a good example of how to use the library. Use the decode tree object / api to build a decoder for your

configured system.

...

...

2. Limited decode can be obtained if your data is presented as a trace

snapshot to the 'trc_pkt_lister' program - this will then do some decoding of your trace. The format specification is defined in decoder/docs/specs/"ARM Trace and Debug Sanpshot file format 0v2.pdf" Example snapshots are seen in decoder/tests/snapshots. The decode from this program is limited to outputting either raw trace packets, or executed instruction ranges. Additional work will be required to provide disassembly / source code attribution of the decoded trace.

Either way you will need the following:- a) Trace data in a binary file. b) configuration information for the ETM hardware at the time of trace

capture.

...

...

c) Any memory images of programs executed while capturing the trace

data.

...

...

I advise building the documentation for the library using the doxygen file in decoder/docs for additional information.

Regards

Mike

On 15 February 2018 at 00:51, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi,

We are trying to us the Open CSD for decoding a onchip trace in our

ETB.

...

...

...

The trace was enabled and is captured in the ETB. We read the trace back and dumped it into a text file. I am attaching it.

How can I use the CSD tool to decode it?

Thanks Ajith

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

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

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

Attaching the files this time. zip file attachment was blocked by the mail server last time.

Thanks, Vinu

On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan < vinu.velayudhan@broadcom.com> wrote:

Hi,

Attached 7z file has all the .ini files we use with OpenCSD. I have attached a sample “tracebin.bin” file collected from the controller.

Thanks,

Vinu

*From: *Ajith Kurian Issac ajith-kurian.issac@broadcom.com *Date: *Monday, September 24, 2018 at 10:25 AM *To: *Mike Leach mike.leach@linaro.org, Vinu Velayudhan < vinu.velayudhan@broadcom.com> *Cc: *coresight@lists.linaro.org *Subject: *Re: Open CSD

Hi Mike,

We rea using an A15 dual-core processor with trace enabled only for Core0

We use PTM protocol from ARM.

We rea running bare metal code no OS .

We are trying to validate the trace by inducing an abort in the code .

The config details Vinu can share

Thanks

Ajith

On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Hi Vinu,

Mike can help us to clear our basic doubts on this. Could you please answer his queries?

On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org wrote:

Hi Ajith,

Can you give me a bit more context on your system - core in use, trace protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N atoms - which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address outputs? I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the app is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

We tried using Open CSD and we got something like this after decoding

the trace .

...

Does the output makes sense for you? The branch address mentioned in the

trace is actually valid.

...

Could you please help

Thanks Ajith

On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach mike.leach@linaro.org

wrote:

...

...

Hi Ajith,

OpenCSD is a trace decode library that is designed to be integrated into a tool to decode trace. It is not a trace decode tool itself.

You have two choices:-

1. Write a program to use the library and decode the trace. The

'trc_pkt_lister' test program and source [decoder/tests/source/trc_pkt_lister.cpp] is a good example of how to use the library. Use the decode tree object / api to build a decoder for your configured

system.

...

...

2. Limited decode can be obtained if your data is presented as a trace

snapshot to the 'trc_pkt_lister' program - this will then do some decoding of your trace. The format specification is defined in decoder/docs/specs/"ARM Trace and Debug Sanpshot file format 0v2.pdf" Example snapshots are seen in decoder/tests/snapshots. The decode from this program is limited to outputting either raw trace packets, or executed instruction ranges. Additional work will be required to provide disassembly / source code attribution of the decoded trace.

Either way you will need the following:- a) Trace data in a binary file. b) configuration information for the ETM hardware at the time of trace

capture.

...

...

c) Any memory images of programs executed while capturing the trace

data.

...

...

I advise building the documentation for the library using the doxygen file in decoder/docs for additional information.

Regards

Mike

On 15 February 2018 at 00:51, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi,

We are trying to us the Open CSD for decoding a onchip trace in our

ETB.

...

...

...

The trace was enabled and is captured in the ETB. We read the trace back and dumped it into a text file. I am attaching it.

How can I use the CSD tool to decode it?

Thanks Ajith

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

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

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

Thanks AI,

We will try it out we saw a lot of below lines getting repeated intially in the trace. Do you also see the same? Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114;

Thanks Ajith

On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com wrote:

Hi Vinu,

As Mike says, to decode to an instruction trace, you will need to give

the decoder the memory image(s) of the code being executed.

I have run this trace through another PTM decoder and it’s not flagging

up anything that looks problematic. The code appears to be looping

over code around 0x1200000, 0x7f800000 and 0xf4000000.

To show details of instructions you’d need to provide the decoder

with the code located in these areas. If you could send the image

(e.g. ELF file) we could check the decode here.

Al

*From:* CoreSight coresight-bounces@lists.linaro.org *On Behalf Of *Vinu Velayudhan *Sent:* 24 September 2018 18:48 *To:* Ajith Kurian Issac ajith-kurian.issac@broadcom.com; Mike Leach < mike.leach@linaro.org>

*Cc:* coresight@lists.linaro.org *Subject:* Re: Open CSD

Attaching the files this time. zip file attachment was blocked by the mail server last time.

Thanks,

Vinu

On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan < vinu.velayudhan@broadcom.com> wrote:

Hi,

Attached 7z file has all the .ini files we use with OpenCSD. I have attached a sample “tracebin.bin” file collected from the controller.

Thanks,

Vinu

*From: *Ajith Kurian Issac ajith-kurian.issac@broadcom.com *Date: *Monday, September 24, 2018 at 10:25 AM *To: *Mike Leach mike.leach@linaro.org, Vinu Velayudhan < vinu.velayudhan@broadcom.com> *Cc: *coresight@lists.linaro.org *Subject: *Re: Open CSD

Hi Mike,

We rea using an A15 dual-core processor with trace enabled only for Core0

We use PTM protocol from ARM.

We rea running bare metal code no OS .

We are trying to validate the trace by inducing an abort in the code .

The config details Vinu can share

Thanks

Ajith

On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Hi Vinu,

Mike can help us to clear our basic doubts on this. Could you please answer his queries?

On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org wrote:

Hi Ajith,

Can you give me a bit more context on your system - core in use, trace protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N atoms - which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address outputs? I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the app is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

We tried using Open CSD and we got something like this after decoding

the trace .

...

Does the output makes sense for you? The branch address mentioned in the

trace is actually valid.

...

Could you please help

Thanks Ajith

On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach mike.leach@linaro.org

wrote:

...

...

Hi Ajith,

OpenCSD is a trace decode library that is designed to be integrated into a tool to decode trace. It is not a trace decode tool itself.

You have two choices:-

1. Write a program to use the library and decode the trace. The

'trc_pkt_lister' test program and source [decoder/tests/source/trc_pkt_lister.cpp] is a good example of how to use the library. Use the decode tree object / api to build a decoder for your configured

system.

...

...

2. Limited decode can be obtained if your data is presented as a trace

snapshot to the 'trc_pkt_lister' program - this will then do some decoding of your trace. The format specification is defined in decoder/docs/specs/"ARM Trace and Debug Sanpshot file format 0v2.pdf" Example snapshots are seen in decoder/tests/snapshots. The decode from this program is limited to outputting either raw trace packets, or executed instruction ranges. Additional work will be required to provide disassembly / source code attribution of the decoded trace.

Either way you will need the following:- a) Trace data in a binary file. b) configuration information for the ETM hardware at the time of trace

capture.

...

...

c) Any memory images of programs executed while capturing the trace

data.

...

...

I advise building the documentation for the library using the doxygen file in decoder/docs for additional information.

Regards

Mike

On 15 February 2018 at 00:51, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi,

We are trying to us the Open CSD for decoding a onchip trace in our

ETB.

...

...

...

The trace was enabled and is captured in the ETB. We read the trace back and dumped it into a text file. I am attaching it.

How can I use the CSD tool to decode it?

Thanks Ajith

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

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

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

Hi Ajith,

I've looked at the output from the tracedump bin you provided and am seeing the same as you. I looked at the raw trace bytes too - there is nothing in the trace that would indicate the trace is incorrect or corrupted.

One point of note - the timestamp count is not increasing - this may be due to the clock driving it not being active.

Regards

Mike On Mon, 24 Sep 2018 at 21:32, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

Thanks AI,

We will try it out we saw a lot of below lines getting repeated intially in the trace. Do you also see the same? Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114;

Thanks Ajith

On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com wrote:

...

Hi Vinu,

As Mike says, to decode to an instruction trace, you will need to give

the decoder the memory image(s) of the code being executed.

I have run this trace through another PTM decoder and it’s not flagging

up anything that looks problematic. The code appears to be looping

over code around 0x1200000, 0x7f800000 and 0xf4000000.

To show details of instructions you’d need to provide the decoder

with the code located in these areas. If you could send the image

(e.g. ELF file) we could check the decode here.

Al

From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Vinu Velayudhan Sent: 24 September 2018 18:48 To: Ajith Kurian Issac ajith-kurian.issac@broadcom.com; Mike Leach mike.leach@linaro.org

Cc: coresight@lists.linaro.org Subject: Re: Open CSD

Attaching the files this time. zip file attachment was blocked by the mail server last time.

Thanks,

Vinu

On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan vinu.velayudhan@broadcom.com wrote:

Hi,

Attached 7z file has all the .ini files we use with OpenCSD. I have attached a sample “tracebin.bin” file collected from the controller.

Thanks,

Vinu

From: Ajith Kurian Issac ajith-kurian.issac@broadcom.com Date: Monday, September 24, 2018 at 10:25 AM To: Mike Leach mike.leach@linaro.org, Vinu Velayudhan vinu.velayudhan@broadcom.com Cc: coresight@lists.linaro.org Subject: Re: Open CSD

Hi Mike,

We rea using an A15 dual-core processor with trace enabled only for Core0

We use PTM protocol from ARM.

We rea running bare metal code no OS .

We are trying to validate the trace by inducing an abort in the code .

The config details Vinu can share

Thanks

Ajith

On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

Hi Vinu,

Mike can help us to clear our basic doubts on this. Could you please answer his queries?

On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org wrote:

Hi Ajith,

Can you give me a bit more context on your system - core in use, trace protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N atoms - which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address outputs? I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the app is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

We tried using Open CSD and we got something like this after decoding the trace . Does the output makes sense for you? The branch address mentioned in the trace is actually valid. Could you please help

Thanks Ajith

On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

OpenCSD is a trace decode library that is designed to be integrated into a tool to decode trace. It is not a trace decode tool itself.

You have two choices:-

1. Write a program to use the library and decode the trace. The

'trc_pkt_lister' test program and source [decoder/tests/source/trc_pkt_lister.cpp] is a good example of how to use the library. Use the decode tree object / api to build a decoder for your configured system.

2. Limited decode can be obtained if your data is presented as a trace

snapshot to the 'trc_pkt_lister' program - this will then do some decoding of your trace. The format specification is defined in decoder/docs/specs/"ARM Trace and Debug Sanpshot file format 0v2.pdf" Example snapshots are seen in decoder/tests/snapshots. The decode from this program is limited to outputting either raw trace packets, or executed instruction ranges. Additional work will be required to provide disassembly / source code attribution of the decoded trace.

Either way you will need the following:- a) Trace data in a binary file. b) configuration information for the ETM hardware at the time of trace capture. c) Any memory images of programs executed while capturing the trace data.

I advise building the documentation for the library using the doxygen file in decoder/docs for additional information.

Regards

Mike

On 15 February 2018 at 00:51, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi,

We are trying to us the Open CSD for decoding a onchip trace in our ETB. The trace was enabled and is captured in the ETB. We read the trace back and dumped it into a text file. I am attaching it.

How can I use the CSD tool to decode it?

Thanks Ajith

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

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

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

Hi Ajith,

You need to add a 'dump' section into the cpu .ini file (cpu_0.ini).

e.g. [dump0] file=afile.bin address=0x8000 length=0x2000 offset=0x100

Where: file: name of file address: address in memory that the contents of file are loaded length: [optional] length of memory in file (less than or equal to file length) offset: [optional] offset within the file that the memory block starts at.

So, for an elf/axf file you need to establish the offset into the file of the loadable code section, and its length within the file and specify these as length and offset parameters above. Address is obviously the load address for the section.

See decoder/docs/specs for the snapshot file specification document.

Most of the example snapshots in decoder\tests use plain binary memory dumps where length is the length of the file, and the start of memory is the beginning of the file so do not use offset and length.

Regards

Mike On Fri, 28 Sep 2018 at 17:44, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

Hi Mike,

Do you how we can feed the ELF file to the trace decoder? whats the command to do that? Is it ELF or axf file? Thanks Ajith

On Tue, Sep 25, 2018 at 12:05 PM Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

I've looked at the output from the tracedump bin you provided and am seeing the same as you. I looked at the raw trace bytes too - there is nothing in the trace that would indicate the trace is incorrect or corrupted.

One point of note - the timestamp count is not increasing - this may be due to the clock driving it not being active.

Regards

Mike On Mon, 24 Sep 2018 at 21:32, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Thanks AI,

We will try it out we saw a lot of below lines getting repeated intially in the trace. Do you also see the same? Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114;

Thanks Ajith

On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com wrote:

...

Hi Vinu,

As Mike says, to decode to an instruction trace, you will need to give

the decoder the memory image(s) of the code being executed.

I have run this trace through another PTM decoder and it’s not flagging

up anything that looks problematic. The code appears to be looping

over code around 0x1200000, 0x7f800000 and 0xf4000000.

To show details of instructions you’d need to provide the decoder

with the code located in these areas. If you could send the image

(e.g. ELF file) we could check the decode here.

Al

From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Vinu Velayudhan Sent: 24 September 2018 18:48 To: Ajith Kurian Issac ajith-kurian.issac@broadcom.com; Mike Leach mike.leach@linaro.org

Cc: coresight@lists.linaro.org Subject: Re: Open CSD

Attaching the files this time. zip file attachment was blocked by the mail server last time.

Thanks,

Vinu

On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan vinu.velayudhan@broadcom.com wrote:

Hi,

Attached 7z file has all the .ini files we use with OpenCSD. I have attached a sample “tracebin.bin” file collected from the controller.

Thanks,

Vinu

From: Ajith Kurian Issac ajith-kurian.issac@broadcom.com Date: Monday, September 24, 2018 at 10:25 AM To: Mike Leach mike.leach@linaro.org, Vinu Velayudhan vinu.velayudhan@broadcom.com Cc: coresight@lists.linaro.org Subject: Re: Open CSD

Hi Mike,

We rea using an A15 dual-core processor with trace enabled only for Core0

We use PTM protocol from ARM.

We rea running bare metal code no OS .

We are trying to validate the trace by inducing an abort in the code .

The config details Vinu can share

Thanks

Ajith

On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

Hi Vinu,

Mike can help us to clear our basic doubts on this. Could you please answer his queries?

On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org wrote:

Hi Ajith,

Can you give me a bit more context on your system - core in use, trace protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N atoms - which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address outputs? I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the app is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

We tried using Open CSD and we got something like this after decoding the trace . Does the output makes sense for you? The branch address mentioned in the trace is actually valid. Could you please help

Thanks Ajith

On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

OpenCSD is a trace decode library that is designed to be integrated into a tool to decode trace. It is not a trace decode tool itself.

You have two choices:-

1. Write a program to use the library and decode the trace. The

'trc_pkt_lister' test program and source [decoder/tests/source/trc_pkt_lister.cpp] is a good example of how to use the library. Use the decode tree object / api to build a decoder for your configured system.

2. Limited decode can be obtained if your data is presented as a trace

snapshot to the 'trc_pkt_lister' program - this will then do some decoding of your trace. The format specification is defined in decoder/docs/specs/"ARM Trace and Debug Sanpshot file format 0v2.pdf" Example snapshots are seen in decoder/tests/snapshots. The decode from this program is limited to outputting either raw trace packets, or executed instruction ranges. Additional work will be required to provide disassembly / source code attribution of the decoded trace.

Either way you will need the following:- a) Trace data in a binary file. b) configuration information for the ETM hardware at the time of trace capture. c) Any memory images of programs executed while capturing the trace data.

I advise building the documentation for the library using the doxygen file in decoder/docs for additional information.

Regards

Mike

On 15 February 2018 at 00:51, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote: > Hi, > > We are trying to us the Open CSD for decoding a onchip trace in our ETB. > The trace was enabled and is captured in the ETB. > We read the trace back and dumped it into a text file. > I am attaching it. > > How can I use the CSD tool to decode it? > > Thanks > Ajith > > _______________________________________________ > CoreSight mailing list > CoreSight@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/coresight >

-- Mike Leach Principal Engineer, ARM Ltd. Blackburn 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!!! we will try it Thanks Ajith

On Wed, Oct 3, 2018 at 3:23 PM Mike Leach mike.leach@linaro.org wrote:

Hi Ajith,

I was trying to create an example snapshot to demo use of the offset parameter in [dump] sections in .ini file when I discovered a bug in the snapshot reader library used by the test program than made it not use these correctly. This is now fixed in v0.9.3 of the library. There is a new test snapshot there - tests/snapshots/test-file-mem-offsets which demonstrates use of 'offset'

Regards

Mike On Mon, 1 Oct 2018 at 11:47, Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

You need to add a 'dump' section into the cpu .ini file (cpu_0.ini).

e.g. [dump0] file=afile.bin address=0x8000 length=0x2000 offset=0x100

Where: file: name of file address: address in memory that the contents of file are loaded length: [optional] length of memory in file (less than or equal to file

length)

...

offset: [optional] offset within the file that the memory block starts

at.

...

So, for an elf/axf file you need to establish the offset into the file of the loadable code section, and its length within the file and specify these as length and offset parameters above. Address is obviously the load address for the section.

See decoder/docs/specs for the snapshot file specification document.

Most of the example snapshots in decoder\tests use plain binary memory dumps where length is the length of the file, and the start of memory is the beginning of the file so do not use offset and length.

Regards

Mike On Fri, 28 Sep 2018 at 17:44, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

Do you how we can feed the ELF file to the trace decoder? whats the command to do that? Is it ELF or axf file? Thanks Ajith

On Tue, Sep 25, 2018 at 12:05 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

Hi Ajith,

I've looked at the output from the tracedump bin you provided and am seeing the same as you. I looked at the raw trace bytes too - there is nothing in the trace that would indicate the trace is incorrect or corrupted.

One point of note - the timestamp count is not increasing - this may be due to the clock driving it not being active.

Regards

Mike On Mon, 24 Sep 2018 at 21:32, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Thanks AI,

We will try it out we saw a lot of below lines getting repeated

intially in the trace.

...

...

...

...

Do you also see the same? Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114;

Thanks Ajith

On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com wrote:

...

Hi Vinu,

As Mike says, to decode to an instruction trace, you will need to

give

...

...

...

...

...

the decoder the memory image(s) of the code being executed.

I have run this trace through another PTM decoder and it’s not

flagging

...

...

...

...

...

up anything that looks problematic. The code appears to be looping

over code around 0x1200000, 0x7f800000 and 0xf4000000.

To show details of instructions you’d need to provide the decoder

with the code located in these areas. If you could send the image

(e.g. ELF file) we could check the decode here.

Al

From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of

Vinu Velayudhan

...

...

...

...

...

Sent: 24 September 2018 18:48 To: Ajith Kurian Issac ajith-kurian.issac@broadcom.com; Mike

Leach mike.leach@linaro.org

...

...

...

...

...

Cc: coresight@lists.linaro.org Subject: Re: Open CSD

Attaching the files this time. zip file attachment was blocked by

the mail server last time.

...

...

...

...

...

Thanks,

Vinu

On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan <

vinu.velayudhan@broadcom.com> wrote:

...

...

...

...

...

Hi,

Attached 7z file has all the .ini files we use with OpenCSD. I

have attached a sample “tracebin.bin” file collected from the controller.

...

...

...

...

...

Thanks,

Vinu

From: Ajith Kurian Issac ajith-kurian.issac@broadcom.com Date: Monday, September 24, 2018 at 10:25 AM To: Mike Leach mike.leach@linaro.org, Vinu Velayudhan <

vinu.velayudhan@broadcom.com>

...

...

...

...

...

Cc: coresight@lists.linaro.org Subject: Re: Open CSD

Hi Mike,

We rea using an A15 dual-core processor with trace enabled only

for Core0

...

...

...

...

...

We use PTM protocol from ARM.

We rea running bare metal code no OS .

We are trying to validate the trace by inducing an abort in the

code .

...

...

...

...

...

The config details Vinu can share

Thanks

Ajith

On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac <

ajith-kurian.issac@broadcom.com> wrote:

...

...

...

...

...

Hi Vinu,

Mike can help us to clear our basic doubts on this. Could you

please answer his queries?

...

...

...

...

...

On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

...

...

Hi Ajith,

Can you give me a bit more context on your system - core in use,

trace

...

...

...

...

...

protocol type.

Also can you upload the raw trace binary, and the snapshot config files you used - I'd like to see what the CS frames look like.

The trace looks unusual in that you seem to have repeating E/N

atoms -

...

...

...

...

...

which could be the result of running a loop. What does the traced application do? Is it a T32 app as suggested by the address

outputs?

...

...

...

...

...

I sometimes expect multiple atoms in a single packet - but in this case the cycle counts are forcing a single atom output per packet. Have you tried the -decode option and providing the memory image of the application to the decode?

This is consistent with valid trace - but without knowing what the

app

...

...

...

...

...

is doing it is not possible to say for certain.

Regards

Mike On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote: > > Hi Mike, > > We tried using Open CSD and we got something like this after

decoding the trace .

...

...

...

...

...

> Does the output makes sense for you? The branch address

mentioned in the trace is actually valid.

...

...

...

...

...

> Could you please help > > Thanks > Ajith > > On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach <

mike.leach@linaro.org> wrote:

...

...

...

...

...

>> >> Hi Ajith, >> >> OpenCSD is a trace decode library that is designed to be

integrated

...

...

...

...

...

>> into a tool to decode trace. It is not a trace decode tool

itself.

...

...

...

...

...

>> >> You have two choices:- >> >> 1) Write a program to use the library and decode the trace. The >> 'trc_pkt_lister' test program and source >> [decoder/tests/source/trc_pkt_lister.cpp] is a good example of

how to

...

...

...

...

...

>> use the library. >> Use the decode tree object / api to build a decoder for your

configured system.

...

...

...

...

...

>> >> 2) Limited decode can be obtained if your data is presented as

a trace

...

...

...

...

...

>> snapshot to the 'trc_pkt_lister' program - this will then do

some

...

...

...

...

...

>> decoding of your trace. >> The format specification is defined in decoder/docs/specs/"ARM

Trace

...

...

...

...

...

>> and Debug Sanpshot file format 0v2.pdf" >> Example snapshots are seen in decoder/tests/snapshots. >> The decode from this program is limited to outputting either

raw trace

...

...

...

...

...

>> packets, or executed instruction ranges. Additional work will be >> required to provide disassembly / source code attribution of the >> decoded trace. >> >> Either way you will need the following:- >> a) Trace data in a binary file. >> b) configuration information for the ETM hardware at the time

of trace capture.

...

...

...

...

...

>> c) Any memory images of programs executed while capturing the

trace data.

...

...

...

...

...

>> >> I advise building the documentation for the library using the

doxygen

...

...

...

...

...

>> file in decoder/docs for additional information. >> >> Regards >> >> Mike >> >> >> On 15 February 2018 at 00:51, Ajith Kurian Issac >> ajith-kurian.issac@broadcom.com wrote: >> > Hi, >> > >> > We are trying to us the Open CSD for decoding a onchip trace

in our ETB.

...

...

...

...

...

>> > The trace was enabled and is captured in the ETB. >> > We read the trace back and dumped it into a text file. >> > I am attaching it. >> > >> > How can I use the CSD tool to decode it? >> > >> > Thanks >> > Ajith >> > >> > _______________________________________________ >> > CoreSight mailing list >> > CoreSight@lists.linaro.org >> > https://lists.linaro.org/mailman/listinfo/coresight >> > >> >> >> >> -- >> Mike Leach >> Principal Engineer, ARM Ltd. >> Blackburn 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

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

Hi Mike/Ajith, We are able to specify multiple dump sections and decode the trace successfully. Will let you guys know in case we encounter any further issues.

Thanks, Karthik

On Tue, Oct 16, 2018 at 1:49 PM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

Adding Karthik,

Karthik, Could you please explain the issue you see now with the list file?

Thanks Ajith

On Wed, Oct 3, 2018 at 3:23 PM Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

I was trying to create an example snapshot to demo use of the offset parameter in [dump] sections in .ini file when I discovered a bug in the snapshot reader library used by the test program than made it not use these correctly. This is now fixed in v0.9.3 of the library. There is a new test snapshot there - tests/snapshots/test-file-mem-offsets which demonstrates use of 'offset'

Regards

Mike On Mon, 1 Oct 2018 at 11:47, Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

You need to add a 'dump' section into the cpu .ini file (cpu_0.ini).

e.g. [dump0] file=afile.bin address=0x8000 length=0x2000 offset=0x100

Where: file: name of file address: address in memory that the contents of file are loaded length: [optional] length of memory in file (less than or equal to file

length)

...

offset: [optional] offset within the file that the memory block starts

at.

...

So, for an elf/axf file you need to establish the offset into the file of the loadable code section, and its length within the file and specify these as length and offset parameters above. Address is obviously the load address for the section.

See decoder/docs/specs for the snapshot file specification document.

Most of the example snapshots in decoder\tests use plain binary memory dumps where length is the length of the file, and the start of memory is the beginning of the file so do not use offset and length.

Regards

Mike On Fri, 28 Sep 2018 at 17:44, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

Do you how we can feed the ELF file to the trace decoder? whats the command to do that? Is it ELF or axf file? Thanks Ajith

On Tue, Sep 25, 2018 at 12:05 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

Hi Ajith,

I've looked at the output from the tracedump bin you provided and am seeing the same as you. I looked at the raw trace bytes too - there is nothing in the trace that would indicate the trace is incorrect or corrupted.

One point of note - the timestamp count is not increasing - this may be due to the clock driving it not being active.

Regards

Mike On Mon, 24 Sep 2018 at 21:32, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Thanks AI,

We will try it out we saw a lot of below lines getting repeated

intially in the trace.

...

...

...

...

Do you also see the same? Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114;

Thanks Ajith

On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com

wrote:

...

...

...

...

> > Hi Vinu, > > > > As Mike says, to decode to an instruction trace, you will need to

give

...

...

...

...

> > the decoder the memory image(s) of the code being executed. > > > > I have run this trace through another PTM decoder and it’s not

flagging

...

...

...

...

> > up anything that looks problematic. The code appears to be looping > > over code around 0x1200000, 0x7f800000 and 0xf4000000. > > To show details of instructions you’d need to provide the decoder > > with the code located in these areas. If you could send the image > > (e.g. ELF file) we could check the decode here. > > > > Al > > > > > > From: CoreSight coresight-bounces@lists.linaro.org On Behalf

Of Vinu Velayudhan

...

...

...

...

> Sent: 24 September 2018 18:48 > To: Ajith Kurian Issac ajith-kurian.issac@broadcom.com; Mike

Leach mike.leach@linaro.org

...

...

...

...

> > > Cc: coresight@lists.linaro.org > Subject: Re: Open CSD > > > > Attaching the files this time. zip file attachment was blocked by

the mail server last time.

...

...

...

...

> > > > Thanks, > > Vinu > > > > > > On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan <

vinu.velayudhan@broadcom.com> wrote:

...

...

...

...

> > Hi, > > > > Attached 7z file has all the .ini files we use with OpenCSD. I

have attached a sample “tracebin.bin” file collected from the controller.

...

...

...

...

> > > > Thanks, > > Vinu > > > > > > From: Ajith Kurian Issac ajith-kurian.issac@broadcom.com > Date: Monday, September 24, 2018 at 10:25 AM > To: Mike Leach mike.leach@linaro.org, Vinu Velayudhan <

vinu.velayudhan@broadcom.com>

...

...

...

...

> Cc: coresight@lists.linaro.org > Subject: Re: Open CSD > > > > Hi Mike, > > > > We rea using an A15 dual-core processor with trace enabled only

for Core0

...

...

...

...

> > We use PTM protocol from ARM. > > We rea running bare metal code no OS . > > We are trying to validate the trace by inducing an abort in the

code .

...

...

...

...

> > > > The config details Vinu can share > > > > > > > Thanks > > Ajith > > > > On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac <

ajith-kurian.issac@broadcom.com> wrote:

...

...

...

...

> > Hi Vinu, > > Mike can help us to clear our basic doubts on this. Could you

please answer his queries?

...

...

...

...

> > > > > > On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

...

> > Hi Ajith, > > Can you give me a bit more context on your system - core in use,

trace

...

...

...

...

> protocol type. > > Also can you upload the raw trace binary, and the snapshot config > files you used - I'd like to see what the CS frames look like. > > The trace looks unusual in that you seem to have repeating E/N

atoms -

...

...

...

...

> which could be the result of running a loop. What does the traced > application do? Is it a T32 app as suggested by the address

outputs?

...

...

...

...

> I sometimes expect multiple atoms in a single packet - but in this > case the cycle counts are forcing a single atom output per packet. > Have you tried the -decode option and providing the memory image

of

...

...

...

...

> the application to the decode? > > This is consistent with valid trace - but without knowing what

the app

...

...

...

...

> is doing it is not possible to say for certain. > > Regards > > Mike > On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac > ajith-kurian.issac@broadcom.com wrote: > > > > Hi Mike, > > > > We tried using Open CSD and we got something like this after

decoding the trace .

...

...

...

...

> > Does the output makes sense for you? The branch address

mentioned in the trace is actually valid.

...

...

...

...

> > Could you please help > > > > Thanks > > Ajith > > > > On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach <

mike.leach@linaro.org> wrote:

...

...

...

...

> >> > >> Hi Ajith, > >> > >> OpenCSD is a trace decode library that is designed to be

integrated

...

...

...

...

> >> into a tool to decode trace. It is not a trace decode tool

itself.

...

...

...

...

> >> > >> You have two choices:- > >> > >> 1) Write a program to use the library and decode the trace. The > >> 'trc_pkt_lister' test program and source > >> [decoder/tests/source/trc_pkt_lister.cpp] is a good example of

how to

...

...

...

...

> >> use the library. > >> Use the decode tree object / api to build a decoder for your

configured system.

...

...

...

...

> >> > >> 2) Limited decode can be obtained if your data is presented as

a trace

...

...

...

...

> >> snapshot to the 'trc_pkt_lister' program - this will then do

some

...

...

...

...

> >> decoding of your trace. > >> The format specification is defined in decoder/docs/specs/"ARM

Trace

...

...

...

...

> >> and Debug Sanpshot file format 0v2.pdf" > >> Example snapshots are seen in decoder/tests/snapshots. > >> The decode from this program is limited to outputting either

raw trace

...

...

...

...

> >> packets, or executed instruction ranges. Additional work will

be

...

...

...

...

> >> required to provide disassembly / source code attribution of

the

...

...

...

...

> >> decoded trace. > >> > >> Either way you will need the following:- > >> a) Trace data in a binary file. > >> b) configuration information for the ETM hardware at the time

of trace capture.

...

...

...

...

> >> c) Any memory images of programs executed while capturing the

trace data.

...

...

...

...

> >> > >> I advise building the documentation for the library using the

doxygen

...

...

...

...

> >> file in decoder/docs for additional information. > >> > >> Regards > >> > >> Mike > >> > >> > >> On 15 February 2018 at 00:51, Ajith Kurian Issac > >> ajith-kurian.issac@broadcom.com wrote: > >> > Hi, > >> > > >> > We are trying to us the Open CSD for decoding a onchip

trace in our ETB.

...

...

...

...

> >> > The trace was enabled and is captured in the ETB. > >> > We read the trace back and dumped it into a text file. > >> > I am attaching it. > >> > > >> > How can I use the CSD tool to decode it? > >> > > >> > Thanks > >> > Ajith > >> > > >> > _______________________________________________ > >> > CoreSight mailing list > >> > CoreSight@lists.linaro.org > >> > https://lists.linaro.org/mailman/listinfo/coresight > >> > > >> > >> > >> > >> -- > >> Mike Leach > >> Principal Engineer, ARM Ltd. > >> Blackburn 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

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

Hi Mike, We have a few additional queries regarding the output file. Copying a snippet from the decoded trace output - .... .... Idx:1189; ID:1a; [0x84 ]; ATOM : Atom packet; E; Cycles=1; Idx:1189; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x1201dce:[0x1201dd4] num_i(3) last_sz(2) (ISA=T32) E BR [CC=1]; ) .... ....

- Is there any way to generate the instructions itself that correspond to the above execution range? i.e. can we specify a map file/disassembly which automatically generates the instructions corresponding to the above packet? - Is there any way to stop the trace and resume the trace later without loosing the trace collected before stopping?

Thanks, Karthik

On Thu, Oct 18, 2018 at 12:11 PM Karthik Raghavan < karthik.raghavan@broadcom.com> wrote:

Hi Mike/Ajith, We are able to specify multiple dump sections and decode the trace successfully. Will let you guys know in case we encounter any further issues.

Thanks, Karthik

On Tue, Oct 16, 2018 at 1:49 PM Ajith Kurian Issac < ajith-kurian.issac@broadcom.com> wrote:

...

Adding Karthik,

Karthik, Could you please explain the issue you see now with the list file?

Thanks Ajith

On Wed, Oct 3, 2018 at 3:23 PM Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

I was trying to create an example snapshot to demo use of the offset parameter in [dump] sections in .ini file when I discovered a bug in the snapshot reader library used by the test program than made it not use these correctly. This is now fixed in v0.9.3 of the library. There is a new test snapshot there - tests/snapshots/test-file-mem-offsets which demonstrates use of 'offset'

Regards

Mike On Mon, 1 Oct 2018 at 11:47, Mike Leach mike.leach@linaro.org wrote:

...

Hi Ajith,

You need to add a 'dump' section into the cpu .ini file (cpu_0.ini).

e.g. [dump0] file=afile.bin address=0x8000 length=0x2000 offset=0x100

Where: file: name of file address: address in memory that the contents of file are loaded length: [optional] length of memory in file (less than or equal to

file length)

...

offset: [optional] offset within the file that the memory block starts

at.

...

So, for an elf/axf file you need to establish the offset into the file of the loadable code section, and its length within the file and specify these as length and offset parameters above. Address is obviously the load address for the section.

See decoder/docs/specs for the snapshot file specification document.

Most of the example snapshots in decoder\tests use plain binary memory dumps where length is the length of the file, and the start of memory is the beginning of the file so do not use offset and length.

Regards

Mike On Fri, 28 Sep 2018 at 17:44, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote:

...

Hi Mike,

Do you how we can feed the ELF file to the trace decoder? whats the command to do that? Is it ELF or axf file? Thanks Ajith

On Tue, Sep 25, 2018 at 12:05 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

Hi Ajith,

I've looked at the output from the tracedump bin you provided and am seeing the same as you. I looked at the raw trace bytes too - there is nothing in the trace that would indicate the trace is incorrect or corrupted.

One point of note - the timestamp count is not increasing - this may be due to the clock driving it not being active.

Regards

Mike On Mon, 24 Sep 2018 at 21:32, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote: > > Thanks AI, > > We will try it out we saw a lot of below lines getting repeated

intially in the trace.

...

...

...

> Do you also see the same? > Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; > Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; > Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114; > > > Thanks > Ajith > > On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com

wrote:

...

...

...

>> >> Hi Vinu, >> >> >> >> As Mike says, to decode to an instruction trace, you will need

to give

...

...

...

>> >> the decoder the memory image(s) of the code being executed. >> >> >> >> I have run this trace through another PTM decoder and it’s not

flagging

...

...

...

>> >> up anything that looks problematic. The code appears to be

looping

...

...

...

>> >> over code around 0x1200000, 0x7f800000 and 0xf4000000. >> >> To show details of instructions you’d need to provide the decoder >> >> with the code located in these areas. If you could send the image >> >> (e.g. ELF file) we could check the decode here. >> >> >> >> Al >> >> >> >> >> >> From: CoreSight coresight-bounces@lists.linaro.org On Behalf

Of Vinu Velayudhan

...

...

...

>> Sent: 24 September 2018 18:48 >> To: Ajith Kurian Issac ajith-kurian.issac@broadcom.com; Mike

Leach mike.leach@linaro.org

...

...

...

>> >> >> Cc: coresight@lists.linaro.org >> Subject: Re: Open CSD >> >> >> >> Attaching the files this time. zip file attachment was blocked

by the mail server last time.

...

...

...

>> >> >> >> Thanks, >> >> Vinu >> >> >> >> >> >> On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan <

vinu.velayudhan@broadcom.com> wrote:

...

...

...

>> >> Hi, >> >> >> >> Attached 7z file has all the .ini files we use with OpenCSD. I

have attached a sample “tracebin.bin” file collected from the controller.

...

...

...

>> >> >> >> Thanks, >> >> Vinu >> >> >> >> >> >> From: Ajith Kurian Issac ajith-kurian.issac@broadcom.com >> Date: Monday, September 24, 2018 at 10:25 AM >> To: Mike Leach mike.leach@linaro.org, Vinu Velayudhan <

vinu.velayudhan@broadcom.com>

...

...

...

>> Cc: coresight@lists.linaro.org >> Subject: Re: Open CSD >> >> >> >> Hi Mike, >> >> >> >> We rea using an A15 dual-core processor with trace enabled only

for Core0

...

...

...

>> >> We use PTM protocol from ARM. >> >> We rea running bare metal code no OS . >> >> We are trying to validate the trace by inducing an abort in the

code .

...

...

...

>> >> >> >> The config details Vinu can share >> >> >> >> >> >> >> Thanks >> >> Ajith >> >> >> >> On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac <

ajith-kurian.issac@broadcom.com> wrote:

...

...

...

>> >> Hi Vinu, >> >> Mike can help us to clear our basic doubts on this. Could you

please answer his queries?

...

...

...

>> >> >> >> >> >> On Fri, Sep 21, 2018, 1:18 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

>> >> Hi Ajith, >> >> Can you give me a bit more context on your system - core in use,

trace

...

...

...

>> protocol type. >> >> Also can you upload the raw trace binary, and the snapshot config >> files you used - I'd like to see what the CS frames look like. >> >> The trace looks unusual in that you seem to have repeating E/N

atoms -

...

...

...

>> which could be the result of running a loop. What does the traced >> application do? Is it a T32 app as suggested by the address

outputs?

...

...

...

>> I sometimes expect multiple atoms in a single packet - but in

this

...

...

...

>> case the cycle counts are forcing a single atom output per

packet.

...

...

...

>> Have you tried the -decode option and providing the memory image

of

...

...

...

>> the application to the decode? >> >> This is consistent with valid trace - but without knowing what

the app

...

...

...

>> is doing it is not possible to say for certain. >> >> Regards >> >> Mike >> On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac >> ajith-kurian.issac@broadcom.com wrote: >> > >> > Hi Mike, >> > >> > We tried using Open CSD and we got something like this after

decoding the trace .

...

...

...

>> > Does the output makes sense for you? The branch address

mentioned in the trace is actually valid.

...

...

...

>> > Could you please help >> > >> > Thanks >> > Ajith >> > >> > On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach <

mike.leach@linaro.org> wrote:

...

...

...

>> >> >> >> Hi Ajith, >> >> >> >> OpenCSD is a trace decode library that is designed to be

integrated

...

...

...

>> >> into a tool to decode trace. It is not a trace decode tool

itself.

...

...

...

>> >> >> >> You have two choices:- >> >> >> >> 1) Write a program to use the library and decode the trace.

The

...

...

...

>> >> 'trc_pkt_lister' test program and source >> >> [decoder/tests/source/trc_pkt_lister.cpp] is a good example

of how to

...

...

...

>> >> use the library. >> >> Use the decode tree object / api to build a decoder for your

configured system.

...

...

...

>> >> >> >> 2) Limited decode can be obtained if your data is presented

as a trace

...

...

...

>> >> snapshot to the 'trc_pkt_lister' program - this will then do

some

...

...

...

>> >> decoding of your trace. >> >> The format specification is defined in

decoder/docs/specs/"ARM Trace

...

...

...

>> >> and Debug Sanpshot file format 0v2.pdf" >> >> Example snapshots are seen in decoder/tests/snapshots. >> >> The decode from this program is limited to outputting either

raw trace

...

...

...

>> >> packets, or executed instruction ranges. Additional work will

be

...

...

...

>> >> required to provide disassembly / source code attribution of

the

...

...

...

>> >> decoded trace. >> >> >> >> Either way you will need the following:- >> >> a) Trace data in a binary file. >> >> b) configuration information for the ETM hardware at the time

of trace capture.

...

...

...

>> >> c) Any memory images of programs executed while capturing the

trace data.

...

...

...

>> >> >> >> I advise building the documentation for the library using the

doxygen

...

...

...

>> >> file in decoder/docs for additional information. >> >> >> >> Regards >> >> >> >> Mike >> >> >> >> >> >> On 15 February 2018 at 00:51, Ajith Kurian Issac >> >> ajith-kurian.issac@broadcom.com wrote: >> >> > Hi, >> >> > >> >> > We are trying to us the Open CSD for decoding a onchip

trace in our ETB.

...

...

...

>> >> > The trace was enabled and is captured in the ETB. >> >> > We read the trace back and dumped it into a text file. >> >> > I am attaching it. >> >> > >> >> > How can I use the CSD tool to decode it? >> >> > >> >> > Thanks >> >> > Ajith >> >> > >> >> > _______________________________________________ >> >> > CoreSight mailing list >> >> > CoreSight@lists.linaro.org >> >> > https://lists.linaro.org/mailman/listinfo/coresight >> >> > >> >> >> >> >> >> >> >> -- >> >> Mike Leach >> >> Principal Engineer, ARM Ltd. >> >> Blackburn 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

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

Thanks Mike.

On Tue, Oct 23, 2018 at 2:52 AM Mike Leach mike.leach@linaro.org wrote:

Hi Karthik, On Fri, 19 Oct 2018 at 00:48, Karthik Raghavan karthik.raghavan@broadcom.com wrote:

...

Hi Mike, We have a few additional queries regarding the output file.

Copying a snippet from the decoded trace output -

...

.... .... Idx:1189; ID:1a; [0x84 ]; ATOM : Atom packet; E; Cycles=1; Idx:1189; ID:1a; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec

range=0x1201dce:[0x1201dd4] num_i(3) last_sz(2) (ISA=T32) E BR [CC=1]; )

...

.... ....

Is there any way to generate the instructions itself that correspond to

the above execution range? i.e. can we specify a map file/disassembly which automatically generates the instructions corresponding to the above packet?

Disassembly is not a function of the opencsd library. We recommend using a disassembler supplied with your chosen compiler. For example, when using perf script under linux, we supply the address information from the INSTR_RANGE packet into objdump from the gcc toolset.

...

Is there any way to stop the trace and resume the trace later without

loosing the trace collected before stopping?

...

This would depend on the mechanics and capacity of your CoreSight system. In your case, for bare metal ETB it is possible to stop trace collection - as long as the trace system is flushed on halt. Any trace would be retained in the ETB, and tracing could then restart at the current buffer pointers. However, trace can be lost if the total amount collected exceeds the buffer capacity and the buffer wraps.

Regards

Mike

...

Thanks, Karthik

On Thu, Oct 18, 2018 at 12:11 PM Karthik Raghavan <

karthik.raghavan@broadcom.com> wrote:

...

...

Hi Mike/Ajith, We are able to specify multiple dump sections and decode the trace

successfully. Will let you guys know in case we encounter any further issues.

...

...

Thanks, Karthik

On Tue, Oct 16, 2018 at 1:49 PM Ajith Kurian Issac <

ajith-kurian.issac@broadcom.com> wrote:

...

...

...

Adding Karthik,

Karthik, Could you please explain the issue you see now with the list file?

Thanks Ajith

On Wed, Oct 3, 2018 at 3:23 PM Mike Leach mike.leach@linaro.org

wrote:

...

...

...

...

Hi Ajith,

I was trying to create an example snapshot to demo use of the offset parameter in [dump] sections in .ini file when I discovered a bug in the snapshot reader library used by the test program than made it not use these correctly. This is now fixed in v0.9.3 of the library. There is a new test snapshot there - tests/snapshots/test-file-mem-offsets which demonstrates use of 'offset'

Regards

Mike On Mon, 1 Oct 2018 at 11:47, Mike Leach mike.leach@linaro.org

wrote:

...

...

...

...

...

Hi Ajith,

You need to add a 'dump' section into the cpu .ini file (cpu_0.ini).

e.g. [dump0] file=afile.bin address=0x8000 length=0x2000 offset=0x100

Where: file: name of file address: address in memory that the contents of file are loaded length: [optional] length of memory in file (less than or equal to

file length)

...

...

...

...

...

offset: [optional] offset within the file that the memory block

starts at.

...

...

...

...

...

So, for an elf/axf file you need to establish the offset into the

file

...

...

...

...

...

of the loadable code section, and its length within the file and specify these as length and offset parameters above. Address is obviously the load address for the section.

See decoder/docs/specs for the snapshot file specification document.

Most of the example snapshots in decoder\tests use plain binary

memory

...

...

...

...

...

dumps where length is the length of the file, and the start of

memory

...

...

...

...

...

is the beginning of the file so do not use offset and length.

Regards

Mike On Fri, 28 Sep 2018 at 17:44, Ajith Kurian Issac ajith-kurian.issac@broadcom.com wrote: > > Hi Mike, > > Do you how we can feed the ELF file to the trace decoder? > whats the command to do that? > Is it ELF or axf file? > Thanks > Ajith > > > On Tue, Sep 25, 2018 at 12:05 PM Mike Leach <

mike.leach@linaro.org> wrote:

...

...

...

...

...

>> >> Hi Ajith, >> >> I've looked at the output from the tracedump bin you provided

and am

...

...

...

...

...

>> seeing the same as you. >> I looked at the raw trace bytes too - there is nothing in the

trace

...

...

...

...

...

>> that would indicate the trace is incorrect or corrupted. >> >> One point of note - the timestamp count is not increasing - this

may

...

...

...

...

...

>> be due to the clock driving it not being active. >> >> Regards >> >> Mike >> On Mon, 24 Sep 2018 at 21:32, Ajith Kurian Issac >> ajith-kurian.issac@broadcom.com wrote: >> > >> > Thanks AI, >> > >> > We will try it out we saw a lot of below lines getting

repeated intially in the trace.

...

...

...

...

...

>> > Do you also see the same? >> > Idx:822; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:824; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:826; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:828; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:830; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:833; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:835; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:837; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:839; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:841; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:843; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:845; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:848; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:850; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:852; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:854; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:856; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:858; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:860; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:864; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:866; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:868; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:870; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:872; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:874; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:876; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:878; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:881; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:883; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:885; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:887; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > Idx:889; ID:1a; ATOM : Atom packet; E; Cycles=114; >> > Idx:891; ID:1a; ATOM : Atom packet; N; Cycles=114; >> > >> > >> > Thanks >> > Ajith >> > >> > On Mon, Sep 24, 2018 at 2:28 PM, Al Grant Al.Grant@arm.com

wrote:

...

...

...

...

...

>> >> >> >> Hi Vinu, >> >> >> >> >> >> >> >> As Mike says, to decode to an instruction trace, you will

need to give

...

...

...

...

...

>> >> >> >> the decoder the memory image(s) of the code being executed. >> >> >> >> >> >> >> >> I have run this trace through another PTM decoder and it’s

not flagging

...

...

...

...

...

>> >> >> >> up anything that looks problematic. The code appears to be

looping

...

...

...

...

...

>> >> >> >> over code around 0x1200000, 0x7f800000 and 0xf4000000. >> >> >> >> To show details of instructions you’d need to provide the

decoder

...

...

...

...

...

>> >> >> >> with the code located in these areas. If you could send the

image

...

...

...

...

...

>> >> >> >> (e.g. ELF file) we could check the decode here. >> >> >> >> >> >> >> >> Al >> >> >> >> >> >> >> >> >> >> >> >> From: CoreSight coresight-bounces@lists.linaro.org On

Behalf Of Vinu Velayudhan

...

...

...

...

...

>> >> Sent: 24 September 2018 18:48 >> >> To: Ajith Kurian Issac ajith-kurian.issac@broadcom.com;

Mike Leach mike.leach@linaro.org

...

...

...

...

...

>> >> >> >> >> >> Cc: coresight@lists.linaro.org >> >> Subject: Re: Open CSD >> >> >> >> >> >> >> >> Attaching the files this time. zip file attachment was

blocked by the mail server last time.

...

...

...

...

...

>> >> >> >> >> >> >> >> Thanks, >> >> >> >> Vinu >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Sep 24, 2018 at 10:42 AM Vinu Velayudhan <

vinu.velayudhan@broadcom.com> wrote:

...

...

...

...

...

>> >> >> >> Hi, >> >> >> >> >> >> >> >> Attached 7z file has all the .ini files we use with OpenCSD.

I have attached a sample “tracebin.bin” file collected from the controller.

...

...

...

...

...

>> >> >> >> >> >> >> >> Thanks, >> >> >> >> Vinu >> >> >> >> >> >> >> >> >> >> >> >> From: Ajith Kurian Issac ajith-kurian.issac@broadcom.com >> >> Date: Monday, September 24, 2018 at 10:25 AM >> >> To: Mike Leach mike.leach@linaro.org, Vinu Velayudhan <

vinu.velayudhan@broadcom.com>

...

...

...

...

...

>> >> Cc: coresight@lists.linaro.org >> >> Subject: Re: Open CSD >> >> >> >> >> >> >> >> Hi Mike, >> >> >> >> >> >> >> >> We rea using an A15 dual-core processor with trace enabled

only for Core0

...

...

...

...

...

>> >> >> >> We use PTM protocol from ARM. >> >> >> >> We rea running bare metal code no OS . >> >> >> >> We are trying to validate the trace by inducing an abort in

the code .

...

...

...

...

...

>> >> >> >> >> >> >> >> The config details Vinu can share >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks >> >> >> >> Ajith >> >> >> >> >> >> >> >> On Fri, Sep 21, 2018 at 2:19 PM, Ajith Kurian Issac <

ajith-kurian.issac@broadcom.com> wrote:

...

...

...

...

...

>> >> >> >> Hi Vinu, >> >> >> >> Mike can help us to clear our basic doubts on this. Could

you please answer his queries?

...

...

...

...

...

>> >> >> >> >> >> >> >> >> >> >> >> On Fri, Sep 21, 2018, 1:18 PM Mike Leach <

mike.leach@linaro.org> wrote:

...

...

...

...

...

>> >> >> >> Hi Ajith, >> >> >> >> Can you give me a bit more context on your system - core in

use, trace

...

...

...

...

...

>> >> protocol type. >> >> >> >> Also can you upload the raw trace binary, and the snapshot

config

...

...

...

...

...

>> >> files you used - I'd like to see what the CS frames look like. >> >> >> >> The trace looks unusual in that you seem to have repeating

E/N atoms -

...

...

...

...

...

>> >> which could be the result of running a loop. What does the

traced

...

...

...

...

...

>> >> application do? Is it a T32 app as suggested by the address

outputs?

...

...

...

...

...

>> >> I sometimes expect multiple atoms in a single packet - but in

this

...

...

...

...

...

>> >> case the cycle counts are forcing a single atom output per

packet.

...

...

...

...

...

>> >> Have you tried the -decode option and providing the memory

image of

...

...

...

...

...

>> >> the application to the decode? >> >> >> >> This is consistent with valid trace - but without knowing

what the app

...

...

...

...

...

>> >> is doing it is not possible to say for certain. >> >> >> >> Regards >> >> >> >> Mike >> >> On Thu, 20 Sep 2018 at 23:58, Ajith Kurian Issac >> >> ajith-kurian.issac@broadcom.com wrote: >> >> > >> >> > Hi Mike, >> >> > >> >> > We tried using Open CSD and we got something like this

after decoding the trace .

...

...

...

...

...

>> >> > Does the output makes sense for you? The branch address

mentioned in the trace is actually valid.

...

...

...

...

...

>> >> > Could you please help >> >> > >> >> > Thanks >> >> > Ajith >> >> > >> >> > On Thu, Feb 15, 2018 at 7:55 AM, Mike Leach <

mike.leach@linaro.org> wrote:

...

...

...

...

...

>> >> >> >> >> >> Hi Ajith, >> >> >> >> >> >> OpenCSD is a trace decode library that is designed to be

integrated

...

...

...

...

...

>> >> >> into a tool to decode trace. It is not a trace decode tool

itself.

...

...

...

...

...

>> >> >> >> >> >> You have two choices:- >> >> >> >> >> >> 1) Write a program to use the library and decode the

trace. The

...

...

...

...

...

>> >> >> 'trc_pkt_lister' test program and source >> >> >> [decoder/tests/source/trc_pkt_lister.cpp] is a good

example of how to

...

...

...

...

...

>> >> >> use the library. >> >> >> Use the decode tree object / api to build a decoder for

your configured system.

...

...

...

...

...

>> >> >> >> >> >> 2) Limited decode can be obtained if your data is

presented as a trace

...

...

...

...

...

>> >> >> snapshot to the 'trc_pkt_lister' program - this will then

do some

...

...

...

...

...

>> >> >> decoding of your trace. >> >> >> The format specification is defined in

decoder/docs/specs/"ARM Trace

...

...

...

...

...

>> >> >> and Debug Sanpshot file format 0v2.pdf" >> >> >> Example snapshots are seen in decoder/tests/snapshots. >> >> >> The decode from this program is limited to outputting

either raw trace

...

...

...

...

...

>> >> >> packets, or executed instruction ranges. Additional work

will be

...

...

...

...

...

>> >> >> required to provide disassembly / source code attribution

of the

...

...

...

...

...

>> >> >> decoded trace. >> >> >> >> >> >> Either way you will need the following:- >> >> >> a) Trace data in a binary file. >> >> >> b) configuration information for the ETM hardware at the

time of trace capture.

...

...

...

...

...

>> >> >> c) Any memory images of programs executed while capturing

the trace data.

...

...

...

...

...

>> >> >> >> >> >> I advise building the documentation for the library using

the doxygen

...

...

...

...

...

>> >> >> file in decoder/docs for additional information. >> >> >> >> >> >> Regards >> >> >> >> >> >> Mike >> >> >> >> >> >> >> >> >> On 15 February 2018 at 00:51, Ajith Kurian Issac >> >> >> ajith-kurian.issac@broadcom.com wrote: >> >> >> > Hi, >> >> >> > >> >> >> > We are trying to us the Open CSD for decoding a onchip

trace in our ETB.

...

...

...

...

...

>> >> >> > The trace was enabled and is captured in the ETB. >> >> >> > We read the trace back and dumped it into a text file. >> >> >> > I am attaching it. >> >> >> > >> >> >> > How can I use the CSD tool to decode it? >> >> >> > >> >> >> > Thanks >> >> >> > Ajith >> >> >> > >> >> >> > _______________________________________________ >> >> >> > CoreSight mailing list >> >> >> > CoreSight@lists.linaro.org >> >> >> > https://lists.linaro.org/mailman/listinfo/coresight >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Mike Leach >> >> >> Principal Engineer, ARM Ltd. >> >> >> Blackburn 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

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

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