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
Hi,
we started looking at how to enable collection of branch traces with
coresight etm on the hikey boards that are the reference platform for
the android linux-4.9 work. Does somebody from Linaro have access
to the description of where the coresight components are located for
the hikey devices? We would appreciate help on enabling linux-perf
collection of traces on the hikey.
Thanks,
Sebastian
[re-adding cc list, assuming didn't hit reply-all?]
On Tue, 14 Mar 2017 19:12:08 +0000
Mike Leach <mike.leach(a)linaro.org> wrote:
> On 14 March 2017 at 16:10, Kim Phillips <kim.phillips(a)arm.com> wrote:
>
> > still results in:
> >
> > util/cs-etm.c:1466:27: error: ‘cs_etm_global_header_fmts’ defined but not
> > used [-Werror=unused-const-variable=]
> > static const char * const cs_etm_global_header_fmts[] = {
> > ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > What toolchain and/or version are you using?
> >
> I'm using a linaro build of gcc 4.9.
>
> aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.05) 4.9.3 20150413 (prerelease)
Linaro appear to have removed that release from their repo:
http://releases.linaro.org/components/toolchain/binaries/
So I used this one - which AFAICT is the closest to your version - to
cross-build both the kernel with your config, and perf:
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease)
Building perf didn't require the patch I sent due to an old gcc bug
that apparently finally got fixed recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
I then ran the resulting kernel (which still had the extra patch, so
commit 0d15341 == c50837 + the patch), and perf:
root@juno:~# ./perf --version
perf version 4.11.rc1.gc50837
root@juno:~# strings -a perf | grep "GCC: ("
GCC: (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease)
root@juno:~# dmesg | grep gcc
[ 0.000000] Linux version 4.11.0-rc1-g0d15341 (kim@dupont) (gcc version 4.9.4 20151028 (prerelease) (Linaro GCC 4.9-2016.02) ) #3 SMP PREEMPT Tue Mar 14 22:41:34 CDT 2017
root@juno:~# taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
[ 870.355660] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled
[ 870.362736] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled
[ 870.369127] coresight-tmc 20010000.etf: TMC-ETF enabled
[ 870.374304] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled
[ 870.380698] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled
[ 870.387858] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled
[ 870.394325] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled
[ 870.400806] coresight-tmc 20010000.etf: TMC disabled
[ 870.405722] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled
[ 870.412184] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled
[ 870.419350] coresight-tmc 20070000.etr: TMC-ETR disabled
[ 870.425083] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled
[ 870.432153] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled
[ 870.438542] coresight-tmc 20010000.etf: TMC-ETF enabled
[ 870.443718] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled
[ 870.450112] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled
Linux
[ 870.476156] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled
[ 870.482625] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled
[ 870.489106] coresight-tmc 20010000.etf: TMC disabled
[ 870.494023] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled
[ 870.500485] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled
[ 870.507651] coresight-tmc 20070000.etr: TMC-ETR disabled
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.015 MB perf.data ]
which appears to have worked the first time.
Then I tried a second time - literally up-arrow, enter - and got the
same exact hard hang as I get with the modern compilers the first time:
root@juno:~# taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
[ 1965.355162] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled
[ 1965.362238] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled
[ 1965.368629] coresight-tmc 20010000.etf: TMC-ETF enabled
[ 1965.373807] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled
[ 1965.380201] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled
Linux
[ 1965.405984] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled
[ 1965.412453] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled
[ 1965.418934] coresight-tmc 20010000.etf: TMC disabled
[ 1965.423850] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled
[ 1965.430312] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled
[ 1965.437478] coresight-tmc 20070000.etr: TMC-ETR disabled
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote
which is along the same instability lines as the other time that
execution behaviour differed depending on whether it executed first or
not...
> > > > $ sudo taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u
> > --per-thread
> > > taskset -c 2 uname
> > > > failed to mmap with 12 (Cannot allocate memory)
> > >
> > > That said I get this too if I do enable sinks. However as you say after
> > the
> > > initial attempt the problem disappears.
> >
> > Right, at least we have one problem reproduced on both sides now.
...here.
> > It hung before completing that last sentence.
> >
> > Perhaps the bug is exasperated by toolchain and/or host and target
> > rootfs distribution differences? My juno target runs debian, and I
> > recently upgraded to stretch in order to get a version of gcc that
> > would support autoFDO.
>
> My juno is has a debian-jessie-developer root-fs from
> http://releases.linaro.org/debian/images/developer-arm64/16.04/
> At present I cannot build autofdo - I still have some package issues, but
> for perf and the kernel I am x-compiling on my ubuntu VM anyway, so the
> installed compilers have no effect on the perf runs,.
OK, can you try a more modern toolchain please? The one you're using
isn't available anymore, AutoFDO requires gcc 5 and higher, and you're
not seeing the build failures others see, but most importantly, it
should make it easier to reproduce the hard lockup: at least that's
the case on the Juno r2.
Thanks,
Kim
Hello,
I am trying to use Coresight drivers on Juno r0 board with 4.9 Linux
sources (Linaro release 17.01 with 'latest-armlt').
I have tried the configuration with ETM as the source and ETF as the
sink and it is working as expected.
But with ETR as the sink, when stopping the tracing, kernel panic occurs.
The bug can be reproduced with the following steps:
/ # echo 1 > /sys/bus/coresight/devices/20070000.etr/enable_sink
/ # echo 1 > /sys/bus/coresight/devices/22040000.etm/enable_source
/ # echo 0 > /sys/bus/coresight/devices/22040000.etm/enable_source
Sometime the system also hangs without printing panic message.
I am attaching the log file and .config file along with this mail. From
the logs, it looks like an arm SCP firmware problem.
Let me know if I am missing some steps/configuration or If this is a
know hardware/firmware problem with hopefully some workarounds existing.
Thanks and regards,
Don Kuzhiyelil
Good day to all,
A patch sent by Suzuki a few weeks ago [1] unearthed a problem with
how we deal with the "enable_sink" flag in the CS core. So far we
have been concentrating on system-wide trace scenarios [2] but per-CPU
[3] scenarios are also valid. In system-wide mode a single event is
generated by the perf user space and communicated to the kernel. In
per-CPU mode an event is generated for each CPU present in the system
or specified on the cmd line, and that is where our handling of the
"enable_sink" flag fails (get back to me if you want more details on
that).
My solution is to add the sink definition to the perf_event_attr
structure [4] that gets sent down to the kernel from user space. That
way there is no confusion about what sink belongs to what event. To
do that I will need to have a chat with the guys in the #perf IRC
channel, something I expect to be fairly tedious.
But before moving ahead we need to agree on the syntax we want to have
in the future. That way what I do now with the perf folks doesn't
have to be undone in a few months.
For the following I will be using figure 2-9 on page 2-33 in this document [5].
So far we have been using this syntax:
# perf record -e cs_etm/(a)20070000.etr/ --per-thread $COMMAND
This will instruct perf to select the ETR as a sink. Up to now not
specifying a sink is treated as an error condition since perf doesn't
know what sink to select.
The main goal of writing all this is that I am suggesting to revisit that.
What I am proposing is that _if_ a sink is omitted on the perf command
line, the perf infrastructure will pick the _first_ sink it finds when
doing a walk through of the CS topology. This is very advantageous
when thinking about the syntax required to support upcoming systems
where we have a one-to-one mapping between source and sink.
In such a system specifying sinks for each CPU on the perf command
line simply doesn't scale. Even on a small system I don't see users
specifying a sink for each CPU. Since the sink for each CPU will be
the first one found during the walk through, it is implicit that this
sink should be used and doesn't need to be specified explicitly.
It would also allow for the support of topologies like Juno-R1 [5]
where we have a couple of ETF in the middle. Those are perfectly
valid sinks but right now the current scheme doesn't allow us to use
them. If we pick the first sink we find along the way we can
automatically support something like this.
I have reflected quite extensively on this and I think it can work.
The only time it can fail is if at some point we we get more than one
sink associated with each tracer. But how likely is this?
What we decide now will not be undone easily, if at all. Please read
my email a couple of times and give it some consideration. Comment
and ideas are welcomed.
Best regards,
Mathieu
[1]. https://patchwork.kernel.org/patch/9657141/
[2]. perf record -e cs_etm/(a)20070000.etr/u --per-thread $COMMAND
[3]. perf record -e cs_etm/(a)20070000.etr/u --C 0,2-3 $COMMAND
[4]. http://lxr.free-electrons.com/source/include/uapi/linux/perf_event.h#L283
[5]. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515d.b/DDI0515D_b_juno…
On 17 April 2017 at 10:45, Bamvor Zhang Jian
<bamvor.zhangjian(a)linaro.org> wrote:
> Hi,
>
> On 17 April 2017 at 21:21, Mathieu Poirier <mathieu.poirier(a)linaro.org> wrote:
>> [snip]
>>
>> I have been travelling for the last two weeks and don't remember if I
>> have answered this already.
>>
>>>>
>>>> The wrapping around is normal and can't be avoided. Problems happens
>>>> when we get a wrap around and Perf decides to concatenate buffers in a
>>>> single notification to user space. When that happens there is no way
>>>> for the decoding library to know the boundaries of individual packets,
>>>> resulting in a lost of synchronisation and proper decoding of traces.
>>>>
>>>> This is very difficult to duplicate, hence taking a long time to deal
>>>> with. I am still not sure about the conditions needed for Perf to
>>>> concatenate buffers together.
>>> Thanks for your expaination. So, will it be exist in the any senario?
>>
>> Yes, this can happen in any scenario.
>>
>>> If so, I think we need this patch too.
>>> We encouter the wrong package recently and we have already use
>>> filter. How could we know if it is the same issue?
>>
>> Sorry, I don't understand what you mean here by "wrong package" and
>> the correlation is has on filters. Please explain further if you
>> still need input on this.
> 'Wrong packages' seem a little bit misleading.
"packet" is the word you are looking for.
> I would say there are some
> unexpected packages. Maybe I could send you the full log of packages
> tomorrow.
I won't be able to look at it.
>In summary, we found the following issues respectively:
> 1. We found that if we start etm in the start/stop range, sometimes the
> first address package(a jump or an instruction after isb) may be lost.
> If we do a 100 times loop after the coresight timeout of etm enable.
> It will not lost the package. I suspect there are some configuration issues
> in our etm. But I do not find a clue right now. Is there some suggestion
> from your side?
I strongly suggest you purchase a dragonboard. That way you can
reproduce the problems you are seeing on your platform on the
dragonboard. That way it is much easier for us to work on issues you
may encounter. This will be money well invested (they are very
cheap).
Beleive me, I wish we could use the HiKey but CS support on that
platform isn't very encouraging at this time (not for the lack of
trying).
> 2. We found that there are some full zero(64bit) packages. Is it usual?
It isn't no. Once again if you can reproduce this on a dragonboard
I'd be happy to look at it. Otherwise it is impossible for me to
help.
>
> Therea are probably some other questions. But it is too late for me(midnight
> in beijing time). I could not recall the details. If I found other issues,
> I will send to you later.
Very well.
Mathieu
>
> Thanks.
>
> Bamvor
>>
>>
>>> I saw the description
>>> of overflow. Could it monitor by CTI?
>>
>> CTIs would indeed prevent this from happening.
>>
>>>
>>> Regards
>>>
>>> Bamvor
>>>
>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Bamvor
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Bamvor
>>>>>>>> After that I may be
>>>>>>>> able to look at it if nothing else gets in the way.
Hi,
I have a question about tracing on cortex A.I have a plateform based on 2 cortex A7,and I need to trace the executed application. How can I activate the trace under linux (without using external hardware) to access to coresight components (STM,ETM,PTM,CTI,ETF...) and configure them as well as the extraction of the datas trace ?Could you please describe the differents steps that allow me to trace my application and what is the librairie should be used for the trace?
Best regards Karim.
Hi,
I was wondering the reasons ARM decided to move towards PTM source
component instead of ETM component. What is the main reason that pushed
towards this change ?
Thanks for your reply.
Best regards,
MAW
