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