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
- 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
- Fixing Issues with on-demand governor for frequency scaling
- 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. |