CoreSight

coresight@lists.linaro.org

4 participants
2387 discussions

Start a nNew thread

DHL EXPRESS DELIVERY NOTIFICATION

by DHL International GmbH

5 years, 10 months

[PATCH 11/17] perf cs-etm: Support sample flags 'insn' and 'insnlen'

by Arnaldo Carvalho de Melo

From: Leo Yan <leo.yan(a)linaro.org> The synthetic branch and instruction samples are missed to set instruction related info, thus the perf tool fails to display samples with flags '-F,+insn,+insnlen'. The CoreSight trace decoder provides sufficient information to decide the instruction size based on the ISA type: A64/A32 instructions are 32-bit size, but one exception is the T32 instruction size, which might be 32-bit or 16-bit. This patch handles these cases and it reads the instruction values from DSO file; thus can support the flags '-F,+insn,+insnlen'. Before: # perf script -F,insn,insnlen,ip,sym 0 [unknown] ilen: 0 ffff97174044 _start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 ffff97174938 _dl_start ilen: 0 [...] After: # perf script -F,insn,insnlen,ip,sym 0 [unknown] ilen: 0 ffff97174044 _start ilen: 4 insn: 2f 02 00 94 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 ffff97174938 _dl_start ilen: 4 insn: c1 ff ff 54 [...] Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Tested-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Robert Walker <robert.walker(a)arm.com> Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Link: http://lkml.kernel.org/r/20190815082854.18191-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/util/cs-etm.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index ed6f7fd5b90b..b3a5daaf1a8f 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -1076,6 +1076,35 @@ bool cs_etm__etmq_is_timeless(struct cs_etm_queue *etmq) return !!etmq->etm->timeless_decoding; } +static void cs_etm__copy_insn(struct cs_etm_queue *etmq, + u64 trace_chan_id, + const struct cs_etm_packet *packet, + struct perf_sample *sample) +{ + /* + * It's pointless to read instructions for the CS_ETM_DISCONTINUITY + * packet, so directly bail out with 'insn_len' = 0. + */ + if (packet->sample_type == CS_ETM_DISCONTINUITY) { + sample->insn_len = 0; + return; + } + + /* + * T32 instruction size might be 32-bit or 16-bit, decide by calling + * cs_etm__t32_instr_size(). + */ + if (packet->isa == CS_ETM_ISA_T32) + sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, + sample->ip); + /* Otherwise, A64 and A32 instruction size are always 32-bit. */ + else + sample->insn_len = 4; + + cs_etm__mem_access(etmq, trace_chan_id, sample->ip, + sample->insn_len, (void *)sample->insn); +} + static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq, struct cs_etm_traceid_queue *tidq, u64 addr, u64 period) @@ -1097,9 +1126,10 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq, sample.period = period; sample.cpu = tidq->packet->cpu; sample.flags = tidq->prev_packet->flags; - sample.insn_len = 1; sample.cpumode = event->sample.header.misc; + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample); + if (etm->synth_opts.last_branch) { cs_etm__copy_last_branch_rb(etmq, tidq); sample.branch_stack = tidq->last_branch; @@ -1159,6 +1189,9 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq, sample.flags = tidq->prev_packet->flags; sample.cpumode = event->sample.header.misc; + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->prev_packet, + &sample); + /* * perf report cannot handle events without a branch stack */ -- 2.21.0

5 years, 10 months

[RFC PATCH v3 00/16] CoreSight CTI Driver

by Mike Leach

CTIs are defined in the device tree and associated with other CoreSight devices. The core CoreSight code has been modified to enable the registration of the CTI devices on the same bus as the other CoreSight components, but as these are not actually trace generation / capture devices, they are not part of the Coresight path when generating trace. However, the definition of the standard CoreSight device has been extended to include a reference to an associated CTI device, and the enable / disable trace path operations will auto enable/disable any associated CTI devices at the same time. Programming is at present via sysfs - a full API is provided to utilise the hardware capabilities. As CTI devices are unprogrammed by default, the auto enable describe above will have no effect until explicit programming takes place. A set of device tree bindings specific to the CTI topology has been defined. The driver accesses these in a platform agnostic manner, so ACPI bindings can be added later, once they have been agreed and defined for the CTI device. Documentation has been updated to describe both the CTI hardware, its use and programming in sysfs, and the new dts bindings required. Tested on DB410 board, on coresight/next tree - 5.2-rc1 based. Changes since v2: Updates to allow for new features on coresight/next and feedback from Mathieu and Leo. 1) Rebase and restructuring to apply on top of ACPI support patch set, currently on coresight/next. of_coresight_cti has been renamed to coresight-cti-platform and device tree bindings added to this but accessed in a platform agnostic manner using fwnode for later ACPI support to be added. 2) Split the sysfs patch info a series of functional patches. 3) Revised the refcount and enabling support. 4) Adopted the generic naming protocol - CTIs are either cti_cpuN or cti_sysM 5) Various minor presentation /checkpatch issues highlighted in feedback. 6) revised CPU hotplug to cover missing cases needed by ETM. Changes since v1: 1) Significant restructuring of the source code. Adds cti-sysfs file and cti device tree file. Patches add per feature rather than per source file. 2) CPU type power event handling for hotplug moved to CoreSight core, with generic registration interface provided for all CPU bound CS devices to use. 3) CTI signal interconnection details in sysfs now generated dynamically from connection lists in driver. This to fix issue with multi-line sysfs output in previous version. 4) Full device tree bindings for DB410 and Juno provided (to the extent that CTI information is available). 5) AMBA driver update for UCI IDs are now upstream so no longer included in this set. Mike Leach (16): coresight: cti: Initial CoreSight CTI Driver coresight: cti: Add sysfs coresight mgmt reg access. coresight: cti: Add sysfs access to program function regs coresight: cti: Add sysfs trigger / channel programming API devicetree: bindings: Documentation for CTI bindings. coresight: cti: Add device tree support for v8 arch CTI coresight: cti: Add device tree support for impdef CTI. coresight: cti: Enable CTI associated with devices. coresight: cti: Add connection information to sysfs devicetree: bindings: Add header with CTI trigger signal type constants. drivers: dts: Add CTI options for qcom msm8916 drivers: dts: Juno platform - add CTI entries to device tree. docs: coresight: Update documentation for CoreSight to cover CTI. docs: sysfs: coresight: Add sysfs documentation for CTI drivers: coresight: Add generic CoreSight cpu power notifications. drivers: coresight: cti: Add CPU power event handling. .../testing/sysfs-bus-coresight-devices-cti | 225 +++ .../bindings/arm/coresight-ect-cti.txt | 203 +++ .../devicetree/bindings/arm/coresight.txt | 7 + Documentation/trace/coresight.txt | 139 ++ MAINTAINERS | 2 + arch/arm64/boot/dts/arm/juno-base.dtsi | 149 +- arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 31 +- arch/arm64/boot/dts/arm/juno-r1.dts | 25 + arch/arm64/boot/dts/arm/juno-r2.dts | 25 + arch/arm64/boot/dts/arm/juno.dts | 25 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 85 +- drivers/hwtracing/coresight/Kconfig | 13 + drivers/hwtracing/coresight/Makefile | 4 + .../coresight/coresight-cti-platform.c | 501 +++++++ .../hwtracing/coresight/coresight-cti-sysfs.c | 1240 +++++++++++++++++ drivers/hwtracing/coresight/coresight-cti.c | 835 +++++++++++ drivers/hwtracing/coresight/coresight-cti.h | 262 ++++ drivers/hwtracing/coresight/coresight-priv.h | 36 + drivers/hwtracing/coresight/coresight.c | 232 ++- include/dt-bindings/arm/coresight-cti-dt.h | 36 + include/linux/coresight.h | 30 + 21 files changed, 4090 insertions(+), 15 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-cti create mode 100644 Documentation/devicetree/bindings/arm/coresight-ect-cti.txt create mode 100644 drivers/hwtracing/coresight/coresight-cti-platform.c create mode 100644 drivers/hwtracing/coresight/coresight-cti-sysfs.c create mode 100644 drivers/hwtracing/coresight/coresight-cti.c create mode 100644 drivers/hwtracing/coresight/coresight-cti.h create mode 100644 include/dt-bindings/arm/coresight-cti-dt.h -- 2.20.1

5 years, 10 months

Arm TechCon 2019

by Loretta Green

Hi If you are interested to get the list of attendees list of Arm TechCon 2019 with 4,458 contacts The expo will showcase the contacts of Information Technology, Software, Graphics, Software Development, Embedded Technology and Embedded Systems. Email me back so that I can share the best pricing & samples for the list of preview. Best Regards, Loretta Green

5 years, 10 months

[PATCH v4 0/6] coresight: etm4x: save/restore ETMv4 context across CPU low power states

by Andrew Murray

Some hardware will ignore bit TRCPDCR.PU which is used to signal to hardware that power should not be removed from the trace unit. Let's mitigate against this by conditionally saving and restoring the trace unit state when the CPU enters low power states. This patchset introduces a firmware property named 'arm,coresight-needs-save-restore' - when this is present the hardware state will be conditionally saved and restored. A module parameter 'pm_save_enable' is also introduced which can be configured to override the firmware property. The hardware state is only ever saved and restored when a self-hosted coresight is in use. Changes since v3: - Only save/restore when self-hosted is being used and detect this without relying on the coresight registers (which may not be available) - Only allocate memory for etmv4_save_state at probe time when configuration indicates it may be used - Set pm_save_enable param to 0444 such that it is static after boot - Save/restore TRCPDCR - Add missing comments to struct etm4_drvdata documentation - Rebased onto coresight/next (8f1f9857) Changes since v2: - Move the PM notifier block from drvdata to file static - Add section names to document references - Add additional information to commit messages - Remove trcdvcvr and trcdvcmr from saved state and add a comment to describe why - Ensure TRCPDCR_PU is set after restore and add a comment to explain why we bother toggling TRCPDCR_PU on save/restore - Reword the pm_save_enable options and add comments - Miscellaneous style changes - Move device tree binding documentation to its own patch Changes since v1: - Rebased onto coresight/next - Correcly pass bit number rather than BIT macro to coresight_timeout - Abort saving state if a timeout occurs - Fix completely broken pm_notify handling and unregister handler on error - Use state_needs_restore to ensure state is restored only once - Add module parameter description to existing boot_enable parameter and use module_param instead of module_param_named - Add firmware bindings for coresight-needs-save-restore - Rename 'disable_pm_save' to 'pm_save_enable' which allows for disabled, enabled or firmware - Update comment on etm4_os_lock, it incorrectly indicated that the code unlocks the trace registers - Add comments to explain use of OS lock during save/restore - Fix incorrect error description whilst waiting for PM stable - Add WARN_ON_ONCE when cpu isn't as expected during save/restore - Various updates to commit messages Andrew Murray (6): coresight: etm4x: remove superfluous setting of os_unlock coresight: etm4x: use explicit barriers on enable/disable coresight: etm4x: use module_param instead of module_param_named coresight: etm4x: improve clarity of etm4_os_unlock comment coresight: etm4x: save/restore state across CPU low power states dt-bindings: arm: coresight: Add support for coresight-needs-save-restore .../devicetree/bindings/arm/coresight.txt | 3 + drivers/hwtracing/coresight/coresight-etm4x.c | 346 +++++++++++++++++- drivers/hwtracing/coresight/coresight-etm4x.h | 64 ++++ 3 files changed, 406 insertions(+), 7 deletions(-) -- 2.21.0

5 years, 10 months

Configuring TRCCONFIGR

by Jeremy Ng

Hi Mathieu, I will like to ask how I might be able to configure the options in trcconfig driver file, found in /sys/bus/coresight/devices/*.etm/mgmt/ . For example, the trcidr0 denotes that tssize = 64bits (which indicates that timestamps are supported), retstack, cc, bb are also supported. However, my trcconfig file shows that none of the options are activated. In the *.etm driver files, it has the following files in it that I thought might have been linked to trcconfig, or at least be related to activating some of the options that are currently activated: 1. bb_ctrl (obviously bb) 2. cntr_ctrl 3. cyc_threshold (cc?) 4. event_ts (ts) I am hoping that help in activating these options can be provided. On another note, I will also like to ask if there might be example files that I may refer to to using sequencer/resource/events. In the *.etm file, there are seq_event,seq_idx,seq_reset_event,seq_state/res_ctrl, res_idx/event,event_instren,event_ts,event_vinst in the respective order (seq/res/events). I will like to understand how I might use these features to improve my tracing results. As well as understanding the various values I could apply to the mode file. As quoted in sysfs-bus-coresight-devices-etm4x, What: /sys/bus/coresight/devices/<memory_map>.etm/mode Date: April 2015 KernelVersion: 4.01 Contact: Mathieu Poirier <mathieu.poirier(a)linaro.org> Description: (RW) Controls various modes supported by this ETM, for example P0 instruction tracing, branch broadcast, cycle counting and context ID tracing. However it does not explain how that file can control various modes. I have tried toying with this files and it went from useful tracing results to just kernel instruction tracing results. After applying 0x0 to the mode again (which was the default value when i start up my device), I am unable to re-obtain useful trace results and had to resort to re-power my device. Lastly, I understand that nr_ss_cmp meant that my etm can only have 1 single-shot comparator during a trace (correct me if I am wrong). This explains why when I applied 0x3 to addr_idx and set addr_start value, I am unable to set a value for addr_stop. On the other hand,i have 0x4 nr_addr_cmp. However, I do not understand how I might be able to use the other 2 addr comparator (i.e. when addr_idx = 0, I am able to set addr_start and addr_stop, which took up 2 addr_cmp. How then, might I be able to use the other 2 addr_cmp?) My apologies for many amateurish questions. I have been looking at the etm documentation (IHI0064F), particularly on comparators, bb, ts, events, resources but unfortunately unable to connect the dots on how I might be able to use them with the coresight drivers. Yours Sincerely, Jeremy Ng

5 years, 10 months

[PATCH v4 2/2] perf machine: arm/arm64: Improve completeness for kernel address space

by Leo Yan

Arm and arm64 architecture reserve some memory regions prior to the symbol '_stext' and these memory regions later will be used by device module and BPF jit. The current code misses to consider these memory regions thus any address in the regions will be taken as user space mode, but perf cannot find the corresponding dso with the wrong CPU mode so we misses to generate samples for device module and BPF related trace data. This patch parse the link scripts to get the memory size prior to start address and reduce this size from 'machine>->kernel_start', then can get a fixed up kernel start address which contain memory regions for device module and BPF. Finally, machine__get_kernel_start() can reflect more complete kernel memory regions and perf can successfully generate samples. The reason for parsing the link scripts is Arm architecture changes text offset dependent on different platforms, which define multiple text offsets in $kernel/arch/arm/Makefile. This offset is decided when build kernel and the final value is extended in the link script, so we can extract the used value from the link script. We use the same way to parse arm64 link script as well. If fail to find the link script, the pre start memory size is assumed as zero, in this case it has no any change caused with this patch. Below is detailed info for testing this patch: - Install or build LLVM/Clang; - Configure perf with ~/.perfconfig: root@debian:~# cat ~/.perfconfig # this file is auto-generated. [llvm] clang-path = /mnt/build/llvm-build/build/install/bin/clang kbuild-dir = /mnt/linux-kernel/linux-cs-dev/ clang-opt = "-g" dump-obj = true [trace] show_zeros = yes show_duration = no no_inherit = yes show_timestamp = no show_arg_names = no args_alignment = 40 show_prefix = yes - Run 'perf trace' command with eBPF event: root@debian:~# perf trace -e string \ -e $kernel/tools/perf/examples/bpf/augmented_raw_syscalls.c - Read eBPF program memory mapping in kernel: root@debian:~# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms root@debian:~# cat /proc/kallsyms | grep -E "bpf_prog_.+_sys_[enter|exit]" ffff00000008a0d0 t bpf_prog_e470211b846088d5_sys_enter [bpf] ffff00000008c6a4 t bpf_prog_29c7ae234d79bd5c_sys_exit [bpf] - Launch any program which accesses file system frequently so can hit the system calls trace flow with eBPF event; - Capture CoreSight trace data with filtering eBPF program: root@debian:~# perf record -e cs_etm/@tmc_etr0/ \ --filter 'filter 0xffff00000008a0d0/0x800' -a sleep 5s - Decode the eBPF program symbol 'bpf_prog_f173133dc38ccf87_sys_enter': root@debian:~# perf script -F,ip,sym Frame deformatter: Found 4 FSYNCS 0 [unknown] ffff00000008a1ac bpf_prog_e470211b846088d5_sys_enter ffff00000008a250 bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a124 bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a14c bpf_prog_e470211b846088d5_sys_enter ffff00000008a13c bpf_prog_e470211b846088d5_sys_enter ffff00000008a14c bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a180 bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a1ac bpf_prog_e470211b846088d5_sys_enter ffff00000008a190 bpf_prog_e470211b846088d5_sys_enter ffff00000008a1ac bpf_prog_e470211b846088d5_sys_enter ffff00000008a250 bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a124 bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a14c bpf_prog_e470211b846088d5_sys_enter 0 [unknown] ffff00000008a180 bpf_prog_e470211b846088d5_sys_enter [...] Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Signed-off-by: Leo Yan <leo.yan(a)linaro.org> --- tools/perf/Makefile.config | 22 ++++++++++++++++++++++ tools/perf/arch/arm/util/Build | 2 ++ tools/perf/arch/arm/util/machine.c | 17 +++++++++++++++++ tools/perf/arch/arm64/util/Build | 1 + tools/perf/arch/arm64/util/machine.c | 17 +++++++++++++++++ 5 files changed, 59 insertions(+) create mode 100644 tools/perf/arch/arm/util/machine.c create mode 100644 tools/perf/arch/arm64/util/machine.c diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index e4988f49ea79..76e0ad0b4fd2 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -51,6 +51,17 @@ endif ifeq ($(SRCARCH),arm) NO_PERF_REGS := 0 LIBUNWIND_LIBS = -lunwind -lunwind-arm + PRE_START_SIZE := 0 + ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds),) + # Extract info from lds: + # . = ((0xC0000000)) + 0x00208000; + # PRE_START_SIZE := 0x00208000 + PRE_START_SIZE := $(shell egrep ' \. \= ${2}0x[0-9a-fA-F]+${2}' \ + $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds | \ + sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \ + awk -F' ' '{printf "0x%x", $$2}' 2>/dev/null) + endif + CFLAGS += -DARM_PRE_START_SIZE=$(PRE_START_SIZE) endif ifeq ($(SRCARCH),arm64) @@ -58,6 +69,17 @@ ifeq ($(SRCARCH),arm64) NO_SYSCALL_TABLE := 0 CFLAGS += -I$(OUTPUT)arch/arm64/include/generated LIBUNWIND_LIBS = -lunwind -lunwind-aarch64 + PRE_START_SIZE := 0 + ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds),) + # Extract info from lds: + # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000; + # PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000) = 0x10080000 + PRE_START_SIZE := $(shell egrep ' \. \= ${8}0x[0-9a-fA-F]+${2}' \ + $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds | \ + sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \ + awk -F' ' '{printf "0x%x", $$6+$$7+$$8}' 2>/dev/null) + endif + CFLAGS += -DARM_PRE_START_SIZE=$(PRE_START_SIZE) endif ifeq ($(SRCARCH),csky) diff --git a/tools/perf/arch/arm/util/Build b/tools/perf/arch/arm/util/Build index 296f0eac5e18..efa6b768218a 100644 --- a/tools/perf/arch/arm/util/Build +++ b/tools/perf/arch/arm/util/Build @@ -1,3 +1,5 @@ +perf-y += machine.o + perf-$(CONFIG_DWARF) += dwarf-regs.o perf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o diff --git a/tools/perf/arch/arm/util/machine.c b/tools/perf/arch/arm/util/machine.c new file mode 100644 index 000000000000..db172894e4ea --- /dev/null +++ b/tools/perf/arch/arm/util/machine.c @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0 +#include <linux/types.h> +#include <linux/string.h> +#include <stdlib.h> + +#include "../../util/machine.h" + +void arch__fix_kernel_text_start(u64 *start) +{ + /* + * On arm, the 16MB virtual memory space prior to 'kernel_start' is + * allocated to device modules, a PMD table if CONFIG_HIGHMEM is + * enabled and a PGD table. To reflect the complete kernel address + * space, compensate the pre-defined regions for kernel start address. + */ + *start = *start - ARM_PRE_START_SIZE; +} diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build index 3cde540d2fcf..8081fb8a7b3d 100644 --- a/tools/perf/arch/arm64/util/Build +++ b/tools/perf/arch/arm64/util/Build @@ -1,4 +1,5 @@ perf-y += header.o +perf-y += machine.o perf-y += sym-handling.o perf-$(CONFIG_DWARF) += dwarf-regs.o perf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o diff --git a/tools/perf/arch/arm64/util/machine.c b/tools/perf/arch/arm64/util/machine.c new file mode 100644 index 000000000000..61058dca8c5a --- /dev/null +++ b/tools/perf/arch/arm64/util/machine.c @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0 +#include <linux/types.h> +#include <linux/string.h> +#include <stdlib.h> + +#include "../../util/machine.h" + +void arch__fix_kernel_text_start(u64 *start) +{ + /* + * On arm64, the root PGD table, device module memory region and + * BPF jit region are prior to 'kernel_start'. To reflect the + * complete kernel address space, compensate these pre-defined + * regions for kernel start address. + */ + *start = *start - ARM_PRE_START_SIZE; +} -- 2.17.1

