linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: adrian.wenl@gmail.com
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	leiwen@outlook.com
Subject: Re: Coresight etmv4 enable over 32bit kernel
Date: Mon, 10 Dec 2018 11:01:55 -0700	[thread overview]
Message-ID: <CANLsYkzTGnPQ3FUPWYc-DOigvzMuTFTGqbbVTqqtVuCQW3esSA@mail.gmail.com> (raw)
In-Reply-To: <CALZhoSRaR-eMyr7HKUTDi5oRiJfRZ7x1NRRM49v-nn6U7e9sJg@mail.gmail.com>

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

  reply	other threads:[~2018-12-10 18:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-08 12:04 Coresight etmv4 enable over 32bit kernel Lei Wen
2018-12-10 18:01 ` Mathieu Poirier [this message]
2018-12-11  9:11   ` Lei Wen
2018-12-11 10:19     ` leo.yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANLsYkzTGnPQ3FUPWYc-DOigvzMuTFTGqbbVTqqtVuCQW3esSA@mail.gmail.com \
    --to=mathieu.poirier@linaro.org \
    --cc=adrian.wenl@gmail.com \
    --cc=leiwen@outlook.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).