Coresight etmv4 enable over 32bit kernel

Coresight etmv4 enable over 32bit kernel

[Lei Wen]

Hi Mathieu,

I am enabling etmv4 coresight over one Cortex-A7 soc, using 32bit kernel.
And I am following [1] to do experiment regarding the addr_range feature.
The default addr_range is set as _stext~_etext, and it works fine with
etb as sink,
and etm as source. I could see there are valid kernel addresses using OpenCSD.

But while I try to store one small range of address pair, which contain only one
kernel function. It doesn't behavior like what said in [1], the write
pointer would
grows rapidly with the read pointer. And I dump the etb buffer and parse it with
openCSD, finding that there is no I_ASYNC packet in the dump and is fulled with
I_NOT_SYNC.

So my question is why ETB continue to grow when there is no trigger at all?
Is it normal? I could provide more info if you need it.

[1]: https://wiki.linaro.org/WorklingGroups/Kernel/Coresight/traceDecodingWithDS5

Thanks,
Lei

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Coresight etmv4 enable over 32bit kernel

[Mathieu Poirier]

Good day Adrian,

On Sat, 8 Dec 2018 at 05:05, Lei Wen <adrian.wenl@gmail.com> wrote:
>
> Hi Mathieu,
>
> I am enabling etmv4 coresight over one Cortex-A7 soc, using 32bit kernel.
> And I am following [1] to do experiment regarding the addr_range feature.

That wiki is very old and after reading it again I seriously consider
removing it.  It is still accurate but there are better ways to do
things now, i.e perf.  The main openCSD documentation page [2]
contains everything you need to know about the integration with perf.

[2]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md

> The default addr_range is set as _stext~_etext, and it works fine with
> etb as sink,
> and etm as source. I could see there are valid kernel addresses using OpenCSD.

I'm really curious about how you use openCSD to validate your traces -
can you  expand more on that?

I think the results are misleading you since the openCSD library can't
readily be used to decode sysfs trace sessions.  The wiki doesn't
mention using openCSD to decode traces either.  The only integrated
way to use openCSD to decode CoreSight traces is via perf.  Again, the
link above will give you all the information you need to do that.

>
> But while I try to store one small range of address pair, which contain only one
> kernel function. It doesn't behavior like what said in [1], the write
> pointer would
> grows rapidly with the read pointer. And I dump the etb buffer and parse it with
> openCSD, finding that there is no I_ASYNC packet in the dump and is fulled with
> I_NOT_SYNC.
>
> So my question is why ETB continue to grow when there is no trigger at all?
> Is it normal? I could provide more info if you need it.

I am dubious about the validation process and as such can't comment on
this.  Please share your results using the perf integration and then
I'll be able to have a better idea of what is going on.

Taking a step back I am curious about the ETMv4/ETB combination...  Is
the ETB the only sink you have to work with?  Moreover, are you sure
it is not a TMC-ETF?  The ETMv4/ETB match seems a little odd to me
since they belong to two different era of the CoreSight architecture.
Usually with an ETMv4 we will see a TMC-ETR, which as a lot more
capabilities.

Regards,
Mathieu

>
> [1]: https://wiki.linaro.org/WorklingGroups/Kernel/Coresight/traceDecodingWithDS5
>
> Thanks,
> Lei

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Coresight etmv4 enable over 32bit kernel

[Lei Wen]

On Tue, Dec 11, 2018 at 2:02 AM Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> Good day Adrian,
>
> On Sat, 8 Dec 2018 at 05:05, Lei Wen <adrian.wenl@gmail.com> wrote:
> >
> > Hi Mathieu,
> >
> > I am enabling etmv4 coresight over one Cortex-A7 soc, using 32bit kernel.
> > And I am following [1] to do experiment regarding the addr_range feature.
>
> That wiki is very old and after reading it again I seriously consider
> removing it.  It is still accurate but there are better ways to do
> things now, i.e perf.  The main openCSD documentation page [2]
> contains everything you need to know about the integration with perf.
>
> [2]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md
>
> > The default addr_range is set as _stext~_etext, and it works fine with
> > etb as sink,
> > and etm as source. I could see there are valid kernel addresses using OpenCSD.
>
> I'm really curious about how you use openCSD to validate your traces -
> can you  expand more on that?


I just manually replace the cstrace.bin in the
decoder/tests/snapshots/juno-ret-stck/.
And modify the register data according to my platform.
Then produce the decode result by below command:
./decoder/tests/bin/builddir/trc_pkt_lister -ss_dir
decoder/tests/snapshots/test -decode -logfilename 2.ppl

>
> I think the results are misleading you since the openCSD library can't
> readily be used to decode sysfs trace sessions.  The wiki doesn't
> mention using openCSD to decode traces either.  The only integrated
> way to use openCSD to decode CoreSight traces is via perf.  Again, the
> link above will give you all the information you need to do that.

>
> >
> > But while I try to store one small range of address pair, which contain only one
> > kernel function. It doesn't behavior like what said in [1], the write
> > pointer would
> > grows rapidly with the read pointer. And I dump the etb buffer and parse it with
> > openCSD, finding that there is no I_ASYNC packet in the dump and is fulled with
> > I_NOT_SYNC.
> >
> > So my question is why ETB continue to grow when there is no trigger at all?
> > Is it normal? I could provide more info if you need it.
>
> I am dubious about the validation process and as such can't comment on
> this.  Please share your results using the perf integration and then
> I'll be able to have a better idea of what is going on.

I see... I would try use perf to get more result and get back here.

>
> Taking a step back I am curious about the ETMv4/ETB combination...  Is
> the ETB the only sink you have to work with?  Moreover, are you sure
> it is not a TMC-ETF?  The ETMv4/ETB match seems a little odd to me
> since they belong to two different era of the CoreSight architecture.
> Usually with an ETMv4 we will see a TMC-ETR, which as a lot more
> capabilities.

ETR is supported. I use ETB as it is mentioned in that old wiki page.

Thanks,
Lei

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Coresight etmv4 enable over 32bit kernel

[leo.yan]

Hi Lei,

On Tue, Dec 11, 2018 at 05:11:02PM +0800, Lei Wen wrote:
> On Tue, Dec 11, 2018 at 2:02 AM Mathieu Poirier
> <mathieu.poirier@linaro.org> wrote:
> >
> > Good day Adrian,
> >
> > On Sat, 8 Dec 2018 at 05:05, Lei Wen <adrian.wenl@gmail.com> wrote:
> > >
> > > Hi Mathieu,
> > >
> > > I am enabling etmv4 coresight over one Cortex-A7 soc, using 32bit kernel.
> > > And I am following [1] to do experiment regarding the addr_range feature.
> >
> > That wiki is very old and after reading it again I seriously consider
> > removing it.  It is still accurate but there are better ways to do
> > things now, i.e perf.  The main openCSD documentation page [2]
> > contains everything you need to know about the integration with perf.
> >
> > [2]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md
> >
> > > The default addr_range is set as _stext~_etext, and it works fine with
> > > etb as sink,
> > > and etm as source. I could see there are valid kernel addresses using OpenCSD.
> >
> > I'm really curious about how you use openCSD to validate your traces -
> > can you  expand more on that?
> 
> 
> I just manually replace the cstrace.bin in the
> decoder/tests/snapshots/juno-ret-stck/.
> And modify the register data according to my platform.
> Then produce the decode result by below command:
> ./decoder/tests/bin/builddir/trc_pkt_lister -ss_dir
> decoder/tests/snapshots/test -decode -logfilename 2.ppl

Just remind, you also could refer TC2 platform, I think it can be more
close to your platform with CA7 CPUs.  And except cpu_X.ini files, you
also need to modify snapshot.ini & trace.ini under the snapshot
folder [1].

[1] https://github.com/Linaro/OpenCSD/blob/master/decoder/docs/specs/ARM%20Trace%20and%20Debug%20Snapshot%20file%20format%200v2.pdf

> > I think the results are misleading you since the openCSD library can't
> > readily be used to decode sysfs trace sessions.  The wiki doesn't
> > mention using openCSD to decode traces either.  The only integrated
> > way to use openCSD to decode CoreSight traces is via perf.  Again, the
> > link above will give you all the information you need to do that.
> 
> >
> > >
> > > But while I try to store one small range of address pair, which contain only one
> > > kernel function. It doesn't behavior like what said in [1], the write
> > > pointer would
> > > grows rapidly with the read pointer. And I dump the etb buffer and parse it with
> > > openCSD, finding that there is no I_ASYNC packet in the dump and is fulled with
> > > I_NOT_SYNC.
> > >
> > > So my question is why ETB continue to grow when there is no trigger at all?
> > > Is it normal? I could provide more info if you need it.
> >
> > I am dubious about the validation process and as such can't comment on
> > this.  Please share your results using the perf integration and then
> > I'll be able to have a better idea of what is going on.
> 
> I see... I would try use perf to get more result and get back here.

I verified mainline kernel with perf tool, it can work well on Juno
board for address range filter.  Please ensure you are using a newer
kernel version (e.g 4.16 but not 4.14, 4.14 kernel doesn't contain
cs-etm decoder in perf tool).

[...]

Thanks,
Leo Yan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel