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_z...@yahoo.com> wrote: > > Hi Mike, hi Matthieu > it works! > > > > On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi > <guermazi_z...@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 > > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
