Linaro10.11 Technical Requirements



Abstract

This document describes the technical requirements for work that will be conducted as part of Linaro.

Keywords

VFP, ARMv7A, SMP, SIMD, Neon, UEFI, Device Tree, SFI, uboot, Thumb 2, ITM, STM, OCD, gcc, gas, gld, gdb

About this Document

Next Steps

This document is being used to generate a number of blueprints [9]. Blueprints describe working projects within Linaro. The first 52 of these were discussed in the ARM strand of the May Ubuntu Developer Summit. This document was further reviewed during the tools sprint the week of 7th June 2010. At this time there are various gaps, these will be filled as the various working groups get established. As their work is planned, the scope of each working group will be reviewed at the TSC.

References

This document refers to the following documents / websites:

Ref

Name

Description

Reference

1

ofono

open source telephony stack

http://www.ofono.org

2

oprofile

Linux profile tool (and kernel patches)

http://oprofile.sourceforge.net/news

3

UEFI

Unified Extensible Firmware Interface

http://www.uefi.org/home/

4

SFI

Simple Firmware Interface

http://simplefirmware.org

5

uboot

Universal boot loader

http://www.denx.de/wiki/U-Boot

6

OpenOCD

Open On Chip Debug

http://openocd.berlios.de/web

7

Qemu

open source instruction set simulator

http://wiki.qemu.org

8

Kernel tree

Linux kernel archives

http://www.kernel.org

9

Blueprints

Linaro ARM blueprints

https://blueprints.edge.launchpad.net/ubuntu?searchtext=arm-m

Terms and Abbreviations

This document contains the following terms and abbreviations:

Term

Meaning

VFP

Vector Floating Point

ARMv7A

ARM Architecture V7, A profile

SMP

Symetric multiprocessing

SIMD

Single Instruction, multiple data

Neon

ARM floating point vector processing engine

Device Tree

Data structure describing system device topology. Passed at boot time from the boot firmware to the kernel.

Thumb 2

ARM Thumb 2 instruction set

ITM

Instrumentation Trace Macrocell

Introduction

Overview

Over the years ARM has contributed code to open source projects and the Linux community to support the ARM architecture and ARM processors, working directly with upstream projects where possible. During that time Linux has grown exponentially and is now poised to become one of the dominant OS players in several of ARM’s traditional market segments including digital TV and set top boxes, automotive, smart books, slates (pads) and smart phones.

Unfortunately for the ARM community, customizing low level code and the current state of project fragmentation makes creating products based on embedded Linux somewhat problematic. The number of ARM based distributions and standards organisations are driving an ever wider choice of kernel versions, boot mechanisms, power management frameworks, packaging formats, graphics sub-systems and so on. If, for example you look at the support for the ARM architecture in the Linux kernel tree you will see roughly three times as many files when compared to some other architectures. Other code bases such as QEMU have a similar story. This is an industry wide issue that will only get worse unless something is done about it.

A somewhat more pressing issue is that for many platforms ARM support is not integrated into the leading edge of the various upstream open source code bases. Even when it is, there may be a significant lag between code finding its way into the trunk development branch, appearing in a stable branch release, and that branch being used to create products.

Platform engineering teams have a tough job coping with silicon delivery, the supporting of many OEMs (and, therefore, Linux distributions and market segment specific standards) and the interacting with the various open source communities. It should also be noted that all of these communities are on different time lines and have differing objectives. Worse still, intellectual property (IP), by its very nature, is secret until it is announced, which further complicates matters.

Linaro aims to help solve these problems by:

  • Working on areas of code and functionality that will benefit the ARM community as a whole. This includes adding support for new ARM based systems where there is currently none along with a focus on low power, which is what ARM does best.
  • Converging ARM architectural and platform support with the various upstream open source projects. Whilst many ARM partners are quickly learning how to interact with the various open source communities, others find it hard to push their patches upstream. Linaro aims to help support the developing, preparing and eventually merging of patches with upstream projects. This will be done by highly skilled expert teams and through the tools Linaro produces to allow patch sets to be managed and tested against known-good, system components
  • Providing 'points of coherence'; stable code that can be taken and used within products as quickly as possible.
  • Supporting as many distributions and OEMs as possible. This will allow the ARM communities efforts to be applied as widely as possible.
  • Providing a collaboration vehicle, a place where the ARM community and open source can collaborate on embedded Linux.

In Summary, Linaro is:

  • A convergence engine
    • Teams, tools and software that converge the kernel, toolchain and middleware source trees
    • Work 'on the trunk'
    • A central resource for embedded Linux on ARM development
  • Vehicle for coherency
    • Coherent and regular releases ready to be used for product and IP development
  • A collaboration space
    • The scope is 'for the good of all ARM vendors and ARM-based embedded communities'
    • A place where ARM and its partners can work together

Scope

alt Teams structure

In order to describe the scope of Linaro we must first map the engineering needs to the teams that will be responsible for delivering the tools, software and engineering effort. There are two distinct areas of effort. The first is the working groups, working exclusively on upstream open source projects and donating resources to open source projects. There are no set boundaries on the scope of the work here, if the goal is of benefit to the whole ARM community then it will be considered by the relevant work group. This includes instruction sets, DSP, GPU and so on.

Linaro initially has three working groups, more will be created as necessary:

  • Kernel and Kernel Consolidation
    • Boot mechanisms
    • Feature enhancement
    • Kernel alignment
    • Platform consolidation
    • Boot and memory usage enhancement
  • Core Toolchain
    • Core tools and toolchains
    • Debugging, instrumentation, profiling
    • Compile and link time optimizations
  • Middleware
    • Power Management
    • Graphics Performance
    • Telephony
    • System services / start up

The teams carrying out this work consists of:

  • Foundations
    • Consolidating the working group's engineering efforts
    • Helping to support the upstreaming of output from the working groups
    • Providing stable, coherent, code bases
    • Ensuring that regular releases are made and support is available
  • User Platforms
    • Creating and maintaining evaluation platforms
    • Supporting teams using evaluation platforms for validation
    • Implementing high-priority user-space features
  • Tools and Automation
    • Tools for validating, measuring and optimizing:
      • web browsers and codecs
      • packaging and the package archive
      • patch review, generation and monitoring
      • image generation and customization
      • configuration tools

The landing teams are an important step for anyone considering benefiting from the Linaro effort. They provide support to the silicon partners, ensuring platform code is integrated and maintained within Linaro. Think of the landing teams as the 'shim layer' between the silicon provider, the Linaro organisation and the various upstream projects. The landing teams may generate, participate and commission generic, useful work in the working groups and foundations teams were it would benefit the whole of the embedded ARM effort. One example is the implementation of generic kernel changes as new functionality is added for one or more hardware platforms thus reducing duplicate code and ensuring that upstream has an easier job of maintaining the platform. From here on in this document describes technical requirements for these areas of activity. In addition it imposes requirements on the build system that spring from the need to support silicon partners developing IP and downstream distributions integrating with Linaro’s engineering. The next sections discuss each of these in turn.

NOTE: Requirements are marked as priority Essential, High, Medium, Low. Which requirements get met in each release will depend on the ultimate level of staffing / funding.


Standard ARMv7 Configuration


  • ARM's licensing model allows partners to choose which architectural features to support. This works well in the embedded system world, but creates a level of fragmentation in a more platform orientated world. With that in mind, Linaro would like to choose a standard ARMv7A configuration:
  • ARMv7-A profile (ARM, 16 & 32-bit Thumb)

  • Explicitly excluding Jazelle DBX and RCT, Thumb-EE
  • VFPv3 D32 fully in hardware – no support code for denorms etc
  • User traps not required
  • Advanced SIMD (Neon)
  • Security Extensions
  • Multi-core (SMP)

Of course, we need to recognise, at least in the short term, that not all ARM based systems will match this configuration. Handling this practicality imposes requirements on the build infrastructure.


Kernel Consolidation


  • Linaro has an overall goal of the Linux kernel tree at kernel.org [8] having the latest support for all ARM platforms. A fully generic kernel that could run on several, highly variant, ARM platforms is also a goal, but we recognise that this may take some time. In order for this to happen, and to help upstream ARM platform support, there needs to be a degree of kernel consolidation work. Essentially this means moving platform and device specific code out of both the ARM and generic infrastructure areas. In some cases, this may mean creating infrastructure to allow this to happen.

Table 1: Kernel Consolidation Requirements

Ref

Agreed

Priority

Requirement

C1

A

Essential

ARMv7A standard configuration

C2

A

Essential

Single ARM kernel source tree for all Linaro supported platforms. There needs to be some initial investigation (experiment) looking at the road blocks for consolidated kernels, this may throw up some more work. C3-C5 are the basic building blocks. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-kernel-version-alignment

C3

A

Essential

Support for device trees. We may need to align device tree format between UEFI/SFI. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-using-device-tree-on-arm and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-alsa-soc-fdt-bindings

C4

A

Essential

Support for pluggable timers and interrupts. The clock API looks useful here. https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-using-device-tree-on-arm

Boot Firmware

Many ARM platforms today use uboot [5] within as they boot. Whilst UEFI [3] is a potential future standard, Linaro aims to standardise the use of uboot within the ARM architecture, adding features and helping to unify the code base.

Table 2: Firmware Requirements

Ref

Agreed

Priority

Requirement

C5

High

Minimize the boot time attributed to uboot, perhaps by storing previous boot states and removing device probing etc in the normal case. https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-uboot-features-and-performance

C6

A

High

Uboot as the standard supported loaded. Includes uboot standard version plus features (to be agreed). See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-uboot-features-and-performance

C7

R

Low

UEFI support.

Core Toolchain

Tools are a key part of the Linaro concept. Provision of ‘best in class’ tools for ARM, underpinning ARM Linux distributions are key to the adoption of the ARM architecture in today’s (and tomorrow’s) embedded Linux systems. This document looks at the work packages involved in delivering tools1. It includes:

  • GNU Core Tools. GCC, GAS, GLD (compiler etc) and GDB (debugger).
  • Profiling tools. Oprofile [2] and performance events.
  • Instrumentation support. Ftrace and LTTng based event transport via TCP/IP and debug hardware plus event viewer.
  • Debug.
  • Valgrind
  • Qemu.

ARM itself carries out tools work as part of creating the ARM architecture. It donates code into upstream open source tools projects where they can be then taken and used within Linux distributions and products. That work is documented elsewhere; this document describes tools work within Linaro. The issue that Linaro can help solve is twofold. Firstly, and this is a key goal for Linaro, it can help aggregate future patches into the current stable tree (for example gcc 4.4.4) and, secondly, it can provide a focus for working on Linux specific tools such as LTTng.

Table 4: Toolchain Requirements

Ref

Agreed

Priority

Requirement

T1

A

Essential

ARMv7A standard configuration

T2

A

Essential

Tuned T2 compiler. Includes backporting CodeSourcery Q1/2010 and PD Tools trunk based work into GCC 4.4.4. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-tool-chain-selection

T3

Essential

Library tuning. This includes the use of efficient ARMv7 instructions when copying memory and so on. The libraries affected are glibc, libgomp, binutils. Bunch of tuning already in the CodeSourcery branch of eglibc; could include that and could develop new optimizations. Need to decide on NEON optimized routines, depends on the hardware you have (good on A8, bad on A9; also looks good on benchmarks but uses a lot of power)

T3bis

Essential

Safe atomic memory operations and tuning for efficient SMP operation. The libraries affected are glibc, libgomp, binutils. Exploration stage for now, lead by ARM.

T4

Essential

GCC tuning around Thumb 2 code size improvements. Linaro/CS to identify more optimizations to do around T2 and develop them.

T4bis

High

GCC tuning around A9 conditional execution tuning. Done or being done by ARM; ready to be published to trunk, but needs more benchmarking; will happen in time for 4.6, so before December. Might be hard to backport to 4.4.

T5

Essential

Valgrind. The main Valgrind ARMv7 work is being directly sponsored by ARM, the work in Linaro is, at a minimum, one of validation, however a number of the Valgrind tools need looking at - Massif, Helgrind, DRD, Ptrcheck and Callgrind. Julian Seward porting the core tools, other tools need porting.

T6

High

Link time optimisations. Consider Gold. Gold being considered for build testing, LTO almost impossible to backport to 4.4.

T7

High

Profiler driven feedback for ARM GCC. Not being worked on at this time, needs an owner, might be Linaro in our CFT.

T8

Essential

GDB hardware debug and watchpoints. This work has been done via performance events and donated upstream but will need back porting to the supported Linux kernel version (2.6.35). Will Deacon pushing to 2.6.36, Linaro happy to pull into our arm-next tree since it's going to the mainline.

T9

Essential

GDB ARM Thumb 2 IT instruction stepping. In trunk; Linaro could pull a gdb snapshot; needs some human testing; low risk of taking a snapshot. Some large Ubuntu patches might conflict in the new snapshot, doko could disable this part of the testsuite.

T10

High

Instrumentation trace (software, ftrace and LTTng). Bad coverage in current competencies; no plans on the ARM side. Risk of not being able to progress on providing this feature.

T11

Medium

Instrumentation trace (hardware ITM/STM, ftrace); includes CoreSight device driver for ITM/STM. Roger at ARM leads some effort on that topic, but timeline unclear.

T12

A

Essential

Performance events supports ARMv7A. These patches are in 2.6.34 and 2.6.35, so this work is basically validating that it works on the supported platforms. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-debugging-with-oprofile

T13

Essential

Benchmarking ARM GCC against Atom GCC. Performance normalised for MHz and code size. Need to pick representative code bases / archives etc and track performance and execution footprint changes per build. Supports T1:T7. Needs validation of the toolchain and needs definition of good benchmarks on reference hardware. Should probably reject unless clarified with practical use cases backed by real test cases.

T14

Essential

Validation framework for GCC, GAS and GLD. May include tuned compiler output (A8 versus A9). Already run testsuites (which fail the build if they don't pass) as part of toolchain uploads; full archive rebuilds for major version updates. Could run CSiBE testsuite in our validation infrastructure.

T15

Essential

Validation framework for performance events (supports T11). Will generate bug fixes, enhancement requests etc. Should develop simple sanity checks and simple tests which make sure that some counters turn. Possibly modify gprof to include profile-feedback directed optimizations

T16

Essential

Validation framework for debug and instrumentation. Will generate bug fixes, missing features, enhancements etc against gdb, performance events etc.

T17

High

OpenOCD [6]. Support Linaro platforms. Should be covered with TI engineering partners.

T18

Essential

GCC bug fixes. As bugs are found Linaro will attempt to fix them. This may involve ARM and the wider open source community. ARM has a private bug database and uses the public FSF bugzilla as well; Linaro would track things in the FSF bugzilla and in Launchpad (linking the bugs together) but can't use the private ARM database. Could use working group call to synchronize on high-profile bugs being worked on. People working on a bug fix should assign themselves when working on the bug and unassign when they pause/give up work on a bug.

T19

A

Essential

All of the development tools developed and improved by Linaro within the toolchain working group should be available self hosted. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-tool-chain-selection

T20

A

Essential

The core toolchain (gcc, gld, gas, gdb) should be available with a cross development tools, able to be installed on an x86 based Linux system. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-xdeb-cross-compilation-environment

T21

Essential

Support Qemu [7] with ARMv7A. Mostly bug fixes and validation.

Middleware

Power Management

In some ways, Linaro's work on power management could be considered as part of the kernel consolidation effort. Linaro will concentrate on generic, infrastructure changes, leaving board and system work to be done by the Silicon Partner.

Table 5: Power Management

Ref

Agreed

Priority

Requirement

M1

R

Power management support for device trees

M2

Essential

Power instrumentation UI – ARM ‘PowerTop’, Gnome Panel integration

M3

Essential

‘ARM SoC’ equivalent of (x)mbmon? Common UI and API for accessing process, temperature and regulator information. (Integrated into ‘ARM PowerTop’ ?)

M4

A

High

Common Regulator Framework for ARM platforms. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-kernel-power-management-consolidation.

M5

A

High

Generalized CPUfreq and CPUidle drivers based on M4. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-kernel-power-management-consolidation.

M6

A

High

Clock-tree / power domain / LDM population based on M4. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-using-device-tree-on-arm.

M7

Power management validation framework, supports M1-M6

M8

High

dbus service abstraction supporting gnome panel

Graphics

In the long term, we believe that graphics acceleration via a standard API such as OpenGLES makes sense. However, there are a number of ARM based devices that are built using X. ARM platforms use a variety of graphics acceleration devices, so, again, this work is really about consolidation, looking at what parts of the X 'plumbing' might be refined in order to allow better overall graphics acceleration via a number of methods, including Neon, GPU and DSP.

Table 6: Graphics Requirements

Ref

Agreed

Priority

Requirement

M9

A

Essential

Classic Linux graphics stack (based on X.org and modern kernel interfaces) acceleration. Accelerate for key SoC graphics devices, with special attention given to the range of toolkits and applications being accelerated. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-graphics-stack-on-x .
Documentation on the standard implementation model and SoC-required kernel components will be provided so partners can provide the necessary software drivers to allow for an accelerated graphics experience.

M10

high

R&D experimentation around alternative, lightweight graphics environments will be conducted, evaluating options and providing guidance to early adopters on what software drivers need to be provided in order to achieve performance.

M11

Validation framework for X (question: what already exists?)

Telephony

Ofono [1] is an open source effort initiated by Intel and Nokia to create a telephony stack. oFono core services are accessible via the DBUS IPC. Core stack allows loading hardware-specific plugin modules to allow hardware differentiation. Currently oFono seems to include just plugin for AT-modem. Feature scope includes call control (sending/receiving/interpreting AT-commands in this case). Actual payload, like voicecalls need to be handled by multimedia streaming system. Maemo Fremantle uses Telepathy connection manager and PulseAudio for actual voice streams. Ubuntu uses Pulseaudio and Telepathy natively. NOTE: Integrating a telephony stack such as ofono into an evaluation platform would help validate the overall system's fitness for inclusion in products etc. This implies testing the integration with Skype, Empathy and so on.

Table 7: Telephony Requirements

Ref

Agreed

Priority

Requirement

M12

A

High

ofono. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-telephony-stack and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-ofono-application-experiment.

M13

Telephony test framework, create or leverage existing framework.

System Services / Startup

The traditional sysvinit start up mechansims (together with device probing) are ok for generic desktop systems. For embedded systems, that do not change between boots we need a faster boot mechanisms. Upstart is an event based system that is designed to run starting services in parallel, which will lead into faster boot times. Taking advantage of this feature requires new service startup scripts (although old sysv-style scripts can be used in compatibility mode this will lesser the performance advantage). Upstart is planned to include features of current cron and at daemons in the future (timed events). This will allow dropping these system daemons eventually. Upstart also contains ability to keep processes running if they exit unexpectedly (similar functionality to Maemo's DSME).

Table 8: System Services

Ref

Agreed

Priority

Requirement

M14

Essential

Ability to boot to usable shell prompt in under 2s.

M15

Essential

Ability to boot to a usable graphics shell in under 3s.

Tools and Automation

Linaro needs tools supporting the needs of IP developers and downstream distribution maintainers. This generates more requirements:

  • Reduce the footprint of the released components, both installation and execution space.
  • The ability to include into validation flows components that are only relevant in a particular market segment, for example MOST drivers for automotive
  • Support development of unreleased IP. ARM and its partners need to be able to develop support privately for unreleased IP. This implies:
    • Being able to build all or part of a release privately
    • Being able to validate a release in order to help test unreleased IP
    • Provide a build and source control system where new components can be easily integrated whilst only be accessible by a restricted set of users.
  • Support for testing unreleased toolchains

ARM has traditionally worked closely with upstream projects, avoiding fragmentation and, in particular, forking code bases. For example, it avoids have too many outstanding kernel patches; pushing them upstream as quickly as possible. However, where release cycles are different from an upstream project’s clock tick, then more ‘buffering’ of patches will need to occur. Taking GCC as an example, any Thumb-2 tuning that ARM put into the trunk today may hit the spring 2010 gcc 4.5 release, but that release will probably not be used in products until spring 2011. A potential gap of over a year. This leads to further requirements:

  • The ability to include as yet unintegrated patches to some components; this is probably most likely in the technology areas partners wish to invest in (see below)
  • Patch management systems managing outstanding patches and helping easily integrate them into the upstream projects, avoiding code forking
  • Collaboration infrastructure to track bugs and patches, enabling to rebase code against upstream projects for each release

Table 9: Build Infrastructure Requirements

Ref

Agreed

Priority

Requirement

P1

R

N/A

Support multiple architectures (ARMv6, ARMv7 etc.)

P2

A

Medium

The ability to include components that are only relevant in a particular market segment, for example MOST drivers for automotive in validation flows

P3

A

Essential

Reduce the installation footprint. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-on-disk-footprint.

P4

A

Essential

Build all or part of a release privately as well as publically. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-development-tools , https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-image-building, https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-archive-branching and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-derived-archive-rebuild

P5

A

Essential

Support the building of evaluation platforms. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-development-tools and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-image-building

P6

A

High

Ability to include queued upstream patches to some components (support buffering to aid product release timeframes)

P7

High

Patch management systems managing outstanding patches and helping easily integrate them into the upstream projects, avoiding code forking

P8

High

Collaboration infrastructure to manage source code, binary packages, bug tracking and developer interactions

P9

A

Essential

Tools for building and managing archives and packages should be available within a cross build environment. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-xdeb-cross-compilation-environment

P10

A

Essential

Add build infrastructure hooks allowing validation and benchmarking as part of (or as an easily run add on to) the build system. For example, collecting code size information. Also associated 'scoreboard' style visualisation tools for this sort of information. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-automated-testing-framework, https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-validation-dashboard and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-testsuites-and-profilers

P11

A

Essential

Investigate and improve the system runtime memory footprint. See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-memory-footprint

Licensing Considerations

Linux products based on Linaro code bases are sensitive to licenses, particularly GPL 3.0 in run time envrionments. If it is to support downstream distributions, directly or via silicon partners, this adds another requirement onto Linaro:

Table 10: License Requirements

Ref

Agreed

Priority

Requirement

P12

Essential

The build mechanisms must be able to precisely describe and manage all licenses, open and proprietary

User Platforms

Linaro uses user platforms for a variety of purposes:

  • Validate working group engineering, including toolchains
  • Benchmarking engineering activities over time, for example, code size regressions and improvements
  • Provide a vehicle for demonstrating ARM platform
  • Prove fitness for integrating Linaro engineering results with downstream distributions

See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-ui-and-test-heads and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-lightweight-panel-for-efl.

Table 11: User Platforms

Ref

Agreed

Priority

Requirement

UP1

A

Essential

Minimum system, along the lines of AEL / ALIP (see http://linux.onarm.com/index.php/Main_Page). This should include:

* Uboot + flattened device tree
* Core toolchain supported
* Support for performance events
* Support for Ftrace, hardware ITM if available.

See https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-ael-alip-evaluation



Cycles/1011/TechnicalRequirements (last modified 2011-03-25 18:15:30)