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
> >>
> >
> >
> >
>
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
This patch set is to explore Coresight tracing data for postmortem
debugging. When kernel panic happens, the Coresight panic kdump can
help to save on-chip tracing data and tracer metadata into DRAM, later
relies on kdump and crash/perf tools to recovery tracing data for
"offline" analysis.
The documentation is important to understand the purpose of Coresight
panic kdump, the implementation of framework and usage. Patches 0001
and patch 0002 are used for creating new sub directory for placing
Coresight docs and add a new doc for Coresight panic kdump.
Patch 0003 introduces the simple panic kdump framework which provides
helper functions can be used by Coresight devices, and it registers
panic notifier for dump tracing data.
Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports the
kdump for ETMv4.
This patch set has been reworked by following suggestions at Linaro
HKG18 connect (mainly suggestions from Mathieu, thanks a lot!), and
it's rebased on acme git tree [1] with last commit 109d59b900e7 ('perf
vendor events s390: Add JSON files for IBM z14').
Due Coresight kdump data structure has been changed significantly, the
corresponding crash extension program also has been updated for this
reason [2]; furthermore the crash extension program is updated to
dynamically generate kernel buildid according to vmlinux elf info [3],
this is a fixing for the old code which uses hard-coded buildid value.
This patch set has been verified on 96boards Hikey620 with Coresight
enabling by the sysFS interface. Also the updated crash extension
program has been verified to cowork with Coresight panic kdump and it
successfully extracts tracing data from the vmcore and finally can be
decoded by perf tool.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
[2] https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump.c
[3] https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump_buil…
Changes from v3:
* Following Mathieu suggestion, reworked the panic kdump framework,
used kdump array to maintain source and sink device handlers;
* According to Mathieu suggestion, optimized panic notifier to
firstly dump panic CPU tracing data and then dump other CPUs tracing
data;
* Refined doc to reflect these implementation changes;
* Changed ETMv4 driver to add source device handler at probe phase;
* Refactored crash extension program to reflect kernel changes.
Changes from v2:
* Add the two patches for documentation.
* Following Mathieu suggestion, reworked the panic kdump framework,
removed the useless flag "PRE_PANIC".
* According to comment, changed to add and delete kdump node operations
in sink enable/disable functions;
* According to Mathieu suggestion, handle kdump node
addition/deletion/updating separately for sysFS interface and perf
method.
Changes from v1:
* Add support to dump ETMv4 meta data.
* Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
format compatible file.
* Refactored panic dump driver to support pre & post panic dump.
Changes from RFC:
* Follow Mathieu's suggestion, use general framework to support dump
functionality.
* Changed to use perf to analyse trace data.
Leo Yan (6):
doc: Add Coresight documentation directory
doc: Add documentation for Coresight panic kdump
coresight: Support panic kdump functionality
coresight: tmc: Hook callback for panic kdump
coresight: Set and clear sink device handler for kdump node
coresight: etm4x: Support panic kdump
Documentation/trace/coresight-cpu-debug.txt | 187 ----------
Documentation/trace/coresight.txt | 383 ---------------------
.../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++
.../trace/coresight/coresight-panic-kdump.txt | 130 +++++++
Documentation/trace/coresight/coresight.txt | 383 +++++++++++++++++++++
MAINTAINERS | 5 +-
drivers/hwtracing/coresight/Kconfig | 9 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +
drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++
drivers/hwtracing/coresight/coresight-etm4x.h | 15 +
.../hwtracing/coresight/coresight-panic-kdump.c | 199 +++++++++++
drivers/hwtracing/coresight/coresight-priv.h | 12 +
drivers/hwtracing/coresight/coresight-tmc-etf.c | 30 ++
drivers/hwtracing/coresight/coresight.c | 16 +-
include/linux/coresight.h | 4 +
16 files changed, 1019 insertions(+), 574 deletions(-)
delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
delete mode 100644 Documentation/trace/coresight.txt
create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
create mode 100644 Documentation/trace/coresight/coresight.txt
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
--
2.7.4
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.
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,
Would you be interested in *Power Lunix* users for your email marketing
campaign? We provide the Database across North America, EMEA, APAC and
Latin America.
We can provide you with titles of Decision Makers regarding the technology.
We also have other technology users like
* SUSE*
* Red Hat*
* CELAD*
* Tanner EDA*
* Callabora*
* iXsystem*
* Linaro and many more…*
List Contains: Name, Company's Name, Phone Number, Fax Number, Job Title,
Email address, Complete Mailing Address, SIC code, Company revenue, size,
Web address etc.
We offer:
Complete list with Email address in an Excel Sheet for unlimited usage.
Do an email blast endorsing your product/services and providing your
contact information.
Email appending, multiple contacts appending, Data appending which will
append or add the missing information to your existing database.
Let me know your thoughts or pass on the message to the right person in
your company.
Thanks & regards,
*Darlena Hard*
Information Specialist
If you don’t want to receive any message from us then please type “Leave
Out” in the Subject Line.
Greetings, i was referred to this mailing list by Mathleu Poirler.
I'm recording Coresight using my Dragonboard 410c board, after compiling
the perf-opencsd-master kernel.
Recording seems to work on a simple program i did which does nothing but
print a string to the screen.
Now, i use perf to hopefully decode the trace, but perf segfaults. I'll let
you know that decoding using the sample trace given here:
https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md
Does work.
I dived into the cs-trace-disasm.py script to see why exactly it doesn't
work and i noticed this command causes the segfault:
$ ~/linux/tools/perf/perf script --show-mmap-events
/lib/aarch64-linux-gnu/ld-2.26.so with build id
6516ef8fa13fcb739834af9e87fb5fe9df612096 not found, con>
Segmentation fault (core dumped)
This command also segfaults:
$ ~/linux/tools/perf/perf report --stdio
/lib/aarch64-linux-gnu/ld-2.26.so with build id
6516ef8fa13fcb739834af9e87fb5fe9df612096 not found, con>
(END)Segmentation fault (core dumped)
But this command works:
$ ~/linux/tools/perf/perf report --stdio --dump
And i can see Coresight packets information when browsing the output.
My .debug directory looks like this:
~/.debug/
|-- [kernel.kallsyms]
| `-- 1dc43d23817467d7717b19af07463af0d9a9bd83
| `-- kallsyms
|-- [vdso]
| `-- 18863444e4f3e2600f53e406421b2a0edd940888
| `-- vdso
|-- bin
| `-- check
| `-- 31694f29996e06da12f63d6088ec6eb23b3079c4
| `-- elf
`-- lib
`-- aarch64-linux-gnu
|-- ld-2.26.so
| `-- 6516ef8fa13fcb739834af9e87fb5fe9df612096
| `-- elf
`-- libc.so.6
`-- 06e99d8d6acabab0643e0f525ac561cf73db6498
`-- elf
Now, another need i wanted to ask is where can i find the code that uses
OpenCSD to decode the trace and output instructions? eventually, i don't
want to use perf, but rather use OpenCSD directly in my code to decode
traces.
Not sure what to do here and how to proceed, i'll appreciate some help.
Thank you all!
