Linaro 10.11 Deliverables Against Requirements

Keys:

  • RAG is (R)ed, (A)mber, (G)reen. Red is not going to happen this cycle, Amber is part of it will be done in this cycle, Green is done and delivered. As an example, the Graphics RAGs are all R as we have not set up that working group this cycle

  • Delivery is where has this been delivered; upstream (say 2.6.36), staging tree (GIT tag foo), release


Kernel Consolidation

Linaro has an overall goal of the Linux kernel tree at kernel.org 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.

Link to working group page: http://wiki.linaro.org/WorkingGroups/KernelConsolidation

Table 1: Kernel Consolidation Requirements

Ref

Agreed

Priority

RAG

Delivery

Requirement

C1

A

Essential

G

existing support in the Ubuntu maverick archive and all images built based on this

ARMv7A standard configuration

C2

A

Essential

G

support for supported platforms comes from a single git tree git.linaro.org/linaro/linux-linaro.git and goes into a single source package https://launchpad.net/ubuntu/+source/linux-linaro

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

A

most of the core support merged upstream, but small set of key boot interface patches still being discussed by upstream ARM maintainers; support for i.MX51, ARM Versatile complete, support for Versatile Express being completed, support for OMAP3 just started
ALSA SoC bindings: specified at devicetree.org, but no implementation this cycle

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

A

patches complete, still making their way upstream

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

NOTES

  • Current engineering test platforms are ARM Versatile Express, OMAP3, and i.MX51 (only mainline support, so lightweight)

We completed other work that wasn't identified as a requirement, but was needed or helpful:

  • RCU improvements for embedded platforms
  • implementation of missing security features on ARM
  • and lots of small bug fixes, cleanups, and improvements

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

RAG

Delivery

Requirement

C5

High

R

jcrigby pursuing some research on boot performance, but not expecting a delivery this cycle

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

G

all supported platforms have support in Linaro's u-boot tree; the Versatile Express are being upstreamed

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

N/A (rejected)

N/A (rejected)

UEFI support.

NOTES

We completed other work that wasn't identified as a requirement, but was needed or helpful:

  • patches for u-boot DeviceTree support on ARM

  • upstream support for Vesatile Express in u-boot


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.

Link to working group page:http://wiki.linaro.org/WorkingGroups/ToolChain

Table 4: Toolchain Requirements

Ref

Agreed

Priority

RAG

Delivery

Requirement

T1

A

Essential

G

existing support in the Ubuntu maverick archive and all images built based on this

ARMv7A standard configuration

T2

A

Essential

G

See Launchpad for tarballs and source. Changes will soon go upstream and land in 4.6

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

A

Initial delivery done. Continuing work in 11.05

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

G

Completing now

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

G

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

T4bis

High

G

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

G

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

R

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

T7

High

R

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

T8

Essential

R

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

R

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

R

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

R

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

R

Not validated

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

R

Not done in a formal manor

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

G

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

R

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

R

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

T17

High

R

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

T18

Essential

G

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

G

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

G

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

G

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

Notes:

Tuned T2 compiler:

  • CSL 4.4 patches are done
  • Patches are being brought forward to 4.5
  • 4.5 will be available as a experimental compiler for the release

Library tuning:

  • Routines exist
  • The risks are resources, license issues, rewrites to work around licensing, and making available to the test head

Safe atomic memory operations and tuning for efficient SMP operation:

  • ARM have fixed the sync primitives upstream. TCWG To backport

  • Scope of other changes are unknown
  • 'Efficient' operation is a new topic

GCC tuning around Thumb 2 code size improvements:

  • There will be some, but this is a 'epic' task that will span many milestones

GCC tuning around A9 conditional execution tuning:

  • ARM work exists. TCWG to backport
  • <#FF0000>No hardware access to do benchmarking or new work on

Valgrind:

  • No resource

Link time optimisations:

  • No resource, low priority
  • Note that GCC itself can do local LTO without the linker
  • A 4.5 feature, but according to the rest we don't have to deliver a 4.5 compiler...

Profiler driven feedback for ARM GCC:

  • Low priority

GDB hardware debug and watchpoints:

  • Could be investigated
  • Can be pulled in providing the work is already done upstream

GDB ARM Thumb 2 IT instruction stepping:

  • Can be pulled in providing the work is already done upstream

