Hi Maryem,
CSAL is a library can be used to program up CoreSight trace components
and subsequently extract the trace data through the register
interface. This library principally manipulates the register sets of
Coresight components. This can be used in bare metal systems or on
Linux by mmaping the hardware memory locations of the components. The
library provides a few worked example programs illustrating the
programming and extraction of trace data.
OpenCSD is a library that will process captured trace data into a
generic output format - this is usually a list of instruction address
ranges representing executed code.
OpenCSD does not have the capability to program trace hardware for
capture, nor convert the processed trace data into assembly language.
This must be done using client programs. The DS-5 dumps you refer to
were created using ARM's DS-5 debugger tool.
The key point here is that both CSAL and OpenCSD are libraries that
are to be used as part of a larger program.
For example in the perf-opencsd-master Linux kernel tree we provide
extensions to perf (which does not use CSAL, but uses the linux
CoreSight drivers directly) that will capture trace data, and
subsequently use the OpenCSD library to process that data. Using the
'perf script' command, and an appropriate python script (also supplied
in the perf-opencsd-master), it is possible to process the trace data
captured by perf, through the OpenCSD library to generate traced
instruction ranges and then passthe traced instruction ranges to
objdump to output a disassembled sequence.
Best Regards
Mike
On 10 August 2017 at 14:49, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
> Hi Mark,
>
> I am working with the Opencsd library under linux in order to collect and
> decode the trace.
> I just discovered The CoreSight Access Library (CSAL) and I want to know
> what's the difference between both libraries.
> Besides, is it possible to work only with the opencsd library to collect and
> decode traces on-target?
>
> I am also trying to generate trace data coded in assembly language like the
> contents of the files existing within
> decoder/tests/snapshots/juno_r1_1/ds-5-dumps in the Opencsd library. It
> would be helpful to send me any steps I should follow.
>
> Best regards,
> Maryem Ayadi
--
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK
On 25 July 2017 at 21:49, yoma sophian <sophian.yoma(a)gmail.com> wrote:
> hi Mathieu:
>>
>> Get (and recompile) the latest revision of the openCSD library - that
>> should do the trick.
> after using the latest revision of the opcdCSD library, compile is pass.
> But I have some question about trace collection and decode flow
> 1. for trace collection, shall we ask perf to save some other places?
> such as USB or somewhere alse
We welcome patches.
> 2. from HOWTO document, is perf.data the trace data from ETM?
The perf.data file contains the trace data from the ETM devices, the
metadata associated with the ETM configuration and miscellaneous perf
events recorded during the session.
> 3. Why we need .debug directory?
That is where all the binaries that were involved in the trace session
are collected. Those are needed by the decoding library for proper
handling of the trace data.
> thanks ur help in advance.
+ coresight mail list
On 9 August 2017 at 18:54, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
> Good morning,
Hi,
>
> I am focusing on OpenCSD library and looking for information about the
> difference between OpenCSD and CSAL library.
> As I noticed, CSAL is for interacting directly with CoreSight trace devices
> on target and programing the tracers while OpenCSD is for collecting the
> trace and decode it.
> Is there any other information you can provide me ?
Have you ever accessed to OpenCSD github [1]? Probably you can get
more information about OpenCSD from there.
I'm not familiar with CSAL though, I can forward an Mike's email in
which he introduced a lot about that library.
I suggest you to cc coresight mail list when you have some question
about CoreSight. There is a lot of knowledgeable people on there.
Regards,
Chunyan
[1] https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md
>
> Best Regards,
> Maryem Ayadi
>
> 2017-08-04 6:42 GMT+01:00 Chunyan Zhang <zhang.chunyan(a)linaro.org>:
>>
>> On 3 August 2017 at 22:47, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote:
>> > Good morning,
>>
>> Hi,
>>
>> >
>> > I am doing an internship at STMicroelectronics and I am new to decoding
>> > traces.
>> > I just red your article entitled "System Trace Module (STM) and its
>> > usage"
>> > and the article "HOWTO-using the library with perf" and started working
>> > on
>> > System Trace Module.
>> > Unfortunately, I can't find stm_source directory. Is it only available
>> > on
>> > certain Kernel versions ?
>>
>> Yes, those patches got merged in v4.10-rc1, and you have to ensure
>> 'STM_SOURCE_FTRACE' is selected when compiling the kernel code.
>>
>> Chunyan
>>
>> >
>> > Best Regards,
>> > Maryem Ayady
>
>
Hello everyone,
Thanks for making this lovely tools, it looks very useful.
I am attempting to use OpenCSD to decode some traces I pulled off of an ARM DSTREAM using it's RDDI interface. However I've run into some trouble, and I have a few questions.
In the ocsd_etmv3_cfg struct, what register is meant by the reg_ctrl? Do they mean the ETM's main control register?
What config settings does TPIU TDATA need to be decoded with? If anyone is familiar with the API, does data from RDDI need any pre-processing before giving to openCSD? Do I need to remove the DSTREAM trace data block footer? A few of the docs reference raw DSTREAm data, so I'm a little hopeful that there's some documentation I've just missed.
- Thanks all!
Hi Mike,
I am trying to decompress trace data produced using the sysfs interface on my Juno r2 board, get back to the assembly code that was executed.
I have read through This Post<https://wiki.linaro.org/WorklingGroups/Kernel/Coresight/traceDecodingWithDS5> on the Linaro wiki, which explains how to do this with DS-5, which I do not have installed on the Juno.
I would like to know if there is a way to use the OpenCSD library, or a part of it, that will allow me to do this.
With your advice in your previous email, I have been able to use the 'trc_pkt_lister' executable, to list trace packets in a human-readable form.
I saw in the documentation for the snapshot format that there is a [dump] section for files describing a core, which might describe an area of memory containing the program executed by the core.
Can this information be used by 'trc_pkt_lister' ? I tried using it on the provided 'juno_r1_1' test snapshot, with '-decode' or with '-decode-only', but these do not appear to be what I am looking for.
Basically, Assuming I have the compiled ELF binary and the associated trace (either in text form using the output of trc_pck_lister, or using the openCSD API), which only gives me virtual addresses executed by the program and indications about taken branches, how do I know where is my program relocated?
This is the part that I am missing, I need to know how the addresses I am seeing in the trace relate to the compiled program.
I would welcome any advice on the subject.
Best regards,
Thierry
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
I'd like to subscribe.
I am trying to get guidance on taking raw TPIU data from a DSTREAM trace session and have OpenCSD as the decoder. Do the TDATA words need to be processed in some way before giving them to OpenCSD? Is there a particular format I need or some processing?
I am also curious as to what the reg_ctrl is for the config struct, is that the master control register for the ETM?
Thanks
- Akira
Title: CoreSight: Roadmap and Feedback
Duration: 45 minutes
Type of Session: Presentation + active discussion
Abstract (100 words):
The CoreSight suite of drivers and the openCSD library have come a
long way since they were first introduced. Up to now development has
been squarely aimed at providing a foundation for people to start
working from and has such concentrated on mainstream features. As the
solution matures and is being used by the community trends are
emerging regarding items to address and new features to add. This
session will highlight what Linaro is currently working on and the
roadmap envisioned for the next 12 months. From there the audience
will be encouraged to provide feedback on the plan and given the
opportunity to voice their opinion on what they think are important
features to work on.
Extended Abstract (500 words):
(I do not think and extended abstract is necessary for this topic)
Hello Mathieu
Is there a perf record option to select trace buffer size? For example something like "-m,16" to allocate 16 pages for the trace buffer?
Regards, Reza
hi all:
I use follow command for getting perf-opencsd-master.
git clone -b perf-opencsd-master
https://github.com/Linaro/OpenCSD.git perf-opencsd-master
And git commit sha is 27ecd6f2b547 ("coresight: etr: Add barrier
packet for synchronisation").
When I try to "make -C tools/perf", I get below compile error message:
util/cs-etm-decoder/cs-etm-decoder.c:238:7: error:
‘OCSD_GEN_TRC_ELEM_SWTRACE’ undeclared (first use in this function)
case OCSD_GEN_TRC_ELEM_SWTRACE:
^
util/cs-etm-decoder/cs-etm-decoder.c:238:7: note: each undeclared
identifier is reported only once for each function it appears in
util/cs-etm-decoder/cs-etm-decoder.c:239:7: error:
‘OCSD_GEN_TRC_ELEM_CUSTOM’ undeclared (first use in this function)
case OCSD_GEN_TRC_ELEM_CUSTOM:
Then I try to grep "OCSD_GEN_TRC_ELEM_SWTRACE" both in
perf-opencsd-master and opencsd/decoder directories, but get nothing.
Did I use the wrong git repository or missing any environment setting?
Thanks for you kind help in advance,
On 14 April 2017 at 16:35, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
> Hello Mathieu
>
> We have changed the device tree to reflect all CoreSight components on our platform.
> Still I do not see any device listed in the following directory
>
> /sys/bus/coresight/devices
>
> Am I missing something in Linux 4.9 configuration? I have enabled CONFIG_CORESIGHT in .config.
When the system boots AMBA probes for devices connected (and
discoverable) on the bus. The first thing to do is make sure the CS
devices show up at enumeration time. I suggest instrumenting function
amba_device_try_add() [1] to see if CS devices are discovered. If not
then it is probably a matter of enabling the debug power domain.
While debugging I also suggest to boot with the "nohlt" option or
disable CPUidle completely. That way tracers (usually located in the
CPU/cluster power domain) are guaranteed to be enabled.
If CS devices show up then you will need to instrument the _probe()
function of each CS driver to see what makes them unhappy.
Mathieu
[1]. http://lxr.free-electrons.com/source/drivers/amba/bus.c#L344
>
> Regards, Reza
>
>
> -----Original Message-----
> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
> Sent: Friday, March 31, 2017 3:37 PM
> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com>
> Subject: Re: Perf-opencsd-4.9
>
> On 31 March 2017 at 14:32, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
>> Thanks Mathieu
>>
>> I am using Yocto tool chain. So, I have to add --sysroot to both opencsd and tools/perf makefiles.
>> If I see more problems, I may have to switch building them on the target.
>
> Ok, let me know.
>
> I will be travelling for the next two weeks. As such I may be slow to respond, if at all. While I am away you can always send your questions to "coresight(a)lists.linaro.org". There is a lot of very knowledgeable people on there that can help you.
>
>>
>> Regards, Reza
>>
>> -----Original Message-----
>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
>> Sent: Friday, March 31, 2017 3:27 PM
>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com>
>> Subject: Re: Perf-opencsd-4.9
>>
>> For my own sanity I tried doing the same thing and everything works as advertised. The only difference is that I'm not cross compiling and I have gcc 5.4.0. We know how to fix the gcc 6.2 problem and the cross compilation isn't part of the equation.
>>
>> For the perf tools I am working with branch perf-openscd-4.9 (b50067a52cf3). On the openCSD side I am using the master branch (054c07caa2eb).
>>
>> Mathieu
>>
>> On 31 March 2017 at 13:52, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
>>> Thanks Mathieu
>>>
>>> I am using master branch
>>>
>>> git clone https://github.com/Linaro/OpenCSD.git my-opencsd
>>> git checkout -b master origin/master
>>>
>>> Is this a correct branch for opencsd?
>>>
>>> I am cross compiling both opencsd and tools/perf.
>>>
>>> Regards, Reza
>>>
>>> -----Original Message-----
>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
>>> Sent: Friday, March 31, 2017 2:34 PM
>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com>
>>> Subject: Re: Perf-opencsd-4.9
>>>
>>> On 31 March 2017 at 12:58, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
>>>> Hello Mathieu
>>>>
>>>>
>>>> We have taken all the patches. When building tools/perf we get the following compilation errors.
>>>> Do you have some ideas if we are missing a patch?
>>>
>>> The problem comes from mismatches between the kernel and the openCSD version. We try to keep them working for older versions but that can't be guaranteed all the time.
>>>
>>>>
>>>> CC util/parse-events.o
>>>> CC util/parse-events-flex.o
>>>> CC util/pmu.o
>>>> util/cs-etm.c:1282:27: error: ?cs_etm_global_header_fmts? defined
>>>> but not used [-Werror=unused-const-variable=] static const char * const cs_etm_global_header_fmts[] = {
>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Right, you are building branch 4.9 with a gcc version that is higher than 6.2. We have a patch for that on the 4.11-rc1 branch [1].
>>>
>>> [1].
>>> https://github.com/Linaro/OpenCSD/commit/2379238cd554a3445b87ceaa4ef0
>>> 0
>>> 15c5d25c4b3
>>>
>>>> CC util/pmu-flex.o
>>>> util/cs-etm-decoder/cs-etm-decoder.c: In function ?cs_etm_decoder__gen_trace_elem_printer?:
>>>> util/cs-etm-decoder/cs-etm-decoder.c:204:7: error: ?OCSD_GEN_TRC_ELEM_SWTRACE? undeclared (first use in this function)
>>>> case OCSD_GEN_TRC_ELEM_SWTRACE:
>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>>>> util/cs-etm-decoder/cs-etm-decoder.c:204:7: note: each undeclared
>>>> identifier is reported only once for each function it appears in
>>>> util/cs-etm-decoder/cs-etm-decoder.c:205:7: error: ?OCSD_GEN_TRC_ELEM_CUSTOM? undeclared (first use in this function)
>>>> case OCSD_GEN_TRC_ELEM_CUSTOM:
>>>> ^~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Those two are related to the openCSD version. What version of the library are you working with? In any case if you stick with the latest revision (0.5.4) or TIP you should be fine. The commits that added these two is here [2].
>>>
>>> [2].
>>> https://github.com/Linaro/OpenCSD/commit/885cb935cf04acc3d0afd2bb242b
>>> d
>>> 9f7328e7104
>>>
>>>> mv: cannot stat 'util/cs-etm-decoder/.cs-etm-decoder.o.tmp': No such
>>>> file or directory
>>>>
>>>> Regards, Reza
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
>>>> Sent: Thursday, March 30, 2017 10:15 AM
>>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com>
>>>> Subject: Re: Perf-opencsd-4.9
>>>>
>>>> On 30 March 2017 at 09:12, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
>>>>> Thanks.
>>>>>
>>>>> Do you have links to these patches?
>>>>
>>>> It's all there:
>>>> https://github.com/Linaro/OpenCSD/commits/perf-opencsd-4.9
>>>>
>>>>>
>>>>> Regards, Reza
>>>>>
>>>>> -----Original Message-----
>>>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
>>>>> Sent: Thursday, March 30, 2017 10:06 AM
>>>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com>
>>>>> Subject: Re: Perf-opencsd-4.9
>>>>>
>>>>> On 30 March 2017 at 08:51, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
>>>>>> Thanks Mathieu
>>>>>>
>>>>>> This is an in-house board and we had to do some BSP changes to boot Linux 4.9 on our board.
>>>>>
>>>>> Ok.
>>>>>
>>>>>> I just want to make sure that I merge perf-openCSD-4.9 correctly with our source tree.
>>>>>> So, are you saying that I only need to replace tool/perf directory?
>>>>>
>>>>> Simply apply the patches you find on perf-opencsd-4.9, that will make life easier on you.
>>>>>
>>>>>>
>>>>>> Regards, Reza
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
>>>>>> Sent: Thursday, March 30, 2017 9:40 AM
>>>>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com>
>>>>>> Subject: Re: Perf-opencsd-4.9
>>>>>>
>>>>>> On 29 March 2017 at 19:47, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote:
>>>>>>> Hello Matt
>>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We have Linux 4.9 running on our ARMv8 platform. I like to try
>>>>>>> instruction tracing using perf-opencsd-4.9.
>>>>>>
>>>>>> Ok, that should be an interesting project.
>>>>>>
>>>>>>>
>>>>>>> I noticed that there is a Linaro Linux source tree for perf-opencsd-4.9.
>>>>>>> Looks like this tree consists of base
>>>>>>>
>>>>>>> Linux kernel 4.9 plus some some additions to support CoreSight
>>>>>>> and instruction trace using Perf tool.
>>>>>>
>>>>>> All the kernel side of the solution is already upstream. What is on gitHub it part of the user space perf tools that haven't been upstreamed yet (we are working on it) and the openCSD decoding library.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For adding trace functionality, Is it possible to get a patch
>>>>>>> that I can apply to my base Linux 4.9?
>>>>>>
>>>>>> I'm not sure of what you mean by "a patch I can add" - can you rephrase of give me more details? All the patches on top of mainline (on gitHub) should apply cleanly to your tree.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Also which files must be changed to reflect specific SOC CoreSight topology?
>>>>>>
>>>>>> CoreSight is different on every platform, which is why all the platform specific stuff has been pushed to the device tree. Is this a commercial board or something in-house?
>>>>>>
>>>>>> In the former case support for vexpress[1], juno (R0/1/2)[2] and the dragonboard[3] are already upstream. There is also something for HiKey that I could share with you if need be. If this is an in-house project you will need to make up your own device tree base on the topology you are working with.
>>>>>>
>>>>>> I'm always interested by what people are doing with CoreSight. Get back to me if you have more questions.
>>>>>>
>>>>>> Regards,
>>>>>> Mathieu
>>>>>>
>>>>>> [1].
>>>>>> http://lxr.free-electrons.com/source/arch/arm/boot/dts/vexpress-v2
>>>>>> p
>>>>>> -
>>>>>> c
>>>>>> a
>>>>>> 15_a7.dts [2].
>>>>>> http://lxr.free-electrons.com/source/arch/arm64/boot/dts/arm/juno-
>>>>>> b
>>>>>> a
>>>>>> s
>>>>>> e
>>>>>> .dtsi [3].
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>>>> /
>>>>>> t
>>>>>> r
>>>>>> e
>>>>>> e/arch/arm64/boot/dts/qcom/msm8916.dtsi?id=refs/tags/v4.11-rc4
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards, Reza
