Arvind,

Thanks for taking and publishing the notes from our discussion.

The following are additional notes for the STM metadata discussion:

STM Framework Spec version .4 uses the STP 2.0 Mark packets for driver 
generated binary messages primarily for broadcasting context changes (process 
id) on an STM channel. So no plan to use Mark packets for metadata. We are 
currently using a dedicated channel for metadata (for processing hw generated 
STM messages), which worked out very efficiently for our decoder.  Since we 
would use a dedicated channel for metadata, I don't see any reason not to 
simply use the basic byte-stream message format to broadcast metadata.

For broadcasting metadata into an ETB, there is a solution Michael and I talked 
about last week that I forgot to mention during our discussion. We can simply 
store the metadata in a debugfs file when routing to the ETB. We may need to 
use some other switch to determine this since routing through the first level 
of trace funnel may be all we should handle from the STM drivers. Would also 
need an interface (another debugfs file) that allows user mode libraries to 
hand off metadata to the driver.

We also touched a bit on the possibility of metadata providing a descriptor for 
binary data allowing for generic decoding beyond simple string data. This may 
be a good solution for decoding tracepoints since they broadcast binary data on 
a dedicated channel. Adding sw message metadata would mean that a STM channel 
would have to be dedicated to a specific data type, which is something OST 
headers avoid.

Other than additions to the spec for metadata support I don't recall anything 
in our discussion that would cause me to modify the STM Framework spec. I have 
started implementation so would like to get feedback on the .4 spec as soon as 
possible.

Thanks,
Doug




________________________________
From: Arvind Chauhan [mailto:arvind.chau...@arm.com]
Sent: Wednesday, January 18, 2012 6:51 AM
To: Deao, Douglas; Ian Spray; Robin Randhawa; John Horley; Al Grant; Ashwin 
Namjoshi
Subject: Meeting Minutes: Discussion on STM framework proposal (17 January 2012)



Minutes - Discussion on STM framework proposal



Present: Linaro: Deao Douglas; ARM: Ian Spray, John Horley, Robin Randhawa, Al 
Grant, Aswhin Namjoshi, Arvind Chauhan


Local Decode


*         Doug mentioned about a requirement for local decode, where some 
customers want to capture data in ETB and decode locally.

o        Use cases: Power and Bus profiling - (hardware messages)

o        Easier to explain to customers in terms of use cases than about STM 
details - they look at it as just another driver to get trace data out

*         Ian provided views on ETB decode being not an optimal option




Trace Ecosystem


*         Discussion on how rest of Coresight world fits together, in terms of 
configuring other sub-systems like funnel, replicators to get trace data out 
reliably

o        Doug mentioned that current view is to have these modules sit 
side-by-side together in a system - STM specifics taken care of by STM 
Framework driver, like so by respective drivers. These various drivers may not 
be interacting a lot beyond init

*         Question: Is it part of Linaro's remit to look at overall Coresight 
components (not just STM)?

o         Answer from Doug: Not particularly.

*         Ian emphasized the point that it's very important to address overall 
trace ecosystem view beyond STM framework driver and testing

o        At least getting the high level overview written down will help in 
guiding how everything fits together

o        Doug is open to considering this aspect.

*         Question: Can ARM put some thoughts together, maybe expand initial 
section of STM framework driver spec to cover overall trace flow?

o        This may lead to future blueprints, increased scope.

o        Ian to see if some text can be put together


Validation Platform


*         Local decode setup: STM framework driver + OMAP Plugins + Standalone 
decoder + User mode library to configure ETB + OMAP4 Platform, OMAP5 in future

o        Pandaboard can be an option


Roadmap


*         Doug mentioned that though most of their customer/tools are for local 
decode, 'agrees that there does exist valid case for transferring trace data to 
host machine/tools for processing

*          Roadmap mentions about LTTng etc. - so not just limited to local 
decode


Metadata channel


*          Question: Any plans of reserved block of channels for metadata? Ver 
0.4 of STM Framework spec doesn't give any details on metadata channel.

o        Doug mentioned that it's not included in current spec - looking at 
using mark packet - were not in favor of metadata transport, as OST headers 
were supported that describes data for TI's decoders

o         Don't see a strong need for broadcasting metadata for software 
messages - have found it useful lately for hardware messages

o        Challenge to determine when to broadcast, as metadata may flood 
buffers - so reluctant for software messages

*         Standard required for software and hardware message descriptions - 
difficult for hardware messages

o        Ian to send a note on metadata approach

*         Ian updated on need for metadata - 'not so much for dynamic channel 
reallocation, but more for external debugger attached and tools to identify 
trace data


Message Format


*         Key to interoperability is with message formatting - Not specific to 
one OS (Linux), OS level interoperability is a goal

*         Hardware messages may be vendor specific

*         Linaro may develop standard set of decoders

*         Not thought much on standardization yet


Security aspects


*         Not much thought given to security aspects of STM framework driver at 
this stage.

*         Point of consideration from Doug - STM exports data, no way to 
broadcast it back in to change system state; Also, will security be important 
while debugging/profiling?


Integration with Perf


*         Robin asked about plans for integration with tools like perf

o        Doug mentions it's on the roadmap

*          Ian described why perf is not ideal as a STM use case

*          Robin discussed about when a developer makes a call to use perf vs 
trace flow around STM

o         Is it that STM gets used for fine grained tuning?

?          Doug updated that it depends on use case and trace using STM is 
relevant for all debug/profiling - not necessarily for only fine grained tuning




As we ran out of planned 1hr, we had to cut short our discussions. Let me know 
if we need to schedule another phone discussion.

Please add/modify with your comments - I may have missed stuff.



Best regards,
Arvind



-- 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.
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to