LCA14: LCA-14-210: ETM/ETB/Coresight
Upcoming SlideShare
Loading in...5

LCA14: LCA-14-210: ETM/ETB/Coresight



Resource: LCA14
Name: LCA-14-210: ETM/ETB/Coresight
Date: 04-03-2014
Speaker: Mathieu Poirier



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

LCA14: LCA-14-210: ETM/ETB/Coresight LCA14: LCA-14-210: ETM/ETB/Coresight Presentation Transcript

  • 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: • • 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:
  • Your Turn: Open Discussion
  • Mathieu Poirier: More about Linaro Connect: More about Linaro: More about Linaro engineering: Linaro members: