CoreSight

coresight@lists.linaro.org

6 participants
2343 discussions

by Mathieu Poirier

Same comment applies with regards to mailing lists. On Mon, 17 Feb 2020 at 10:16, zied guermazi <guermazi_zied(a)yahoo.com> wrote: > > Hi Mike, hi Matthieu, > > I was too rapid to press the send button, sorry for the inconvienience. > and yes, it works. I published the source code in github (https://github.com/gzied/binutils-gdb/tree/gdb_arm_coresight) ,as well as a mail in linaro mailing list (https://lists.linaro.org/pipermail/coresight/2020-February/003676.html). Unfortunately you didn't publish your work in "PATCH" format and as such it can't be reviewed. > Eventhough there is still an effort needed to stabilize it for armv7, and test it for armv8, I consider this as a breakthough that we can build on the top of it. > I will be visiting Embedded world exhibition between 25th and 27th of February in Nuremberg, Germany. are you planning to be there too. I am looking forwards to meet you there if possible to discuss possibilities of further development and integration in the main stream. I won't be in Nuremberg next week and I'm pretty sure Mike won't be there either. Other people on the lists might be around and interested in meeting with you. Mike and I will be attending Linaro Connect in Budapest between the 23rd and 27th of March. The Linaro toolchain group will also be there so it might be the perfect opportunity to sit down for an hour or so and have a chat. A good day to you, Mathieu > > Kind Regards > Zied Guermazi > > > > > > On Monday, February 17, 2020, 06:08:26 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote: > > > Hi Mike, hi Matthieu > it works! > > > > On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote: > > > hi Mike, hi Mathieu > last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level. > 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). > I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here? > > during the implementation few technical question raised: > - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress) > - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs. > > for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call? > > I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round. > > Thanks for your support > Zied Guermazi > >

5 years, 2 months

Build coresight drivers as module

by tingwei＠codeaurora.org

Hi all, This regarding to the plan to build coresight drivers as Kernel module. Currently, it doesn't support that. I noticed there's some patch to add the ability to build as module but that patch doesn't end to be merged. I'd like to know whether anyone is working on this or has plan for this. I'm interesting in this since there's some trend on mobile device especially Android device that all drivers should be built as Kernel modules. Coresight drivers are important for mobile device to debug SW/HW issues. Thanks, Tingwei

5 years, 2 months

[PATCH v4 0/5] perf cs-etm: Fix synthesizing instruction samples

by Leo Yan

This patch series is to address issues for synthesizing instruction samples, especially when the instruction sample period is small enough, the current logic cannot synthesize multiple instruction samples within one instruction range packet. Patch 0001 is to swap packets for instruction samples, so this allow option '--itrace=iNNN' can work well. Patch 0002 avoids to reset the last branches for every instruction sample; if reset the last branches for every time generating sample, the later samples in the same range packet cannot use the last branches anymore. Patch 0003 is the fixing for handling different instruction periods, especially for small sample period. Patch 0004 is an optimization for copying last branches; it only copies last branches once if the instruction samples share the same last branches. Patch 0005 is a minor fix for unsigned variable comparison to zero. This patch set has been rebased on the latest perf/core branch; and verified on Juno board with below commands: # perf script --itrace=i2 # perf script --itrace=i2il16 # perf inject --itrace=i2il16 -i perf.data -o perf.data.new # perf inject --itrace=i100il16 -i perf.data -o perf.data.new Changes from v3: * Refactored patch 0001 with new function cs_etm__packet_swap() (Mike); * Refined instruction sample generation flow with single while loop, which completely uses Mike's suggestions (Mike); * Added Mike's review tags for patch 01/02/04/05. Changes from v2: * Added patch 0001 which is to fix swapping packets for instruction samples; * Refined minor commit logs and comments; * Rebased on the latest perf/core branch. Changes from v1: * Rebased patch set on perf/core branch with latest commit 9fec3cd5fa4a ("perf map: Check if the map still has some refcounts on exit"). Leo Yan (5): perf cs-etm: Swap packets for instruction samples perf cs-etm: Continuously record last branch perf cs-etm: Correct synthesizing instruction samples perf cs-etm: Optimize copying last branches perf cs-etm: Fix unsigned variable comparison to zero tools/perf/util/cs-etm.c | 157 +++++++++++++++++++++++++++------------ 1 file changed, 111 insertions(+), 46 deletions(-) -- 2.17.1

5 years, 2 months

Re: progress in btrace with etm in gdb

by Mathieu Poirier

i Hi Zied, As requested before, always add the CS mailing list when interacting with us. There is a fair amount of people on there that would surely be interested in this work. I also CC'd the linaro-toolchain group since some of the content below is related to what they do. On Mon, 17 Feb 2020 at 10:08, zied guermazi <guermazi_zied(a)yahoo.com> wrote: > > Hi Mike, hi Matthieu > it works! > > > > On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote: > > > hi Mike, hi Mathieu > last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level. > 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). > I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here? I will address your questions one by one: Q: Do you think it is ok to push it in this status (feature partially achieved) ? A: That depends on how advanced things are. If it is stable (i.e it does something) and can be used as a starting point for other people to work on, then there is probably value in publishing your work. Q: is linaro gdb git the correct one? A: I see from your other email that you've already published your work. Q: who is the maintainer of this part of gdb? A: I'm sure the GDB project has documentation and a well defined process that would identify who you should submit your code to. Q: I do not have an ARMv8 platform to test. who can support here? A: No doubt you'd get a lot more interest if you were working on V8. I suggest purchasing a dragonboard 410c - they are super cheap, well supported and one of our CS reference platforms. I think we talked about that before... > > during the implementation few technical question raised: > - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress) I would assume this "set record btrace" command has an effect on the current session only. If so I would go for the latter option. > - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs. > I am very confused by this question. Yes, the path "/sys/bus/event_source/devices/cs_etm/" is guaranteed to be unique but it is by no means a "default source". Is is simply a directory used by the perf tools to have more details on the CS specifics for the running platform. Nowadays it is fair to assume there is one ETM perf CPU, all enumerated under sysfs. Also keep in mind that processes are being moved around by the scheduler and as such, a specific source can't be hard coded. > for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call? Configuration of the tracers does indeed need to be considered. At this time we assume all the tracers in an implementation are similar, hence using ".../cpu0/mgmt". The information gathered from there is related to the static configuration of the tracers. Per session dynamic configuration is collected from the perf tools command line and communicated to the perf infrastructure for later interpretation by the decoding code when instantiating a decoder from the openCSD library. Since the current framework handles only N:1 source/sink configuration, there can only be one trace session using a sink. There is currently no way to extract trace session configuration other than the user space perf tools mechanic. > > I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round. > > Thanks for your support > Zied Guermazi > >

