Technical Requirements

Notes:

  • Anything with a reference is an item that was rolled over from the 10.11 requirements. We'll need to re-number as we enter the May 2011 cycle and start to track these.
  • These requirements need refining to a point where they can be executed by engineering as a series of work items and / or blueprints.
  • For the full May 2011 Technical Requirements specification, see Releases/1105/Specification

Key:

  • Engineering. Requirement sufficiently described. Can be turning into an engineering plan consisting of work packages and blueprints.

  • Refine. The requirement needs some refining before it can be turned into an engineering plan.

  • Effort. Requirement translates to an amount of effort being applied to a problem, rather than a definite deliverable. These are usually 'epic' and cover several releases.

  • Research. The requirement needs a research phase to help narrow down the exact engineering.

Toolchain

As well as feature work upstream, the Toolchain working group needs to continue supporting distributions with with stable and preview tools releases in each cycle. The emphasis in this cycle though is on tools that allow the system to be tuned; be those existing tools that need ARM support adding or new tools that need to be invented.

Core Toolchain

Table N: Core Toolchain Requirements

Ref

Agreed

Type

Requirement

Refine

Create and support a stable toolchain release suitable for downstream distributions. Likely to be 4.5 based, need to decide

Refine

Create and support a preview toolchain release suitable for downstream distributions. Early 4.6

Effort

Ongoing gcc bug fixing. Maintain prioritised bug list.

Research

LLVM (core). Investigate the LLVM compiler framework for ARM. What functionality is missing, what areas need improving

Engineering

GCC autovectorization. Add support for Neon vectorization via the gcc vectorization subsystem

Engineering

GCC Address re-association and mode selection

Engineering

GCC Predictive commoning

Engineering

GCC Register spill/fill

Engineering

gcc back-end rewrite - Push SSA infrastructure into back-end processing

T6

Research

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

T7

Research

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

T13

Refine

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

Engineering

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.

T3

Effort

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

Refine

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

Refine

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

T4bis

Refine

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.

T8

Effort

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

Effort

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.

T18

Effort

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.

Performance

Table N: Toolchain Performance Requirements

Ref

Agreed

Type

Requirement

Refine

Examine performance of and tune operation of Memread / Memwrite, Memcpy / Memset operations. Consider Neon versions

Debug and Visibility

The general theme here is to provide tools that make debuging and tuning ARM based systems easier and quicker.

Table N: Toolchain Visibility Requirements

Ref

Agreed

Type

Requirement

Refine

oprofile - check that it supports ARMv7 (A8,A9) SMP systems. May be validation, but may include bug fixing, back porting

Research

Is there an open source vtune? If not, is it worth creating one?

Refine

User space tool to display CPU Configurations (incl. CP15, GIC, cache L1/L2 cache controller, MMU, etc), configure PMU and export detailed statistics. May need some kernel work.

Refine

Investigate Android tools (which tools?) for latest features (for example, top displays load per thread)

Refine

User space tool allowing dynamic configuration of ARM PMU (Performance Monitoring Unit) and dynamically export statistics like cache miss rates,CPU stall cycles etc

Research

Tool to investigate the throughput of various drivers (MMC, USB etc). Does one already exist? May need to write one.

T5

Refine

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.

T15

Research

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

Research

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

T17

Refine

OpenOCD. Validate its support for ARMv7 Linaro platforms. May include bug fixing.

T10

Refine

Instrumentation trace (software, ftrace and LTTng). Validate support for ARMv7 Linaro platforms. May include bug fixing.

T11

Engineering

Instrumentation trace (hardware ITM/STM, ftrace); includes CoreSight device driver for ITM/STM. Backport and validate ARM efforts as they're upstreamed.


Kernel Consolidation

Kernel Consolidation: Boot

Table N: Kernel Consolidation Boot Requirements

Ref

Agreed

Type

Requirement

Research

Alternative to uboot? Investigate barebox. BSD bootloader? Avoiding a fork?

C7

Research

UEFI support. This was rejected in the last cycle. Is it time to join in?

Kernel Consolidation: Kernel

Table N: Kernel Consolidation Kernel Requirements

Ref

Agreed

Type

Requirement

Rejected

Consolidate ARM platform support in the upstream source tree. This is the job of the member BSP and landing teams.

Refine

Support stable kernel version (including back ports if needed) that could be used by distributions. Need to chose a version

Engineering

Basic pinmux, memory controller and clock setup, the additional peripheral support - MMC, eMMC, mUSB (including gadget and fastboot), and network drivers

Refine

Use LTP, Linux Test Project http://ltp.sourceforge.net/ to help validate consolidated kernels

Effort

Ongoing ARM Linux kernel bug fixing and maintainance (Note: not BSP work)

Kernel Consolidation: Performance

Table N: Kernel Consolidation Performance Requirements

Ref

Agreed

Type

Requirement

Engineering

Efficiency of L2 cache maintenance (invalidate, clean) optimizations

Refine

Video buffer management - phys contiguous, size, fragmentation, sharing buffers, tweaking cache attributes. Virtual Contiguous Memory Manager. Note: May be better being part of the Graphics or Multimedia working groups.

Refine

swap file, swappiness, partition alignment, file system alignment, TRIM support, etc

Refine

Better MMC/SD rootfs support - better SSD tuning

Engineering

Memory segregation (AKA "regions") to enable large allocations (Hot_pluggable_memory(use_case).pptx) and powering off banks of main memory


Power Management

  • http://wiki.linaro.org/WorkingGroups/PowerManagement

  • Priority 1 – Improving Linux Kernel Capabilities for ARM and Real time use cases
    • Fixing Issues with on-demand governor for frequency scaling
      • Currently on-demand governor is not able to scale frequencies for all use cases
      • Because of this, user space apps are manually setting OPP constraints
    • Enhance cpuidle governor to tackle real time use cases (frequent interrupts)
      • Currently CPU Idle governor is not able to predict the next C state properly when use cases are going (because it prediction algorithm is not considering too frequent interrupts properly) Because of this, we have to manually set C state constraints for use cases
    • CPU Idle instrumentation for latency measurement
      • Currently there is no standard method for measuring latencies for various C states. It will be good have a instrumentation framework for measure this latency
    • Enhancement in Governor framework to be more Thermal aware
      • Thermal Management within the Governor code base in Linux that can be generic for all ARM SoCs

  • Priority 2 – Additional Improvements in Kernel and ARM specific frameworks
    • Debug capabilities in PM to debug issues in low power use-cases (OS Idle & suspend resume)

    • Support for Bus/L3 interconnect governor
    • User space policy manager for frequency management and cpu hot-plug features
  • Priority 3 – SoC Driven Improvements
    • CPU Freq governor Improvements to support multiple CPUs and/or co-processors
    • Battery driver improvement for charging algorithm and battery status

Table N: Power Management Requirements

Ref

Type

Type

Requirement


Emulation Platforms

Table N: Emulation Platform Requirements

Ref

Type

Type

Requirement

Engineering

Check that QEMU supports ARMv7A, VFP D16, Neon. If not, bug fix.

Effort

QEMU: General maintainance and bug fixing (prioritize and fix). Create and maintain QEMU consolidation tree.

Effort

Add support in QEMU for Linaro platforms. Note: may be done by member BSP and landing teams, but would need consolidation


Middleware

Middleware: General

Table N: Multimedia General Requirements

Ref

Agreed

Type

Requirement

Research

OpenCL. What is the future of OpenCL within Linux? Is this something that the community will standardise on?

Middleware: Graphics

These requirements are being investigated and refined by the Graphics WG (WorkingGroups/Middleware/Graphics).

Table N: Multimedia Graphics Requirements

Ref

Agreed

Priority

Requirement

Accelerating X. DRI2, GEM, OGLES, EXA, xrandr, xrender – any standardization from ARM perspective?

X11: Better unified memory support

X11: Standard GLX replacement. FSL has custom X extension underneath EGL for sharing buffers

Common OpenMax core supporting vendor plug ins

Chromium browser full-screen video output path optimization

OpenGL/ES and/or OpenVG backend for Cairo

Middleware: Multimedia

Note: Need to get the multimedia working group going so that it can help refine these requirements.

Table N: Middleware Multimedia Requirements

Ref

Agreed

Priority

Requirement

Support standard baseline of ARM based codecs for Audio, Video, Imaging – that can be leveraged across all ARM SoCs

Support consistent Neon acceleration libraries that ARM SoCs can use for Multimedia, Display blt, 2D, memcpy and any other common domains that benefit from Neon – Base / Minimal Common Domain need based routines on Neon

Neon optimizations in libpixman, libjpeg, libpng, ffmpeg, other open codecs? VP8?

gstreamer / OpenMax optimizations

Middleware: Web 2.0

Table N: Middleware Web 2.0 Requirements

Ref

Agreed

Priority

Requirement

Research

Consider ARM optimizations for Webkit, various JVMs

System Services / Startup

Table N: System Services

Ref

Agreed

Type

Requirement

M14

Refine

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

M15

Refine

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


Platforms and Infrastructure

User Platforms

http://wiki.linaro.org/Platform/UserPlatforms

In the November 2010 cycle we have concentrated on a minimal test head, used primarily for testing Linaro deliverables but also as a tool for silicon and IP providers to use during their development flow. As we move into the next cycle, we need to decide how much effort to put into test heads versus effort into integration of build systems with down stream distributions.

Infrastructure

http://wiki.linaro.org/Platform/Infrastructure

In the November 2010 cycle, the infrastructure has built and a refined a number of tools that are used within Linaro to create and manage Linaro software. For the May 2011 cycle, we need to be looking at how Linaro deliverables can be integrated into distributions and organisations. In particular those that use the Open Build System (OBS) as the basis for their work.

Table N: System Services

Ref

Agreed

Type

Requirement

Research

Look at how to integrate Linaro engineering deliverables with Linux Foundation OBS.

Cycles/1105/TechnicalRequirements (last modified 2011-03-25 18:15:24)