CoreSight

coresight@lists.linaro.org

7 participants
2372 discussions

Re: [PATCH v3 1/2] dt-bindings: arm: Add qcom,qmi-id for remote etm

by Jinlong Mao

On 2024/8/23 15:39, Krzysztof Kozlowski wrote: > On Fri, Aug 23, 2024 at 03:16:07PM +0800, Jinlong Mao wrote: >> >> >> On 2024/8/22 15:41, Krzysztof Kozlowski wrote: >>> On Wed, Aug 21, 2024 at 11:41:18PM -0700, Mao Jinlong wrote: >>>> qcom,qmi-id is the instance id used by qmi API to communicate with >>>> remote processor. >>>> >>>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >>>> --- >>>> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >>>> index 4fd5752978cd..27e5f18bfedf 100644 >>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >>>> @@ -20,6 +20,13 @@ properties: >>>> compatible: >>>> const: qcom,coresight-remote-etm >>>> + qcom,qmi-id: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + This id is used by qmi API to communicate with remote processor for >>>> + enabling and disabling remote etm. Each processor has its unique instance >>>> + id. >>>> + >>>> out-ports: >>>> $ref: /schemas/graph.yaml#/properties/ports >>>> additionalProperties: false >>>> @@ -31,6 +38,7 @@ properties: >>>> required: >>>> - compatible >>>> + - qcom,qmi-id >>> >>> That's an ABI break. >>> >>> Best regards, >>> Krzysztof >> Hi Krzysztof, >> >> Sorry, I didn't get your point. >> Could you please share more details ? > > Adding new required properties is an ABI break. Nothing in commit msg > explained why this is okay or even needed. > > Best regards, > Krzysztof Thank you. I will update in the commit msg. >

10 months

Re: [PATCH v3 1/2] dt-bindings: arm: Add qcom,qmi-id for remote etm

by Jinlong Mao

On 2024/8/22 15:41, Krzysztof Kozlowski wrote: > On Wed, Aug 21, 2024 at 11:41:18PM -0700, Mao Jinlong wrote: >> qcom,qmi-id is the instance id used by qmi API to communicate with >> remote processor. >> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> index 4fd5752978cd..27e5f18bfedf 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml >> @@ -20,6 +20,13 @@ properties: >> compatible: >> const: qcom,coresight-remote-etm >> >> + qcom,qmi-id: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + This id is used by qmi API to communicate with remote processor for >> + enabling and disabling remote etm. Each processor has its unique instance >> + id. >> + >> out-ports: >> $ref: /schemas/graph.yaml#/properties/ports >> additionalProperties: false >> @@ -31,6 +38,7 @@ properties: >> >> required: >> - compatible >> + - qcom,qmi-id > > That's an ABI break. > > Best regards, > Krzysztof Hi Krzysztof, Sorry, I didn't get your point. Could you please share more details ? Thanks Jinlong Mao > >

10 months

[PATCH v3 0/3] source filtering for multi-port output

by Tao Zhang

In our hardware design, by combining a funnel and a replicator, it implement a hardware device with one-to-one correspondence between output ports and input ports. The programming usage on this device is the same as funnel. The software uses a funnel and a static replicator to implement the driver of this device. Since original funnels only support a single output connection and original replicator only support a single input connection, the code needs to be modified to support this new feature. The following is a typical topology diagram of multi-port output mechanism. |----------| |---------| |----------| |---------| | TPDM 0 | | Source0 | | Source 1 | | TPDM 1 | |----------| |---------| |----------| |---------| | | | | | | | | | --------- | | | | | | | | | | | | | | | \-------------/ ---------------------- | \ Funnel 0 / | | ----------- | ------------------------------ | | | | | | \------------------/ \ Funnel 1 / ----| \--------------/ | | |----> Combine a funnel and a | | static replicator /-----------------\ | / replicator 0 \ ----| /---------------------\ | | | | | |-----------| | |---------| | | |TPDM0 |TPDM1 | \-----------------/ | \ TPDA 0 / | \-------------/ | | | | |Source0/1 | \-------------------------------/ \ Funnel 2 / \---------------------------/ Changes in V3: 1. Rename the function "coresight_source_filter" to "coresight_block_source". And refine this function. -- Suzuki K Poulose 2. Rename the parameters of the function "coresight_find_out_connection" to avoid confusion. -- Suzuki K Poulose 3. Get the source of path in "coresight_enable_path" and "coresight_disable_path". -- Suzuki K Poulose 4. Fix filter source device before skip the port in "coresight_orphan_match". -- Suzuki K Poulose 5. Make sure the device still orphan if whter is a filter source firmware node but the filter source device is null. -- Suzuki K Poulose 6. Walk through the entire coresight bus and fixup the "filter_src_dev" if the source is being removed. -- Suzuki K Poulose 7. Refine the commit description of patch#2. -- Suzuki K Poulose 8. Call "fwnode_handle_put" to "drop" the refcount for the device firmware node. -- Suzuki K Poulose 9. Fix the warning reported by kernel test robot. -- kernel test robot. 10. Use the source device directly if the port has a hardcoded filter in "tpda_get_element_size". -- Suzuki K Poulose Changes in V2: 1. Change the reference for endpoint property in dt-binding. -- Krzysztof Kozlowski 2. Change the property name "filter_src" to "filter-src". -- Krzysztof Kozlowski 3. Fix the errors in running 'make dt_binding_check'. -- Rob Herring 4. Pass in the source parameter instead of path. -- Suzuki K Poulose 5. Reset the "filter_src_dev" if the "src" csdev is being removed. -- Suzuki K Poulose 6. Add a warning if the "filter_src_dev" is of not the type DEV_TYPE_SOURCE. -- Suzuki K Poulose 7. Optimize the procedure for handling all possible cases. -- Suzuki K Poulose Changes in V1: 1. Add a static replicator connect to a funnel to implement the correspondence between the output ports and the input ports on funnels. -- Suzuki K Poulose 2. Add filter_src_dev and filter_src_dev phandle to "coresight_connection" struct, and populate them if there is one. -- Suzuki K Poulose 3. To look at the phandle and then fixup/remove the filter_src device in fixup/remove connections. -- Suzuki K Poulose 4. When TPDA reads DSB/CMB element size, it is implemented by looking up filter src device in the connections. -- Suzuki K Poulose Tao Zhang (3): dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering coresight: Add support for trace filtering by source coresight-tpda: Optimize the function of reading element size .../arm/arm,coresight-static-replicator.yaml | 19 ++- drivers/hwtracing/coresight/coresight-core.c | 136 +++++++++++++++--- .../hwtracing/coresight/coresight-platform.c | 18 +++ drivers/hwtracing/coresight/coresight-tpda.c | 11 +- include/linux/coresight.h | 5 + 5 files changed, 164 insertions(+), 25 deletions(-) -- 2.17.1

10 months

Re: [PATCH v3 3/5] dt-bindings: arm: Add Coresight TMC Control Unit hardware

by Suzuki K Poulose