5 years, 2 months

[PATCH v4 0/5] perf cs-etm: Support thread stack and callchain

by Leo Yan

This patch series adds support for thread stack and callchain; this is a sequential version from v3 [1] but reorgnized the patches, some changes have been refactored into the instruction sample fix patch set [2], and this patch set is only to focus on thread stack and callchain support. Patch 01 is to refactor the instruction size calculation; this patch is used by patch 02. Patch 02 is to add thread stack support, after applying this patch the option '-F,+callindent' can be used by perf script tool; patch 03 is to add branch filter thus the Perf tool can display branch samples only for function calls and returns after enable the call indentation or call chain related options. Patch 04 is to synthesize call chain for the instruction samples. Patch 05 allows the instruction sample can be handled synchronously with the thread stack, thus it fixes an error for the callchain generation. This patch set has been tested on Juno-r2 after applied on perf/core branch with latest commit 85fc95d75970 ("perf maps: Add missing unlock to maps__insert() error case"), and this patch set is dependent on the instruction sample fix patch set [2]. Test for option '-F,+callindent': Before: # perf script -F,+callindent main 840 1 branches: main ffffa2319d20 __libc_start_main+0xe0 (/usr/lib/aarch64-linux-gnu/libc-2.28.so) main 840 1 branches: aaaab94cb7d0 main+0xc (/root/coresight_test/main) main 840 1 branches: aaaab94cb808 main+0x44 (/root/coresight_test/main) main 840 1 branches: lib_loop_test@plt aaaab94cb7dc main+0x18 (/root/coresight_test/main) main 840 1 branches: lib_loop_test@plt aaaab94cb67c lib_loop_test@plt+0xc (/root/coresight_test/main) main 840 1 branches: _init aaaab94cb650 _init+0x30 (/root/coresight_test/main) main 840 1 branches: _dl_fixup ffffa24a5b44 _dl_runtime_resolve+0x40 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: _dl_lookup_symbol_x ffffa24a0070 _dl_fixup+0xb8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) [...] After: # perf script -F,+callindent main 840 1 branches: main ffffa2319d20 __libc_start_main+0xe0 (/usr/lib/aarch64-linux-gnu/libc-2.28.so) main 840 1 branches: lib_loop_test@plt aaaab94cb7dc main+0x18 (/root/coresight_test/main) main 840 1 branches: _dl_fixup ffffa24a5b44 _dl_runtime_resolve+0x40 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: _dl_lookup_symbol_x ffffa24a0070 _dl_fixup+0xb8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: do_lookup_x ffffa249c4a4 _dl_lookup_symbol_x+0x104 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: check_match ffffa249bbf8 do_lookup_x+0x238 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa249b890 check_match+0x70 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: printf@plt aaaab94cb7f0 main+0x2c (/root/coresight_test/main) main 840 1 branches: _dl_fixup ffffa24a5b44 _dl_runtime_resolve+0x40 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: _dl_lookup_symbol_x ffffa24a0070 _dl_fixup+0xb8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: do_lookup_x ffffa249c4a4 _dl_lookup_symbol_x+0x104 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: _dl_name_match_p ffffa249baf8 do_lookup_x+0x138 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa24a17e8 _dl_name_match_p+0x18 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa24a180c _dl_name_match_p+0x3c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: _dl_name_match_p ffffa249baf8 do_lookup_x+0x138 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa24a17e8 _dl_name_match_p+0x18 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa24a180c _dl_name_match_p+0x3c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: check_match ffffa249bbf8 do_lookup_x+0x238 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa249b890 check_match+0x70 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 840 1 branches: strcmp ffffa249b968 check_match+0x148 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) [...] Test for option '--itrace=g': Before: # perf script --itrace=g16l64i100 main 840 100 instructions: ffff8000102642c0 event_sched_in.isra.119+0x140 ([kernel.kallsyms]) main 840 100 instructions: ffff800010264794 flexible_sched_in+0xe4 ([kernel.kallsyms]) main 840 100 instructions: ffff800010263024 perf_pmu_disable+0x4 ([kernel.kallsyms]) main 840 100 instructions: ffff80001026b0e0 perf_swevent_add+0xb8 ([kernel.kallsyms]) main 840 100 instructions: ffff80001025b504 calc_timer_values+0x34 ([kernel.kallsyms]) main 840 100 instructions: ffff80001019bd24 clocks_calc_mult_shift+0x3c ([kernel.kallsyms]) main 840 100 instructions: ffff80001026556c perf_event_update_userpage+0xec ([kernel.kallsyms]) main 840 100 instructions: ffff80001025c5e4 visit_groups_merge+0x194 ([kernel.kallsyms]) [...] After: # perf script --itrace=g16l64i100 main 840 100 instructions: ffff800010264794 flexible_sched_in+0xe4 ([kernel.kallsyms]) ffff80001025c57c visit_groups_merge+0x12c ([kernel.kallsyms]) main 840 100 instructions: ffff800010263024 perf_pmu_disable+0x4 ([kernel.kallsyms]) ffff8000102641f0 event_sched_in.isra.119+0x70 ([kernel.kallsyms]) ffff8000102643d8 group_sched_in+0x60 ([kernel.kallsyms]) ffff8000102647b0 flexible_sched_in+0x100 ([kernel.kallsyms]) ffff80001025c57c visit_groups_merge+0x12c ([kernel.kallsyms]) main 840 100 instructions: ffff80001026b0e0 perf_swevent_add+0xb8 ([kernel.kallsyms]) ffff80001026423c event_sched_in.isra.119+0xbc ([kernel.kallsyms]) ffff8000102643d8 group_sched_in+0x60 ([kernel.kallsyms]) ffff8000102647b0 flexible_sched_in+0x100 ([kernel.kallsyms]) ffff80001025c57c visit_groups_merge+0x12c ([kernel.kallsyms]) [...] Changes from v3: * Splitted out separate patch set for instruction samples fixing. * Rebased on latest perf/core branch. Changes from v2: * Added patch 01 to fix the unsigned variable comparison to zero (Suzuki). * Refined commit logs. Changes from v1: * Added comments for task thread handling (Mathieu). * Split patch 02 into two patches, one is for support thread stack and another is for callchain support (Mathieu). * Added a new patch to support branch filter. [1] https://lkml.org/lkml/2019/10/5/51 [2] https://lkml.org/lkml/2020/2/2/228 Leo Yan (5): perf cs-etm: Refactor instruction size handling perf cs-etm: Support thread stack perf cs-etm: Support branch filter perf cs-etm: Support callchain for instruction sample perf cs-etm: Synchronize instruction sample with the thread stack tools/perf/util/cs-etm.c | 145 ++++++++++++++++++++++++++++++++------- 1 file changed, 121 insertions(+), 24 deletions(-) -- 2.17.1

5 years, 2 months

[PATCH v3 0/5] perf cs-etm: Fix synthesizing instruction samples

by Leo Yan

Let's restart this work [1], this patch set is the dependency for support callchain for Arm CoreSight, which will be sent out in another patch set. This patch series is to address issues for synthesizing instruction samples, especially when the instruction sample period is small enough, the current logic cannot synthesize multiple instruction samples within one instruction range packet. Patch 0001 is to swap packets for instruction samples, so this allow option '--itrace=iNNN' can work well. Patch 0002 avoids to reset the last branches for every instruction sample; if reset the last branches for every time generating sample, the later samples in the same range packet cannot use the last branches anymore. Patch 0003 is the fixing for handling different instruction periods, especially for small sample period. Patch 0004 is an optimization for copying last branches; it only copies last branches once if the instruction samples share the same last branches. Patch 0005 is a minor fix for unsigned variable comparison to zero. This patch set has been rebased on the latest perf/core branch; and verified on Juno board with below commands: # perf script --itrace=i2 # perf script --itrace=i2il16 # perf inject --itrace=i2il16 -i perf.data -o perf.data.new # perf inject --itrace=i100il16 -i perf.data -o perf.data.new Changes from v2: * Added patch 0001 which is to fix swapping packets for instruction samples; * Refined minor commit logs and comments; * Rebased on the latest perf/core branch. Changes from v1: * Rebased patch set on perf/core branch with latest commit 9fec3cd5fa4a ("perf map: Check if the map still has some refcounts on exit"). [1] https://patchwork.kernel.org/cover/11222259/ Leo Yan (5): perf cs-etm: Swap packets for instruction samples perf cs-etm: Continuously record last branch perf cs-etm: Correct synthesizing instruction samples perf cs-etm: Optimize copying last branches perf cs-etm: Fix unsigned variable comparison to zero tools/perf/util/cs-etm.c | 142 ++++++++++++++++++++++++++++++++------- 1 file changed, 118 insertions(+), 24 deletions(-) -- 2.17.1

5 years, 3 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, 3 months

Consommation de carburant

by Madeleine Durand

Bonjour, Je représente une entreprise qui commercialise des solutions de gestion de flotte. Grâce à la télématique vous pouvez économiser jusqu'à 20% des coûts de carburant et de maintenance de vos véhicules, notamment grâce à la remontée et à l'analyse des comportements de conduite de vos chauffeurs. Vous souhaitez réduire les coûts de votre flotte et augmenter sa productivité ? Contactez-moi pour plus d’informations. Cordialement, Madeleine Durand

5 years, 3 months

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, 3 months

[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, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight