Greetings,
I'm enabling a sink(ETR) via sysfs:
> $ echo "1"> /sys/bus/coresight/devices/826000.etr/enable_sink
And the sink is enabled successfully.
Now, i try to turn on a random ETMv4 source, so i just choose this one:
$ echo "1" > /sys/bus/coresight/devices/85c000.etm/enable_source
And this freezes my entire system. This ETMv4 is for CPU 0.. So i tried to
turn on(after a reboot, and enabling a sink again) the next ETMv4(for CPU
1):
$ echo "1" > /sys/bus/coresight/devices/85d000.etm/enable_source
And i can see the kernel logs are happy, and tracing is(assuming the logs
are true) enabled:
> [ 61.495119] coresight-tmc 826000.etr: TMC-ETR enabled
> [ 61.495150] coresight-dynamic-replicator 824000.replicator: REPLICATOR
> enabled
> [ 61.499261] coresight-tmc 825000.etf: TMC-ETF enabled
> [ 61.506468] coresight-funnel 821000.funnel: FUNNEL inport 4 enabled
> [ 61.511438] coresight-funnel 841000.funnel: FUNNEL inport 1 enabled
> [ 61.517635] coresight-etm4x 85d000.etm: ETM tracing enabled
But when i try to turn it off:
> $ echo "0" > /sys/bus/coresight/devices/85d000.etm/enable_source
This freezes my entire system.. again.
I'm using the perf-opencsd-master kernel(https://github.com/
Linaro/perf-opencsd),
and the Dragonboard 410c.
Any ideas, hints?
Thank you.
What version of linux should I expect to contain a version of perf
that knows about libopencsd?
Debian is currently at 4.15.11. Is that new enough?
It contains a
tools/perf/arch/arm/util/cs-etm.c
and
tools/include/linux/coresight-pmu.h
but if I build perf (with make VF=1 -C tools/perf )
then Auto-detecting system features:
does not mention libopencsd.
but then make it doesn't try on x86?
some clue about whether to expect this to work with 4.15.11, or if I
need a newer mainline, or if that is not sufficient, and I still need
the perf-opencsd-master mentioned in the HOWTO would be useful. Or
perhaps https://github.com/Linaro/perf-opencsd is the place to go?
Also how does the enabling machinery work?
I can't enable this in debian until a) its in the debian mainline
kernel packages and b) libopencsd is uploaded, but I can mess with it
locally and get bugs filed to make it work in due course.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Hi
I'm adding Coresight tracing support to FreeBSD.
The kernel support is currently on review (https://reviews.freebsd.org/D14618, https://reviews.freebsd.org/D12875).
At this step I would like to include OpenCSD to base FreeBSD distribution, but I have small local change preventing me to do so.
Here is a small patch to OpenCSD attached. Can someone take a look? We use LLVM and the 'params' vector is left uninitialized in ETMv4 decoder.
I'm not sure if this is correct fix, but it works fine for us.
I also added a pull request here: https://github.com/Linaro/OpenCSD/pull/12
Thank you.
Ruslan
They're not needed anymore.
Suggested-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Signed-off-by: Kim Phillips <kim.phillips(a)arm.com>
---
drivers/hwtracing/coresight/Kconfig | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index 506fe5db3074..d4f683366cd2 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -24,7 +24,7 @@ config CORESIGHT_LINKS_AND_SINKS
config CORESIGHT_LINK_AND_SINK_TMC
tristate "Coresight generic TMC driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for the Trace Memory Controller driver.
Depending on its configuration the device can act as a link (embedded
@@ -34,7 +34,7 @@ config CORESIGHT_LINK_AND_SINK_TMC
config CORESIGHT_SINK_TPIU
tristate "Coresight generic TPIU driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for the Trace Port Interface Unit driver,
responsible for bridging the gap between the on-chip coresight
@@ -45,7 +45,7 @@ config CORESIGHT_SINK_TPIU
config CORESIGHT_SINK_ETBV10
tristate "Coresight ETBv1.0 driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for the Embedded Trace Buffer version 1.0 driver
that complies with the generic implementation of the component without
@@ -53,7 +53,7 @@ config CORESIGHT_SINK_ETBV10
config CORESIGHT_SOURCE_ETM3X
tristate "CoreSight Embedded Trace Macrocell 3.x driver"
- depends on !ARM64 && CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT && !ARM64
help
This driver provides support for processor ETM3.x and PTM1.x modules,
which allows tracing the instructions that a processor is executing
@@ -62,7 +62,7 @@ config CORESIGHT_SOURCE_ETM3X
config CORESIGHT_SOURCE_ETM4X
tristate "CoreSight Embedded Trace Macrocell 4.x driver"
- depends on ARM64 && CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT && ARM64
help
This driver provides support for the ETM4.x tracer module, tracing the
instructions that a processor is executing. This is primarily useful
@@ -71,7 +71,7 @@ config CORESIGHT_SOURCE_ETM4X
config CORESIGHT_DYNAMIC_REPLICATOR
tristate "CoreSight Programmable Replicator driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for dynamic CoreSight replicator link driver.
The programmable ATB replicator allows independent filtering of the
@@ -80,7 +80,7 @@ config CORESIGHT_DYNAMIC_REPLICATOR
config CORESIGHT_STM
tristate "CoreSight System Trace Macrocell driver"
depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
- depends on STM && CORESIGHT_LINKS_AND_SINKS
+ depends on STM
help
This driver provides support for hardware assisted software
instrumentation based tracing. This is primarily used for
--
2.16.2
This allows modules to match struct device.bus to amba_bustype for the
purpose of casting the device to an amba_device with to_amba_device().
Cc: Alex Williamson <alex.williamson(a)redhat.com>
Cc: Eric Auger <eric.auger(a)redhat.com>
Cc: Russell King <linux(a)armlinux.org.uk>
[RESEND due to new coresight modularization dependency]
Signed-off-by: Kim Phillips <kim.phillips(a)arm.com>
---
Reviving https://lkml.org/lkml/2017/6/20/682, since it's needed by
CoreSight modularization, and I can't tell what fate the original
version had.
Change(s) from RFC: none.
drivers/amba/bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228d2f02..12283bd06733 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -197,6 +197,7 @@ struct bus_type amba_bustype = {
.pm = &amba_pm,
.force_dma = true,
};
+EXPORT_SYMBOL_GPL(amba_bustype);
static int __init amba_init(void)
{
--
2.16.2
Hi,
Any updates to below emails,.?
Awaiting your kind response for regarding my previous email. If it makes
sense to talk, please let me know how your calendar looks.
I would appreciate if you could pass along my details to the appropriate
person if you don't handle this.
Do you have any other requirement kindly let me know your exact target
industry and target audience and target location, we will provide the exact
cost and counts with many more ....
Regards,
Chris
From: Chris Samuel [mailto:chris.samuel@lead-marketings.com]
Sent: Tuesday, April 03, 2018 3:40 PM
To: 'coresight(a)lists.linaro.org'
Subject: IBM lotus-accounts
Hi,
A quick check to see if you would you be interested to acquire updated
Slack, IBM Lotus Domino, IBM Lotus Notes, LogMeIn, Microsoft SharePoint,
Accounts with verified email and phone numbers.
kindly let me know your exact target industry and target audience and target
location, we will provide the exact database counts with cost and many
more....
Appreciate your time and look forward to your response.
Best Regards,
Chris,
Marketing Executive,
If you do not want to receive from us then reply back "Unsubscribe" as a
Subject Line.
Tracing problem
I have been using CoreSight PTM component on Zynq for more than two
years. I started out by programming a simple library to program these
components on a “bare-metal” system (without OS). Then, I moved on Linux
and Mathieu Poirier (I can't thank him enough) helped me a lot during
this phase. So far, I have been tracing small portions of my
applications and the amount of trace generated was not that important. I
was getting the expected trace i.e. for each branch (direct or
indirect), I was getting a branch address packet in my trace. Now, I
started tracing the whole .text section of binaries and I am not
understanding the obtained trace.
Here is how I configure Linux kernel driver (Kernel v4.9):
|cd /sys/bus/coresight/devices/f889c000.ptm0 echo 1 > addr_idx echo 0 >
addr_acctype echo 0 > addr_idx echo 0 > addr_acctype echo 20 > mode echo
100e0 104b4 > addr_range # These two addresses represent the beginning
and end of .text section |
Then, I enable the trace sink component (either ETB or TPIU) and trace
source (PTM) component.
|cd /sys/bus/coresight/devices/ echo 1 > f8801000.etb/enable_sink echo 1
> f889c000.ptm0/enable_source |
Then, I run my application and stop tracing.
|./application.elf ./disable # simply writes 0 to each enabled component
(source and sink) |
Then, I recover the trace using |dd|.
When I trace small portions of my application, the obtained trace gives
the right behavior. I check it manually by looking at |objdump| of the
binary.
However, when I trace the whole .text section of the application, the
amount of obtained trace is very small (even smaller than if I trace
only main function of the application) which is quite strange for me.
Basically, the obtained trace is going through libc functions that call
the main function and it stops while it is in libc. I don’t understand
why I am getting this strange behavior. Do you have any ideas about what
I am doing wrong.
I have attached a binary source code that I am trying to trace.
Thank you for your help and time.
Best regards,
Muhammad
