_______________________________________________Hi Hugh, sorry no, I don't know of any. As far as I know, any integration
work we did at our end for either of these features, used FPGA targets.
Al
From: Hugh O'Keeffe <hugh.okeeffe@ashling.com>
Sent: 06 April 2022 14:23
To: Mike Leach <mike.leach@linaro.org>; Al Grant <Al.Grant@arm.com>
Cc: coresight@lists.linaro.org
Subject: Reference platform
Hi Mike and Al,
Any suggestions for a reference platform that we could start some OpenCSD and CSAL investigative engineering working on?
Ideally:
- Multi-core with SoC-600 and ELA-600 CoreSight
- SoC-600 trace streaming interface between host and target using USB3.1 (i.e. no debug probe necessary)
- Linux/Android
Would appreciate your inputs
Thanks
Hugh
-----Original Message-----
From: Al Grant <Al.Grant@arm.com>
Sent: Monday 28 March 2022 16:25
To: Mike Leach <mike.leach@linaro.org>; Hugh O'Keeffe <hugh.okeeffe@ashling.com>
Cc: coresight@lists.linaro.org
Subject: RE: CoreSight ELA-600 Embedded Logic Analyzer
> -----Original Message-----
> From: Mike Leach <mike.leach@linaro.org>
> Sent: 28 March 2022 12:44
> To: Hugh O'Keeffe <hugh.okeeffe@ashling.com>
> Cc: Al Grant <Al.Grant@arm.com>; coresight@lists.linaro.org
> Subject: Re: CoreSight ELA-600 Embedded Logic Analyzer
>
> Hi Hugh,
>
> On Mon, 28 Mar 2022 at 11:41, Hugh O'Keeffe <hugh.okeeffe@ashling.com>
> wrote:
> >
> > Hi Al and Mike,
> >
> > Appreciate your response. It seems that OpenCSD and CSAL are very
> similar. Are they two different approaches to solving the same problem
> OR in fact are they inherently different? I note that OpenCSD appears
> to actually decode trace as well (which CSAL does not appear to support).
> >
>
> CSAL primarily configures and programs CoreSight components using the
> memory interface. Either bare metal, or under linux if the correct
> memory access is allowed by the kernel configuration. It also has a
> bunch of example programs demonstrating usage of the library, and
> extracting trace on certain platforms.
>
> OpenCSD decodes any collected trace. It does not do any configuration
> - but requires certain trace configuration values to be provided in
> order to do the decode - alongside memory images if full CPU
> instruction trace decode is required.
> It does not do any data presentation or correlation - that is for any
> client application to do - though it does have packet printing
> routines that will give a human readable version of the decoded packets.
>
> OpenCSD is used by perf in linux to do all the decode for this tool.
>
> OpenCSD does come with its own standalone test program trc_pkt_lister
> - which will decode trace snapshots and output packets in the readable
> format mentioned above. These snapshots consist of trace data buffers
> + a set of .ini type files that contain the configuration of the
> hardware, and the memory images needed for full decode. If packet
> decode only is required then the memory images can be omitted. The
> specification for trace snapshots is provided in the OpenCSD github
> repository, and example snapshots are also in the repository.
>
> There is no current ELA600 driver in the kernel - and I am unsure if
> there is one in development.
> If your ELA600 is configured to output to the Coresight trace bus -
> then configuring using CSAL / decoding using OpenCSD would be a possible path.
> If it is configured to use its own internal RAMs then OpenCSD will not help.
>
> As Al mentions, the actual format of any given ELA data is SoC
> specific - so interpretation will have to be customized.
>
> Assuming you configure and get the device to trace into an ETR / ETF
> then this data will be multiplexed into the CoreSight frame format -
> on an ATID basis.
> OpenCSD could help here in that the front end will demultiplex the
> data to produce a byte stream input for a decoder based on the ATID.
> OpenCSD contains an API that allows custom decoders to be registered
> with the library.
> Thus an ELA decoder can be registered, then an instance attached to
> the ATID being used for the ELA600 and the library would feed the
> demultiplexed stream to the decoder. Alternatively, it should be
> relatively easy to write a simple program using the library demux
> components to take in a formatted buffer and output a binary file of raw data for a given ATID.
>
> Regards
>
> Mike
>
> > Would appreciate any pointers or comments as to how they compare and
> what would be my best starting point.
Further to Mike's excellent summary, CSAL is really a few different things:
- a pure C library for CoreSight configuration, suitable for embedding in firmware, RTOS, boot code etc. It can run over Linux /dev/mem, but this is more for general testing than expectation anyone would want to run it this way, especially now that Linux has its own drivers for ETM. In theory this could be combined with OpenCSD, i.e. use CSAL to configure a trace device and OpenCSD to decode it. I don't know that anyone has done that as CSAL's really designed for more limited targets where you’d likely decode the trace offline.
- in coresight-tools (csscan.py and some kernel modules): tools for CoreSight device and topology discovery, and status reporting.
The discovery phase is usally something that you'd only do once when you get a new target, as it may leave the target in odd states. Status reporting is harmless though and may be useful when diagnosing issues with kernel drivers, or even external debug. These Python tools can write to the CoreSight devices. This is required for topology discovery, but any kind of programming is possible if you know the register offsets and values.
- for testing, there's a daemon (devmemd) which can run on a target to do the low-level register access, allowing all the complicated stuff done by CSAL and csscan.py to be run on your development machine where it may be easier to experiment with it.
We also have some Python modules for decoding trace but these currentlly aren't upstream - you wouldn't want to use these for a production tool (you should use OpenCSD) but they may be useful when experimenting - I will look at getting them upstream.
Al
> >
> > Thanks
> > Hugh
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Al Grant <Al.Grant@arm.com>
> > Sent: Friday 25 March 2022 09:49
> > To: Mike Leach <mike.leach@linaro.org>; Hugh O'Keeffe
> > <hugh.okeeffe@ashling.com>
> > Cc: coresight@lists.linaro.org
> > Subject: RE: CoreSight ELA-600 Embedded Logic Analyzer
> >
> > > On Thu, 24 Mar 2022 at 17:47, Hugh O'Keeffe
> > > <hugh.okeeffe@ashling.com>
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Couple of questions:
> > > >
> > > > 1. Does anyone know of any other software options other than
> > > > DS-5 for
> > > configuring, capturing and viewing data using the ELA-600 ?
> >
> > In https://github.com/ARM-software/CSAL, the csscan.py script has
> > some
> basic support for reading the ELA config and dumping its SRAM buffer.
> No support for decoding ELA capture out of a CoreSight trace stream
> though, as it was only tested on ELA-500.
> >
> > The assignment of input signals may be SoC-specific and there may
> > also be
> SoC-specific obfuscation applied to the data - this is one of those
> "ask your SoC vendor" situations. The scripts that have gone upstream
> don't reveal anything that is not already public.
> >
> > Al
> >
> >
> > > >
> > > > 2. I could roll my own but I don't think OpenCSD has support for
> > > > the
> > > > ELA-
> > > 600. Correct ?
> > > >
> > >
> > > As I maintain OpenCSD I can answer this second question....
> > >
> > > No - there is not an ELA specific decoder in OpenCSD. Nor are
> > > there plans to add one at present.
> > > That said the the OpenCSD infrastucture should allow a new decode
> > > module to be added easily.
> > >
> > > Regards
> > >
> > > Mike
> > >
> > >
> > > > Thanks in advance
> > > >
> > > > Hugh
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: coresight-request@lists.linaro.org
> > > > <coresight-request@lists.linaro.org>
> > > > Sent: Thursday 24 March 2022 17:36
> > > > To: Hugh O'Keeffe <hugh.okeeffe@ashling.com>
> > > > Subject: Welcome to the "CoreSight" mailing list
> > > >
> > > > Welcome to the "CoreSight" mailing list!
> > > >
> > > > To post to this list, send your message to:
> > > >
> > > > coresight@lists.linaro.org
> > > >
> > > > You can unsubscribe or make adjustments to your options via
> > > > email by
> > > sending a message to:
> > > >
> > > >
> > > > with the word 'help' in the subject or body (don't include the
> > > > quotes), and
> > > you will get back a message with instructions. You will need your
> > > password to change your options, but for security purposes, this
> > > password is not included here. If you have forgotten your
> > > password you will need to reset it via the web UI.
> > > > _______________________________________________
> > > > CoreSight mailing list -- coresight@lists.linaro.org To
> > > > unsubscribe send an email to coresight-leave@lists.linaro.org
> > >
> > >
> > >
> > > --
> > > Mike Leach
> > > Principal Engineer, ARM Ltd.
> > > Manchester Design Centre. UK
> > > _______________________________________________
> > > CoreSight mailing list -- coresight@lists.linaro.org To
> > > unsubscribe send an email to coresight-leave@lists.linaro.org
>
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
CoreSight mailing list -- coresight@lists.linaro.org
To unsubscribe send an email to coresight-leave@lists.linaro.org