Instrumentation trace (software, ftrace and LTTng):

  • No resource

Instrumentation trace (hardware ITM/STM, ftrace):

  • No resource

Performance events supports ARMv7A:

  • No resource
  • Can be pulled in providing the work is already done upstream

Benchmarking ARM GCC against Atom GCC:

  • Can be done in a basic way
  • Useful as a internal progress indicator
  • Workload and benchmarks will not be rigorous enough to publish

Validation framework for GCC, GAS and GLD:

  • MLH doesn't know what this means

Validation framework for performance events (supports T11):

  • No resource
  • MLH doesn't know what this means

Validation framework for debug and instrumentation:

  • No resource
  • MLH doesn't know what this means

OpenOCD [6]:

  • No resource

GCC bug fixes:

  • A 'epic' task. Bug fixes are being made

All of the development tools should be available self hosted:

  • Implicit in the tools that we are using

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:

  • Marcin is making good progress
  • GDB is not on the list

Support Qemu [7] with ARMv7A

  • QEMU already supports some ARMv7 platforms
  • Peter will do minor improvements by the milestone


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.

Link to working group page: http://wiki.linaro.org/WorkingGroups/PowerManagement

Table 5: Power Management

Ref

Agreed

Priority

RAG

Delivery

Requirement

M1

R

R

No resource

Power management support for device trees

M2

Essential

G

Patch accepted in powertop upstream

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

M3

Essential

A

Powerdebug tool started, dumps regulator and clock information

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

M4

A

High

R

Invalid requirement, nothing special required for ARM

Common Regulator Framework for ARM platforms.

M5

A

High

A

Patches reviewed upstream for latency measurement infrastructure, refactoring ongoing

Generalized CPUfreq and CPUidle drivers based on M4. See blueprint. This task has several work items which are listed in more detail in the Master Task List

M6

A

High

R

No resource, parts being done under Device Tree work (common clock API)

Clock-tree / power domain / LDM population based on M4.

M7

R

No resource, belongs to Tool group? Needs better specification

Power management validation framework, supports M1-M6

M8

High

R

No resource, Needs better specification

dbus service abstraction supporting gnome panel

Notes

  • Any ARM platform implementing cpufreq and cpuidle drivers should now see the states reflected in powertop
    • Still no standardisation on what the C-state mapping means on ARM platforms

Graphics

This WG has not yet been created; we are in requirements gathering mode for the 11.5 cycle.

Link to working group page: TBD

Table 6: Graphics Requirements

Ref

Agreed

Priority

RAG

Delivery

Requirement

M9

A

Essential

R

11.05

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

11.05

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

R

11.05

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.

Link to working group page: TBD

Table 7: Telephony Requirements

Ref

Agreed

Priority

RAG

Delivery

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).

Link to working group page: TBD

Table 8: System Services

Ref

Agreed

Priority

RAG

Delivery

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

Link to working group page: http://wiki.linaro.org/Platform/Infrastructure

Table 9: Build Infrastructure Requirements

Ref

Agreed

Priority

RAG

Delivery

Requirement

P1

R

N/A

G

Rejected by TSC. ARMv7 only

Support multiple architectures (ARMv6, ARMv7 etc.)

P2

A

Medium

R

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

G

minimal headless image available; dpkg support for excluding documentation at install-time available.

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

P4

A

Essential

A

LP, PPA

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, https://blueprints.launchpad.net/ubuntu/+spec/arm-m-private-archive-hosting-infrastructure and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-derived-archive-rebuild

P5

A

Essential

G

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

G

per DEB

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

P7

High

R

No agreement by TSC.

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

P8

High

G

LP

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

P9

A

Essential

G

packages in Ubuntu 10.10.

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

A

PPA LP LP

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 visualization 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, https://blueprints.launchpad.net/ubuntu/+spec/arm-m-webkit-and-browser-performance and https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-testsuites-and-profilers

P11

A

Essential

A

Experimental modifications to bootchart to add memory profiling (PPA); minimal changes to memory footprint expected for this cycle

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

RAG

Delivery

Requirement

P12

Essential

G

PPA

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

Notes

P1: Requirement rejected by TSC. Linaro will only support ARMv7.

P2: Poor requirement. Include components in what? I thought we agreed to reject this requirement at the sprint in Cambridge.

P4: This requirement is way to broad in scope. Covers three large topics; derived archives, archive rebuilds and image building.

  • Derived archives are being implemented. Much of this work occurs in Launchpad, and is being done by the Launchpad team. Infrastructure team is working on the ability to derive archives privately. This work is named vostok, and involves deploying a small portion of Launchpad code inside a members premise. Vostok work expected to be complete by 10.11 release, but is dependent upon external Launchpad team for success. Planning phase with Launchpad team took much longer than expected, and resulted in a new blueprint being written. This development is very tight; there is a risk of it being late. Work described in arm-m-development tools postponed as it depends upon the work in active development.
  • Derived archive rebuilds are being implemented. Planning phase with Launchpad team for derived archives occupied much of the teams time, so the implementation was delayed in starting. It is expected to be completed for the 10.11 release, but there is a low risk of it being late. Work described in arm-m-development tools postponed as it depends upon the work in active development.
  • Image building was dependent upon LexBuilder being open sourced. Two specifications were done; one for open sourcing LexBuilder and a fall back position for documentation and modifications to Debian live-helper, should open sourcing LexBuilder not be possible. Most of the live-helper spec has been dropped as the open sourcing of LexBuilder is well under way and expected to be complete for the 10.11 release. LexBuilder may be deployed as either a shared public instance or privately.

P5: The infrastructure currently team currently supports the other teams in the building of evaluation platforms. Our early modifications to LexBuilder concentrated on those changes that removed dependencies on OEM infrastructure to allow Linaro to use the OEM LexBuilder instance for this purpose. I have a bi-weekly call with OEM to coordinate changes to LexBuilder and see they get into the monthly internal releases so the changes get testing before release. The infrastructure team is also working on the development of hardware packs to aid in this goal. We have been working on a specification with the User Platforms group, and will be implementing the spec. The infrastructure team also arranged to have an instance of a tool called ISO tracker available by beta time to help in tracking of the testing of images.

P6: This requirement is handled on per-package basis. It is a normal course of business in the open source world. Such changes either make it into the Maverick archive or are placed in a PPA if Ubuntu will not accept the change.

P7: This requirement was never agreed to by the TSC. There has been some discussion of patch management strategies on linaro-dev, and the Infrastructure team would be happy to investigate the possibility of deploying a PatchWork server next cycle. There is no resource available for this ATM, unless someone is taken away from another task. This would affect our scheduled deliverables.

P8: This requirement was satisfied from startup. The agreement was to use Launchpad for these purposes; which is currently being done.

P10: This is requirement is covered by two tools under development; abrek and the dashboard.

  • Abrek is an application that provides infrastructure on evaluation platforms to install, run and remove tests, and push test results to the dashboard. It is nearly complete and focus is shifting to defining tests for use in the system. We have currently looked into the LTP, OpenPosix and Phoronix test suites, browser startup benchmarks, and have started looking into Javascript benchmarks.

  • The dashboard provides a results repository and visualization tool for the results. Work is ongoing and the visualization tool is expected to be complete with basic views implemented to allow viewing of the results in the repository. The team has started a process of consultation with the members and working groups to seek feedback and information on what views would be interesting to them.
  • Two of the blueprints define the dashboard and abrek. The other two blueprints define the tests and benchmarks we are interested in providing via the tools. Abrek and the dashboard are expected to be ready for the 11.10 release. The tests that were be included were never defined, they were always to be worked on and included as a best effort. Those we did not get to would be pushed off to 11.04. Tests are being evaluated for suitability for ARM, whether they run on ARM now or need fixing, and the length of time the tests and benchmarks take to run.
  • There is no integration with the build system and the QA system planned for 10.11. This issue was deferred until next cycle until the situation with LexBuilder became more clear.

P12: LexBuilder currently has a feature that generates a license report from the list of Debian packages used to create an image.


User Platforms


Link to working group page: http://wiki.linaro.org/Platform/UserPlatforms

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

RAG

Delivery

Requirement

UP1

A

Essential

A

ALIP UI Image (288M) delivered for 10.11; minimal system for early hardware validation postponed

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/DeliverablesVersusRequirements (last modified 2011-03-25 18:14:57)