Hi,
We are trying to us the Open CSD for decoding a onchip trace in our ETB.
The trace was enabled and is captured in the ETB.
We read the trace back and dumped it into a text file.
I am attaching it.
How can I use the CSD tool to decode it?
Thanks
Ajith
I've been packaging libopenCSD for debian. That has resulted in
various changes, largely to the makefiles. Most of those changes
should go upstream, rather than exist only in the debian version.
I'll post my issues/changes here for discussion so we can decide what is upstreamable.
In the meantime anyone interested can try the debian packages here:
http://wookware.org/software/repo/
either manually from:
http://wookware.org/software/repo/pool/main/libo/libopencsd/
or with
deb [ trusted=yes ] http://wookware.org/software/repo unstable main
apt update; apt install libopencsd0
(and/or libopencsd-dev libopencsd-doc libopencsd-dbgsym)
(for debian unstable, amd64 only) (package is signed, but repo isn't. Sorry)
Or get the source and rebuild for a different debian-based distro/release.
I've not separated all my changes into proper standalone patches yet,
but some are so let's start with those.
1) The doxygen doc build doesn't find all the components because they moved.
This fixes that:
Index: libopencsd-0.8.0/decoder/docs/doxygen_config.dox
===================================================================
--- libopencsd-0.8.0.orig/decoder/docs/doxygen_config.dox
+++ libopencsd-0.8.0/decoder/docs/doxygen_config.dox
@@ -765,11 +765,11 @@ WARN_LOGFILE =
INPUT = ../include \
../include/interfaces \
- ../include/etmv3 \
- ../include/etmv4 \
- ../include/ptm \
- ../include/c_api \
- ../include/stm \
+ ../include/opencsd/etmv3 \
+ ../include/opencsd/etmv4 \
+ ../include/opencsd/ptm \
+ ../include/opencsd/c_api \
+ ../include/opencsd/stm \
../include/mem_acc \
../../README.md \
. \
2)
The makefile provides no doc-build. The patch below adds that.
I didn't include an install-docs target, although if you added one
with a variable to set the target dir then I'd use it.
Index: libopencsd-0.8.0/decoder/build/linux/makefile
===================================================================
--- libopencsd-0.8.0.orig/decoder/build/linux/makefile
+++ libopencsd-0.8.0/decoder/build/linux/makefile
@@ -155,6 +155,13 @@ tests: libs
cd $(OCSD_ROOT)/tests/build/linux/trc_pkt_lister && make
cd $(OCSD_ROOT)/tests/build/linux/c_api_pkt_print_test && make
+#
+# build docs
+.PHONY: docs
+docs:
+ (cd $(OCSD_ROOT/docs); doxygen doxygen_config.dox)
+
+
#############################################################
# clean targets
#
@@ -176,3 +183,4 @@ clean_install:
rm -f $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).so
rm -f $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).so
rm -rf $(INSTALL_INCLUDE_DIR)/$(LIB_UAPI_INC_DIR)
+ rm -rf $(OCSD_ROOT)/docs/html
3) The static libraries are built but not installed.
Now static libraries aren't much use to anyone these days, but if you
build them then you might as well install them.
This patch does that:
Index: libopencsd-0.8.0/decoder/build/linux/makefile
===================================================================
--- libopencsd-0.8.0.orig/decoder/build/linux/makefile
+++ libopencsd-0.8.0/decoder/build/linux/makefile
@@ -136,6 +136,8 @@
mkdir -p $(INSTALL_LIB_DIR) $(INSTALL_INCLUDE_DIR)
$(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_BASE_NAME).so $(INSTALL_LIB_DIR)/
$(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_CAPI_NAME).so $(INSTALL_LIB_DIR)/
+ $(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_BASE_NAME).a $(INSTALL_LIB_DIR)/
+ $(INSTALL) --mode=644 $(LIB_TARGET_DIR)/lib$(LIB_CAPI_NAME).a $(INSTALL_LIB_DIR)/
cd $(OCSD_ROOT)/build/linux/rctdl_c_api_lib && make install_inc
################################
@@ -192,6 +194,6 @@
cd $(OCSD_ROOT)/tests/build/linux/c_api_pkt_print_test && make clean
clean_install:
- rm -f $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).so
- rm -f $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).so
+ rm -f $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).{so,a}
+ rm -f $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).{so,a}
rm -rf $(INSTALL_INCLUDE_DIR)/$(LIB_UAPI_INC_DIR)
4) The makefile arbitrarily restricts the build to arm and x86
architectures. The only reason for this is in order to build into a
particular named directory, and to set -m32/-m64 flags for x86 which
should be defaulted correctly on any sensible toolchain or cross-toolchain
anyway.
This code can build, and be used, on any arch and the makefile should
allow that, so this should be fixed.
I don't see the need to build into a host-arch named PLAT_DIR
directory. Is there one? It only does one build at a time, whether
crossing or not, so I see no reason not to use a fixed name for this
dir, such as 'builddir'. This has no effect on the ability to cross or
not. If you really want to change the name of PLAT_DIR then find out
the HOST triplet and use that. On debian this is
dpkg-architecture -q DEB_HOST_GNU_TYPE, (which is also the same prefix as would
be used to specify the toolchain prefix for crossing). But like I say, I
think a fixed builddir is actually all you need unless I'm missing something.
So this patch lets the build work on any arch:
Index: libopencsd-0.8.0/decoder/build/linux/makefile
===================================================================
--- libopencsd-0.8.0.orig/decoder/build/linux/makefile
+++ libopencsd-0.8.0/decoder/build/linux/makefile
@@ -92,27 +92,6 @@ BUILD_VARIANT=rel
endif
-# platform bit size variant
-ifeq ($(ARCH),x86)
- MFLAG:="-m32"
- BIT_VARIANT=32
-else ifeq ($(ARCH),x86_64)
- MFLAG:="-m64"
- BIT_VARIANT=64
-else ifeq ($(ARCH),arm)
- BIT_VARIANT=-arm
-else ifeq ($(ARCH),arm64)
- BIT_VARIANT=-arm64
-else ifeq ($(ARCH),aarch64)
- BIT_VARIANT=-arm64
-else ifeq ($(ARCH),aarch32)
- BIT_VARIANT=-arm
-endif
-
-MASTER_CC_FLAGS += $(MFLAG)
-MASTER_CPP_FLAGS += $(MFLAG)
-MASTER_LINKER_FLAGS += $(MFLAG)
-
# export build flags
export MASTER_CC_FLAGS
export MASTER_CPP_FLAGS
@@ -120,7 +99,7 @@ export MASTER_LINKER_FLAGS
export MASTER_LIB_FLAGS
# target directories
-export PLAT_DIR=linux$(BIT_VARIANT)/$(BUILD_VARIANT)
+export PLAT_DIR=builddir
export LIB_TARGET_DIR=$(OCSD_LIB_ROOT)/$(PLAT_DIR)
export LIB_TEST_TARGET_DIR=$(OCSD_TESTS)/lib/$(PLAT_DIR)
export BIN_TEST_TARGET_DIR=$(OCSD_TESTS)/bin/$(PLAT_DIR)
All these patches included as files too.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Hello Mathieu,
Thank for the config file. It works. I was able to build the OpenCSD kernel (form the perf-opencsd-master branch) and install on the USB (I used the ArchLinuxARM-aarch64-latest.tar.gz). I also built the perf tool (make -C tools/perf). Everything is booting but the perf has some issues:
[root@alarm home]# ./perf record -vvv -e cs_etm/(a)20070000.etr/u --per-thread uname
map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir
Problems setting modules path maps, continuing anyway...
------------------------------------------------------------
perf_event_attr:
type 8
size 112
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
enable_on_exec 1
sample_id_all 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 4
------------------------------------------------------------
perf_event_attr:
type 1
size 112
config 0x9
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
mmap 1
comm 1
enable_on_exec 1
task 1
sample_id_all 1
mmap2 1
comm_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 5
mmap size 528384B
AUX area mmap length 4194304
perf event ring buffer mmapped per thread
failed to mmap AUX area
failed to mmap with 12 (Cannot allocate memory)
I fixed the "map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir" issue by adding appropriate symbolic link but I still have an issue with the mmap. Any idea what can be wrong here (below limits that I have on my Juno)?
[root@alarm ~]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31798
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31798
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@alarm ~]#
Regards
Marek
W dniu 2017-08-18 16:54:42 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> On 18 August 2017 at 04:22, marekzmyslowski
> <marekzmyslowski(a)poczta.onet.pl> wrote:
> > Hello Mathieu,
> >
> > I've decided that currently I don't need Android. The Linux is enough.
>
> That is probably a better place to start.
>
> > However I have another issue. I've downloaded the perf-opencsd-master branch. I run the config with the ARCH=arm64 and CROSS_COMPLIE=aarch64-linux-gnu- and added support for Versatile board. Then I compiled kernel - everything was OK. Next I built the USB using the following instruction:
> > https://archlinuxarm.org/platforms/armv8/arm/juno (it works fine. The linux boot on the Juno).
> > Next I copied the Image file and juno.dtb into the USB but it doesn't boot. It hangs here:
> >
> > initrd: address 0x0
> > initrd: length 0x0
> > PEI 1132 ms
> > DXE 1695 ms
> > BDS 368934875444 ms
> > BDS 368934873448 ms
> > BDS 1535 ms
> > Total Time = 368934871781 ms
> >
> > linux: address 0x80080000
> > linux: length 0x1150200
> > fdt: address 0x9FE00000
> > fdt: length 0x5F54
> >
> > Any idea what I'm doing wrong? Any help will be appreciated (I'm so close to have Juno + CoreSight + perf :) )
>
> I can't help you with booting the board itself. The best I can do is
> advise to use u-boot instead of UEFI and give you my kernel .config
> file (attached). For the rest there is plenty of documentation out
> there.
>
> >
> > Regards
> > Marek
> >
> > W dniu 2017-08-16 23:08:04 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> >> Hello Marek,
> >>
> >> Please CC the CoreSight mailing list when asking questions as someone
> >> else may also be able to answer.
> >>
> >> First and foremost I advise using the official CoreSight kernel found
> >> on the openCSD site [1] rather than my personal branch [2] - you
> >> never know what you'll get with the latter.
> >>
> >> That being said the CoreSight kernel on the openCSD site is not an
> >> Android kernel - it is simply a mainline kernel supplemented with
> >> patches that haven't made their way to mainline yet. You will have to
> >> either add the android patches to the CoreSight kernel or the other
> >> way around (CoreSight patches on android kernel).
> >>
> >> Android user space is also different and does not include the
> >> perf-tools. You will have to add them manually along with the
> >> dependencies they require. I haven't gone through that process and as
> >> such can't advise more on that portion.
> >>
> >> Get back to me with your questions if the above isn't sufficient.
> >>
> >> Best regards,
> >> Mathieu
> >>
> >> [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master
> >> [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/
> >>
> >> On 16 August 2017 at 14:32, marekzmyslowski
> >> <marekzmyslowski(a)poczta.onet.pl> wrote:
> >> > Hello Mathieu,
> >> >
> >> > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12.
> >> > Any help with this will be appreciated :)
> >> >
> >> > Regards
> >> > Marek Zmysłowski
> >>
> >
> >
> >
>
On 27 April 2018 at 12:24, Robert Walker <Robert.Walker(a)arm.com> wrote:
> Hi,
>
>
>
> Strobing the ETM to reduce the amount of trace data when collecting profiles
> for AutoFDO seems to be working and providing useful optimizations. We’re
> currently working with some proof of concept patches (attached for
> reference) that add parameters to sysfs to configure the strobe period –
> before running perf record, the user must write to these parameters for each
> ETM. This isn’t suitable for production use as it has to be done for each
> ETM and the values persist after the trace session. To get this into
> upstream, we need to have this done by the perf record tool.
>
>
>
> I understand there is work planned to enable more complex ETM configurations
> (such as strobing) from perf, possibly using a file to load register values
> from. Is this still the case, and if so, when is it likely to be done?
Hi Robert,
I am currently working on supporting CPU-wide trace scenarios where I
can start seeing the end of the tunnel. After that my plan was to add
support for ETMv3.x/PTM trace decoding followed by support for N:N
source/sink topology. Part of the latter is to introduce a way to
enable more complex ETM configuration using a configuration file. In
fact I already stumbled on how I want to do that and have a (very)
small prototype that works.
So that is what I had in mind... But it doesn't mean I can't be talked
into changing my priorities. In fact I will gladly do so if we, as a
group, decide it is more important to introduce support for complex
configuration before ETMv3.x/PTM decoding. I personally don't have a
preference, it is simply a matter of deciding what we want to do.
I have CC'ed the coresight mailing list in order to reach a broader
audience. Please speak up if you really have an issue (along with the
rational) with supporting ETM complex configurations before
ETMv3.x/PTM decoding.
Best regards,
Mathieu
>
>
>
> Thanks
>
>
>
> Rob
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
Hi,
Any updates to below emails,.?
Regards
Chris
From: Chris Samuel [mailto:chris.samuel@lead-marketings.com]
Sent: Thursday, April 05, 2018 10:40 AM
To: 'coresight(a)lists.linaro.org'
Subject: RE: IBM lotus-accounts
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.
Hello,
I hope you're doing well!
I am following up with you on the below since I have not heard back from
you. Please let me know if you would like to get more information on the
same.
Looking forward to hearing from you.
Warm Regards,
Rick Forster
From: Rick Forster [mailto:rick.forster@attendeeinfo.com]
Sent: 24 April 2018 09:23
To: 'coresight(a)lists.linaro.org'
Subject: California Dental Association - Spring - CDA 2018 Attendees list
Hello,
I hope you are the right person to discuss about California Dental
Association - Spring - CDA May 2018 Attendees Info?
California Dental Association - Spring - CDA 2018 Attendees list of 18,900
contacts with complete contact details and verified email addresses info
will be provided for unlimited usage.
Interested? Email me back, I'd love to provide more information.
Thank you.
Regards,
Rick Foster
Demand Generation Executive.
If you do not wish to receive future
emails from us, please reply as "opt-out"
Hello,
I hope you are the right person to discuss about California Dental
Association - Spring - CDA May 2018 Attendees Info?
California Dental Association - Spring - CDA 2018 Attendees list of 18,900
contacts with complete contact details and verified email addresses info
will be provided for unlimited usage.
Interested? Email me back, I'd love to provide more information.
Thank you.
Regards,
Rick Foster
Demand Generation Executive.
If you do not wish to receive future
emails from us, please reply as "opt-out"
Hi all,
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
PS: Sorry, I formatted my previous mail in markdown rather than HTML. This should be more readable than the previous mail.
They're not needed anymore.
Suggested-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Signed-off-by: Kim Phillips <kim.phillips(a)arm.com>
---
Change(s) from first PATCH series: none.
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 09a682013ea2..f1e05fbef257 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -30,7 +30,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
@@ -43,7 +43,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
@@ -57,7 +57,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
@@ -68,7 +68,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
@@ -80,7 +80,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
@@ -92,7 +92,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
@@ -104,7 +104,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.17.0
