Good day Leo,
Please meet my new friend Christophe. He is from ST-Micro and is currently working on integrating the CS framework in their next platform. I would be grateful if you could share with him the instructions you have used to get STM doing on the dragon board and how you got the snapshot decoder to decode the traces.
Christophe is also looking to get a trace snapshot that is known to be working properly to test in his environment.
Many thanks, Mathieu
Hi Mathieu & Christophe,
On Mon, Aug 27, 2018 at 11:35:16AM -0600, Mathieu Poirier wrote:
Good day Leo,
Please meet my new friend Christophe. He is from ST-Micro and is currently working on integrating the CS framework in their next platform. I would be grateful if you could share with him the instructions you have used to get STM doing on the dragon board and how you got the snapshot decoder to decode the traces.
Sure, my pleasure.
Below is detailed steps for using STM on DB410c board:
- Need apply one offline patch for DT binding for STM component (Thanks a lot for Chunyan for sharing this!).
Please see enclosed patch for this.
- In the kernel command line, please add 'nohlt' to ensure CPUs are not powered off;
- Enable STM path with SysFS nodes:
# echo 1 > /sys/bus/coresight/devices/825000.etf/enable_sink # echo 1 > /sys/bus/coresight/devices/802000.stm/enable_source
- Connect STM driver to Ftrace function tracer, so all Ftrace function trace data will be routed into STM:
# echo 802000.stm > /sys/class/stm_source/ftrace/stm_source_link # echo function > /sys/kernel/debug/tracing/current_tracer # echo schedule > /sys/kernel/debug/tracing/set_ftrace_filter
- Then the CoreSight STM will produce trace data, so we can get out the trace data with command:
# cp /dev/825000.etf ./cstrace.data
- Build OpenCSD repository on host PC side; if you want you also can do this on the target board with Debian rootFS.
$ git clone https://github.com/Linaro/OpenCSD -o my_opencsd $ cd my_opencsd/decoder/build/linux $ make LINUX64=1 DEBUG=1
- Copy the trace data to host PC side to the OpenCSD folder:
$ cd my_opencsd/decoder/tests/snapshots/stm_only $ cp cstrace.data ./cstraceitm.bin # replace the db410c data
- Change to 'STMTCSR(0x3A0)=0x00810007' in the file device_0.ini so this can match well with TCSR register value on DB410c.
- Decoding the trace data with snapshot mode in OpenCSD:
$ ../../bin/builddir/trc_pkt_lister
Christophe is also looking to get a trace snapshot that is known to be working properly to test in his environment.
Yeah, if have further question, please let me know.
Many thanks, Mathieu
Hi Al,
On Wed, Aug 29, 2018 at 09:35:34AM +0000, Al Grant wrote:
Hi Leo,
- In the kernel command line, please add 'nohlt' to ensure CPUs are not powered off;
Is there work in progress (KWG ticket?) to avoid needing nohlt?
I'd like to leave this question for Mathieu, Mathieu has more insight for this topic and for KWG ticket.
Just give more input at here: at about 1~2 monthes ago I sent one email with Mathieu for power management with CoreSight, one dependency is to use GenPD to maintain between the Coresight power domain and CPU power domain, IIRC the GenPD hasn't been merged in mailine kernel for this part.
Another topic is to save and restore contexts for CPU suspend/resume flow so even the CPU has been powered off but CoreSight won't lose the context after the CPU resumes back.
Not sure if at YVR18 connect in next month if we have chance to some discussion for this. I think one meaningful thing is to firstly summary what's power management related issues we need to resolve for CoreSight, some power management is more relative with CoreSight, some are overlap between CoreSight and CPU power domain; the situation will get complex if we need cover the case when the power management logic is insane in the SoC design (please refer patch [1]), though this is low priority but it's better to find robust solution for insane system IMO.
[1] https://patchwork.kernel.org/patch/10064611/
We should aim for trace to be usable under 'normal' power-saving conditions without needing any special settings.
Totally agree.
Thanks, Leo Yan
Good day to all,
On Wed, 29 Aug 2018 at 04:16, leo.yan@linaro.org wrote:
Hi Al,
On Wed, Aug 29, 2018 at 09:35:34AM +0000, Al Grant wrote:
Hi Leo,
- In the kernel command line, please add 'nohlt' to ensure CPUs are not powered off;
Is there work in progress (KWG ticket?) to avoid needing nohlt?
I'd like to leave this question for Mathieu, Mathieu has more insight for this topic and for KWG ticket.
There is no work in progress to fix power management issues on the dragon board nor do I see any coming in the foreseeable future.
One way of allowing CS and dynamic CPU power management to be active simultaneously is to properly implement TRCPDCR:PU. This is what was done on Juno and things work quite well. The downside of this approach is the required HW support and an update to the FW image for the PMIC.
Despite TRCPDCR:PU my preferred approach to dealing with CS power management on all platform has always been via the generic power domain subsystem (genPD), something that would void the aforementioned HW and FW requirements. When I looked into this 4 years ago the genPD subsystem was far from being ready for such a task, meaning that it couldn't handle domains shared by both devices (in this case CS) and CPU cores. The silver lining here is that I am told a lot of work has been done and things are almost ready for CS to be integrated with genPD.
Just give more input at here: at about 1~2 monthes ago I sent one email with Mathieu for power management with CoreSight, one dependency is to use GenPD to maintain between the Coresight power domain and CPU power domain, IIRC the GenPD hasn't been merged in mailine kernel for this part.
Another topic is to save and restore contexts for CPU suspend/resume flow so even the CPU has been powered off but CoreSight won't lose the context after the CPU resumes back.
Right, this would be needed for sysFS trace scenarios. This is currently a low priority item for me since this interface is very restrictive. If anything I would rather see time invested in dealing with genPDs.
Not sure if at YVR18 connect in next month if we have chance to some discussion for this. I think one meaningful thing is to firstly summary what's power management related issues we need to resolve for CoreSight, some power management is more relative with CoreSight, some are overlap between CoreSight and CPU power domain; the situation will get complex if we need cover the case when the power management logic is insane in the SoC design (please refer patch [1]), though this is low priority but it's better to find robust solution for insane system IMO.
We also have to come to term with the fact that some platforms simply can't be salvaged and other more intrusive means (like disabling CPUidle) need to be used.
[1] https://patchwork.kernel.org/patch/10064611/
We should aim for trace to be usable under 'normal' power-saving conditions without needing any special settings.
That is always my primary goal and the main reason for all the work that went in to making Juno right.
Mathieu
Totally agree.
Thanks, Leo Yan
-
Al Grant -
leo.yan＠linaro.org -
Mathieu Poirier