Revision 3 as of 2011-03-25 18:15:24

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.

http://wiki.linaro.org/WorkingGroups/ToolChain

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

http://wiki.linaro.org/WorkingGroups/KernelConsolidation

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

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.