Mathieu Poirier - LCA14-210, Macau

ETM/ETB/Coresight : Initial Discussion

Overview

• What are ETM, ETB and Coresight• Current state upstream• Patches by various contributor• Linaro’s initial proposal for upstreaming• Open discussion

Overview: ETM/ETB/Coresight

• Coresight is a set of IP block meant to provide non-intrusive debug capabilities.

• Allow for debugging of different types of components, not just processors (DSP, DMA).

• Cross-trigger interface stops everything that is connected.

• Blocks usually split in: Source, link and sinks.• SoCs designer will choose to implement different

“paths” based on requirement.• Depending on the configurations, “paths” can be

modified on the fly.

Current State Upstream:• Only one file: arch/arm/kernel/etm.c• Includes ETB support and a single ETM

component.• Enabled only by setting CONFIG_OMAP2.• Works on beagleboard/beagleXM.• Static and rigid configuration.• Trace buffer output to the console.• Nothing in the “Documentation/” directory.• No longer maintained.

Patches by Contributors (ETM/ETB)• Arve Hjønnevåg (Google):

• Mostly making the driver configuration more flexible• Adds robustness and fixes a few bugs• Added support for multiple ETM/PTM• Adds tuning capabilities via sysfs• Patches in the Android tree

• Adrien Vergé (Mtl. Polytechnic School of Eng.)• Fixing basic memory allocation problems• kobj_attribute → device_attribute• Add tracing for specific address range (similar to Arve)• Introducing tracing by PID, supports namespace• Patches sent for review, already in its 3rd iteration

Patches by Contributors (Coresight)• Pratik Patel (CodeAurora):

• Comprehensive drivers for the Coresight framework:• ETM, ETB, Funnel, Replicator, STM, TMC, TPIU.

• Defines a new “coresight” platform bus.• All components register with the coresight bus:

• Coresight components are independent.• Connection between devices is defined in DT.• Coresight sysfs bus interface enables the “path”.• A “path” can be changed from sysfs interface.

• Already under “drivers/coresight/”• Big - around 7K lines of code.• Some hard coded values (clock name and buffer size)• Minimal working functionality for each component

Patches by Contributors (Coresight)• Robert Marklund (ST-Ericsson at the time):

• Building on the work done by Pratik Patel.• Not sure if the patchset was ever sent for review.

• John Hunter (TI) has a Cross-trigger Interface:• https://github.com/jonhunter/linux/commits/dev-cti• Pratik thinks this implementation is better than his but

needs work, i.e doesn’t support routing one trigger (CTI) to another.

What Should We Do Now?

• We don’t want efforts to be wasted by duplicating what’s already done.

• Consensus on the mailing list toward Pratik’s work: • Should probably start from that and aggregate

contributions from other people.• If we start with that, the patchset will need to be submitted

in smaller chunks.• Comments from upstream need to be addressed

• AMBA vs platform bus.• debugfs over sysfs.

We have questions...

• Where should the driver live (keeping arch64 in mind)?

• Do we keep both current and new driver in the tree for some time?

• AMBA or Coresight bus?• Russel seemed to favour AMBA (clock issues in mind)• There may be problems with multiple address space

access, i.e config registers + data plane• Do we need ROM table discovery or DT is fine?• What do do about:

• ARMv8• TrustZone and security

Prerequisite for Uptreaming

• Items considered mandatory for upstream acceptance of new patches:• Move current code outside of “arch/arm/kernel”

• Remove dependency on CONFIG_OMAP2

• Move configurables to debugfs rather than sysfs

• Make the driver work on multiple platforms

Prerequisite for Uptsreaming (Cont’d)• No loss of functionality while working on a solution

• Upstream suggested a new kernel config for the driver that is conditional to !CONFIG_OC_ETM.

• That’s exactly what Pratik did.

• Front-end for platforms, back-end for generic parts or multiple drivers for components?• I guess we’ll just have to wait and see.

• Integration with ftrace or perf is a must• Mandate intimate knowledge of ARM PFTv1.1.• I would start with ftrace because of kernelshark.

Linaro’s Initial Proposal

• Start with Pratik’s work but:• Rebase everything on 3.15.• Add coresight components to beagleXM’s DT spec.• Get the code working.• Add enhancement from Google and A. Vergé (if not

already present).• Address initial upstream comments (sysfs and AMBA)• Send patches with ETM/ETB only as initial RFC.• Add more advance features when the quarks of the initial

jet have been resolved.• With an initial framework, other people will be

able to add in their code.

Who’s Willing to Help?• If you have ETM/ETB/Coresigh work done

internally, your opinion counts.

• We need development boards with Coresight enabled SoCs.

• I will start consolidating all this work:http://git.linaro.org/git/people/mathieu.poirier/coresight.git

Your Turn: Open Discussion

Mathieu Poirier: mathieu.poirier@linaro.orgMore about Linaro Connect: http://connect.linaro.org

More about Linaro: http://www.linaro.org/about/More about Linaro engineering: http://www.linaro.org/engineering/

Linaro members: www.linaro.org/members