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