Advanced Development Technical Topics

This wiki pages contains advanced development technical topics. These are (potential) research topics during the November 2010 - May 2011 engineering cycle. These would be activities sponsored by the Linaro TSC and outside of normal engineering cycle activities. They usually result in a document together with a recommendation as to how best to proceed. Some of them are derived from 'washboard' items, those that are hovering on the edge of technical requirements, either because they were rejected as too low a priority or because there is insufficient information to proceed. If engineering priorities get changed, or if resource can be found, then they may come back into the engineering cycle.

Advanced Development Technical Topics

Key:

Key

Description

Rejected

Not considered in this cycle

Essential

Must happen in this cycle

High

Desirable in this cycle

Medium

Would like to happen in this cycle

Low

May be dropped from this cycle

Advanced Development Technical Topics:

Ref

Name

Type

Description

Reference

AD-T

Tools

AD-T1

Windows hosted cross tools

High

Windows hosted cross development environment

Windows Hosted Toolchain

AD-T2

Crash

Low

Red Hat crash utility.

http://people.redhat.com/anderson/crash_whitepaper/, tr-toolchain-dev-tools

AD-T3

CPU configuration tools

Low

Tools to show and modify CPU configuration, such as L2 cache mechanisms

AD-T4

Userspace performance tools

Low

Tools displaying user level performance metrics. What tools exist, what should be created?

AD-T5

LLVM

Medium