5 years, 10 months

Re: coresight@lists.linaro.org

by Jeremy Ng

Hi Mike, Thank you for your reply! On Thu, Aug 1, 2019 at 1:09 AM Mike Leach <mike.leach(a)linaro.org> wrote: > > Hi Jeremy, > > The trc_pkt_lister app uses a mapping from core name to determine architecture version and core profile. A73 was not included inthe version of the library you are using, but it has been updated in v0.12.0 released today. > > Thank you for updating me on this information. I have tried it with Cortex-A73 and it works! > > On Thu, 25 Jul 2019 at 10:44, Jeremy Ng <ngyzj95(a)gmail.com> wrote: >> >> Dear Mike, >> >> I will like to ask you for guidance on using openCSD. >> >> I was trying to use and understand trc_pkt_lister from demos >> and notice that snapshot of the device is required >> (hikey960 device is used here). >> >> I have also tried looking at the programmer's guide for >> openCSD but I am confused with what I am required to do. >> >> Nevertheless, I tried running trc_pkt_lister in the hikey960 >> snapshot folder and it gave me this error: >> >> Trace Packet Lister : reading snapshot from path ./ >> Using ETR_0 as trace source >> ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_4. >> ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_5. >> ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_6. >> ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_7. >> Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x10 >> Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x12 >> Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x14 >> Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x16 >> Trace Packet Lister : Error : Unable to open trace buffer >> >> >> I am not exactly sure if there is a proper software to >> perform snapshots/kernel dump/reading registers values. >> I also thought it worthy to note that the snapshot files >> are made in reference to the juno-uname-002 demo project. >> >> >> On another note, I will like to ask if it is possible >> to use openCSD to decode just the trace binary dumps >> without the need for snapshots. > > > If you write your own application to use the library then you can specify whatever input format you wish to provide the correct data for the library. > > What level of decode are you looking for? If you want to simply convert the trace binaries into simple packet listings like ptmtohuman, then far less information is needed. For a full trace decode however both configuration information and program images are required for decode. > > The snapshots provide a format that manages this information and is easy to use for the library test programs such as trc_pkt_lister. May I inquire how I might go about doing that? I am have gotten a snapshot of my device, thanks to Leo Yan, however, I will like to understand how the information in the snapshot was acquired. Especially the following values: In cpu_0.ini: 1) ``` [regs] PC(size:64)=0xFFFFFFC000081000 SP(size:64)=0 SCTLR_EL1=0x1007 CPSR=0x1C5 ``` How was the value for PC, SP, SPCTLR_EL1 and CPSR acquired? 2) ``` [dump1] file=kernel_dump.bin address=0xFFFFFFC000081000 length=0x00050000 ``` How do I acquire kernel_dump.bin and how was the address and length decided? My apologies for the amateurish questions. Regards, Jeremy > > Regrds > > Mike > > >> >> Any assistance will be appreciated >> >> Cheers, >> Jeremy > > -- > Mike Leach > Principal Engineer, ARM Ltd. > Manchester Design Centre. UK

5 years, 11 months

Release of OpenCSD 0.12.0 and development branch 0.13.0-dev

by Mike Leach

Hi, The OpenCSD library is released today @ version 0.12.0 Key updates include:- i) Correction and enhancement of ETMv4 Exception packets. The ETMv4 exception packet contains a preferred return address. This address can also be a target address for the preceding branch if the exception was taken after a branch but before any instructions at the branch target was taken. This is implied by the ordering of the output generic elements in previous versions of the library - but this version has an explicit flag to indicate when this occurs. The intention here is to make it easier for clients that such as perf that are creating lists of branch source/target pairs to correctly spot this event. The preferred return address can also contain a context element in the circumstances that it is also a target address. This was not being emitted correctly by the library. This has been corrected. ii) Support for trace source captures that come from TPIU - these will include FSYNC bytes that need to be handled by the library. Update to test program and snapshot to demo this. iii) Various minor bugfixes and documentation updates to support the changes above. The OpenCSD dev-0v13v0 branch is created. This contains support not previously available in the library, to allow the processing of ETMv4 Q packets. This feature is still undergoing testing but is being made available should any users have a target that can enable these packets. Support for speculative trace will be made available on this branch in due course. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

5 years, 11 months

[PATCH] coresight: acpi: Static funnel support

by Suzuki K Poulose

The ACPI bindings for CoreSight has been updated to add the device id for non-programmable CoreSight funnels (aka static funnels) as of v1.1 [0]. Add the ACPI id for static funnels in the driver. [0] https://static.docs.arm.com/den0067/a/DEN0067_CoreSight_ACPI_1.1.pdf Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> --- drivers/hwtracing/coresight/coresight-funnel.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c index fa97cb9ab4f9..0c99848a5d69 100644 --- a/drivers/hwtracing/coresight/coresight-funnel.c +++ b/drivers/hwtracing/coresight/coresight-funnel.c @@ -5,6 +5,7 @@ * Description: CoreSight Funnel driver */ +#include <linux/acpi.h> #include <linux/kernel.h> #include <linux/init.h> #include <linux/types.h> @@ -302,11 +303,19 @@ static const struct of_device_id static_funnel_match[] = { {} }; +#ifdef CONFIG_ACPI +static const struct acpi_device_id static_funnel_ids[] = { + {"ARMHC9FE", 0}, + {}, +}; +#endif + static struct platform_driver static_funnel_driver = { .probe = static_funnel_probe, .driver = { .name = "coresight-static-funnel", .of_match_table = static_funnel_match, + .acpi_match_table = ACPI_PTR(static_funnel_ids), .pm = &funnel_dev_pm_ops, .suppress_bind_attrs = true, }, -- 2.21.0

5 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight