Good day Jan,
Please CC the coresight mailing list when you have questions such as
this one. There is a lot of knowledgeable people on it that are also
be able to help you.
On Fri, 18 Oct 2019 at 07:42, Jan Hoogerbrugge <jan.hoogerbrugge(a)nxp.com> wrote:
>
> Hi Mathieu,
>
> I am trying to understand Coresight support in the Linux kernel. I am using a Xilinx Zynq
> Ultrascale+ system. I configured the kernel with coresight support enabled. When the
> system is running I see the /sys/bus/coresight directory but the devices directory in it
> stays empty. Also, I do not see messages about coresight reported when booting:
>
> root@xilinx-zcu102-2017_4:~# ls -R /sys/bus/coresight
> /sys/bus/coresight:
> devices drivers_autoprobe uevent
> drivers drivers_probe
>
> /sys/bus/coresight/devices:
>
> /sys/bus/coresight/drivers:
> root@xilinx-zcu102-2017_4:~# dmesg | grep -i coresight
> root@xilinx-zcu102-2017_4:~#
>
> Any idea what I am doing wrong?
My guess it that coresight devices for that processor have not been
specified in the device tree. If I'm not mistaking some people (also
on this list) from Xiling have been experiencing with coresight on
that specific platform - hopefully they will chime in.
>
> I want to use Coresight to obtain some TPUI/ETM traces so that I can experiment with them.
Note that a driver for the TPIU IP block is currently not available.
I never had time to write a driver and nobody has ever submitted one.
> I hope that I can dump some traces to file so that I can process them later. Do you know about
> publicly accessible archives with traces on the Internet? This might be then an alternative
> for me.
I do not know of any.
Thanks,
Mathieu
>
> Regards,
>
> Jan
>
> --
>
> Jan Hoogerbrugge
>
> Principal Security Architect
>
> Competence Center Crypto & Security
>
> NXP Semiconductors
>
> High Tech Campus 46, 5656AE Eindhoven, The Netherlands
>
> Phone: +31 6 57728704
Review of ETMV4 sysfs code resulted in a number of minor issues being
discovered.
Patch set fixes these issues:-
1) Update for ETM v4.4 archtecture.
2) Add missing single shot comparator API.
3) Misc fixes and improvements to sysfs API
4) Updated programmers documentation and reference.
Changes since v2 (reviews from Mathieu and Leo):-
Patch 0002 now adds stable tag. Tested on 4.9, 4.14, 4.19
Applies to coresight/next (5.4-rc1)
Documentation changed to .rst format to match recent updates that
converted other CoreSight .txt files.
Misc typo / comment changes.
Changes since v1 (from reviews by Mathieu and Leo):-
Usability patch split into 2 separate functional patches.
Docs patch split into 3 patches.
Misc style and comment typo fixes.
Mike Leach (11):
coresight: etm4x: Fixes for ETM v4.4 architecture updates.
coresight: etm4x: Fix input validation for sysfs.
coresight: etm4x: Add missing API to set EL match on address filters
coresight: etm4x: Fix issues with start-stop logic.
coresight: etm4x: Improve usability of sysfs - include/exclude addr.
coresight: etm4x: Improve usability of sysfs - CID and VMID masks.
coresight: etm4x: Add view comparator settings API to sysfs.
coresight: etm4x: Add missing single-shot control API to sysfs
coresight: etm4x: docs: Update ABI doc for sysfs features added.
coresight: docs: Create common sub-directory for coresight trace.
coresight: etm4x: docs: Adds detailed document for programming etm4x.
.../testing/sysfs-bus-coresight-devices-etm4x | 183 ++--
.../{ => coresight}/coresight-cpu-debug.rst | 0
.../coresight/coresight-etm4x-reference.rst | 798 ++++++++++++++++++
.../trace/{ => coresight}/coresight.rst | 2 +-
Documentation/trace/{ => coresight}/stm.rst | 0
MAINTAINERS | 3 +-
.../coresight/coresight-etm4x-sysfs.c | 312 ++++++-
drivers/hwtracing/coresight/coresight-etm4x.c | 32 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 17 +-
9 files changed, 1245 insertions(+), 102 deletions(-)
rename Documentation/trace/{ => coresight}/coresight-cpu-debug.rst (100%)
create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.rst
rename Documentation/trace/{ => coresight}/coresight.rst (99%)
rename Documentation/trace/{ => coresight}/stm.rst (100%)
--
2.17.1
Hi Yabin,
On Tue, 17 Sep 2019 at 15:53, Yabin Cui <yabinc(a)google.com> wrote:
>
> Hi guys,
>
> I am trying to reduce ETM data lose. There seems to have two types of data lose:
> 1. caused by instruction trace buffer overflow, which generates an Overflow packet after recovering.
> 2. caused by ETR buffer overflow, which generates an PERF_RECORD_AUX with PERF_AUX_FLAG_TRUNCATED.
>
> In practice, the second one is unlikely to happen when I set ETR buffer size to 4M, and can be improved by setting higher buffer size.
> The first one happens much more frequently, can happen about 21K times when generating 5.3M etm data.
> So I want to know if there is any way to reduce that.
>
> I found in the ETM arch manual that the overflow seems controlled by TRCSTALLCTLR, a stall control register.
> But TRCIDR3.NOOVERFLOW is not supported on my experiment device, which seems using qualcomm sdm845.
> TRCSTALLCTLR.ISTALL seems can be set by writing to mode file in /sys. But I didn't find any way to set
> TRCSTALLCTLR.LEVEL in linux kernel. So I wonder if it is ever used.
>
> Do you guys have any suggestions?
In order to get a timely response to your questions I advise to CC the
coresight mailing list (which I have included). There is a lot of
knowledgeable people there that can also help, especially with
architecture specific configuration.
TRCSTALLCTLR.LEVEL is currently not accessible to users because we
simply never needed to use the feature. If using the ISTALL and LEVEL
parameters help with your use case send a patch that exposes the
entire TRCSTALLCTLR register (rather than just the LEVEL field) and
I'll be happy to fold it in.
Thanks,
Mathieu
>
> Best,
> Yabin
>
Hi coresight team,
In ARM ETM specification for ETM4.0 to 4.2, TRCAUTHSTATUS contains NSNID,
showing whether non-invasive debug is disabled.
And In ARM Coresight Specification 3.0, NSNID field is 0b10 (supported and
disabled) if (NIDEN | DBGEN) == FALSE.
And In ARM architecture manual for ARMv8-A, in K2.1:
DBGEN is for external debug enable.
NIDEN is for external profiling and trace enable.
So it seems if DBGEN and NIDEN is disabled by hardware, even if the
intention is to disable external debug interface, ETM is totally
disabled. And there is no way to use it for self-hosted tracing.
Is it true? And if yes, is there any plan to solve it in the future?
Thanks,
Yabin
Hello,
We are using coresight to dump compressed stream through ETR into a 16MB
buffer in RAM. (The platform is nVidia TX2) To gather data from the buffer
we are using the Linux dd command:
dd if=/dev/8050000.etr of=~/coresightdata.bin
The issue is that during the copying of the data, the coresight recording
becomes disabled (which shouldn't really be the case since its a circular
buffer), so we are having some blind spots in the recordings for the
duration of the copying of data from RAM into a file.
Is there any way to prevent this from happening? Maybe to set up some kind
of ping-pong scheme, or to specify somehow that coresight shouldn't stop
recording while accessing the ETR buffer?
Thank you.
Srdjan Stokic
Mobile: +389-78-835-505