Monitor LLVM (also, what is our long term approach?

llvm-investigate

AD-M

Middleware

AD-M1

Libunwind

Low

Investigate, may only require a small effort to fix.

tr-toolchain-dev-tools

AD-M2

USB OTG and / or Android gadget stack

Low

Are these areas that Linaro should get involved with?

http://en.wikipedia.org/wiki/USB_On-The-Go, USB OTG and Android Gadget Stack

AD-M3

WLAN throughput, stability, performance

Low

AD-M4

Wayland

Low

Are any distributions planning to make use of this within cycle 2 or 3? Probably should monitoring activity

Wayland, http://groups.google.com/group/wayland-display-server

AD-M5

HDMI Driver

Low

This is probably a Landing Team activity

AD-M6

OpenMAX Bellagio layer

Rejected

Donate member code allowing dynamic codec plug in

http://omxil.sourceforge.net/

AD-M7

Webkit

What work, if any, should Linaro be doing on !Webkit?

http://webkit.org/

AD-M8

OpenJDK

What work, if any, should Linaro be doing on !OpenJDK

http://openjdk.java.net/

AD-P

Platform

AD-P1

Google Android build infrastructure work

Rejected

This is outside of Linaro's scope

AD-A

Architecture

AD-A1

L2 Cache maintainance

Low

Benchmark and tune L2 cache operation efficiencies

L2 Cache Operations

AD-A2

Atomic memory operations / memory barriers

High

Efficient ARMv7A atomic memory operations

Supporting Atomic Memory Operations, atomic-memory-operations

AD-A3

Hardware vfp / ABI

Medium

Rollout and testing of Hardware VFP ABI support

Hardware VFP

AD-B

Boot

Essential

Boot

AD-B1

Boot architecture

Overall boot architecture specifying roles and interfaces between the boot agents, the kernel and the applications

Boot Architecture

AD-B2

Boot performance

Benchmark and tune boot performance in the bootloader, kernel and system.

Boot Performance

AD-B3

UEFI

Investigate use of UEFI, fit with FDT / uboot

UEFI, Releases/1105/TechnicalTopicsAD-UEFI, http://www.uefi.org/home/

AD-AVI

Automotive IVI

Medium

Automotive IVI, http://www.genivi.org/

AD-AVI1

Automotive

Investigate additional engineering effort needed to support automotive use of ARM embedded Linux


Windows Hosted Toolchain

This was discussed (and rejected at the Milan TSC). There has been some further thinking on the scope of this work. By 'supporting windows core toolchain, we mean building and testing command line only flavours of gcc, binutils, gdb etc running via cygwin. Linaro's primary tools support is focussed on the A profile ARM architecture running Linux. Support would be limited to fixing serious code creation problems that don't have work arounds (this would be true across all host types) and crashes (which would be per host type). If Linaro were to do this work, it would be useful to any cross toolchain hosted on windows, for example Android, or to other tools providers.

Supporting Atomic Memory Operations

As ARMv7A, ARM atomic memory operations (via LDREX, STREX, CLREX instructions) are used within ARM Linux in:

  • The kernel to provide atomic kernel operations
  • The kernel to provider user helper functions (essentially these are functions mapped into each user's address space). These are selected at run time by the kernel based on the version of the architecture of the CPU.
  • Library support code
  • gcc intrinsics (atomic operation code emitted versus emitted call to the kernel user helper functions)

It is not clear that all of these changes have been implemented or, if they have, when they're available. As an example, the __sync primitives are now properly supported in GCC 4.5 and map through to the LDREX, STREX, DMB instruction sequences on the ARMv7A and to the kernel helpers on others. The Toolchain WG plans to change GLIBC to use these __sync primitives.

Create a report (wiki page) detailing:

  • Describe for each of the above pieces of code which releases are the various changes are in

  • What work is missing?

  • Recommended future work in this area, if any

NOTE: The scope of any library work should be limited to software being worked on in Linaro or relied upon in Linaro for testing / validation.

L2 Cache Operations

Investigate the L2 cache operations to see what opportunities there are for tuning them for efficiency. This is reliant upon one or more platforms running the latest kernel.

Create a report (wiki page) detailing recommended improvements L2 cache operations; any work becoming part of the kernel working group.

Boot

A collection of work needed to make it easier to get fast-booting ARM embedded Linux systems to market. Included is:

  • the roll out of FDT and the uboot improvements
  • uboot / UEFI roadmap and consolidation
  • boot architecture
  • boot performance measurement

Boot Architecture

Define an ARM embedded Linux boot architecture that defines the roles of the boot agents (uboot, UEFI etc), the Linux kernel and the operating system.

Boot Performance

Take a couple of platforms and measure the boot times, breaking down into 3 areas, boot (ie uboot), kernel (time to the init process), boot to usable graphics.

  • Input is one or more stable platforms running the latest kernel
  • A test head capable of graphics activity (consider actual OS, such as MeeGo or Android)

Create a report (wiki page) TSC detailing the boot performance results and suggesting areas that would help improve overall boot performance times.

NOTE: Any recommended work would be part of an embedded boot architecture project (together with UEFI and FDT).

UEFI

The UEFI standard is starting to gain popularity in embedded systems. Does it make sense for Linaro to do anything here beyond monitoring its progress? This could be part of an embedded boot architecture project (together with Boot Performance and FDT).

Recommend a long term Linaro strategy with respect to UEFI.

Wayland

Wayland is a nano display server, relying on drm modesetting, gem batchbuffer submission and hw initialization generally in the kernel. Wayland puts the compositing manager and display server in the same process. Window management is largely pushed to the clients, they draw their own decorations and move and resize themselves, typically implemented in a toolkit library.

Initially, find out which distributions are interested in including Wayland. If any are, build Wayland for an ARM platform, investigate what improvements need to be made and propose appropriate work packages.

Hardware VFP

Hardware VFP is an ABI change where floating point arguments are passed in VFP / Neon registers. There is much discussion about the effect on system performance, but only where floating point is used extensively. Generally, Thumb 2 gives a better overall system performance improvement. The key thing is the ABI change, which is highly disruptive.

The core GCC toolchain has been stabilized for hardware VFP, both upstream (it will come out in 4.6) and in Linaro's consolidation trees), but Linaro is not building its software that way. Linaro could consider supporting communities (say Debian) using the core tools this way. That would help stabilize the ABI support.

Create a report (wiki page) detailing Linaro's strategy with respect to Hardware VFP

Automotive IVI

Linux in automitive In-Vehicle-Entertainment (IVI) is being driven by the GENIVI Alliance. This was founded on March 2, 2009 by BMW Group, Delphi, GM, Intel, Magneti-Marelli, PSA Peugeot Citroen, Visteon, and Wind River with the goal of establishing a globally competitive, Linux-based operating system, middleware and platform for automotive industry. Since then, the alliance has expanded to more than 50 members who are working together to deliver an open and globally consistent software platform based on Linux for use by the whole car industry. Unfortunately, the Genivi architectural document is not yet public, so working in this space is somewhat difficult in a fully open source environment.

Roughly speaking, an Automotive IVI solution would need the following features over and above a standard desktop Linux solution:

  • Automotive specific kernel device drivers (MOST, CAM)
  • IVI specific software frameworks (AUTOSAR logging etc)
  • Boot time constraints

Investigate and recommend what engineering problems Linaro could help solve, with a long term view to setting up a working group.

USB OTG and Android Gadget Stack

USB OTG: For the most part the only work that needs to be done here is to ensure the USB subsystem on the SoC functions correctly in USB host and slave mode. Two problems occur regularly; autoswitching between host/slave mode when using an appropriate cable and directly connecting to OTG ports.

Android on the other hand only supports gadget mode. It does not support USB host mode. Android often assumes the only removable media is an SDCARD at /sdcard. There is also the problem of power drain, the USB host is assumed to supply power to the USB slaves

Cycles/1105/TechnicalTopicsAD (last modified 2011-03-25 18:14:56)