On 22/08/2024 10:55, Krzysztof Kozlowski wrote: > On 20/08/2024 08:36, JieGan wrote: >> On Mon, Aug 19, 2024 at 11:51:41AM +0200, Krzysztof Kozlowski wrote: >>> On 19/08/2024 10:51, JieGan wrote: >>>> On Mon, Aug 19, 2024 at 08:25:33AM +0200, Krzysztof Kozlowski wrote: >>>>> On 19/08/2024 03:49, JieGan wrote: >>>>>> On Sun, Aug 18, 2024 at 08:28:34AM -0600, Rob Herring wrote: >>>>>>> On Mon, Aug 12, 2024 at 10:41:39AM +0800, Jie Gan wrote: >>>>>>>> Add binding file to specify how to define a Coresight TMC >>>>>>>> Control Unit device in device tree. >>>>>>>> >>>>>>>> It is responsible for controlling the data filter function >>>>>>>> based on the source device's Trace ID for TMC ETR device. >>>>>>>> The trace data with that Trace id can get into ETR's buffer >>>>>>>> while other trace data gets ignored. >>>>>>>> >>>>>>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com> >>>>>>>> --- >>>>>>>> .../bindings/arm/qcom,coresight-ctcu.yaml | 79 +++++++++++++++++++ >>>>>>>> 1 file changed, 79 insertions(+) >>>>>>>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..7a9580007942 >>>>>>>> --- /dev/null >>>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>>>>>> @@ -0,0 +1,79 @@ >>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>>>>> +%YAML 1.2 >>>>>>>> +--- >>>>>>>> +$id: http://devicetree.org/schemas/arm/qcom,coresight-ctcu.yaml# >>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>>> + >>>>>>>> +title: CoreSight TMC Control Unit >>>>>>>> + >>>>>>>> +maintainers: >>>>>>>> + - Yuanfang Zhang <quic_yuanfang(a)quicinc.com> >>>>>>>> + - Mao Jinlong <quic_jinlmao(a)quicinc.com> >>>>>>>> + - Jie Gan <quic_jiegan(a)quicinc.com> >>>>>>>> + >>>>>>>> +description: >>>>>>>> + The Coresight TMC Control unit controls various Coresight behaviors. >>>>>>>> + It works as a helper device when connected to TMC ETR device. >>>>>>>> + It is responsible for controlling the data filter function based on >>>>>>>> + the source device's Trace ID for TMC ETR device. The trace data with >>>>>>>> + that Trace id can get into ETR's buffer while other trace data gets >>>>>>>> + ignored. >>>>>>> >>>>>>> Nowhere is TMC defined. >>>>>> The Coresight TMC control unit(CTCU) connected to Coresight TMC device via replicator and >>>>>> works as a helper device to TMC device. >>>>> >>>>> Did you understand the feedback or just responding with whatever to get >>>>> rid of reviewers? >>>> >>>> Sorry for the insufficient clarity in my response, I am just misunderstood the feedback and try >>>> to explain the relationship between TMC and CTCU device. >>>> >>>> I will add the TMC description to explain what TMC is as shown below: >>>> The Trace Memory Controller(TMC) is used for Embedded Trace Buffer(ETB), Embedded Trace FIFO(ETF) >>>> and Embedded Trace Router(ETR) configurations. The configuration mode (ETB, ETF, ETR) is >>>> discovered at boot time when the device is probed. >>> >>> Thanks. >>> >>>> >>>>> >>>>>> >>>>>> The in-ports listed below illustrate their connection to TMC devices. >>>>>> >>>>>>> >>>>>>>> + >>>>>>>> +properties: >>>>>>>> + compatible: >>>>>>>> + enum: >>>>>>>> + - qcom,sa8775p-ctcu >>>>>>>> + >>>>>>>> + reg: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + clocks: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + clock-names: >>>>>>>> + items: >>>>>>>> + - const: apb >>>>>>>> + >>>>>>>> + in-ports: >>>>>>> >>>>>>> Use 'ports' unless you have both in and out ports. >>>>>> The ‘in-ports’ and ‘out-ports’ properties will be parsed by ‘of_coresight_get_port_parent’ >>>>>> and their relationships to other devices will be stored in the coresight_platform_data structure. >>>>>> >>>>>> for example: >>>>>> struct coresight_platform_data { >>>>>> int nr_inconns; >>>>>> int nr_outconns; >>>>>> struct coresight_connection **out_conns; >>>>>> struct coresight_connection **in_conns; >>>>>> }; >>>>>> >>>>>> https://elixir.bootlin.com/linux/v6.11-rc4/source/drivers/hwtracing/coresig… >>>>> >>>>> and? If you respond with some unrelated argument, we will respond with >>>>> the same: Use 'ports' unless you have both in and out ports. >>>> >>>> Sorry for the insufficient response. >>>> >>>> The Coresight driver prefers using ‘in-ports’ and ‘out-ports’ instead of the ‘ports’ property, as each >>>> Coresight component needs to specify its input and output directions. >>>> >>>> The Coresight system operates by integrating all Coresight components and construting its data flow path >>>> based on the defined directions. >>>> >>>> Consequently, the data flow direction cannot be determined when utilizing the ‘ports’ property in the >>>> Coresight system. >>> >>> It can be determined. Driver knows that there are only in-ports, so you >>> cannot have here other direction. Maybe the drivers have somehow this >>> hard-coded? But that's a bit annoying limitation. >>> >> In Coresight platform driver, the of_coresight_get_port_parent function is used to retrieve the parent of the 'ports' node. >> The function is specifically hard-coded to recognize 'in-ports' and 'out-ports'. I think that's the limitation for >> 'ports' property. >> >> https://elixir.bootlin.com/linux/v6.11-rc4/source/drivers/hwtracing/coresig… > > That's a limitation of coresight platform driver, not bindings. Fix your > drivers. A bit more of context and history. We have a generic platform parsing code for parsing the firmware tables (DT and ACPI) in CoreSight. This will parse most generic bits (read, the graph connections) to avoid duplicating the code. Most of the components have both in and out connections (except trace sources and other helper devices like this TMC CU). Also, the "previous" (now legacy) DT graph bindings for CoreSight relied on using standard "ports" with a property to indicate whether a given port is "input". The platform driver still supports this for any legacy platform that hasn't moved over (of course with a complaint of using obsolete bindings in the dmesg). Now the above proposal is going to conflict with the legacy binding handling, where "ports" indicate output ports by default, without the obsolete property and the driver can't differentiate this from a legacy binding vs modern binding with individual driver to decide the direction of the port. Nothing unfixable, but I don't understand what is wrong in calling "input ports" in-ports. But if that is definitely a no go area, we would need to add "fixup" logic in individual drivers to "correct" the type of a port (i.e, all output ports in the parsed data to input ports) and live with it. Kind regards Suzuki > > Best regards, > Krzysztof >

