CoreSight

coresight@lists.linaro.org

2 participants
2791 discussions

Fwd: Collection of metadata in a multi-session environment

by Mathieu Poirier

---------- Forwarded message ---------- From: Mathieu Poirier <mathieu.poirier(a)linaro.org> Date: 3 November 2015 at 21:27 Subject: Collection of metadata in a multi-session environment To: private-opencsd <private-opencsd(a)linaro.org> As reported in my other email (Trace bundles for ETMv3/v4) moving to a multi-session scheme his forcing me to rethink how metadata is collected as one can no longer assume that what gets read from sysFS actually pertains to the session being reported. When looking at the required registers (once again, please refer to Mike's document, section 4.3.1 to 4.3.3) a lot of them are RO: ETMv3/PTM: ETMIDR ETMv4: TRCIDR[0, ..., 13], TRCAUTHSTATUS Some are RW but can easily be made RO when using the CS framework from Perf: ETMv3/PTM: ETMTRACEID ETMv4: TRCTRACEIDR In fact I remember having this conversation with Mike in San Francisco and nobody would cry if we were to let the framework decide the traceIDs configured on the tracers. Anything that is RO can still be retrieved using the current sysFS driven method since their values don't change. That leaves us with the other RW registers: ETMv3/PTM: ETMCR, ETMCCR ETMv4: TRCCONFIGR The question is, what information is needed from these registers in order to do trace decoding? Is there anything in there that is coming from the HW that can't be deduced otherwise? From what I understand we are talking about user configurable options that could be communicated to the trace decoding library using other means than conveying the whole registers. Using a bitmap is the first option that comes to mind, i.e, if cycle accurate tracing is configured, bit X is set. With the above in mind I need you guys to help me identify the mandatory information in those tracer registers that is needed for trace decoding. Once again we can discuss this further in our meeting tomorrow. Thanks, Mathieu

10 years, 8 months

Fwd: Trace bundles for ETMv3/v4

by Mathieu Poirier

---------- Forwarded message ---------- From: Mathieu Poirier <mathieu.poirier(a)linaro.org> Date: 3 November 2015 at 11:48 Subject: Trace bundles for ETMv3/v4 To: private-opencsd <private-opencsd(a)linaro.org> After a programming marathon I am please to bring you trace bundles for both ETMv3[1] and v4[2]. The code is based on the latest development branch[3], something that seemed like a good idea to avoid maintaining two different tree. It certainly served the purpose but other problems inherent to that approach have also showed up - more on that later. Since the ETMv4 has more metadata (as per Mike's enclosed document[4]) I had to modify the AUX_TRACE header format. The new format can be found here [5], with the assignment of the slots described here [6]. The end result is that ETMv3 headers will have zero'ed out slots, something I can't avoid since the auxiliary area foundation assumes a fix amount of data for all tracers. It's not my ideal solution but we can always try to change the world when things are actually working. The perf.data file found in both bundles have been generated using this command: $ perf record -vvv -e cs_etm// --per-thread uname As such the amount of traces should be relatively small. In the bundles you will also find the .debug directory, the perf.data file and a medata.txt file. The latter is simply a snapshot of the relevant registers as listed in Mike's document[4]. The snapshot was taken *after* the trace run and only there to *somewhat* make sense of how things were configured, which brings us to the problems I've hinted about earlier. Contrary to V1 and V2 the newest code base is configuring tracers as the event is scheduled rather than at initialisation time, making the metadata in the perf.data completely irrelevant. I will likely have a solution for that so hang tight, it's coming. Please have a look and we'll touch base in the meeting tomorrow. Regards, Mathieu [1]. uname.etmv3.tgz [2]. uname.etmv4.tgz [3]. https://git.linaro.org/people/mathieu.poirier/coresight.git/shortlog/refs/h… [4]. RefTrcDecode-API and Components_0v3.pdf [5]. https://git.linaro.org/people/mathieu.poirier/coresight.git/blob/refs/heads… [6]. https://git.linaro.org/people/mathieu.poirier/coresight.git/blob/refs/heads…

10 years, 8 months

Waiting for status bits

by Mathieu Poirier

Tor, Mike and all, Here is something i'd like your opinion on... Before programming the ETMv3/PTM, ETMCR:10 needs to be set to one and when enabling the tracer, the bit needs to be cleared. Each time the status of ETMSR:1 needs to be probed before moving on, something that is quite costly. Is there a official limit of time for this operation to be carried out? The same question applies for ETB's FFCR:6 and FFSR:1. At this time the driver wait for 100 usec before complaining - from your experience, this this too short or it may need more time? Thanks, Mathieu

10 years, 9 months

Coresight configuration options

by Mathieu Poirier

Al and Mike, With the work on coresight/Perf integration proceeding as planned the time to start looking at how configuration parameters can be conveyed to the tracers using the perf cmd tool is fast approaching, and that's where I need to pick your brain. In your opinion and based on your experience with coresight, what are the 5 most wanted configuration options we need to start with? The question could also be thought of as the 5 most common thing people configure when using coresight. Finding a way to give access to all the configuration option of a tracer via cmd line won't be easy but I believe it can be done. If we find a way to address the most commonly used options as an starting point the rest should come easily. Please think about it and get back to me. My plan is to get the discussion going with the perf maintainer about the best way to proceed sometime this week or the next, depending on schedule. Thanks, Mathieu

10 years, 9 months

IntelPT repository and Perf resources

by Mathieu Poirier

Gentlemen, As promised in the meeting the work on IntelPT done by Alex Shishkin can be found on github [1]. All the user space integration work can be found under tools/perf/. Adrian Hunter (formally at TI) did most of the user space work. There is good documentation [2] that shows how IntelPT is used and how the decoding library is called. On the flip side the different between full trace and snapshot mode isn't all that clear - I will touch base on that in my status update in SF. Get back to me if you really can't wait that long and I'll be happy to clarify. I also bring your attention to two web pages. The first one [3] is an awesome wiki on perf where most of the basics are highlighted. The second one [4] is Brendan Gregg's in depth look at how he uses perf to debug real life problems. Regards, Mathieu [1]. https://github.com/virtuoso/linux-perf/tree/intel_pt [2]. https://github.com/virtuoso/linux-perf/blob/intel_pt/tools/perf/Documentati… [3]. https://perf.wiki.kernel.org/index.php/Tutorial [4]. http://www.brendangregg.com/perf.html

10 years, 9 months

OpenCSD Weekly IRC Meeting on 13 August 2015

by Serge Broslavsky

Gentlemen, Here is the log for this weeks team meeting. Tor, is the timing for the meeting bad for you? You did not attend the meeting while we all wanted to hear a few words of feedback from you for the code Mike has published two weeks ago. Have you had a chance to look at that? -- Best Regards, Serge Broslavsky <serge.broslavsky(a)linaro.org> Core Development Project Manager, Linaro M: +37129426328 IRC: ototo Skype: serge.broslavsky http://linaro.org | Open source software for ARM SoCs

10 years, 10 months

OpenCSD Infrastructure

by Serge Broslavsky

Gentlemen, I'd like to describe project's infrastructure so that you'd be able to start using it. PROJECT SOURCE REPOSITORY We're using GitHub project [https://github.com/Linaro/OpenCSD] for tracking sources for OpenCSD. In order to get commit rights for that repository I need to know your user ids. So far only Tor and Al have provided me their names (and were added to the project group). As soon as you get yourselves added to the project, you should be able to commit your code into the repository. For that you need to clone it locally using [git@github.com:Linaro/OpenCSD.git]. So, Mike, please go to GitHub [https://github.com/join], create a new user for yourself and let me know the user id. If you don't feel yourself fluent enough with Git - please take a look at ProGit online book [https://progit.org/]. PROJECT DOCUMENTATION We're using GitHub wiki [https://github.com/Linaro/OpenCSD/wiki] for project related documentation. Please use it as the primary location for that purpose. You can also do that using git and your favorite editor by cloning its repository [git@github.com:Linaro/OpenCSD.wiki.git] PROJECT COMMUNICATIONS 1. Mailing List Traditionally project mailing list is the major communication tool for almost any open community project. We also have a mailing list that is available for this project as well as other CoreSight related discussions [https://lists.linaro.org/mailman/listinfo/coresight]. Please use it for all the technical discussions around OpenCSD. It's archive will help people joining later so please invest in project future by using its mailing list. 2. IRC While mailing list is a proper way of communication in a typical community project, having other, more realtime means of communication does help a lot. For this purpose we're using IRC channel named #linaro-coresight which is located on freenode IRC network [http://freenode.net/]. Please note that freenode also offers a web-based IRC client, which might be useful for the cases when you can't use your standard setup. Using web-based IRC client as a main option is highly discouraged. Depending on your OS and habits I'd recommend using XChat [http://xchat.org/] for MS Windows and GUI Linux, and weechat [https://weechat.org/] for terminal under Linux. I'm using the latter one as I prefer terminal apps. Let's have a weekly syncup meeting on IRC to discuss the progress, issues and synchronize our efforts. I'm proposing to have it on Wednesdays, on Wednesdays at 17:00 +0000 (London time) on #linaro-coresight IRC channel. I've sent an invitation for that meeting starting from the next week. Please let me know your IRC nicknames when you set your clients up - I'll list those on a team page on project wiki. My IRC nickname is "ototo". -- Best Regards, Serge Broslavsky <serge.broslavsky(a)linaro.org> Core Development Project Manager, Linaro M: +37129426328 IRC: ototo Skype: serge.broslavsky http://linaro.org | Open source software for ARM SoCs

10 years, 11 months

OpenCSD - Relevant documentation

by Serge Broslavsky

Good localtime, As you've noticed from the subject line of this email, the name for the project has been changed to "OpenCSD" (Open CoreSight Decoder), which has more eye candy and is easier to pronounce. I hope you agree with that. The project's goal is to not only create the initial codebase, but also help a community to form around it. For that to happen it is very important to make the ramp-up costs as low as possible. I'll be adding the project set up documentation to the wiki soon. Thus, I'd like to start building the project wiki on GitHub and one of the sections that we definitely need to have there is relevant documentation (one that we use, not create). I've created a placeholder Home and Documents wiki pages and would like you guys to help me gathering links to all the relevant documentation in the Documents.md page [1]. You can edit pages directly on GitHub [2], but I prefer using my favorite vim editor locally by cloning wiki pages via git with the following command: $ git clone git@github.com:Linaro/OpenCSD.wiki.git For that to be possible I need to know your GitHub user names to give you write permissions for the project. You can also reply back to this email with your URLs - I'll add those to the page myself in this case. Links: [1] https://github.com/Linaro/OpenCSD/wiki/Documents [2] https://github.com/Linaro/OpenCSD/wiki -- Best Regards, Serge Broslavsky <serge.broslavsky(a)linaro.org> Core Development Project Manager, Linaro M: +37129426328 IRC: ototo Skype: serge.broslavsky http://linaro.org | Open source software for ARM SoCs

10 years, 12 months

API Document

by Mike Leach

Hi, As discussed I have attached the API document that describes the design and current implementation of a CoreSight decoder library framework that we have been working on within ARM. This is very much a work in progress (both the document and the API) - but questions / comments etc. are always welcome. The document does have a distribution list on the front but it is not limited by this so if I have missed anyone off I apologise. Regards Mike ---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ---------------------------------------------------------------- -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

10 years, 12 months

CS/TSDL Project Scope Brainstorming

by Serge Broslavsky

Good localtime, I am the project manager assigned to CS/TSDL Project by Linaro. I hope this journey will be something pleasant and fruitful for all the participants of this project as well as for the community around ARM technologies and Linux. So, let's start with an answer to "what?" question. In order to be able to properly plan the scope of the project we need to define the first approximation of the project work item structure. Quite many of the people subscribed to this mailing list have practical experience implementing trace stream decoders for CoreSight. That increases our chances of defining a decent approximation of the project scope, which then will be refined gradually as project continues. I need your help brainstorming this topic. So, please, throw your ideas about the potential work items into this thread and I'll be summarizing your ideas and putting them into a single "backlog", which will get prioritized according to needs and dependencies afterwards. Usage of a hierarchical representation of the work items might be a good idea as it allows seeing the dependencies from the very beginning. So, something along the lines of the example below is proposed to be used (the structure below is just an example - I don't have enough technical knowledge for the area to propose a good initial structure): 1. Frontend 1.1. ... 2. Core 2.1. ... 2. Backends 2.1. ETMv3 2.1.1. ... 2.2. ETMv4 2.2.1. ... 2.3. STM 2.3.1. ... 3. ... Also, please share your relevant DOs and DONTs from your past experience. This undertaking needs all your skills and knowledge to create a fast, reliable and easy to use decoding library. PS. "CS/TSDL" in the subject stands for "CoreSight/Trace Stream Decoding Library". Proposals for a better name are welcome. :) -- Best Regards, Serge Broslavsky <serge.broslavsky(a)linaro.org> Core Development Project Manager, Linaro M: +37129426328 IRC: ototo Skype: serge.broslavsky http://linaro.org | Open source software for ARM SoCs

11 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight