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
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
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
Good afternoon,
As promised in our last meeting I have generated traces for ETMv3 and
ETMv4. ETMv3 traces have been generated on a A7 (vexpress-TC2) core
while the latter on an A53 (Juno).
Both bundles have been updated here [1]. A while back I used DS-5's
command line interface to decode ETMv3 traces[2]. I figured that
capturing the same files and content for this exercise would likely
suffice. Please get back to me if you don't fine what you are looking
for.
Last but not least I'm not sure about the ETMv4 traces. I wasn't able
to use the address range resource the same way I did on ETMv3,
something I will rectify when I get back on the week of the 15th of
June.
Regards,
Mathieu
[1]. http://people.linaro.org/~mathieu.poirier/coresight/trace_decode/
[2]. https://wiki.linaro.org/WorklingGroups/Kernel/Coresight/traceDecodingWithDS5
