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
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.
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!
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,
JaniceWhite
Information Specialist
If you don’t want to receive any message from us then please type “Leave Out” in the Subject Line.
Good day to all,
The CS specification defines replicators that are not showing on the
AMBA bus and can't be configured - they simply provide a hard wire
between components. Earlier this week someone wrote to me on the open
mailing list asking for guidance in dealing with a new type of funnel
their company has introduced in a design. Just like a replicator it
doesn't show up on the AMBA bus and can't be configured.
It makes sense to deal with this new component the same way we do with
the above-mentioned replicator, i.e use a platform driver that does
nothing and add it to the CS topology when specified in the device
tree. It also make sense to re-use the same code [1] for that.
But moving forward with this also means we need to re-brand the
current coresight-replicator.c file, along with adding new
"compatible" strings. Here is what I suggest:
1) Keep the "arm,coresight-replicator" compatible string for backward
compatibility (I'm seriously tempted not to [2]).
2) Add a new "arm,coresight-hw-replicator" compatible string for
replicators that don't show up on the AMBA bus.
3) Add a new "arm,coresight-hw-funnel" compatible string for funnels
that don't show up on the AMBA bus.
4) Use a match table to deal with the above two new compatible string
and the old one (if we keep it around).
5) Rename coresight-replicator.c to coresight-hw-link.c.
I'm reaching out to the list because once we have a naming convention
it is hard to modify it. Let me know what you think of the above.
Thanks,
Mathieu
[1]. https://elixir.bootlin.com/linux/latest/source/drivers/hwtracing/coresight/…
[2]. We could also delete the old "arm,coresight-replicator" and make
the changes in the DT for current users. People that haven't upstream
their in-house solution will have to adapt, but that's something that
happens with all the out-of-tree code.
