CoreSight January 2020

coresight@lists.linaro.org

11 participants
13 discussions

Re: Coresight enablement on NXP ARMv8 device

by Mathieu Poirier

Hi Poonam, Please CC the coresight mailing list (as I did) when asking questions - there is a lot of well informed people on there that can also help you. On Thu, 23 Jan 2020 at 22:33, Poonam Aggrwal <poonam.aggrwal(a)nxp.com> wrote: > > Hello Mathieu > > > > Greetings! > > > > I have started to take a look at the Linux coresight framework, and get this enabled on a NXP ARMv8 device. > > > > Can you share some documentation on the configs required to be enabled and the device tree nodes? For V8 we have to reference implementation - ARM Juno and the dragonboard 410c. I highly recommend purchasing the latter (because it is very cheap) in order to get an understanding of what a working coresight system look like. It is much easier to start from a working example than nothing at all. Other than that the coresight bindings [1] are full of good examples. I would also have a look at the DT for Juno [2] and the dragonboard[3]. The HOWTO.md [4] on github is a really good starting point when you'll get to test things out. [1]. https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bin… [2]. https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/arm/juno… [3]. https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm… [4]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md > > To start I am looking to enable the ARMv8 ETM tracing. Before going further I advise you to look at the source and sink configuration on your platform. Up to now we've been working with configurations where sources share a single sink (N:1 topology). Newer SoC will have one source per sink (1:1 topology). At this time only the former is supported by the framework. Supporting 1:1 topologies would require a fair amount of refactoring, something we haven't had the opportunity to do for lack of HW platform to work with. Regards, Mathieu > > Is there a reference which I can check in Linux for device tree and config. > > > > Many Thanks > > Poonam

4 years, 9 months

[PATCH] docs: Document how to change buildid cache (a.k.a ~/.debug)

by Wojciech Żmuda

From: Wojciech Zmuda <wzmuda(a)n7space.com> Perf allows changing where the buildid cache directory is created. Mention it in the howto document. Signed-off-by: Wojciech Zmuda <wzmuda(a)n7space.com> --- HOWTO.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/HOWTO.md b/HOWTO.md index b16294a..a8b5ce9 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -633,4 +633,5 @@ Best regards, [2]: http://people.linaro.org/~mathieu.poirier/openCSD/uname.v4.user.sept20.tgz -[3]: Get in touch with us if you know a way to change this. +[3]: It can be changed with: perf-config: + perf config --system buildid.dir=/my/own/buildid/dir -- 2.11.0

4 years, 10 months

[PATCH 0/1] Xilinx Zynq Ultrascale+ MPSoc CoreSight DT nodes

by Wojciech Żmuda

From: Wojciech Zmuda <wzmuda(a)n7space.com> This patch adds CoreSight nodes to Zynq US+ device tree. I tested in on recent v5.5 tree, on Xilinx ZCU104 development board. Tracing with perf: root@zynq:~# perf record -e cs_etm/timestamp,cycacc,@tmc_etr0/u true Couldn't synthesize bpf events. [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.073 MB perf.data ] root@zynq:~# perf report --dump | grep "CoreSight ETM Trace data" -A10 . ... CoreSight ETM Trace data: size 74112 bytes Idx:0; ID:14; I_ASYNC : Alignment Synchronisation. Idx:12; ID:14; I_TRACE_INFO : Trace Info.; INFO=0x1 { CC.1 }; CC_THRESHOLD=0x100 Idx:19; ID:14; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFF800010839BF8; Idx:28; ID:14; I_TRACE_ON : Trace On. Idx:29; ID:14; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x0000FFFF83F37080; Ctxt: AArch64,EL0, NS; CID=0x00000281; Idx:44; ID:14; I_ATOM_F1 : Atom format 1.; E Idx:45; ID:14; I_CCNT_F1 : Cycle Count format 1.; Count=0x0 Idx:46; ID:14; I_TIMESTAMP : Timestamp.; Updated val = 0x29aa0b739ec; CC=0x1 Idx:58; ID:14; I_EXCEPT : Exception.; Data Fault; Ret Addr Follows; Idx:60; ID:14; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000FFFF83F37964; Please note that to get non-zero timestamps on this platform, the timestamp generator module needs to be explicitly enabled, e.g. from U-Boot, by writing '1' to 0xfe900000. Debug components: root@zynq:~# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable root@zynq:~# echo c > /proc/sysrq-trigger [ 57.5093] ARM external debug module: [ 57.513099] coresight-cpu-deb fec10000.debug0: CPU[0]: [ 57.518407] coresight-cpu-debug fec10000.debug0: EDPRSR: 00000001 (Power:On DLK:Unlock [ 57.526583] coresight-cpu-debug fec10000.debug0: EDPCSR: ocal_cpu_stop+0x2c/0x38 [ 57.534236] coresight-cpu-debug fec10000.debug0: EDCIDSR: 00000000 [ 57.540494] coresit-cpu-debug fec10000.debug0: EDVIDSR: 90000000 (State:Non-sece Mode:EL1/0 Width:64bits VMID:0) [ 57.551095] coresight-cpu-debug fed10000.debug1: CPU[1]: [ 57.556406] coresig-cpu-debug fed10000.debug1: EDPRSR: 00000001 (Power:On DLK:Uock) [ 57.564584] coresight-cpu-debug fed10000.debug1: EDPCSR: local_cpu_stop+0x2c/0x38 [ 57.572237] coresightpu-debug fed10000.debug1: EDCIDSR: 00000000 [ 57.578494] cesight-cpu-debug fed10000.debug1: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) [ 57.589096]oresight-cpu-debug fee10000.debug2: CPU[2]: [ 57.594408] cosight-cpu-debug fee10000.debug2: EDPRSR: 00000001 (Power:On DLK:Unlock) [ 57.602587] coresight-cpu-debug fee10000ebug2: EDPCSR: debug_notifier_call+0x2b8/0x3b0 [ 57.61084 coresight-cpu-debug fee10000.debug2: EDCIDSR: 00000170 [ 57.617103] coresight-cpu-debug fee10000.debug2: EDVIDSR90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) [ 57.627705] coresight-cpu-debug fef10000.debug3: CPU[3]: [ 57.633016] coresight-cpu-debug fef10000.debug3: EDPRSR: 0000001 (Power:On DLK:Unlock) [ 57.641193] coresight-cpu-deg fef10000.debug3: EDPCSR: local_cpu_stop+0x2c/0x38 [ 57.648846] coresight-cpu-debug fef10000.debug3: EDCIDSR: 000000 [ 57.655104] coresight-cpu-debug fef10000.debug3: EDDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0) [ 57.665708] Rebooting in 60 seconds.. Wojciech Zmuda (1): arm64: zynqmp: Add CoreSight components arch/arm64/boot/dts/xilinx/zynqmp-coresight.dtsi | 272 +++++++++++++++++++++++ arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 + 2 files changed, 274 insertions(+) create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-coresight.dtsi -- 2.11.0

5 years

Biomedical Users list

by Linda Castillo

Hi, I'm writing to check if you would be interested to acquire the newly released "BIOMEDICAL Companies" Leads with all verified business contact information. Target audience: - Biomedical companies, Biomedical material researchers, Pharmacies Executives, Pharmaceutical Companies, Medical Laboratories Data Fields:- Contact name, Title, Company, Revenue Size, Employee Size, Any Location, Opt-In Email address, Phone & Fax numbers, SIC Code, and etc. Please fill in the details below of your target market: Target Industry: ___________, Target title: ___________, Geography: ___________. Please confirm the above and I shall get back to you with list details, counts and a sample file for your review. I look forward to hearing from you. Linda Castillo Database Coordinator If you do not wish to receive any further emails please reply "Unsubscribe" in the subject Line.

5 years

