CoreSight

coresight@lists.linaro.org

6 participants
2349 discussions

[PATCH -next] coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

by Wei Yongjun

In case of error, the function devm_kasprintf() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> --- drivers/hwtracing/coresight/coresight-trbe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c index 5ce239875c98..176868496879 100644 --- a/drivers/hwtracing/coresight/coresight-trbe.c +++ b/drivers/hwtracing/coresight/coresight-trbe.c @@ -871,7 +871,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp dev = &cpudata->drvdata->pdev->dev; desc.name = devm_kasprintf(dev, GFP_KERNEL, "trbe%d", cpu); - if (IS_ERR(desc.name)) + if (!desc.name) goto cpu_clear; desc.type = CORESIGHT_DEV_TYPE_SINK;

4 years, 1 month

[PATCH -next] coresight: core: Make symbol 'csdev_sink' static

by Wei Yongjun

The sparse tool complains as follows: drivers/hwtracing/coresight/coresight-core.c:26:1: warning: symbol '__pcpu_scope_csdev_sink' was not declared. Should it be static? This symbol is not used outside of coresight-core.c, so this commit marks it static. Fixes: 2cd87a7b293d ("coresight: core: Add support for dedicated percpu sinks") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> --- drivers/hwtracing/coresight/coresight-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c index 3e779e1619ed..6c68d34d956e 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -23,7 +23,7 @@ #include "coresight-priv.h" static DEFINE_MUTEX(coresight_mutex); -DEFINE_PER_CPU(struct coresight_device *, csdev_sink); +static DEFINE_PER_CPU(struct coresight_device *, csdev_sink); /** * struct coresight_node - elements of a path, from source to sink

4 years, 1 month

[PATCH v6 00/20] coresight: Add support for ETE and TRBE

by Suzuki K Poulose

This series enables future IP trace features Embedded Trace Extension (ETE) and Trace Buffer Extension (TRBE). This series applies on kvmarm/fixes tree. A standalone tree is also available here [0]. The queued patches (almost there) are included in this posting for the sake of constructing a tree from the posting. ETE is the PE (CPU) trace unit for CPUs, implementing future architecture extensions. ETE overlaps with the ETMv4 architecture, with additions to support the newer architecture features and some restrictions on the supported features w.r.t ETMv4. The ETE support is added by extending the ETMv4 driver to recognise the ETE and handle the features as exposed by the TRCIDRx registers. ETE only supports system instructions access from the host CPU. The ETE could be integrated with a TRBE (see below), or with the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same firmware description as the ETMs and requires a node per instance. Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which is accessible via the system registers and can be combined with the ETE to provide a 1x1 configuration of source & sink. TRBE is being represented here as a CoreSight sink. Primary reason is that the ETE source could work with other traditional CoreSight sink devices. As TRBE captures the trace data which is produced by ETE, it cannot work alone. TRBE representation here have some distinct deviations from a traditional CoreSight sink device. Coresight path between ETE and TRBE are not built during boot looking at respective DT or ACPI entries. Unlike traditional sinks, TRBE can generate interrupts to signal including many other things, buffer got filled. The interrupt is a PPI and should be communicated from the platform. DT or ACPI entry representing TRBE should have the PPI number for a given platform. During perf session, the TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting it back. System registers being used here to configure ETE and TRBE could be referred in the link below. https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers. [0] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/ete/v6/ Changes since v6: - Rebased to kvmarm/fixes tree (which has some patches queued that this series depends on) - Fixed a sparse warning in TRBE driver Reported-by: kernel test robot <lkp(a)intel.com> - Add explicit undef handler for TRFCR_EL1 (Marc Zyngier) - Check for the SPE support early, kvm_arch_vcpu_load(), instead of every single time in guest_enter() (Patch 06) Changes since V4: https://lkml.kernel.org/r/20210225193543.2920532-1-suzuki.poulose@arm.com - Split the documentation patches from the TRBE driver - Drop the patches already queued for v5.12. - Mark the buffer TRUNCATED in case of a WRAP event - Fix error code for vmap failure - Fix build break on arm32 for per-cpu sink patch - Address comments on ETE dts bindings. - Make ete_sysreg_read/write static (kernel test robot) - Merged ete sysreg definition patch with ete support, to avoid a "defined but unused warning" on build in part of the series. - Add new bindings to MAINTAINERS Changes since V3: https://lore.kernel.org/linux-arm-kernel/1611737738-1493-1-git-send-email-a… - ETE and TRBE changes have been captured in the respective patches - Better support for nVHE - Re-ordered and splitted the patches to keep the changes separate for the generic/arm64 tree from CoreSight driver specific changes. - Fixes for KVM handling of Trace/SPE Changes since V2: https://lore.kernel.org/linux-arm-kernel/1610511498-4058-1-git-send-email-a… - Rebased on coresight/next - Changed DT bindings for ETE - Included additional patches for arm64 nvhe, perf aux buffer flags etc - TRBE changes have been captured in the respective patches Changes since V1: https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-… - Converted both ETE and TRBE DT bindings into Yaml - TRBE changes have been captured in the respective patches Changes since RFC: - There are not much ETE changes from Suzuki apart from splitting of the ETE DTS patch - TRBE changes have been captured in the respective patches RFC: https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-… Cc: Will Deacon <will(a)kernel.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Peter Zilstra <peterz(a)infradead.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Linu Cherian <lcherian(a)marvell.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (5): arm64: Add TRBE definitions coresight: core: Add support for dedicated percpu sinks coresight: sink: Add TRBE driver Documentation: coresight: trbe: Sysfs ABI description Documentation: trace: Add documentation for TRBE Suzuki K Poulose (15): perf: aux: Add flags for the buffer format perf: aux: Add CoreSight PMU buffer formats arm64: Add support for trace synchronization barrier kvm: arm64: Handle access to TRFCR_EL1 kvm: arm64: Move SPE availability check to VCPU load arm64: kvm: Enable access to TRBE support for host coresight: etm4x: Move ETM to prohibited region for disable coresight: etm-perf: Allow an event to use different sinks coresight: Do not scan for graph if none is present coresight: etm4x: Add support for PE OS lock coresight: ete: Add support for ETE sysreg access coresight: ete: Add support for ETE tracing dts: bindings: Document device tree bindings for ETE coresight: etm-perf: Handle stale output handles dts: bindings: Document device tree bindings for Arm TRBE .../testing/sysfs-bus-coresight-devices-trbe | 14 + .../devicetree/bindings/arm/ete.yaml | 75 ++ .../devicetree/bindings/arm/trbe.yaml | 49 + .../trace/coresight/coresight-trbe.rst | 38 + MAINTAINERS | 2 + arch/arm64/include/asm/barrier.h | 1 + arch/arm64/include/asm/el2_setup.h | 13 + arch/arm64/include/asm/kvm_arm.h | 2 + arch/arm64/include/asm/kvm_host.h | 8 + arch/arm64/include/asm/sysreg.h | 50 + arch/arm64/kernel/hyp-stub.S | 3 +- arch/arm64/kvm/arm.c | 2 + arch/arm64/kvm/debug.c | 36 +- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 56 +- arch/arm64/kvm/hyp/nvhe/switch.c | 1 + arch/arm64/kvm/sys_regs.c | 1 + drivers/hwtracing/coresight/Kconfig | 24 +- drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 +- .../hwtracing/coresight/coresight-etm-perf.c | 119 +- .../coresight/coresight-etm4x-core.c | 161 ++- .../coresight/coresight-etm4x-sysfs.c | 19 +- drivers/hwtracing/coresight/coresight-etm4x.h | 83 +- .../hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-priv.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 1157 +++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 152 +++ include/linux/coresight.h | 13 + include/uapi/linux/perf_event.h | 13 +- 29 files changed, 2054 insertions(+), 77 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml create mode 100644 Documentation/trace/coresight/coresight-trbe.rst create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h -- 2.24.1

4 years, 1 month

Invitation to Project Monitoring and Evaluation with Data Management and Analysis Workshop

by Jackson From FDC-K Africa

4 years, 1 month

[GIT PULL v2] coresight: Add support for ETE and TRBE

by Mathieu Poirier

The following changes since commit a354a64d91eec3e0f8ef0eed575b480fd75b999c: KVM: arm64: Disable guest access to trace filter controls (2021-03-24 17:26:38 +0000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE for you to fetch changes up to 4fb13790417a7bf726f3867a5d2b9723efde488b: dts: bindings: Document device tree bindings for Arm TRBE (2021-04-06 16:05:38 -0600) ---------------------------------------------------------------- Anshuman Khandual (5): arm64: Add TRBE definitions coresight: core: Add support for dedicated percpu sinks coresight: sink: Add TRBE driver Documentation: coresight: trbe: Sysfs ABI description Documentation: trace: Add documentation for TRBE Suzuki K Poulose (15): perf: aux: Add flags for the buffer format perf: aux: Add CoreSight PMU buffer formats arm64: Add support for trace synchronization barrier KVM: arm64: Handle access to TRFCR_EL1 KVM: arm64: Move SPE availability check to VCPU load arm64: KVM: Enable access to TRBE support for host coresight: etm4x: Move ETM to prohibited region for disable coresight: etm-perf: Allow an event to use different sinks coresight: Do not scan for graph if none is present coresight: etm4x: Add support for PE OS lock coresight: ete: Add support for ETE sysreg access coresight: ete: Add support for ETE tracing dts: bindings: Document device tree bindings for ETE coresight: etm-perf: Handle stale output handles dts: bindings: Document device tree bindings for Arm TRBE .../ABI/testing/sysfs-bus-coresight-devices-trbe | 14 + Documentation/devicetree/bindings/arm/ete.yaml | 75 ++ Documentation/devicetree/bindings/arm/trbe.yaml | 49 + Documentation/trace/coresight/coresight-trbe.rst | 38 + MAINTAINERS | 2 + arch/arm64/include/asm/barrier.h | 1 + arch/arm64/include/asm/el2_setup.h | 13 + arch/arm64/include/asm/kvm_arm.h | 2 + arch/arm64/include/asm/kvm_host.h | 8 + arch/arm64/include/asm/sysreg.h | 50 + arch/arm64/kernel/hyp-stub.S | 3 +- arch/arm64/kvm/arm.c | 2 + arch/arm64/kvm/debug.c | 35 +- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 56 +- arch/arm64/kvm/hyp/nvhe/switch.c | 1 + arch/arm64/kvm/sys_regs.c | 1 + drivers/hwtracing/coresight/Kconfig | 24 +- drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 119 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 161 ++- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 19 +- drivers/hwtracing/coresight/coresight-etm4x.h | 83 +- drivers/hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-priv.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 1157 ++++++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 152 +++ include/linux/coresight.h | 13 + include/uapi/linux/perf_event.h | 13 +- 29 files changed, 2053 insertions(+), 77 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml create mode 100644 Documentation/trace/coresight/coresight-trbe.rst create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h

4 years, 1 month

[PATCH v5 00/10] CoreSight configuration management; ETM strobing

by Mike Leach

This patchset introduces initial concepts in CoreSight system configuration management support. to allow more detailed and complex programming to be applied to CoreSight systems during trace capture. Configurations consist of 2 elements:- 1) Features - programming combinations for devices, applied to a class of device on the system (all ETMv4), or individual devices. 2) Configurations - a set of programmed features used when the named configuration is selected. Features and configurations are declared as a data table, a set of register, resource and parameter requirements. Features and configurations are loaded into the system by the virtual cs_syscfg device. This then matches features to any registered devices and loads the feature into them. Individual device classes that support feature and configuration register with cs_syscfg. Once loaded a configuration can be enabled for a specific trace run. Configurations are registered with the perf cs_etm event as entries in cs_etm/events. These can be selected on the perf command line as follows:- perf record -e cs_etm/<config_name>/ ... This patch set has one pre-loaded configuration and feature. A named "strobing" feature is provided for ETMv4. A named "autofdo" configuration is provided. This configuration enables strobing on any ETM in used. Thus the command: perf record -e cs_etm/autofdo/ ... will trace the supplied application while enabling the "autofdo" configuation on each ETM as it is enabled by perf. This in turn will enable strobing for the ETM - with default parameters. Parameters can be adjusted using configfs. The sink used in the trace run will be automatically selected. A configuration can supply up to 15 of preset parameter values, which will subsitute in parameter values for any feature used in the configuration. Selection of preset values as follows perf record -e cs_etm/autofdo,preset=1/ ... (valid presets 1-N, where N is the number supplied in the configuration, not exceeding 15. preset=0 is the same as not selecting a preset.) Applies to coresight/next (5.12-rc2 base) Changes since v4: (based on comments from Matthieu and Suzuki). No large functional changes - primarily code improvements and naming schema. 1) Updated entire set to ensure a consistent naming scheme was used for variables and struct members that refer to the key objects in the system. Suffixes _desc used for all references to feature and configuraion descriptors, suffix _csdev used for all references to load feature and configs in the csdev instances. (Mathieu & Suzuki). 2) Dropped the 'configurations' sub dir in cs_etm perf directories as superfluous with the configfs containing the same information. (Mathieu). 3) Simplified perf handling code (suzuki) 4) Multiple simplifications and improvements for code readability (Matthieu and Suzuki) Changes since v3: (Primarily based on comments from Matthieu) 1) Locking mechanisms simplified. 2) Removed the possibility to enable features independently from configurations.Only configurations can be enabled now. Simplifies programming logic. 3) Configuration now uses an activate->enable mechanism. This means that perf will activate a selected configuration at the start of a session (during setup_aux), and disable at the end of a session (around free_aux) The active configuration and associated features will be programmed into the CoreSight device instances when they are enabled. This locks the configuration into the system while in use. Parameters cannot be altered while this is in place. This mechanism will be extended in future for dynamic load / unload of configurations to prevent removal while in use. 4) Removed the custom bus / driver as un-necessary. A single device is registered to own perf fs elements and configfs. 5) Various other minor issues addressed. Changes since v2: 1) Added documentation file. 2) Altered cs_syscfg driver to no longer be coresight_device based, and moved to its own custom bus to remove it from the main coresight bus. (Mathieu) 3) Added configfs support to inspect and control loaded configurations and features. Allows listing of preset values (Yabin Cui) 4) Dropped sysfs support for adjusting feature parameters on the per device basis, in favour of a single point adjustment in configfs that is pushed to all device instances. 5) Altered how the config and preset command line options are handled in perf and the drivers. (Mathieu and Suzuki). 6) Fixes for various issues and technical points (Mathieu, Yabin) Changes since v1: 1) Moved preloaded configurations and features out of individual drivers. 2) Added cs_syscfg driver to manage configurations and features. Individual drivers register with cs_syscfg indicating support for config, and provide matching information that the system uses to load features into the drivers. This allows individual drivers to be updated on an as needed basis - and removes the need to consider devices that cannot benefit from configuration - static replicators, funnels, tpiu. 3) Added perf selection of configuarations. 4) Rebased onto the coresight module loading set. To follow in future revisions / sets:- a) load of additional config and features by loadable module. b) load of additional config and features by configfs c) enhanced resource management for ETMv4 and checking features have sufficient resources to be enabled. d) ECT and CTI support for configuration and features. Mike Leach (10): coresight: syscfg: Initial coresight system configuration coresight: syscfg: Add registration and feature loading for cs devices coresight: config: Add configuration and feature generic functions coresight: etm-perf: update to handle configuration selection coresight: syscfg: Add API to activate and enable configurations coresight: etm-perf: Update to activate selected configuration coresight: etm4x: Add complex configuration handlers to etmv4 coresight: config: Add preloaded configurations coresight: syscfg: Add initial configfs support coresight: docs: Add documentation for CoreSight config .../trace/coresight/coresight-config.rst | 244 ++++++ Documentation/trace/coresight/coresight.rst | 16 + drivers/hwtracing/coresight/Makefile | 7 +- .../hwtracing/coresight/coresight-cfg-afdo.c | 149 ++++ .../coresight/coresight-cfg-preload.c | 27 + .../coresight/coresight-cfg-preload.h | 11 + .../hwtracing/coresight/coresight-config.c | 274 +++++++ .../hwtracing/coresight/coresight-config.h | 253 ++++++ drivers/hwtracing/coresight/coresight-core.c | 12 +- .../hwtracing/coresight/coresight-etm-perf.c | 155 +++- .../hwtracing/coresight/coresight-etm-perf.h | 12 +- .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 +++++ .../hwtracing/coresight/coresight-etm4x-cfg.h | 30 + .../coresight/coresight-etm4x-core.c | 38 +- .../coresight/coresight-etm4x-sysfs.c | 3 + .../coresight/coresight-syscfg-configfs.c | 399 ++++++++++ .../coresight/coresight-syscfg-configfs.h | 45 ++ .../hwtracing/coresight/coresight-syscfg.c | 738 ++++++++++++++++++ .../hwtracing/coresight/coresight-syscfg.h | 81 ++ include/linux/coresight.h | 7 + 20 files changed, 2644 insertions(+), 39 deletions(-) create mode 100644 Documentation/trace/coresight/coresight-config.rst create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h create mode 100644 drivers/hwtracing/coresight/coresight-config.c create mode 100644 drivers/hwtracing/coresight/coresight-config.h create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h -- 2.17.1

4 years, 1 month

Re: opencsd: issue when decoding exceptions in ARMv7 M

by Mike Leach

Hi Zied, I can't see a reason for the issues based on what you have sent. The trace should start at the exception entry after the exception packet. I have checked the decoder code around the exception handling, but there is no obvious error there. There are no issues that have been logged between the version you are using and the latest decoder version that would suggest what you are seeing is a known issue. To investigate further please enable the packet logging and raw data logging output from the library. If we can see the individual packets we can determine if there is a fault in the decoder, or if the issue lies elsewhere. The example test program shows how to enable this support. Thanks Mike ________________________________ From: Zied Guermazi <zied.guermazi(a)trande.de> Sent: 02 April 2021 20:39 To: Mike Leach <Mike.Leach(a)arm.com> Subject: opencsd: issue when decoding exceptions in ARMv7 M hi Mike I have observed a strange behavior opencsd decoder when decoding traces of an IRQ on an stm32f4 (armv7 M4) MCU. let me first describe the context: here is the vector table with the list of address of exceptions handlers: 08000000 <g_pfnVectors>: 8000000: 30 08 00 20 33 06 00 08 31 06 00 08 31 06 00 08 0.. 3...1...1... 8000010: 31 06 00 08 31 06 00 08 31 06 00 08 00 00 00 00 1...1...1....... ... 800002c: 31 06 00 08 31 06 00 08 00 00 00 00 31 06 00 08 1...1.......1... 800003c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800004c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800005c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800006c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800007c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800008c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800009c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000ac: 31 06 00 08 c9 02 00 08 31 06 00 08 31 06 00 08 1.......1...1... 80000bc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000cc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000dc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000ec: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000fc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800010c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800011c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800012c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800013c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800014c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800015c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800016c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800017c: 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1... Timer2 (exception number 0x2c) exception handler is located at 080002c8, below is the disassembled code around it 08000290 <bubble_sort>: void bubble_sort (int *a, int n) { 8000290: b4f0 push {r4, r5, r6, r7} int i, t, s = 1; while (s) { 8000292: 4684 mov ip, r0 8000294: 3804 subs r0, #4 8000296: eb00 0481 add.w r4, r0, r1, lsl #2 s = 0; 800029a: 2700 movs r7, #0 for (i = 1; i < n; i++) { if (a[i] < a[i - 1]) { t = a[i]; a[i] = a[i - 1]; a[i - 1] = t; s = 1; 800029c: 2601 movs r6, #1 800029e: e00c b.n 80002ba <bubble_sort+0x2a> for (i = 1; i < n; i++) { 80002a0: 42a3 cmp r3, r4 80002a2: d009 beq.n 80002b8 <bubble_sort+0x28> if (a[i] < a[i - 1]) { 80002a4: 685a ldr r2, [r3, #4] 80002a6: f853 0b04 ldr.w r0, [r3], #4 80002aa: 4282 cmp r2, r0 80002ac: daf8 bge.n 80002a0 <bubble_sort+0x10> a[i] = a[i - 1]; 80002ae: 6018 str r0, [r3, #0] a[i - 1] = t; 80002b0: f843 2c04 str.w r2, [r3, #-4] s = 1; 80002b4: 4635 mov r5, r6 80002b6: e7f3 b.n 80002a0 <bubble_sort+0x10> while (s) { 80002b8: b125 cbz r5, 80002c4 <bubble_sort+0x34> for (i = 1; i < n; i++) { 80002ba: 2901 cmp r1, #1 80002bc: dd02 ble.n 80002c4 <bubble_sort+0x34> 80002be: 4663 mov r3, ip s = 0; 80002c0: 463d mov r5, r7 80002c2: e7ef b.n 80002a4 <bubble_sort+0x14> } } } } 80002c4: bcf0 pop {r4, r5, r6, r7} 80002c6: 4770 bx lr 080002c8 <TIM2_IRQHandler>: void TIM2_IRQHandler() { 80002c8: b530 push {r4, r5, lr} 80002ca: b087 sub sp, #28 int values[5] = {0x20,0x10,0x30,0x25,0x15}; 80002cc: ac01 add r4, sp, #4 80002ce: 4d11 ldr r5, [pc, #68] ; (8000314 <TIM2_IRQHandler+0x4c>) 80002d0: cd0f ldmia r5!, {r0, r1, r2, r3} 80002d2: c40f stmia r4!, {r0, r1, r2, r3} 80002d4: 682b ldr r3, [r5, #0] 80002d6: 6023 str r3, [r4, #0] int i; if (TIM_GetITStatus(TIM2, TIM_IT_Update)) 80002d8: 2101 movs r1, #1 80002da: f04f 4080 mov.w r0, #1073741824 ; 0x40000000 80002de: f001 fa85 bl 80017ec <TIM_GetITStatus> 80002e2: b908 cbnz r0, 80002e8 <TIM2_IRQHandler+0x20> ITM_SendValue(2, values[i]);*/ // Clears the TIM2 interrupt pending bit TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } } when opencsd decodes etm traces it reports following btrace] ETM trace_element: index= 15079610, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800044c:[0x8000450] num_i(1) last_sz(4) (ISA=T32) E BR b+link ) [btrace] ETM trace_element: index= 15079617, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x8000282:[0x8000284] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079618, channel= 0x2, OCSD_GEN_TRC_ELEM_EXCEPTION(excep num (0x2c) ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c0:[0x80002c2] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c2:[0x80002c4] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c4:[0x80002c6] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c6:[0x80002c8] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c8:[0x80002ca] num_i(1) last_sz(2) (ISA=T32) E --- ) instead of starting at 0x80002c8 after the OCSD_GEN_TRC_ELEM_EXCEPTION, it starts at 0x80002c0 which not the start address of the irq handler but rather belonging to the function preceding it in the elf file. why do we have those 4 OCSD_GEN_TRC_ELEM_INSTR_RANGE preceding the actual irq handler? how should I handle them? The issue observed with opencsd version 0.12.2-1. is this a known issue? Kind Regards Zied Guermazi -- Zied Guermazi founder Trande UG Leuschnerstraße 2 69469 Weinheim/Germany Mobile: +491722645127 mailto:zied.guermazi@trande.de Trande UG Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.

4 years, 1 month

[Question] ETM data loss due to limited buffer size of sink device

by liuqi (BA)

Hi Mathieu & Suzuki, Here is a question about the amount of data traced by ETM device. In high-CPU-utilization scene, volume of ETM trace data may be very large, but limited buffer in sink device which is used to store trace data can not hold all of these data. It seems that data loss in sink device is inevitable. So how could we ensure the data we are interested in isn't lost, or what we can do to reduce this kind of data loss? Any response will be highly appreciated. Thanks, Qi

4 years, 1 month

Re:Puff plus XXL

by Simon

4 years, 1 month

following up on my last email

by Lucas Hawkins

4 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight