CoreSight March 2021

coresight@lists.linaro.org

36 participants
31 discussions

[PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing

by Sai Prakash Ranjan

Hardware assisted tracing families such as ARM Coresight, Intel PT provides rich tracing capabilities including instruction level tracing and accurate timestamps which are very useful for profiling and also pose a significant security risk. One such example of security risk is when kernel mode tracing is not excluded and these hardware assisted tracing can be used to analyze cryptographic code execution. In this case, even the root user must not be able to infer anything. To explain it more clearly in the words of a security team member (credits: Mattias Nissler), "Consider a system where disk contents are encrypted and the encryption key is set up by the user when mounting the file system. From that point on the encryption key resides in the kernel. It seems reasonable to expect that the disk encryption key be protected from exfiltration even if the system later suffers a root compromise (or even against insiders that have root access), at least as long as the attacker doesn't manage to compromise the kernel." Here the idea is to protect such important information from all users including root users since root privileges does not have to mean full control over the kernel [1] and root compromise does not have to be the end of the world. But "Peter said even the regular counters can be used for full branch trace, the information isn't as accurate as PT and friends and not easier but is good enough to infer plenty". This would mean that a global tunable config for all kernel mode pmu tracing is more appropriate than the one targeting the hardware assisted instruction tracing. Currently we can exclude kernel mode tracing via perf_event_paranoid sysctl but it has following limitations, * No option to restrict kernel mode instruction tracing by the root user. * Not possible to restrict kernel mode instruction tracing when the hardware assisted tracing IPs like ARM Coresight ETMs use an additional interface via sysfs for tracing in addition to perf interface. So introduce a new config CONFIG_EXCLUDE_KERNEL_PMU_TRACE to exclude kernel mode pmu tracing for all users including root which will be generic and applicable to all hardware tracing families and which can also be used with other interfaces like sysfs in case of ETMs. Patch 1 adds this new config and the support in perf core to exclude all kernel mode PMU tracing. Patch 2 adds the perf evsel warning message when the perf tool users attempt to perform a kernel mode trace with the config enabled to exclude the kernel mode tracing. Patch 3 and Patch 4 adds the support for excluding kernel mode for ARM Coresight ETM{4,3}XX sysfs mode using the newly introduced generic config. [1] https://lwn.net/Articles/796866/ Changes in v2: * Move from kernel mode instruction tracing to all kernel level PMU tracing (Peter) * Move the check and warning to the caller mode_store() (Doug) Sai Prakash Ranjan (4): perf/core: Add support to exclude kernel mode PMU tracing perf evsel: Print warning for excluding kernel mode instruction tracing coresight: etm4x: Add support to exclude kernel mode tracing coresight: etm3x: Add support to exclude kernel mode tracing drivers/hwtracing/coresight/coresight-etm3x-core.c | 3 +++ drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 6 ++++++ drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++++- drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 6 ++++++ init/Kconfig | 11 +++++++++++ kernel/events/core.c | 3 +++ tools/perf/util/evsel.c | 3 ++- 7 files changed, 36 insertions(+), 2 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

2 years, 11 months

[PATCH 0/7] Split Coresight decode by aux records

by James Clark

Hi All, Since my previous RFC, I've fixed --per-thread mode and solved most of the open questions. I've also changed --dump-raw-trace to use the same code path so it's also working now. I think the only open questions are: * General approach * If aux records need to be saved, or if they can be pulled from elsewhere. I've also tested perf inject which is now working with troublesome files. Thanks James James Clark (7): perf cs-etm: Split up etm queue setup function perf cs-etm: Only search timestamp in current sample's queue. perf cs-etm: Save aux records in each etm queue perf cs-etm: don't process queues until cs_etm__flush_events perf cs-etm: split decode by aux records. perf cs-etm: Use existing decode code path for --dump-raw-trace perf cs-etm: Suppress printing when resetting decoder .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 +- tools/perf/util/cs-etm.c | 300 ++++++++++-------- 2 files changed, 168 insertions(+), 142 deletions(-) -- 2.28.0

3 years

[PATCH v5 00/19] 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 v5.12-rc4 + some patches queued. 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/v5/ 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 (14): [Queued] kvm: arm64: Hide system instruction access to Trace registers [Queued] kvm: arm64: Disable guest access to trace filter controls perf: aux: Add flags for the buffer format perf: aux: Add CoreSight PMU buffer formats arm64: Add support for trace synchronization barrier 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 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 | 3 + arch/arm64/include/asm/kvm_host.h | 2 + arch/arm64/include/asm/sysreg.h | 50 + arch/arm64/kernel/cpufeature.c | 1 - arch/arm64/kernel/hyp-stub.S | 3 +- arch/arm64/kvm/debug.c | 6 +- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 + arch/arm64/kvm/hyp/nvhe/switch.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 +- 28 files changed, 2016 insertions(+), 64 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

3 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

3 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

3 years, 1 month

[PATCH v3] arm64: dts: msm8916: Enable CoreSight STM component

by Leo Yan

From: Georgi Djakov <georgi.djakov(a)linaro.org> Add DT binding for CoreSight System Trace Macrocell (STM) on msm8916, which can benefit the CoreSight development on DB410c. Signed-off-by: Georgi Djakov <georgi.djakov(a)linaro.org> Signed-off-by: Leo Yan <leo.yan(a)linaro.org> --- Changes from v2: * Correct for author name. Changes from v1: * alphabetically and address ordering for DT node; pad addresses with zeroes (Stephan Gerhold). arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi index 3a9538e1ec97..2165b7415add 100644 --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi @@ -410,6 +410,7 @@ &wcd_codec { &funnel0 { status = "okay"; }; &funnel1 { status = "okay"; }; &replicator { status = "okay"; }; +&stm { status = "okay"; }; &tpiu { status = "okay"; }; &smd_rpm_regulators { diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index 402e891a84ab..f02b976480d5 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -489,6 +489,26 @@ snoc: interconnect@580000 { <&rpmcc RPM_SMD_SNOC_A_CLK>; }; + stm: stm@802000 { + compatible = "arm,coresight-stm", "arm,primecell"; + reg = <0x00802000 0x1000>, + <0x09280000 0x180000>; + reg-names = "stm-base", "stm-stimulus-base"; + + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + status = "disabled"; + + out-ports { + port { + stm_out: endpoint { + remote-endpoint = <&funnel0_in7>; + }; + }; + }; + }; + /* System CTIs */ /* CTI 0 - TMC connections */ cti0: cti@810000 { @@ -562,6 +582,13 @@ funnel0_in4: endpoint { remote-endpoint = <&funnel1_out>; }; }; + + port@7 { + reg = <7>; + funnel0_in7: endpoint { + remote-endpoint = <&stm_out>; + }; + }; }; out-ports { -- 2.25.1

3 years, 1 month

Bidding invitation

by Albert Bourla

Good Day Sir/Ms, We are please to invite you or your company to quote the following item listed below: Product/Model No: A702TH FYNE PRESSURE REGULATOR Model Number: A702TH Qty. 30 units Compulsory,Kindly send your quotation to: quotation(a)pfizerbvsupply.com for immediate approval. Kind Regards, Albert Bourla PFIZER B.V Supply Chain Manager Tel: +31(0)208080 880 ADDRESS: Rivium Westlaan 142, 2909 LD Capelle aan den IJssel, Netherlands

3 years, 1 month

Bloqueo del Vehiculo - Multa no pagada

by Ministerio Del Interior 428245

Saludos Cordiales correo electronico: coresight(a)lists.linaro.org Tienes una multa pendiente Se ha identificado en nuestro sistema una multa de trafico no pagada, dirigida a usted o su vehiculo. Para ver la notificacion Visite: multa-pendiente-coresight(a)lists.linaro.org Atencion: Para ver la notificacion, abra en un sistema (Windows). Copyright DGT 2021. Todos los derechos reservados.   P65LOEPP65LOP65LOEAJP65LOEP65LOEP65LP6P65LOEAJUP65LOEAP65LOEP65LOEP65LOEP65LOEP65LOEP65LOE P65LOEPP65LOP65LOEAJP65LOEP65LOEP65LP6P65LOEAJUP65LOEAP65LOEP65LOEP65LOEP65LOEP65LOEP65LOE P65LOEPP65LOP65LOEAJP65LOEP65LOEP65LP6P65LOEAJUP65LOEAP65LOEP65LOEP65LOEP65LOEP65LOEP65LOE  

3 years, 1 month

[PATCH v2] coresight: core: Fix typo in coresight-core.c

by Qi Liu

Fix the following checkpatch warning: WARNING: 'compoment' may be misspelled - perhaps 'component'? Fixes: 8e264c52e1da ("coresight: core: Allow the coresight core driver to be built as a module") Signed-off-by: Qi Liu <liuqi115(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 0062c89..b57bea1 100644 --- a/drivers/hwtracing/coresight/coresight-core.c +++ b/drivers/hwtracing/coresight/coresight-core.c @@ -86,7 +86,7 @@ static int coresight_id_match(struct device *dev, void *data) i_csdev->type != CORESIGHT_DEV_TYPE_SOURCE) return 0; - /* Get the source ID for both compoment */ + /* Get the source ID for both components */ trace_id = source_ops(csdev)->trace_id(csdev); i_trace_id = source_ops(i_csdev)->trace_id(i_csdev); -- 2.8.1

3 years, 1 month

Missing cs-trace-disasm.py

by Szymanski, Pawel

Hello, I am trying to run trace capturing from Coresight on N1 SDP using perf as described here: https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md I was able to gather the traces, but when I wanted to get the python script to get more human readable output as described in section https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md#trace-decoding-with-…, I found that the cs-trace-disasm.py Is missing in my system. Do you know where I can find the file? Regards Pawel Intel Technology Poland sp. z o.o. ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN. Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

3 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight March 2021