[PATCH v8 00/15] 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 and Juno board, against the Linux 5.5-rc4. 5.5-rc6 trees. Changes since v7: NB: No functional driver changes in this set. Full set released for consistency, completeness and ease of use. 1) Updates to device tree bindings .yaml following comments from Rob Herring. Adds #size-cells and #address-cells to properties and constrained as required. Validated using dt_binding_check. 2) Minor typo fixes to cti documentation file. Changes since v6: NB: No functional driver changes in this set. Full set released for consistency, completeness and ease of use. 1) Updates to .yaml following comments from Maxime Ripard. Correct child node descriptions, fix validation, and ensure reg entries required in child nodes as per DeviceTree specification. 2) Update to Juno bindings to implement reg entry specification requirements. Changes since v5: 1) Fixed up device tree .yaml file. Using extra compatible string for v8 architecture CTI connections. 2) Ensure association code respects coresight mutex when setting cross referenced pointers. Add in shutdown code. 3) Multiple minor code fixes & rationalisation. Changes since v4: Multiple changes following feedback from Mathieu, Leo and Suzuki. 1) Dropped RFC tag - wider distribution 2) CTI bindings definition now presented as a .yaml file - tested with with 'dt-doc-validate' from devicetree.org/dt-schema project and in kernel build tree with 'make dtbs_check' per kernel docs. 3) Sysfs links to other CoreSight devices moved out of this set into a following set that deals with all CoreSight devices & sysfs links. 4) Documentation in .rst format and new directory following patchset in [1]. Extended example provided in docs. 5) Rationalised devicetree of_ specifics to use generic fwnode functions where possible to enable easier addition of ACPI support later. 6) Other minor changes as requested in feedback from last patchset. Changes since v3: 1) After discussion on CS mailing list, each CTI connection has a triggers<N> sysfs directory with name and trigger signals listed for the connection. 2) Initial code for creating sysfs links between CoreSight components is introduced and implementation for CTI provided. This allows exploration of the CoreSight topology within the sysfs infrastructure. Patches for links between other CoreSight components to follow. 3) Power management - CPU hotplug and idle omitted from this set as ongoing developments may define required direction. Additional patch set to follow. 4) Multiple fixes applied as requested by reviewers esp. Matthieu, Suzuki and Leo. 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 (15): 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 dt-bindings: arm: Adds CoreSight CTI hardware definitions. coresight: cti: Add device tree support for v8 arch CTI coresight: cti: Add device tree support for custom CTI. coresight: cti: Enable CTI associated with devices. coresight: cti: Add connection information to sysfs dt-bindings: qcom: Add CTI options for qcom msm8916 dt-bindings: arm: Juno platform - add CTI entries to device tree. dt-bindings: hisilicon: Add CTI bindings for hi-6220 docs: coresight: Update documentation for CoreSight to cover CTI. docs: sysfs: coresight: Add sysfs ABI documentation for CTI Update MAINTAINERS to add reviewer for CoreSight. .../testing/sysfs-bus-coresight-devices-cti | 221 ++++ .../bindings/arm/coresight-cti.yaml | 336 +++++ .../devicetree/bindings/arm/coresight.txt | 7 + .../trace/coresight/coresight-ect.rst | 211 +++ Documentation/trace/coresight/coresight.rst | 13 + MAINTAINERS | 3 + arch/arm64/boot/dts/arm/juno-base.dtsi | 162 ++- arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 37 +- 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 + .../boot/dts/hisilicon/hi6220-coresight.dtsi | 130 +- arch/arm64/boot/dts/qcom/msm8916.dtsi | 85 +- drivers/hwtracing/coresight/Kconfig | 21 + drivers/hwtracing/coresight/Makefile | 3 + .../coresight/coresight-cti-platform.c | 485 +++++++ .../hwtracing/coresight/coresight-cti-sysfs.c | 1175 +++++++++++++++++ drivers/hwtracing/coresight/coresight-cti.c | 748 +++++++++++ drivers/hwtracing/coresight/coresight-cti.h | 235 ++++ .../hwtracing/coresight/coresight-platform.c | 21 + drivers/hwtracing/coresight/coresight-priv.h | 15 + drivers/hwtracing/coresight/coresight.c | 86 +- include/dt-bindings/arm/coresight-cti-dt.h | 37 + include/linux/coresight.h | 27 + 24 files changed, 4102 insertions(+), 31 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-cti create mode 100644 Documentation/devicetree/bindings/arm/coresight-cti.yaml create mode 100644 Documentation/trace/coresight/coresight-ect.rst 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.17.1

5 years

perf-record: failed to set sink (Linux 5.5, possible regression)

by Wojciech Żmuda

Hello, I've found an issue that I believe is regression in the user space part of perf. I'm trying to use CoreSight with Linux 5.5.0-rc7 with perf application built from the same source. Previously, I have been using 5.1-rc4 for a couple of months successfully. The platform I use is Xilinx Zynq Ultrascale+, but I believe is not related to the problem. I managed to find a hacky way to fix the issue, but I don't fully understand the nature of the problem, so I decided to share my findings here with hope I can gain more knowledge or attract attention of somebody who already knows how to fix it. I've noticed it's not possible to start tracing session with perf-record anymore: root@zynq:/# /linux/tools/perf/perf record -e cs_etm/@tmc_etf0/u --per-thread true failed to set sink "" on event cs_etm/@tmc_etf0/u with 21 (Is a directory) Sink tmc_etf0 is present in the system.: root@zynq:/# ls -l /sys/bus/event_source/devices/cs_etm/sinks/ total 0 -r--r--r-- 1 root root 4096 Jan 27 14:31 tmc_etf0 -r--r--r-- 1 root root 4096 Jan 27 17:00 tmc_etf1 -r--r--r-- 1 root root 4096 Jan 27 13:24 tmc_etr0 -r--r--r-- 1 root root 4096 Jan 27 17:00 tpiu0 Regardless the sink string I provide, the error is always the same, always with the empty quote and "Is a directory" errno: root@zynq:/# /linux/tools/perf/perf record -e cs_etm/@this_obviously_does_not_exist/u --per-thread true failed to set sink "" on event cs_etm/@this_obviously_does_not_exist/u with 21 (Is a directory) I discovered that the error is generated by this function in tools/perf/arch/arm/util/cs-etm.c: static int cs_etm_set_sink_attr(struct perf_pmu *pmu, struct evsel *evsel) { char msg[BUFSIZ], path[PATH_MAX], *sink; struct perf_evsel_config_term *term; int ret = -EINVAL; u32 hash; if (evsel->core.attr.config2 & GENMASK(31, 0)) return 0; list_for_each_entry(term, &evsel->config_terms, list) { if (term->type != PERF_EVSEL__CONFIG_TERM_DRV_CFG) continue; sink = term->val.drv_cfg; snprintf(path, PATH_MAX, "sinks/%s", sink); ret = perf_pmu__scan_file(pmu, path, "%x", &hash); if (ret != 1) { pr_err("failed to set sink \"%s\" on event %s with %d (%s)\n", sink, perf_evsel__name(evsel), errno, str_error_r(errno, msg, sizeof(msg))); return ret; } evsel->core.attr.config2 |= hash; return 0; } The problem occurs because perf_pmu__scan_file() cannot open the file path built by snprintf(). Specifically, char* sink points to an empty string, resulting in sink path leading to the sinks/ directory in sysfs, skipping the file name of the sink. With git-bisect I narrowed the case down to the specific commit that might have introduced the problem: commit 1dc925568f015edfdbb89e20ad41755bb70538b9 Author: Ian Rogers <irogers(a)google.com> Date: Wed Oct 30 15:34:47 2019 -0700 perf parse: Add a deep delete for parse event terms Add a parse_events_term deep delete function so that owned strings and arrays are freed. After I revert this commit, tracing works properly. What the commit does, is to improve memory freeing of perf configuration. Specifically, it adds the following function that frees strings associated with specific config terms: +void parse_events_term__delete(struct parse_events_term *term) +{ + if (term->array.nr_ranges) + zfree(&term->array.ranges); + + if (term->type_val != PARSE_EVENTS__TERM_TYPE_NUM) + zfree(&term->val.str); + + zfree(&term->config); + free(term); +} Since the zfree(&term->val.str) part didn't exist prior to this commit, the cs_etm_set_sink_attr() function quoted above was able to determine proper sink file in sysfs. However, I analyzed the code further and I see nothing wrong with this part, as there is no other part that frees the string allocated memory. I believe then, that this commit revealed the already existing problem, rather than introduced it. I also noticed, that, before the CoreSight-specific code is looking for the sysfs sink file, terms objectsare duplicated along with their associated strings (in pmu.c:perf_pmu__check_alias()). I failed to understand what is the purpose of this behavior, however at later stage, still before CS-specific part, both the original lists of terms, the original and the duplicated one, are freed by this snippet in parse-events.y: parse_events_terms__delete($2); parse_events_terms__delete(orig_terms); free($1); $$ = list; #undef CLEANUP_YYABORT By analyzing pointers in gdb, I determined that the first parse_events_terms__delete() in this snippet frees the structure that is later retrieved by cs_etm_set_sink_attr(). In fact, instead of reverting the previously mentioned commit, removing the `parse_events_terms__delete($2);` makes perf-record work again. This line was introduced by: commit 4a35a9027f64d588d2fd9436dda4126e8d5647d7 Author: Arnaldo Carvalho de Melo <acme(a)redhat.com> Date: Mon May 7 15:27:01 2018 -0300 Revert "perf pmu: Fix pmu events parsing rule" At this point I'm not sure what actually is the nature of the problem: 1. It may be a problem with cs_etm_set_sink_attr(), as it shouldn't use the config_term list but obtain the name in a different manner. I investigated this path, but failed to find a smart way to do this other that to parse the string pointer by perf_evsel__name(evsel). 2. It may be a problem with the superfluous free in the parse-events.y file, and the removal of the first _delete() actually solves the issue. 3. The root cause is actually something else and I'm digging in the wrong direction. I'll be grateful for any suggestions that may help to understand and solve this issue. Best regards, Wojciech

5 years

Car Rental software users list

by Megan Jacobs

Hi, We have newly updated "Car Rental Software" Users Contact Database you can use for pipeline your sales and marketing campaign. Would you be interested to acquire this list? Than please let me know your targets so that I can get you potential clients with their company name, email address, contact name, website and more information as per your requirement. We can also assist you with similar users list like:- . HQ Rental Software . ASAP Rent . Easy Rent Pro . TSD Rental Please let me know your thoughts for more information and we have special discounted price for this month. Await your response, Best Regards, Megan Jacobs Database Coordinator If you do not wish to receive future emails from us, please reply as 'unsubscribe'

5 years

adding branch tracing and reverse debugging in GDB using Coresight etm traces

by zied guermazi

hiI am progressing in the implementation of the proposal "GDB process record and replay with ARM Coresight" https://lists.linaro.org/pipermail/coresight/2019-July/003021.html so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7). and I can collect the traces from the perf mmapped aux area. For parsing them I needed to gather information about the cpu and etm registers. those are available in the events of type PERF_RECORD_AUXTRACE_INFO in the priv section. priv is a kind of "opaque" data structure where the layout is depending on the perf pmu drivers. the implementation of perf tool gives a good example to follow. I needed also to make a wrapper around opencsd library and again perf was offering a good example to follow. those are good reasons to think about factoring out the functionality of parsing etm traces on linux system in a dedicated library that can be reused by other software, a kind of libcoresightperf.is there any plan or ongoing activities for such a library? Kind RegardsZied Guermazi

5 years

IoT/Artificial Intelligence/Machine Learning Software users

by lynda.moses＠craftinsoft.com

<div dir="ltr">Hi, Good Day I just wanted to know if you would be interested in targeting below IoT/Artificial Intelligence/Machine Learning Software users for your Upcoming Channel Marketing Strategy. We can provide you- Amazon, GE Predix, Siemens MindSphere, Pega, Salesforce, Appzen, Oracle, SAP, IBM, Microsoft and many more. Kindly review and advice or forward this email to the marketing head in your company who are currently working on some requirements. Await your response. Regards Lynda Moses Data Specialist To opt-out reply in subject line.</div>  <a style='display: block; margin: 32px 0 40px 0; padding: 10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid gray; ' href='chrome.google.com/webstore/detail/gsm-mailmerge/fjimadonilpeknihlnnkbgmlmjn…'>powered by GSM. Free mail merge and email marketing software for Gmail.</a>

5 years

RE: Doplatek na úcet c.1 (0093-51332)

by Patrik Šimonek

Dobrý den, kontrolou naší účetní evidence jsme zjistili, že jste nám dosud neuhradili dlužnou částku ve výši 8.340,- Kč. V opačném případě budu nucen/a obrátit se se svým nárokem na soud s návrhem na vydání platebního rozkazu. Věřím však, že to nebude nutné. S pozdravem, Patrik Šimonek advokat/attorney at law Opatovicka 1658/4, Praha 1

5 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight January 2020