CoreSight July 2019

coresight@lists.linaro.org

10 participants
12 discussions

[PATCH v2 0/5] coresight: etm4x: save/restore ETMv4 context across CPU low power states

by Andrew Murray

Some hardware will ignore bit TRCPDCR.PU which is used to signal to hardware that power should not be removed from the trace unit. Let's mitigate against this by conditionally saving and restoring the trace unit state when the CPU enters low power states. This patchset introduces a firmware property named 'arm,coresight-needs-save-restore' - when this is present the hardware state will be conditionally saved and restored. A module parameter 'pm_save_enable' is also introduced which can be configured to override the firmware property. The hardware state is only ever saved and restored when the claim tags indicate that self-hosted mode is in use. Changes since v1: - Rebased onto coresight/next - Correcly pass bit number rather than BIT macro to coresight_timeout - Abort saving state if a timeout occurs - Fix completely broken pm_notify handling and unregister handler on error - Use state_needs_restore to ensure state is restored only once - Add module parameter description to existing boot_enable parameter and use module_param instead of module_param_named - Add firmware bindings for coresight-needs-save-restore - Rename 'disable_pm_save' to 'pm_save_enable' which allows for disabled, enabled or firmware - Update comment on etm4_os_lock, it incorrectly indicated that the code unlocks the trace registers - Add comments to explain use of OS lock during save/restore - Fix incorrect error description whilst waiting for PM stable - Add WARN_ON_ONCE when cpu isn't as expected during save/restore - Various updates to commit messages Andrew Murray (5): coresight: etm4x: remove superfluous setting of os_unlock coresight: etm4x: use explicit barriers on enable/disable coresight: etm4x: use module_param instead of module_param_named coresight: etm4x: improve clarity of etm4_os_unlock comment coresight: etm4x: save/restore state across CPU low power states .../devicetree/bindings/arm/coresight.txt | 3 + drivers/hwtracing/coresight/coresight-etm4x.c | 315 +++++++++++++++++- drivers/hwtracing/coresight/coresight-etm4x.h | 66 ++++ drivers/hwtracing/coresight/coresight.c | 2 +- include/linux/coresight.h | 8 + 5 files changed, 387 insertions(+), 7 deletions(-) -- 2.21.0

4 years, 9 months

Re: coresight ETM tracing and GDB

by Mathieu Poirier

Good day Zied, Apologies for the delay in responding to you - my mail client sent your email to my spam folder. Moreover, I suggest to CC the coresight mailing list when seeking guidance on this topic. There is a lot of knowledgeable people on there that can help you as much as I can. On Wed, 26 Jun 2019 at 06:47, zied guermazi <guermazi_zied(a)yahoo.com> wrote: > > hi Mathieu, > > I was tracking the progress of coresight group within Linaro in providing coresight tracing in linux kernel as well as tools around it (e.g. perf, opencsd). I noticed that it reached a good maturity level to enable other use cases for this feature, one of them is providing non intrusive instruction tracing in GDB using ETM. This can bring a huge benefit to ARM community using open source tools (reduce debugging time, record and replay buggy execution, test coverage, performance analysis etc ..). in addition it can open the doors for business targeting introducing debuggers with ETM tracing support in the market with more affordable price. > > I would like to present this opportunity to Linaro, and I am seeking getting their feedback and involvement. I have seen that you were active since the beginning in the coresight project at Linaro, so you probably went through such a process. I want to get your advise on how to proceed to reach this target. > I am attaching an RFC where technical aspects are discussed, this can give you a better insight on the use case and its realizability. I commend you for taking the time to put this RFC together. Integration of coresight with GDB is something that has been on the radar for a long time. Several people have looked at the feature but it was never pursued further for various reasons. Your RFC has a lot of details and you definitely took time to think about this. Other than that it is not possible for me to cast further judgement on the viability of the project without a small prototype to evaluate and code to look at. I suggest you come up with a proof of concept that covers a basic scenario. That will make it easier for us to review your work and assess the feasibility of the feature. I also advise to take time to understand how coresight has been integrated with perf, how interactions with the openCSD library are made and the complexity inherent to coresight trace decoding. Thanks, Mathieu > > looking forward for your feedback > Best Regards > Zied Guermazi >

4 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight July 2019