10 months

[PATCH v3 0/2] coresight: Add remote etm support

by Mao Jinlong

The system on chip (SoC) consists of main APSS(Applications processor subsytem) and additional processors like modem, lpass. There is coresight-etm driver for etm trace of APSS. Coresight remote etm driver is for enabling and disabling the etm trace of remote processors. It uses QMI interface to communicate with remote processors' software and uses coresight framework to configure the connection from remote etm source to TMC sinks. Example to capture the remote etm trace: Enable source: echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink echo 1 > /sys/bus/coresight/devices/remote_etm0/enable_source Capture the trace: cat /dev/tmc_etf0 > /data/remote_etm.bin Disable source: echo 0 > /sys/bus/coresight/devices/remote_etm0/enable_source Change since V2: 1. Change qcom,inst-id to qcom,qmi-id 2. Fix the error in code for type of remote_etm_remove 3. Depend on QMI helper in Kconfig Changes since V1: 1. Remove unused content 2. Use CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS as remote etm source type. 3. Use enabled instead of enable in driver data. 4. Validate instance id value where it's read from the DT. Mao Jinlong (2): dt-bindings: arm: Add qcom,qmi-id for remote etm coresight: Add remote etm support .../arm/qcom,coresight-remote-etm.yaml | 10 + drivers/hwtracing/coresight/Kconfig | 13 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-qmi.h | 89 +++++ .../coresight/coresight-remote-etm.c | 307 ++++++++++++++++++ 5 files changed, 420 insertions(+) create mode 100644 drivers/hwtracing/coresight/coresight-qmi.h create mode 100644 drivers/hwtracing/coresight/coresight-remote-etm.c -- 2.41.0

10 months

[PATCH] coresight: tmc: sg: Do not leak sg_table

by Suzuki K Poulose

Running perf with cs_etm on Juno triggers the following kmemleak warning ! :~# cat /sys/kernel/debug/kmemleak unreferenced object 0xffffff8806b6d720 (size 96): comm "perf", pid 562, jiffies 4297810960 hex dump (first 32 bytes): 38 d8 13 07 88 ff ff ff 00 d0 9e 85 c0 ff ff ff 8............... 00 10 00 88 c0 ff ff ff 00 f0 ff f7 ff 00 00 00 ................ backtrace (crc 1dbf6e00): [<ffffffc08107381c>] kmemleak_alloc+0xbc/0xd8 [<ffffffc0802f9798>] kmalloc_trace_noprof+0x220/0x2e8 [<ffffffc07bb71948>] tmc_alloc_sg_table+0x48/0x208 [coresight_tmc] [<ffffffc07bb71cbc>] tmc_etr_alloc_sg_buf+0xac/0x240 [coresight_tmc] [<ffffffc07bb72538>] tmc_alloc_etr_buf.constprop.0+0x1f0/0x260 [coresight_tmc] [<ffffffc07bb7280c>] alloc_etr_buf.constprop.0.isra.0+0x74/0xa8 [coresight_tmc] [<ffffffc07bb72950>] tmc_alloc_etr_buffer+0x110/0x260 [coresight_tmc] [<ffffffc07bb38afc>] etm_setup_aux+0x204/0x3b0 [coresight] [<ffffffc08025837c>] rb_alloc_aux+0x20c/0x318 [<ffffffc08024dd84>] perf_mmap+0x2e4/0x7a0 [<ffffffc0802cceb0>] mmap_region+0x3b0/0xa08 [<ffffffc0802cd8a8>] do_mmap+0x3a0/0x500 [<ffffffc080295328>] vm_mmap_pgoff+0x100/0x1d0 [<ffffffc0802cadf8>] ksys_mmap_pgoff+0xb8/0x110 [<ffffffc080020688>] __arm64_sys_mmap+0x38/0x58 [<ffffffc080028fc0>] invoke_syscall.constprop.0+0x58/0x100 This due to the fact that we do not free the "sg_table" itself while freeing up the SG table and data pages. Fix this by freeing the sg_table in tmc_free_sg_table(). Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Cc: Mike Leach <mike.leach(a)linaro.org> Cc: James Clark <james.clark(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> --- drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c index e75428fa1592..610ad51cda65 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c @@ -261,6 +261,7 @@ void tmc_free_sg_table(struct tmc_sg_table *sg_table) { tmc_free_table_pages(sg_table); tmc_free_data_pages(sg_table); + kfree(sg_table); } EXPORT_SYMBOL_GPL(tmc_free_sg_table); @@ -342,7 +343,6 @@ struct tmc_sg_table *tmc_alloc_sg_table(struct device *dev, rc = tmc_alloc_table_pages(sg_table); if (rc) { tmc_free_sg_table(sg_table); - kfree(sg_table); return ERR_PTR(rc); } -- 2.34.1

10 months

Re: [PATCH v2 RESEND] Coresight: Set correct cs_mode for TPDM to fix disable issue

by Suzuki K Poulose

On Mon, 12 Aug 2024 12:30:43 +0800, Jie Gan wrote: > The coresight_disable_source_sysfs function should verify the > mode of the coresight device before disabling the source. > > However, the mode for the TPDM device is always set to > CS_MODE_DISABLED, resulting in the check consistently failing. > As a result, TPDM cannot be properly disabled. > > [...] Applied, thanks! [1/1] Coresight: Set correct cs_mode for TPDM to fix disable issue https://git.kernel.org/coresight/c/14f5fa9b5fcbe2b3d5098893aba6ad62254d2ef6 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

10 months

Re: [PATCH v1 RESEND] Coresight: Set correct cs_mode for dummy source to fix disable issue

by Suzuki K Poulose

On Mon, 12 Aug 2024 12:28:44 +0800, Jie Gan wrote: > The coresight_disable_source_sysfs function should verify the > mode of the coresight device before disabling the source. > However, the mode for the dummy source device is always set to > CS_MODE_DISABLED, resulting in the check consistently failing. > As a result, dummy source cannot be properly disabled. > > Configure CS_MODE_SYSFS/CS_MODE_PERF during the enablement. > Configure CS_MODE_DISABLED during the disablement. > > [...] Applied, thanks! [1/1] Coresight: Set correct cs_mode for dummy source to fix disable issue https://git.kernel.org/coresight/c/e6b64cda393efd84709ab3df2e42d36d36d7553e Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

10 months

Re: [PATCH v2 0/3] use device_for_each_child_node_scoped to access device child nodes

by Suzuki K Poulose

On Thu, 08 Aug 2024 17:12:36 +0200, Javier Carrasco wrote: > This series removes accesses to the device `fwnode` to iterate over its > own child nodes. Using the `device_for_each_child_node` macro provides > direct access to the device child nodes, and given that in all cases > they are only required within the loop, the scoped variant of the macro > can be used. > > It has been stated in previous discussions [1] that `device_for_each_*` > should be used to access device child nodes, removing the need to access > its internal fwnode, and restricting `fwnode_for_each_*` to traversing > subnodes when required. > > [...] Applied, to coresight next tree. Thanks! [1/3] coresight: cti: use device_* to iterate over device child nodes https://git.kernel.org/coresight/c/daca644d0c9e0 Best regards, -- Suzuki K Poulose <suzuki.poulose(a)arm.com>

10 months, 1 week

OpenCSD new branch

by Mike Leach

A new branch of OpenCSD is now available:- ocsd-consistency-checks-1.5.4-rc1 This adds in a number of consistency tests to try to detect when clients provide incorrect program images used for decode. Correct decode is dependent on getting the correct program image to walk looking for waypoints (branch instructions etc) to associate with the E/N atoms in the trace. Checks are enabled using operation flags in decoder creation:- OCSD_C_API ocsd_err_t ocsd_dt_create_decoder(const dcd_tree_handle_t handle, const char *decoder_name, const int create_flags, const void *decoder_cfg, unsigned char *pCSID ); Added flags for the create_flags parameter: OCSD_OPFLG_N_UNCOND_DIR_BR_CHK Check for N atom on unconditional direct branches - unconditional branches should always have associated E atoms. This option will generate an error and reset and resync the decoder if the target of the direct branch is not the next instruction. Some ETM IP will incorrectly trace taken branches to the next instruction as not taken branches - so this allows for these cases OCSD_OPFLG_STRICT_N_UNCOND_BR_CHK Check for N atom on all unconditional branches. This includes any direct and indirect unconditional branches. This check may be used if it is known the ETM IP does not have the issue mentioned above. OCSD_OPFLG_CHK_RANGE_CONTINUE Inconsistent range continuity on not taken branches. If a range has been output the ends on a non taken branch, it is expected that the next range will start at the end address of the previous range. If any of these checks fail then a OCSD_GEN_TRC_ELEM_NO_SYNC packet with a reason of UNSYNC_BAD_IMAGE will be output. Clients can choose which flags to use. By default all checks are off - to minimise possible performance hit. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

10 months, 1 week

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight