CoreSight

coresight@lists.linaro.org

7 participants
2372 discussions

[PATCH v5 0/3] coresight: Add static trace id support

by Mao Jinlong

Some HW has static trace id which cannot be changed via software programming. For this case, configure the trace id in device tree with "arm,static-trace-id = <xxx>", and call coresight_trace_id_get_static_system_id with the trace id value in device probe function. The id will be reserved for the HW all the time if the device is probed. Changes since V4: 1. Use fwnode_property_read_u32 in fwnode_property_read_u32. 2. Update date and version in sysfs-bus-coresight-devices-dummy-source Changes since V3: 1. Adda new API function int coresight_trace_id_get_system_static_id(int trace_id). 2. Use the term "static trace id" for these devices where the hardware sets a non-programmable trace ID. Changes since V2: 1. Change "trace-id" to "arm,trace-id". 2. Add trace id flag for getting preferred id or ODD id. Changes since V1: 1. Add argument to coresight_trace_id_get_system_id for preferred id instead of adding new function coresight_trace_id_reserve_system_id. 2. Add constraint to trace-id in dt-binding file. Mao Jinlong (3): dt-bindings: arm: Add arm,static-trace-id for coresight dummy source coresight: Add support to get static id for system trace sources coresight: dummy: Add static trace id support for dummy source .../sysfs-bus-coresight-devices-dummy-source | 15 +++++ .../arm/arm,coresight-dummy-source.yaml | 6 ++ drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++-- .../hwtracing/coresight/coresight-platform.c | 9 +++ .../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++---- .../hwtracing/coresight/coresight-trace-id.h | 9 +++ include/linux/coresight.h | 1 + 7 files changed, 123 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source -- 2.17.1

8 months

Re: [PATCH 1/1] coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

by Anshuman Khandual

On 10/18/24 19:38, Zhen Lei wrote: > Function devm_kzalloc() returns NULL instead of ERR_PTR() when it fails. Right, devm_kzalloc() calls devm_kmalloc() with additional __GFP_ZERO which returns NULL on error. > The IS_ERR() test in the return value check should be replaced with NULL > test. > > Fixes: 39744738a67d ("coresight: trbe: Allocate platform data per device") > Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Actually this problem is caused by the following commit which had replaced coresight_get_platform_data() with devm_kzalloc() for a dummy 'desc.pdata' allocation. Earlier IS_ERR() test for the return value, was correct for coresight_get_platform_data() which returns ERR_PTR() on error, but then it should have been changed for devm_kzalloc() into a NULL check instead. 4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE") Please add "Fixes:" tag for the above commit instead. > Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com> > --- > drivers/hwtracing/coresight/coresight-trbe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c > index 96a32b213669940..93fe9860acf16bd 100644 > --- a/drivers/hwtracing/coresight/coresight-trbe.c > +++ b/drivers/hwtracing/coresight/coresight-trbe.c > @@ -1266,7 +1266,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp > * into the device for that purpose. > */ > desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL); > - if (IS_ERR(desc.pdata)) > + if (!desc.pdata) > goto cpu_clear; > > desc.type = CORESIGHT_DEV_TYPE_SINK; Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com>

8 months

Re: [PATCH 1/1] coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

by James Clark

On 18/10/2024 3:08 pm, Zhen Lei wrote: > Function devm_kzalloc() returns NULL instead of ERR_PTR() when it fails. > The IS_ERR() test in the return value check should be replaced with NULL > test. > > Fixes: 39744738a67d ("coresight: trbe: Allocate platform data per device") > Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") I don't think the code that this patches exists in 3fbf7f011f24, but it looks ok for 39744738a67d. > Signed-off-by: Zhen Lei <thunder.leizhen(a)huawei.com> > --- > drivers/hwtracing/coresight/coresight-trbe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c > index 96a32b213669940..93fe9860acf16bd 100644 > --- a/drivers/hwtracing/coresight/coresight-trbe.c > +++ b/drivers/hwtracing/coresight/coresight-trbe.c > @@ -1266,7 +1266,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp > * into the device for that purpose. > */ > desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL); > - if (IS_ERR(desc.pdata)) > + if (!desc.pdata) > goto cpu_clear; > > desc.type = CORESIGHT_DEV_TYPE_SINK; Reviewed-by: James Clark <james.clark(a)linaro.org>

8 months

Re: [PATCH v3 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Suzuki K Poulose

On 18/10/2024 11:31, Krzysztof Kozlowski wrote: > On 18/10/2024 12:08, Suzuki K Poulose wrote: >> On 18/10/2024 11:05, Krzysztof Kozlowski wrote: >>> On 17/10/2024 09:23, Tao Zhang wrote: >>>> >>>> On 10/9/2024 6:52 PM, Suzuki K Poulose wrote: >>>>> Krzysztof >>>>> >>>>> On 22/08/2024 12:50, Suzuki K Poulose wrote: >>>>>> On 22/08/2024 11:34, Suzuki K Poulose wrote: >>>>>>> On 22/08/2024 08:08, Krzysztof Kozlowski wrote: >>>>>>>> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote: >>>>>>>>> On 21/08/2024 04:13, Tao Zhang wrote: >>>>>>>>>> The is some "magic" hard coded filtering in the replicators, >>>>>>>>>> which only passes through trace from a particular "source". Add >>>>>>>>>> a new property "filter-src" to label a phandle to the coresight >>>>>>>>>> trace source device matching the hard coded filtering for the port. >>>>>>>>> >>>>>>>>> Minor nit: Please do not use abbreviate "source" in the bindings. >>>>>>>>> I am not an expert on other changes below and will leave it to >>>>>>>>> Rob/Krzysztof to comment. >>>>>>>>> >>>>>>>>> Rob, Krzysztof, >>>>>>>>> >>>>>>>>> We need someway to "link" (add a phandle) from a "port". The patch >>>>>>>>> below >>>>>>>>> is extending "standard" port to add a phandle. Please let us know if >>>>>>>>> there is a better way. >>>>>>>>> >>>>>>>>> e.g.: >>>>>>>>> >>>>>>>>> filters = list of tuples of port, phandle. ? >>>>>>>>> >>>>>>>>> e.g.: >>>>>>>>> >>>>>>>>> filters = < 0, <&tpdm_video>, >>>>>>>>> 1, <&tpdm_mdss> >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>> Current solution feels like band-aid - what if next time you need some >>>>>>>> second filter? Or "wall"? Or whatever? Next property? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Isn't filter just one endpoint in the graph? >>>>>>>> >>>>>>>> A <--> filter <--> B >>>>>>> >>>>>>> To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a >>>>>>> multi output ports). >>>>>>> >>>>>>> For clearer example: >>>>>>> >>>>>>> A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) >>>>>>> <--> B1 >>>>>>> A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) >>>>>>> <--> B2 >>>>>>> A2 <--> .. <--> ../ p2 \ --> Unfiltered >>>>>>> <--> B0 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Instead of >>>>>>>> >>>>>>>> A <----through-filter----> B? >>>>>>> >>>>>>> The problem is we need to know the components in the path from A0 to X >>>>>>> through, (Not just A0 and L). And also we need to know "which port >>>>>>> (p0 vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out >>>>>>> of the >>>>>>> link "L". >>>>>>> >>>>>>> So ideally, we need a way to tie p0 -> A1, p1 -> A2. >>>>>>> >>>>>>> would we need something else in the future ? I don't know for sure. >>>>>>> People could design their own things ;-). But this was the first time >>>>>>> ever in the last 12yrs since we supported coresight in the kernel. >>>>>>> (there is always a first time). >>>>>>> >>>>>>> Fundamentally, the "ports" cannot have additional properties today. >>>>>>> Not sure if there are other usecases (I don't see why). So, we have >>>>>>> to manually extend like above, which I think is not nice. >>>>>> >>>>>> Replying to the other thread [0], made me realize that the above is not >>>>>> true. Indeed it is possible to add properties for endpoints, e.g: >>>>>> >>>>>> e.g.: media/video-interfaces.yaml >>>>>> >>>>>> So extending the endpoint node is indeed acceptable (unlike I thought). >>>>>> May be the we it is achieved in this patch is making it look otherwise. >>>>>> >>>>>> Suzuki >>>>>> [0] >>>>>> https://lkml.kernel.org/r/4b51d5a9-3706-4630-83c1-01b01354d9a4@arm.com >>>>> >>>>> Please could you let us know if it is acceptable to extend "endpoint" >>>>> node to have an optional property ? >>>> >>>> Hi Krzysztof, >>>> >>>> >>>> Kindly reminder, could you help comment on this? >>> >>> I don't have any smart ideas and with earlier explanation sounds ok. >> >> Just to confirm, are you OK with adding a property to the "endpoint" >> node that will indicate a phandle that the device allows on this >> endpoint ? > > You mean the filter property in endpoint? if so, then yes. Thanks for confirming ! Cheers Suzuki > > Best regards, > Krzysztof >

8 months

Re: [PATCH v4 1/2] dt-bindings: arm: Add device-name in the coresight components

by Suzuki K Poulose

On 24/07/2024 20:13, Krzysztof Kozlowski wrote: > On 03/07/2024 14:23, Mao Jinlong wrote: >> Current name of coresight component's folder consists of prefix of >> the device and the id in the device list. When run 'ls' command, >> we can get the register address of the device. Take CTI for example, >> if we want to set the config for modem CTI, but we can't know which >> CTI is modem CTI from all current information. >> >> cti_sys0 -> ../../../devices/platform/soc(a)0/138f0000.cti/cti_sys0 >> cti_sys1 -> ../../../devices/platform/soc(a)0/13900000.cti/cti_sys1 >> >> Add device-name in device tree which can provide a better description >> of the coresight device. It can provide the info like the system or >> HW it belongs to. >> >> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com> >> --- >> .../devicetree/bindings/arm/arm,coresight-cti.yaml | 6 ++++++ >> .../devicetree/bindings/arm/arm,coresight-dummy-source.yaml | 6 ++++++ >> .../devicetree/bindings/arm/arm,coresight-stm.yaml | 6 ++++++ >> .../devicetree/bindings/arm/qcom,coresight-tpdm.yaml | 6 ++++++ >> 4 files changed, 24 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml >> index 2d5545a2b49c..6a73eaa66a42 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml >> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml >> @@ -98,6 +98,12 @@ properties: >> power-domains: >> maxItems: 1 >> >> + arm,cs-dev-name: >> + $ref: /schemas/types.yaml#/definitions/string >> + description: >> + Define the name which can describe what kind of HW or system the >> + coresight device belongs to. > > Don't we use already label for such cases? Power domains, input, leds, > panels, IIO, hwmon and more. We do and if we can get hold of them, that would be ideal. but do we get them in the binary DT blob ? At least I couldn't see them on my Juno dtb. Cheers Suzuki > > Best regards, > Krzysztof >

8 months

Re: [PATCH v3 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Suzuki K Poulose

On 18/10/2024 11:05, Krzysztof Kozlowski wrote: > On 17/10/2024 09:23, Tao Zhang wrote: >> >> On 10/9/2024 6:52 PM, Suzuki K Poulose wrote: >>> Krzysztof >>> >>> On 22/08/2024 12:50, Suzuki K Poulose wrote: >>>> On 22/08/2024 11:34, Suzuki K Poulose wrote: >>>>> On 22/08/2024 08:08, Krzysztof Kozlowski wrote: >>>>>> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote: >>>>>>> On 21/08/2024 04:13, Tao Zhang wrote: >>>>>>>> The is some "magic" hard coded filtering in the replicators, >>>>>>>> which only passes through trace from a particular "source". Add >>>>>>>> a new property "filter-src" to label a phandle to the coresight >>>>>>>> trace source device matching the hard coded filtering for the port. >>>>>>> >>>>>>> Minor nit: Please do not use abbreviate "source" in the bindings. >>>>>>> I am not an expert on other changes below and will leave it to >>>>>>> Rob/Krzysztof to comment. >>>>>>> >>>>>>> Rob, Krzysztof, >>>>>>> >>>>>>> We need someway to "link" (add a phandle) from a "port". The patch >>>>>>> below >>>>>>> is extending "standard" port to add a phandle. Please let us know if >>>>>>> there is a better way. >>>>>>> >>>>>>> e.g.: >>>>>>> >>>>>>> filters = list of tuples of port, phandle. ? >>>>>>> >>>>>>> e.g.: >>>>>>> >>>>>>> filters = < 0, <&tpdm_video>, >>>>>>> 1, <&tpdm_mdss> >>>>>>> > >>>>>>> >>>>>> >>>>>> Current solution feels like band-aid - what if next time you need some >>>>>> second filter? Or "wall"? Or whatever? Next property? >>>>> >>>>> >>>>> >>>>>> >>>>>> Isn't filter just one endpoint in the graph? >>>>>> >>>>>> A <--> filter <--> B >>>>> >>>>> To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a >>>>> multi output ports). >>>>> >>>>> For clearer example: >>>>> >>>>> A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) >>>>> <--> B1 >>>>> A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) >>>>> <--> B2 >>>>> A2 <--> .. <--> ../ p2 \ --> Unfiltered >>>>> <--> B0 >>>>> >>>>> >>>>> >>>>>> Instead of >>>>>> >>>>>> A <----through-filter----> B? >>>>> >>>>> The problem is we need to know the components in the path from A0 to X >>>>> through, (Not just A0 and L). And also we need to know "which port >>>>> (p0 vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out >>>>> of the >>>>> link "L". >>>>> >>>>> So ideally, we need a way to tie p0 -> A1, p1 -> A2. >>>>> >>>>> would we need something else in the future ? I don't know for sure. >>>>> People could design their own things ;-). But this was the first time >>>>> ever in the last 12yrs since we supported coresight in the kernel. >>>>> (there is always a first time). >>>>> >>>>> Fundamentally, the "ports" cannot have additional properties today. >>>>> Not sure if there are other usecases (I don't see why). So, we have >>>>> to manually extend like above, which I think is not nice. >>>> >>>> Replying to the other thread [0], made me realize that the above is not >>>> true. Indeed it is possible to add properties for endpoints, e.g: >>>> >>>> e.g.: media/video-interfaces.yaml >>>> >>>> So extending the endpoint node is indeed acceptable (unlike I thought). >>>> May be the we it is achieved in this patch is making it look otherwise. >>>> >>>> Suzuki >>>> [0] >>>> https://lkml.kernel.org/r/4b51d5a9-3706-4630-83c1-01b01354d9a4@arm.com >>> >>> Please could you let us know if it is acceptable to extend "endpoint" >>> node to have an optional property ? >> >> Hi Krzysztof, >> >> >> Kindly reminder, could you help comment on this? > > I don't have any smart ideas and with earlier explanation sounds ok. Just to confirm, are you OK with adding a property to the "endpoint" node that will indicate a phandle that the device allows on this endpoint ? Kind regards Suzuki > > Best regards, > Krzysztof >

8 months

Re: [PATCH v3 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

by Suzuki K Poulose

On 22/08/2024 08:08, Krzysztof Kozlowski wrote: > On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote: >> On 21/08/2024 04:13, Tao Zhang wrote: >>> The is some "magic" hard coded filtering in the replicators, >>> which only passes through trace from a particular "source". Add >>> a new property "filter-src" to label a phandle to the coresight >>> trace source device matching the hard coded filtering for the port. >> >> Minor nit: Please do not use abbreviate "source" in the bindings. >> I am not an expert on other changes below and will leave it to >> Rob/Krzysztof to comment. >> >> Rob, Krzysztof, >> >> We need someway to "link" (add a phandle) from a "port". The patch below >> is extending "standard" port to add a phandle. Please let us know if >> there is a better way. >> >> e.g.: >> >> filters = list of tuples of port, phandle. ? >> >> e.g.: >> >> filters = < 0, <&tpdm_video>, >> 1, <&tpdm_mdss> >> > >> > > Current solution feels like band-aid - what if next time you need some > second filter? Or "wall"? Or whatever? Next property? > > Isn't filter just one endpoint in the graph? > > A <--> filter <--> B To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a multi output ports). For clearer example: A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) <--> B1 A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) <--> B2 A2 <--> .. <--> ../ p2 \ --> Unfiltered <--> B0 > Instead of > > A <----through-filter----> B? The problem is we need to know the components in the path from A0 to X through, (Not just A0 and L). And also we need to know "which port (p0 vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out of the link "L". So ideally, we need a way to tie p0 -> A1, p1 -> A2. would we need something else in the future ? I don't know for sure. People could design their own things ;-). But this was the first time ever in the last 12yrs since we supported coresight in the kernel. (there is always a first time). Fundamentally, the "ports" cannot have additional properties today. Not sure if there are other usecases (I don't see why). So, we have to manually extend like above, which I think is not nice. Happy to proceed with anything that seems acceptable for you folks. Suzuki > > Best regards, > Krzysztof >

8 months, 1 week

Re: [PATCH V9 0/2] arm-cs-trace-disasm.py/perf must accommodate non-zero DSO text offset

by Steve Clevenger

On 10/16/2024 10:51 AM, Namhyung Kim wrote: > Hello, > > On Fri, Oct 11, 2024 at 11:17:10AM -0600, Steve Clevenger wrote: >> Changes in V9: >> - Removed V8 patch files 1/4 and 2/4. >> - Modified set_sym_in_dict (trace-event-python.c) to add map_pgoff >> in dictionary as-is without regard to MAPPING_IDENTITY. This patch >> file is now patch 2/2. > > I think the previous version had Leo's Reviewed-by tag. > > Leo, can you confirm if it still holds? > > Thanks, > Namhyung It did. You can confirm there's no arm-cs-trace-python.py script change from V8. Note the patch file numbering is different (since 2 patches dropped). The trace-event-python.c patch file changed so I had to drop out his "Reviewed-by" tag for that file. Due to the patch numbering change, I didn't want to add confusion so I left it out. Steve > >> >> Changes in V8: >> - in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to >> string. >> - Remove map_pgoff integer conversion in dso not found print >> message. >> >> Changes in V7: >> - In arm-cs-trace-disasm.py, fix print message core dump resulting >> from mixed type arithmetic. >> - Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The >> CS_ETM_TRACE_ON message is changed to print only in verbose mode. >> - Removed verbose mode only notification for start_addr/stop_addr >> outside of dso address range. >> >> Changes in V6: >> - In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add >> map_pgoff to start/end address for dso not found message. >> - Added "Reviewed-by" trailer for patches 1-3 previously reviewed >> by Leo Yan in V4 and V5. >> >> Changes in V5: >> - In symbol-elf.c, branch to exit_close label if open file. >> - In trace_event_python.c, correct indentation. set_sym_in_dict >> call parameter "map_pgoff" renamed as "addr_map_pgoff" to >> match local naming. >> >> Changes in V4: >> - In trace-event-python.c, fixed perf-tools-next merge problem. >> >> Changes in V3: >> - Rebased to linux-perf-tools branch. >> - Squash symbol-elf.c and symbol.h into same commit. >> - In map.c, merge dso__is_pie() call into existing if statement. >> - In arm-cs-trace-disasm.py, remove debug artifacts. >> >> Changes in V2: >> - In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer >> checks per Leo Yan review. >> - Updated mailing list distribution. >> >> Steve Clevenger (2): >> Add map_pgoff to python dictionary >> Adjust objdump start/end address per map_pgoff parameter >> >> tools/perf/scripts/python/arm-cs-trace-disasm.py | 16 +++++++++++----- >> .../util/scripting-engines/trace-event-python.c | 9 ++++++--- >> 2 files changed, 17 insertions(+), 8 deletions(-) >> >> -- >> 2.44.0 >>

8 months, 1 week

[PATCH v4 0/3] coresight: Add static trace id support

by Mao Jinlong

Some HW has static trace id which cannot be changed via software programming. For this case, configure the trace id in device tree with "arm,static-trace-id = <xxx>", and call coresight_trace_id_get_static_system_id with the trace id value in device probe function. The id will be reserved for the HW all the time if the device is probed. Changes since V3: 1. Adda new API function int coresight_trace_id_get_system_static_id(int trace_id). 2. Use the term "static trace id" for these devices where the hardware sets a non-programmable trace ID. Changes since V2: 1. Change "trace-id" to "arm,trace-id". 2. Add trace id flag for getting preferred id or ODD id. Changes since V1: 1. Add argument to coresight_trace_id_get_system_id for preferred id instead of adding new function coresight_trace_id_reserve_system_id. 2. Add constraint to trace-id in dt-binding file. Mao Jinlong (3): dt-bindings: arm: Add arm,trace-id for coresight dummy source coresight: Add support to get static id for system trace sources coresight: dummy: Add static trace id support for dummy source .../sysfs-bus-coresight-devices-dummy-source | 15 +++++ .../arm/arm,coresight-dummy-source.yaml | 6 ++ drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++-- .../hwtracing/coresight/coresight-platform.c | 26 ++++++++ .../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++---- .../hwtracing/coresight/coresight-trace-id.h | 9 +++ include/linux/coresight.h | 1 + 7 files changed, 140 insertions(+), 14 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source -- 2.41.0

8 months, 1 week

Minimal or Incomplete trace data on zynq-7000

by deepanjali.s.19＠gmail.com

I am currently working with a ZedBoard featuring the Zynq 700 and have enabled CoreSight components in the kernel features and device tree blob (DTB). I can confirm that I can view the CoreSight devices located in /sys/bus/. However, I've encountered an issue when attempting to enable or disable CoreSight data dumps. The results are only producing minimal binary files. ubuntu@arm:/sys/bus/coresight/devices$ ls -lh total 0 lrwxrwxrwx 1 root root 0 Mar 27 2023 etb0 -> ../../../devices/soc0/axi/f8801000.etb/etb0 lrwxrwxrwx 1 root root 0 Mar 27 2023 etm0 -> ../../../devices/soc0/axi/f889c000.ptm/etm0 lrwxrwxrwx 1 root root 0 Mar 27 2023 etm1 -> ../../../devices/soc0/axi/f889d000.ptm/etm1 lrwxrwxrwx 1 root root 0 Mar 27 2023 funnel0 -> ../../../devices/soc0/axi/f8804000.funnel/funnel0 lrwxrwxrwx 1 root root 0 Mar 27 2023 replicator0 -> ../../../devices/soc0/replicator/replicator0 lrwxrwxrwx 1 root root 0 Mar 27 2023 tpiu0 -> ../../../devices/soc0/axi/f8803000.tpiu/tpiu0 ubuntu@arm:/sys/bus/coresight/devices$ dmesg | grep coresight [ 1.578865] coresight etm0: PTM 1.0 initialized [ 1.584452] coresight etm1: PTM 1.0 initialized ubuntu@arm:/sys/bus/coresight/devices$ dmesg | grep amba [ 0.033923] amba f8801000.etb: Fixed dependency cycle(s) with /replicator/out-ports/port@1/endpoint [ 0.034129] amba f8803000.tpiu: Fixed dependency cycle(s) with /replicator/out-ports/port@0/endpoint [ 0.034358] amba f8804000.funnel: Fixed dependency cycle(s) with /replicator/in-ports/port/endpoint [ 0.034571] amba f889c000.ptm: Fixed dependency cycle(s) with /axi/funnel@f8804000/in-ports/port@0/endpoint [ 0.034779] amba f889d000.ptm: Fixed dependency cycle(s) with /axi/funnel@f8804000/in-ports/port@1/endpoint root@arm:/sys/bus/coresight/devices# echo 1 | sudo tee etb0/enable_sink 1 root@arm:/sys/bus/coresight/devices# echo 1 | sudo tee etm1/enable_source 1 root@arm:/sys/bus/coresight/devices# dd if=/dev/etb0 of=~/cstrace.bin 8+0 records in 8+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00763361 s, 537 kB/s root@arm:~# hexdump -C cstrace.bin 00000000 ff ff ff 7f ff ff ff 7f ff ff ff 7f ff ff ff 7f |................| 00000010 25 86 d2 1f c4 8c 86 1a 8a e9 22 84 c4 a9 c8 4b |%........."....K| 00000020 02 c1 b0 e3 00 d1 a8 c8 02 e7 de a8 04 e0 8a 3b |...............;| 00000030 ce 18 8e c1 18 e5 22 88 ac e1 d6 03 de d7 a8 75 |......"........u| 00000040 04 86 f6 1f 8c 85 20 8c 0e ce 86 85 f6 c7 02 d2 |...... .........| 00000050 ea fe f0 00 8a b9 8e c8 02 84 4a f1 fe f0 00 31 |..........J....1| 00000060 a0 9d c0 d3 02 b4 fe 00 94 8d 00 dc 14 94 9a ee |................| 00000070 fc f0 00 b8 d6 c0 d2 03 9c 7f 94 8d 00 dc 14 cd |................| 00000080 94 c1 fa e0 00 8a b8 c3 22 f5 fe 22 ae fd 30 7a |........".."..0z| 00000090 25 8c 36 9a 44 ee 50 b8 f6 8e c8 03 a6 c9 00 9e |%.6.D.P.........| 000000a0 9c 55 84 59 92 0f c8 cc 9c a1 c8 e5 00 84 fc e4 |.U.Y............| 000000b0 96 c8 02 a8 ac 0f ea d4 ea fc ea d4 ec c4 b8 07 |................| 000000c0 ca 12 e6 f6 f2 cb fe f0 00 c2 9e e5 a6 3c e6 41 |.............<.A| 000000d0 84 f5 1a a2 da 1c f4 8c 8a f2 38 f0 94 bb 8e b6 |..........8.....| 000000e0 3a 88 56 b7 f2 39 84 f3 9c 3c a6 0d 9e ef 26 82 |:.V..9...<....&.| 000000f0 ca 98 da fe 30 98 f0 f6 c6 03 84 79 b0 cb de 9a |....0......y....| 00000100 a8 04 8c ad e0 d7 02 df d6 a8 04 86 d2 1f c4 5c |...............\| 00000110 25 8c 86 1a 8a e9 22 84 c4 a9 c8 03 c0 b1 e2 d3 |%.....".........| 00000120 00 d1 a8 c8 02 e7 de a8 04 e0 8a cf 18 8e c0 8e |................| 00000130 18 e5 22 88 ac e1 d6 03 de d7 a8 04 86 f7 1e 9d |..".............| 00000140 8c 85 20 8c 0e ce 86 85 f6 c7 02 eb fe f0 00 34 |.. ............4| 00000150 8a b9 8e c8 02 84 4a f1 fe f0 00 a0 9c c1 d2 cc |......J.........| 00000160 02 b4 fe 00 94 8d 00 dc 14 94 9a fd f0 00 b8 3b |...............;| 00000170 d6 c0 d2 03 9c 7f 94 8d 00 dc 14 94 c0 fb e0 73 |...............s| 00000180 00 8a b8 c3 22 f5 fe 22 ae fd 30 8c 36 9a 44 de |....".."..0.6.D.| 00000190 25 ee 50 b8 f6 8e c8 03 a6 c9 00 9c 54 84 58 e6 |%.P.........T.X.| 000001a0 92 0f c8 cc 9c a1 c8 e5 00 84 fc 97 c8 03 a8 39 |...............9| 000001b0 ac 0f ea d4 ea fc ea d4 ec c4 b8 cb 12 e6 f6 01 |................| 000001c0 f2 cb fe f0 00 c2 9e e5 a6 3c e6 84 f4 1b a2 50 |.........<.....P| 000001d0 da 1c f4 8c 8a f2 38 f0 94 bb 8e 3a 88 57 b6 ad |......8....:.W..| 000001e0 f2 39 84 f3 9c 3c a6 0d 9e ef 26 ca 98 db fe 20 |.9...<....&.... | 000001f0 30 98 f0 f6 c6 03 84 79 b0 cb de a8 04 8c ac a6 |0......y........| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 With perf i get I get Error:70 Incomplete data With Opencsd root@arm:/home/ubuntu/my-opencsd/decoder/tests/bin/builddir# ls -l /root/my/ total 8 -rw-r--r-- 1 root root 4096 Oct 10 07:11 cstrace.bin drwxr-xr-x 3 root root 4096 Sep 10 06:30 own root@arm:/home/ubuntu/my-opencsd/decoder/tests/bin/builddir# ./trc_pkt_lister -ss_dir /root/my/ -decode Trace Packet Lister: CS Decode library testing ----------------------------------------------- ** Library Version : 1.5.4 Test Command Line:- ./trc_pkt_lister -ss_dir /root/my/ -decode Trace Packet Lister : reading snapshot from path /root/my/ Trace Packet Lister : Snapshot path/root/my/ not found

8 months, 1 week

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight