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.Chauhan@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.