CoreSight

coresight@lists.linaro.org

4 participants
2646 discussions

Re: Reading and Decoding Data From ETB Buffer

by Mathieu Poirier

Adding the coresight mailing list On Tue, 12 Jan 2021 at 04:17, Ajay Bharadwaj <ajayrbharadwaj(a)gmail.com> wrote: > > Hi, > > I'm working on enabling STM and ETB support on Texas Instruments' platforms. > > Currently, I can write directly to the STM device in sysfs and read back > the encoded data from the ETB's buffer. I am using the Trace Packet > Lister (trc_pkt_lister) from Linaro's OpenCSD [1] to decode the data > obtained from the ETB. The decoded data matches what was written to the > STM (Albeit the data is reversed in some cases, this seems to be > expected according to the ARM specification). > > However, when I use the STM Source Console [2] instead of writing > directly to the STM device, I can still read back the encoded data from > the ETB buffer but OpenCSD cannot find any trace data in it. > > Is there any other tool that I can use instead of OpenCSD or am I doing > something wrong? Here are the commands I am running (I've tried using > the p_sys-t STP policy as well with the same result): > > Enabling CoreSight and STM Source Console: > 1. mkdir -p /config > 2. mount -t configfs none /config > 3. mkdir /config/stp-policy/stm0.policy > 4. mkdir /config/stp-policy/stm0.policy/console > 5. echo 1 > /sys/bus/coresight/devices/etb0/enable_sink > 6. echo stm0 > /sys/class/stm_source/console/stm_source_link > > Reading decoded data from ETB buffer: > 1. dd if=/dev/etb0 of=test.bin > > OpenCSD Output: > Trace Packet Lister: CS Decode library testing > ----------------------------------------------- > > ** Library Version : 0.14.4 > > Test Command Line:- > ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir > tests/snapshots/stm_only/ -src_name ETB_1 > > Trace Packet Lister : reading snapshot from path tests/snapshots/stm_only/ > Using ETB_1 as trace source > Trace Packet Lister : Protocol printer STM on Trace ID 0x1 > ID:1 END OF TRACE DATA > Trace Packet Lister : Trace buffer done, processed 16384 bytes. > > [1] > https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/source/trc_pkt_… > [2] Driver: hwtracing/stm/console.c > > Any help or guidance would be much appreciated. > > Regards, > Ajay Bharadwaj

5 years, 1 month

CHARITY WORK

by Majid Al Futtaim

I intend to give you a portion of my wealth as a free-will financial donation to you, Respond to partake. Majid Al Futtaim

5 years, 1 month

[PATCH] perf: cs-etm: update ETM metadata format

by Mike Leach

The current fixed metadata version format (version 0), means that adding metadata parameter items renders files from a previous version of perf unreadable. Per CPU parameters appear in a fixed order, but there is no field to indicate the number of ETM parameters per CPU. This patch updates the per CPU parameter blocks to include a NR_PARAMs value which indicates the number of parameters in the block. The header version is incremented to 1. Fixed ordering is retained, new ETM parameters are added to the end of the list. The reader code is updated to be able to read current version 0 files, For version 1, the reader will read the number of parameters in the per CPU block. This allows the reader to process older or newer files that may have different numbers of parameters than in use at the time perf was built. Signed-off-by: Mike Leach <mike.leach(a)linaro.org> --- tools/perf/arch/arm/util/cs-etm.c | 3 +- tools/perf/util/cs-etm.c | 171 ++++++++++++++++++++++++------ tools/perf/util/cs-etm.h | 22 +++- 3 files changed, 159 insertions(+), 37 deletions(-) diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c index bd446aba64f7..1876cdf146a0 100644 --- a/tools/perf/arch/arm/util/cs-etm.c +++ b/tools/perf/arch/arm/util/cs-etm.c @@ -629,6 +629,7 @@ static void cs_etm_get_metadata(int cpu, u32 *offset, /* Build generic header portion */ info->priv[*offset + CS_ETM_MAGIC] = magic; info->priv[*offset + CS_ETM_CPU] = cpu; + info->priv[*offset + CS_ETM_NR_PARAMS] = increment - CS_ETM_NR_PARAMS - 1; /* Where the next CPU entry should start from */ *offset += increment; } @@ -674,7 +675,7 @@ static int cs_etm_info_fill(struct auxtrace_record *itr, /* First fill out the session header */ info->type = PERF_AUXTRACE_CS_ETM; - info->priv[CS_HEADER_VERSION_0] = 0; + info->priv[CS_HEADER_VERSION_0] = CS_HEADER_CURRENT_VERSION; info->priv[CS_PMU_TYPE_CPUS] = type << 32; info->priv[CS_PMU_TYPE_CPUS] |= nr_cpu; info->priv[CS_ETM_SNAPSHOT] = ptr->snapshot_mode; diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index a2a369e2fbb6..394331aa058a 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -2443,6 +2443,7 @@ static const char * const cs_etm_global_header_fmts[] = { static const char * const cs_etm_priv_fmts[] = { [CS_ETM_MAGIC] = " Magic number %llx\n", [CS_ETM_CPU] = " CPU %lld\n", + [CS_ETM_NR_PARAMS] = " NR_PARAMS %llx\n", [CS_ETM_ETMCR] = " ETMCR %llx\n", [CS_ETM_ETMTRACEIDR] = " ETMTRACEIDR %llx\n", [CS_ETM_ETMCCER] = " ETMCCER %llx\n", @@ -2452,6 +2453,7 @@ static const char * const cs_etm_priv_fmts[] = { static const char * const cs_etmv4_priv_fmts[] = { [CS_ETM_MAGIC] = " Magic number %llx\n", [CS_ETM_CPU] = " CPU %lld\n", + [CS_ETM_NR_PARAMS] = " NR_PARAMS %llx\n", [CS_ETMV4_TRCCONFIGR] = " TRCCONFIGR %llx\n", [CS_ETMV4_TRCTRACEIDR] = " TRCTRACEIDR %llx\n", [CS_ETMV4_TRCIDR0] = " TRCIDR0 %llx\n", @@ -2461,24 +2463,127 @@ static const char * const cs_etmv4_priv_fmts[] = { [CS_ETMV4_TRCAUTHSTATUS] = " TRCAUTHSTATUS %llx\n", }; +static const char * const param_unk_fmt = + " Unknown parameter [%d] %llx\n"; +static const char * const magic_unk_fmt = + " Magic number Unknown %llx\n"; + static void cs_etm__print_auxtrace_info(__u64 *val, int num) { - int i, j, cpu = 0; + int i, j, cpu = 0, version, nr_params; + __u64 magic; + fprintf(stdout, " Reader Header version %llx\n", + (__u64)CS_HEADER_CURRENT_VERSION); for (i = 0; i < CS_HEADER_VERSION_0_MAX; i++) fprintf(stdout, cs_etm_global_header_fmts[i], val[i]); + version = val[0]; for (i = CS_HEADER_VERSION_0_MAX; cpu < num; cpu++) { - if (val[i] == __perf_cs_etmv3_magic) - for (j = 0; j < CS_ETM_PRIV_MAX; j++, i++) - fprintf(stdout, cs_etm_priv_fmts[j], val[i]); - else if (val[i] == __perf_cs_etmv4_magic) - for (j = 0; j < CS_ETMV4_PRIV_MAX; j++, i++) - fprintf(stdout, cs_etmv4_priv_fmts[j], val[i]); - else + /* common header block */ + magic = val[i]; + fprintf(stdout, cs_etm_priv_fmts[0], val[i++]); + fprintf(stdout, cs_etm_priv_fmts[1], val[i++]); + + /* nr param only present in version 1 */ + if (version) { + nr_params = val[i]; + fprintf(stdout, cs_etm_priv_fmts[2], val[i++]); + } + + if (magic == __perf_cs_etmv3_magic) { + /* version 0 - fixed number of params */ + if (!version) + nr_params = CS_ETM_NR_PARAMS_V0; + + /* after common block */ + for (j = 3; j < nr_params + 3; j++, i++) { + /* if newer record - could be excess params */ + if (j >= CS_ETM_PRIV_MAX) + fprintf(stdout, param_unk_fmt, j, val[i]); + else + fprintf(stdout, cs_etm_priv_fmts[j], val[i]); + } + } else if (magic == __perf_cs_etmv4_magic) { + /* version 0 - fixed number of params */ + if (!version) + nr_params = CS_ETMV4_NR_PARAMS_V0; + + /* after common block */ + for (j = 3; j < nr_params + 3; j++, i++) { + /* if newer record - could be excess params */ + if (j >= CS_ETMV4_PRIV_MAX) + fprintf(stdout, param_unk_fmt, j, val[i]); + else + fprintf(stdout, cs_etmv4_priv_fmts[j], val[i]); + } + } else { /* failure.. return */ + fprintf(stdout, magic_unk_fmt, magic); return; + } + } +} + +/* + * Read a single cpu parameter block from the auxtrace_info priv block. + * + * For version 1 there is a per cpu nr_params entry. If we are handling + * version 1 file, then there may be less, the same, or more params + * indicated by this value than the compile time number we understand. + * + * For a version 0 info block, there are a fixed number, and we need to + * fill out the nr_param value in the metadata we create. + */ +static u64 *cs_etm__create_meta_blk(u64 *buff_in, int *buff_in_offset, + int out_blk_size, int nr_params_v0) +{ + u64 *metadata = NULL; + int hdr_version; + int nr_in_params, nr_out_params, nr_cmn_params; + int i, k; + + metadata = zalloc(sizeof(*metadata) * out_blk_size); + if (!metadata) + return NULL; + + /* read block current index & version */ + i = *buff_in_offset; + hdr_version = buff_in[CS_HEADER_VERSION_0]; + + if (!hdr_version) { + /* read version 0 info block into a version 1 metadata block */ + nr_in_params = nr_params_v0; + metadata[CS_ETM_MAGIC] = buff_in[i + CS_ETM_MAGIC]; + metadata[CS_ETM_CPU] = buff_in[i + CS_ETM_CPU]; + metadata[CS_ETM_NR_PARAMS] = nr_in_params; + /* remaining block params at offset +1 from source */ + for (k = 2; k < nr_in_params; k++) + metadata[k+1] = buff_in[i + k]; + /* version 0 has 2 common params */ + nr_cmn_params = 2; + } else { + /* read version 1 info block - input and output nr_params may differ */ + /* version 1 has 3 common params */ + nr_cmn_params = 3; + nr_in_params = buff_in[i + CS_ETM_NR_PARAMS]; + + /* if input has more params than output - skip excess */ + nr_out_params = nr_in_params + nr_cmn_params; + if (nr_out_params > out_blk_size) + nr_out_params = out_blk_size; + + for (k = 0; k < nr_out_params; k++) + metadata[k] = buff_in[i + k]; + + /* record the actual nr params we copied */ + metadata[CS_ETM_NR_PARAMS] = nr_out_params - nr_cmn_params; } + + /* adjust in offset by number of in params used */ + i += nr_in_params + nr_cmn_params; + *buff_in_offset = i; + return metadata; } int cs_etm__process_auxtrace_info(union perf_event *event, @@ -2492,11 +2597,12 @@ int cs_etm__process_auxtrace_info(union perf_event *event, int info_header_size; int total_size = auxtrace_info->header.size; int priv_size = 0; - int num_cpu; - int err = 0, idx = -1; - int i, j, k; + int num_cpu, trcidr_idx; + int err = 0; + int i, j; u64 *ptr, *hdr = NULL; u64 **metadata = NULL; + u64 hdr_version; /* * sizeof(auxtrace_info_event::type) + @@ -2512,8 +2618,9 @@ int cs_etm__process_auxtrace_info(union perf_event *event, /* First the global part */ ptr = (u64 *) auxtrace_info->priv; - /* Look for version '0' of the header */ - if (ptr[0] != 0) + /* Look for version of the header */ + hdr_version = ptr[0]; + if (hdr_version > CS_HEADER_CURRENT_VERSION) return -EINVAL; hdr = zalloc(sizeof(*hdr) * CS_HEADER_VERSION_0_MAX); @@ -2552,35 +2659,31 @@ int cs_etm__process_auxtrace_info(union perf_event *event, */ for (j = 0; j < num_cpu; j++) { if (ptr[i] == __perf_cs_etmv3_magic) { - metadata[j] = zalloc(sizeof(*metadata[j]) * - CS_ETM_PRIV_MAX); - if (!metadata[j]) { - err = -ENOMEM; - goto err_free_metadata; - } - for (k = 0; k < CS_ETM_PRIV_MAX; k++) - metadata[j][k] = ptr[i + k]; + metadata[j] = + cs_etm__create_meta_blk(ptr, &i, + CS_ETM_PRIV_MAX, + CS_ETM_NR_PARAMS_V0); /* The traceID is our handle */ - idx = metadata[j][CS_ETM_ETMTRACEIDR]; - i += CS_ETM_PRIV_MAX; + trcidr_idx = CS_ETM_ETMTRACEIDR; + } else if (ptr[i] == __perf_cs_etmv4_magic) { - metadata[j] = zalloc(sizeof(*metadata[j]) * - CS_ETMV4_PRIV_MAX); - if (!metadata[j]) { - err = -ENOMEM; - goto err_free_metadata; - } - for (k = 0; k < CS_ETMV4_PRIV_MAX; k++) - metadata[j][k] = ptr[i + k]; + metadata[j] = + cs_etm__create_meta_blk(ptr, &i, + CS_ETMV4_PRIV_MAX, + CS_ETMV4_NR_PARAMS_V0); /* The traceID is our handle */ - idx = metadata[j][CS_ETMV4_TRCTRACEIDR]; - i += CS_ETMV4_PRIV_MAX; + trcidr_idx = CS_ETMV4_TRCTRACEIDR; + } + + if (!metadata[j]) { + err = -ENOMEM; + goto err_free_metadata; } /* Get an RB node for this CPU */ - inode = intlist__findnew(traceid_list, idx); + inode = intlist__findnew(traceid_list, metadata[j][trcidr_idx]); /* Something went wrong, no need to continue */ if (!inode) { diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h index 4ad925d6d799..fffc6b50beb9 100644 --- a/tools/perf/util/cs-etm.h +++ b/tools/perf/util/cs-etm.h @@ -24,16 +24,28 @@ enum { CS_HEADER_VERSION_0_MAX, }; +/* + * Update the version for new format. + * + * New version 1 format adds a param count to the per cpu metadata. + * This allows easy adding of new metadata parameters. + * Requires that new params always added after current ones. + * Also allows client reader to handle file versions that are different by + * checking the number of params in the file vs the number expected. + */ +#define CS_HEADER_CURRENT_VERSION 1 + /* Beginning of header common to both ETMv3 and V4 */ enum { CS_ETM_MAGIC, CS_ETM_CPU, + CS_ETM_NR_PARAMS, }; /* ETMv3/PTM metadata */ enum { /* Dynamic, configurable parameters */ - CS_ETM_ETMCR = CS_ETM_CPU + 1, + CS_ETM_ETMCR = CS_ETM_NR_PARAMS + 1, CS_ETM_ETMTRACEIDR, /* RO, taken from sysFS */ CS_ETM_ETMCCER, @@ -41,10 +53,13 @@ enum { CS_ETM_PRIV_MAX, }; +/* define fixed version 0 length - allow new format reader to read old files. */ +#define CS_ETM_NR_PARAMS_V0 (CS_ETM_ETMIDR - CS_ETM_ETMCR + 1) + /* ETMv4 metadata */ enum { /* Dynamic, configurable parameters */ - CS_ETMV4_TRCCONFIGR = CS_ETM_CPU + 1, + CS_ETMV4_TRCCONFIGR = CS_ETM_NR_PARAMS + 1, CS_ETMV4_TRCTRACEIDR, /* RO, taken from sysFS */ CS_ETMV4_TRCIDR0, @@ -55,6 +70,9 @@ enum { CS_ETMV4_PRIV_MAX, }; +/* define fixed version 0 length - allow new format reader to read old files. */ +#define CS_ETMV4_NR_PARAMS_V0 (CS_ETMV4_TRCAUTHSTATUS - CS_ETMV4_TRCCONFIGR + 1) + /* * ETMv3 exception encoding number: * See Embedded Trace Macrocell spcification (ARM IHI 0014Q) -- 2.17.1

5 years, 1 month

Invitation to Information Security and Data Management training Feb 2021

by FDC Training

5 years, 1 month

Private Label (Clothing)

by Ashley Rosa

Hello, Who can I speak to about branding and custom apparel for your brand? One of the largest custom clothing manufacturer, our office is in London, Sydney, HQ in Beverly Hills, California. We currently work with some top brands and companies worldwide and would love to discuss your branding and custom clothing with you. If you can direct me in the right direction, I would truly appreciate that, as we are factory direct and can save you 30% cost on your bills. Items we manufacture: - T-Shirts - Hoodies - Jackets - Activewear - Towels - Bags, clutches, and pouches - Hats - Promotional items - Custom Cotton Masks - Sublimated Apparel - Sports Uniform We are very creative, innovative, and offer you a full design team and direct factory. We will do everything right, and provide amazing quality at competitive prices which can be very effective for your brand development and growth. Let me know if you have a moment to discuss this. I can also get some designs done for you. Our MOQ is 500 pcs per style, multiple sizes. Let me know your thoughts Thanks, -- The Dioz Group of Companies. HQ: Beverly Hills, California Corporate offices in Australia and U.K Phone: 310 800 6438 Website: oasisapparel.com <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/d?c=10608409&l=fa…> You may unsubscribe <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/u?u=20891784-6ed9…> to stop receiving our emails.

5 years, 1 month

OpenCSD v1.0.0 release.

by Mike Leach

The latest version of OpenCSD has been released. This v1.0.0 release adds in support for ETE - an extended trace protocol, used by ARM PEs that have the FEAT_ETE architectural feature. (See ARM future architecture docs). The documentation 'man' file is added in this release. This release also adds a fix for github issue #33. Note: the protocol update results in additional output packet types, This requires an update to the perf cs-etm-decoder code to handle new enum values, and the makefile to ensure that perf builds with 1.0.0 using this extension. The patch for this can be seen here:- https://lists.linaro.org/pipermail/coresight/2021-January/005496.html Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

5 years, 1 month

[PATCH] coresight: etm-perf: Add support for PID tracing for kernel at EL2

by Suzuki K Poulose

When the kernel is running at EL2, the PID is stored in CONTEXTIDR_EL2. So, tracing CONTEXTIDR_EL1 doesn't give us the pid of the process. Thus we should trace the VMID with VMIDOPT set to trace CONTEXTIDR_EL2 instead of VMID. Given that we have an existing config option "contextid" and this will be useful for tracing virtual machines (when we get to support virtualization). So instead, this patch adds a new option, contextid_in_vmid as a separate config. Thus on an EL2 kernel, we will have two options available for the perf tool. However, to make it easier for the user to do pid tracing, we add a new format which will default to "contextid" (on EL1 kernel) or "contextid_in_vmid" (on EL2 kernel). So that the user doesn't have to bother which EL the kernel is running. i.e, perf record -e cs_etm/pid/u -- will always do the "pid" tracing, independent of the kernel EL. Also, the perf tool will be updated to automatically select "pid" config instead of the "contextid" for system wide/CPU wide mode. Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Al Grant <al.grant(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> --- Changes since previous version: - Fix build break on 32bit kernel (kernel test robot <lkp(a)intel.com>) --- .../hwtracing/coresight/coresight-etm-perf.c | 18 ++++++++++++++++++ .../hwtracing/coresight/coresight-etm4x-core.c | 9 +++++++++ include/linux/coresight-pmu.h | 11 +++++++---- 3 files changed, 34 insertions(+), 4 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c index bdc34ca449f7..f13c3a7bbc84 100644 --- a/drivers/hwtracing/coresight/coresight-etm-perf.c +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c @@ -30,14 +30,32 @@ static DEFINE_PER_CPU(struct coresight_device *, csdev_src); /* ETMv3.5/PTM's ETMCR is 'config' */ PMU_FORMAT_ATTR(cycacc, "config:" __stringify(ETM_OPT_CYCACC)); PMU_FORMAT_ATTR(contextid, "config:" __stringify(ETM_OPT_CTXTID)); +PMU_FORMAT_ATTR(contextid_in_vmid, "config:" __stringify(ETM_OPT_CTXTID_IN_VMID)); PMU_FORMAT_ATTR(timestamp, "config:" __stringify(ETM_OPT_TS)); PMU_FORMAT_ATTR(retstack, "config:" __stringify(ETM_OPT_RETSTK)); /* Sink ID - same for all ETMs */ PMU_FORMAT_ATTR(sinkid, "config2:0-31"); +static ssize_t format_attr_pid_show(struct device *dev, + struct device_attribute *attr, + char *page) +{ + int pid_fmt = ETM_OPT_CTXTID; + +#ifdef CONFIG_CORESIGHT_SOURCE_ETM4X + if (is_kernel_in_hyp_mode()) + pid_fmt = ETM_OPT_CTXTID_IN_VMID; +#endif + return sprintf(page, "config:%d\n", pid_fmt); +} + +struct device_attribute format_attr_pid = __ATTR(pid, 0444, format_attr_pid_show, NULL); + static struct attribute *etm_config_formats_attr[] = { &format_attr_cycacc.attr, &format_attr_contextid.attr, + &format_attr_contextid_in_vmid.attr, + &format_attr_pid.attr, &format_attr_timestamp.attr, &format_attr_retstack.attr, &format_attr_sinkid.attr, diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index b20b6ff17cf6..8b7c7a8b2874 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -477,6 +477,15 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata, /* bit[6], Context ID tracing bit */ config->cfg |= BIT(ETM4_CFG_BIT_CTXTID); + /* Do not enable VMID tracing if we are not running in EL2 */ + if (attr->config & BIT(ETM_OPT_CTXTID_IN_VMID)) { + if (!is_kernel_in_hyp_mode()) { + ret = -EINVAL; + goto out; + } + config->cfg |= BIT(ETM4_CFG_BIT_VMID) | BIT(ETM4_CFG_BIT_VMID_OPT); + } + /* return stack - enable if selected and supported */ if ((attr->config & BIT(ETM_OPT_RETSTK)) && drvdata->retstack) /* bit[12], Return stack enable bit */ diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h index b0e35eec6499..927c6285ce5d 100644 --- a/include/linux/coresight-pmu.h +++ b/include/linux/coresight-pmu.h @@ -11,16 +11,19 @@ #define CORESIGHT_ETM_PMU_SEED 0x10 /* ETMv3.5/PTM's ETMCR config bit */ -#define ETM_OPT_CYCACC 12 -#define ETM_OPT_CTXTID 14 -#define ETM_OPT_TS 28 -#define ETM_OPT_RETSTK 29 +#define ETM_OPT_CYCACC 12 +#define ETM_OPT_CTXTID 14 +#define ETM_OPT_CTXTID_IN_VMID 15 +#define ETM_OPT_TS 28 +#define ETM_OPT_RETSTK 29 /* ETMv4 CONFIGR programming bits for the ETM OPTs */ #define ETM4_CFG_BIT_CYCACC 4 #define ETM4_CFG_BIT_CTXTID 6 +#define ETM4_CFG_BIT_VMID 7 #define ETM4_CFG_BIT_TS 11 #define ETM4_CFG_BIT_RETSTK 12 +#define ETM4_CFG_BIT_VMID_OPT 15 static inline int coresight_get_trace_id(int cpu) { -- 2.24.1

5 years, 1 month

[PATCH v6 00/26] coresight: etm4x: Support for system instructions

by Suzuki K Poulose

CoreSight ETMv4.4 obsoletes memory mapped access to ETM and mandates the system instructions for registers. This also implies that they may not be on the amba bus. Right now all the CoreSight components are accessed via memory map. Also, we have some common routines in coresight generic code driver (e.g, CS_LOCK, claim/disclaim), which assume the mmio. In order to preserve the generic algorithms at a single place and to allow dynamic switch for ETMs, this series introduces an abstraction layer for accessing a coresight device. It is designed such that the mmio access are fast tracked (i.e, without an indirect function call). This will also help us to get rid of the driver+attribute specific sysfs show/store routines and replace them with a single routine to access a given register offset (which can be embedded in the dev_ext_attribute). This is not currently implemented in the series, but can be achieved. Further we switch the generic routines to work with the abstraction. With this in place, we refactor the etm4x code a bit to allow for supporting the system instructions with very little new code. We use TRCDEVARCH for the detection of the ETM component, which is a standard register as per CoreSight architecture, rather than the etm specific id register TRCIDR1. This is for making sure that we are able to detect the ETM via system instructions accurately, when the the trace unit could be anything (etm or a custom trace unit). To keep the backward compatibility for any existing broken impelementation which may not implement TRCDEVARCH, we fall back to TRCIDR1. Also this covers us for the changes in the future architecture [0]. Also, v8.4 self-hosted tracing extensions (coupled with ETMv4.4) adds new filtering registers for trace by exception level. So on a v8.4 system, with Trace Filtering support, without the appropriate programming of the Trace filter registers (TRFCR_ELx), tracing will not be enabled. This series also includes the TraceFiltering support to cover the ETM-v4.4 support. The series has been mildly tested on a model for system instructions. I would really appreciate any testing on real hardware. Applies on coresight/next. A tree is available here [1]. [0] https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers/trcidr1 [1] https://gitlab.arm.com/linux-arm/linux-skp coresight/etm/sysreg-v6 Changes since v5: - Rebased on to coresight/next. - Moved trcdevarch to mgmt/ in sysfs and updated the sysfs ABI document (Mike Leach) - New patch : Moved the etm4_check_arch_features to run on the CPU, since the PID of the ETM has to be read on the CPU and is unavailable otherwise. Changes since v4: - Fix typo in commit description for the patches 02 & 15 - Refactor the AMBA device "remove" call back for use with paltform_driver. (patch 21). Thus remove Review tag by Mathieu, even though the changes are minimal. - Added "remove" callback for platform_driver in patch 22, removed Review tag by Mathieu - Add 'U' suffix for constants in Patch 24 (Catalin) - Fixed field extraction in Patch 25 Changes since v3: - Device tree compatible changed to etm4x - Use etm4x_** instead of generalizing etm_ in etm4x driver. - Added v8.4 self hosted trace support patches, reworked from Jonathan's series. - Dropped queued patches. - Expose TRCDEVARCH via trcidr, as this will be needed for the userspace tools to determine the trace major/minor arch versions. - Remove csa argument to read()/write() (Mathieu) - Fix secure exception mask calculation (Mathieu) - Fix various coding style comments (Mathieu) (See individual patches for change log) Changes since V2: - Several fixes to the ETM register accesses. Access a register when it is present. - Add support for TRCIDR3.NUMPROCS for v4.2+ - Drop OS lock detection. Use software lock only in case of mmio. - Fix issues with the Exception level masks (Mike Leach) - Fall back to using TRCIDR1 when TRCDEVARCH is not "present" - Use a generic notion of ETM architecture (rather than using the encoding as in registers) - Fixed some checkpatch issues. - Changed the dts compatible string to "arm,coresight-etm-sysreg" (Mike Leach) Changes since V1: - Flip the switch for iomem from no_iomem to io_mem in csdev_access. - Split patches for claim/disclaim and CS_LOCK/UNLOCK conversions. - Move device access initialisation for etm4x to the target CPU - Cleanup secure exception level mask handling. - Switch to use TRCDEVARCH for ETM component discovery. This is for making - Check the availability of OS/Software Locks before using them. Known issues: Checkpatch failure for "coresight: etm4x: Add sysreg access helpers" : ERROR: Macros with complex values should be enclosed in parentheses #121: FILE: drivers/hwtracing/coresight/coresight-etm4x.h:153: +#define CASE_READ(res, x) \ + case (x): { (res) = read_etm4x_sysreg_const_offset((x)); break; } I don't know a way to fix the warning without loosing the code readability, which I believe is crucial for such a construct. Jonathan Zhou (2): arm64: Add TRFCR_ELx definitions coresight: Add support for v8.4 SelfHosted tracing Suzuki K Poulose (24): coresight: etm4x: Handle access to TRCSSPCICRn coresight: etm4x: Skip accessing TRCPDCR in save/restore coresight: Introduce device access abstraction coresight: tpiu: Prepare for using coresight device access abstraction coresight: Convert coresight_timeout to use access abstraction coresight: Convert claim/disclaim operations to use access wrappers coresight: etm4x: Always read the registers on the host CPU coresight: etm4x: Convert all register accesses coresight: etm4x: Add commentary on the registers coresight: etm4x: Add sysreg access helpers coresight: etm4x: Define DEVARCH register fields coresight: etm4x: Check for Software Lock coresight: etm4x: Cleanup secure exception level masks coresight: etm4x: Clean up exception level masks coresight: etm4x: Handle ETM architecture version coresight: etm4x: Detect access early on the target CPU coresight: etm4x: Use TRCDEVARCH for component discovery coresight: etm4x: Expose trcdevarch via sysfs coresight: etm4x: Add necessary synchronization for sysreg access coresight: etm4x: Detect system instructions support coresight: etm4x: Refactor probing routine coresight: etm4x: Run arch feature detection on the CPU coresight: etm4x: Add support for sysreg only devices dts: bindings: coresight: ETM system register access only units .../testing/sysfs-bus-coresight-devices-etm4x | 8 + .../devicetree/bindings/arm/coresight.txt | 5 +- arch/arm64/include/asm/sysreg.h | 11 + drivers/hwtracing/coresight/coresight-catu.c | 12 +- drivers/hwtracing/coresight/coresight-core.c | 122 ++- .../hwtracing/coresight/coresight-cti-core.c | 18 +- drivers/hwtracing/coresight/coresight-etb10.c | 10 +- .../coresight/coresight-etm3x-core.c | 9 +- .../coresight/coresight-etm4x-core.c | 805 ++++++++++++------ .../coresight/coresight-etm4x-sysfs.c | 46 +- drivers/hwtracing/coresight/coresight-etm4x.h | 498 ++++++++++- .../hwtracing/coresight/coresight-funnel.c | 7 +- .../coresight/coresight-replicator.c | 13 +- drivers/hwtracing/coresight/coresight-stm.c | 4 +- .../hwtracing/coresight/coresight-tmc-core.c | 16 +- .../hwtracing/coresight/coresight-tmc-etf.c | 10 +- .../hwtracing/coresight/coresight-tmc-etr.c | 4 +- drivers/hwtracing/coresight/coresight-tpiu.c | 31 +- include/linux/coresight.h | 225 ++++- 19 files changed, 1423 insertions(+), 431 deletions(-) -- 2.24.1

5 years, 2 months

[PATCH 00/11] arm64: coresight: Enable ETE and TRBE

by Anshuman Khandual

This series enables future IP trace features Embedded Trace Extension (ETE) and Trace Buffer Extension (TRBE). This series depends on the ETM system register instruction support series [0] which is available here [1]. This series which applies on [1] is avaialble here [2] for quick access. 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. Things todo: - Improve TRBE IRQ handling for all possible corner cases - Implement sysfs based trace sessions [0] https://lore.kernel.org/linux-arm-kernel/20201214173731.302520-1-suzuki.pou… [1] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/etm/sysreg-v5 [2] https://gitlab.arm.com/linux-arm/linux-anshuman/-/tree/coresight/ete_trbe_v1 Changes in V1: - 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 Changes in RFC: https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-… 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: etm-perf: Truncate the perf record if handle has no space coresight: sink: Add TRBE driver dts: bindings: Document device tree binding for Arm TRBE Suzuki K Poulose (6): 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 Documentation/devicetree/bindings/arm/ete.txt | 41 + Documentation/devicetree/bindings/arm/trbe.txt | 20 + Documentation/trace/coresight/coresight-trbe.rst | 39 + arch/arm64/include/asm/sysreg.h | 51 ++ drivers/hwtracing/coresight/Kconfig | 11 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 14 + drivers/hwtracing/coresight/coresight-etm-perf.c | 51 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 138 ++- drivers/hwtracing/coresight/coresight-etm4x.h | 64 +- drivers/hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-trbe.c | 925 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 248 ++++++ include/linux/coresight.h | 12 + 14 files changed, 1580 insertions(+), 41 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/ete.txt create mode 100644 Documentation/devicetree/bindings/arm/trbe.txt 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.7.4

5 years, 2 months

Calendario de Cursos Bonificables 2021

by FOESCO

Buenos días Os informamos desde FOESCO (Formación Estatal Continua) que nos encontramos organizando el Calendario de Cursos Bonificables 2021 para empleados en activo o en ERTE. Rogamos respondáis a este mismo correo electrónico eligiendo una de las opciones que a continuación indicamos: 1 - Precisamos información para la PRESENTE convocatoria ENERO 2021 2 - Precisamos información para el mes de .......... (Indicar mes) 3 - No precisamos ninguna información BAJA Quedamos a la espera de vuestra respuesta. Un cordial saludo. Alex Pons. Director FOESCO. FOESCO Formación Estatal Continua e-mail: cursos(a)foesco.net Tel.: 91 032 37 94 (Horario de 9h a 14h y de 16:30h a 21h de Lunes a Viernes) FOESCO ofrece formación a empresas y trabajadores en activo a través de cursos bonificables por la Fundación Estatal para la Formación en el Empleo (antiguo FORCEM) que gestiona las acciones formativas de FORMACIÓN CONTINUA para trabajadores y se rige por la ley 30/2015 de 9 de Septiembre. Antes de imprimir este e-mail piense bien si es necesario hacerlo. Before printing this e-mail please think twice if you really need it. FOESCO Tfno: 910 382 880 Email: cursos(a)foesco.com. La información transmitida en este mensaje está dirigida solamente a las personas o entidades que figuran en el encabezamiento y contiene información confidencial, por lo que, si usted lo recibiera por error, por favor destrúyalo sin copiarlo, usarlo ni distribuirlo, comunicándolo inmediatamente al emisor del mensaje. De conformidad con lo dispuesto en el Reglamento Europeo del 2016/679, del 27 de Abril de 2016, FOESCO le informa que los datos por usted suministrados serán tratados con las medidas de seguridad conformes a la normativa vigente que se requiere. Dichos datos serán empleados con fines de gestión. Para el ejercicio de sus derechos de transparencia, información, acceso, rectificación, supresión o derecho al olvido, limitación del tratamiento , portabilidad de datos y oposición de sus datos de carácter personal deberá dirigirse a la dirección del Responsable del tratamiento a C/ LAGUNA DEL MARQUESADO Nº10, 28021, MADRID, "PULSANDO AQUI" <mailto:bajas@foesco.com?Subject=BAJA%20CORREOS> y "ENVIAR" o a traves de la dirección de correo electrónico: bajas(a)foesco.com <mailto:bajas@foesco.com?Subject=BAJA%20CORREOS>

5 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight