CE Linux Forum
http://tree.celinuxforum.org//images/CELinuxForumLogo_15.jpg

Contents

  1. Introduction
  2. Global Terminology
    1. Normative Language
  3. Introduction
  4. Rationale
  5. Terminology
  6. Work In Progress
  7. Introduction
  8. Rationale
    1. Power Dissipation Elements in CMOS Circuits
    2. Power Reduction Methods
    3. Power Management Architecture
  9. Work in Progress
    1. Platform suspend/resume
      1. Protocol between Energy-Aware Application and Policy Manager
    2. Device Power Management
      1. Automatic Device Power Saving
    3. Dynamic Power Management
      1. Energy-Aware(EA) Application Specification
      2. Performance vs. Battery Lifetime Policy
  10. Introduction
  11. Rationale
  12. Terminology
    1. Acronyms and terms
    2. Compliance classifiers
  13. Platforms
  14. Audio Specification
  15. Video-in/Capture Specification
  16. Video-out/Graphics Specification
    1. Graphics formats
    2. Multi-plane support
  17. Work in progress
    1. Framebuffer specification
      1. YCbCr Format
        1. Resolution Support
        2. Memory representation
      2. Font rendering
      3. Basic 2D acceleration
      4. Video format control
      5. Multi-plane support
    2. DirectFB specification
      1. Important Terminology
        1. Surface
        2. Sub-surface
        3. Primary Surface
        4. Layer
        5. Window/Windowstack
      2. YCbCr Format
        1. Resolution Support
        2. Memory representation
      3. Font rendering
      4. Basic 2D acceleration
      5. Video format control
      6. Multi-plane support
      7. GFX Card Driver
      8. DirectFb benchmarks
  18. References
  19. Remaining Issues
  20. Introduction
    1. Rationale
    2. Scope
  21. Introduction
    1. Rationale
  22. Specifications
  23. Notes (Informational and Non-Normative)
  24. References
  25. Introduction
    1. Rationale
  26. Specification
  27. Notes
  28. References
  29. Introduction
    1. Rationale
  30. Specification
  31. Notes
  32. References
  33. Introduction
    1. Rationale
  34. Specification
  35. References
  36. Introduction
    1. Rationale
  37. Specification
  38. Notes
  39. References
  40. Introduction
    1. Rationale
  41. Specification
  42. Notes
  43. References
  44. Introduction
  45. Specification
  46. References
  47. Interrupt priorities
  48. Prioritized wait queues
  49. Introduction
    1. Overview of "CE Linux"
    2. Introduction of this document
  50. Rationale
  51. Terminology and Definition
    1. Definition
      1. Platform
      2. Measurement Method
  52. Work in Progress
    1. Candidate Projects
  53. Introduction
  54. Rationale
  55. Terminology
  56. Appendix
    1. Typical Embedded Boot
    2. Kernel XIP
    3. Compress FS(initrd)
    4. Compress FS(Cramfs)
    5. Compress FS(jffs2)

Introduction

The purpose of this document is to define and specify features and technologies intended to make Linux a better base for developing consumer electronics products. This document is the result of the work of the CE Linux Forum's technical working groups, addressing technical requirements in six specific areas of Linux where barriers to use in consumer electronics products had been identified. The specification represents the consensus of the forum members in those working groups.

Some of the specifications in this document describe features for which implementations already exist (and, indeed, are already integrated into the 2.6 version of Linux). The purpose of including these specifications is to provide rationale for the desirability of these features in the consumer electronics space.

Other features specified in this document are forward-looking, describing features that have not yet been implemented, or for which the implementations are not yet finished or mature. The purpose of these specifications is to provide developers with guidance in creating or augmenting these features.

The rationale for each specified feature is presented, to communicate and clarify the requirements in the consumer electronics space that affect the design decisions for the (existing or future) implementation of that feature.

This document is targeted at multiple audiences. First, it is primarily directed at system developers who wish to create or extend individual technologies in Linux. The specification will help enable collaboration among them and between them and CE Linux Forum members on development of these technologies. Many of these developers are employees of the member companies of the CE Linux Forum itself. However, this document is also open for public review and comment. Therefore, a second audience for the document is members of the open source community who are interested in embedded use of Linux, or in the specific technologies mentioned herein. For this group, this document should provide rationale for individual desired features, provide input on specific requirements and interfaces, and foster dialog on their design and use.

The scope of this document, in this first release, is limited (with one exception - see Section 5.7) to the Linux kernel. Note that this specification is meant as a guideline for Linux development, not as a formal standard to which an implementation should be claimed to conform.

The CE Linux Forum welcomes any and all feedback and inputs in response to this document. Please direct your comments to the forum’s public mailing list, at: celinux-dev@tree.celinuxforum.org.

Global Terminology

In general, each technology working group defines terminology for their section of the specification. However, the following definitions apply to the entire specification document.

Normative Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119].

This is the specification of bootup time technologies and features, of the Bootup Time Working Group of the CE Linux Forum.

{{{#noprint TableOfContents3 #noprint}}}

Introduction

The specifications of the Bootup Time Working Group deals with reducing the time required to boot a Linux kernel in a consumer electronics products. The purpose of this specification is to define requested or required features of Linux which improve the bootup time of the system for such products. Also, this specification mentions features which, over the long term, will assist developers in measuring and enhancing the bootup time for their systems.

While suspend, resume, and shutdown times are also within the scope of the Bootup Time Working Group, this version 1.0 of specifications does not include any technology in support of reductions in these areas. Reductions in those areas will be covered in future versions of the specification.

Rationale

Users expect to be able to use their CE products very soon after turning them on. Linux, as configured and used for desktop and server systems, exhibits long bootup times - on the order of 30 seconds to a few minutes. The technologies mentioned here (while small in number, in this first release), represent a few mechanisms which can be used to reduce bootup time.

Terminology

The following table presents terms used in this specification related to bootup time technology and features.

Include3(BootupTimeDefinitionOfTerms_R2)

Include3(CalibrateDelayAvoidanceSpecification_R2,"Calibrate Delay Avoidance",1)

Include3(IDENoProbeSpecification_R2,"IDE NoProbe",1)

Include3(KernelXIPSpecification_R2,"Kernel Execute-In-Place (XIP)",1)

Work In Progress

The following item is currently being worked on, but is not ready for publication yet.

Include3(TimingAPISpecification_R2,"Timing API",2)

{{{#noprint VERSION 1.0 - for other versions, click the "info" button.

Table Of Contents: TableOfContents3 #noprint}}}

Introduction

The goal of power management technology is to allow Consumer Electronic (CE) device manufacturers to optimize the power use of their products, including a variety of mobile devices, home appliances, and other end-user devices.

Rationale

In CE products, battery-driven mobile devices have particularly stringent requirements for power management, and this affects the product's competitiveness significantly in specific product categories. Mobile phones and other handheld devices are driven by secondary batteries, not wired power supply. Efficient power usage is required to increase the utilization time of such products.

Power Dissipation Elements in CMOS Circuits

CMOS(Complementary Metal Oxide Semiconductor) circuit has three elements of power dissipation; leakage current, dynamic current, short-circuit current power dissipation. The leakage current power dissipation is caused by the leakage current. The leakage current power dissipation is quadratically dependent on operating voltage but not dependent on clock frequency. The dynamic current power dissipation is caused by the dynamic current which is required for signal transitions. The dynamic power dissipation is quadratically dependent on the voltage and linearly dependent on the frequency of signal transitions. The short-circuit current dissipation is generated by short circuit current when NMOS and PMOS transistors are activated simultaneously. Short-circuit current power dissipation is either linearly or quadratically dependent on the supply voltage, depending on the size of the length of channel between PMOS and NMOS transistors. Of those three elements, the dynamic current power dissipation is a dominant factor because the frequency of signal transitions is very high.

Power Reduction Methods

There are various methods for reducing power consumption: voltage/clock scaling, clock gating, power supply gating, input signal selection and so on.

  • The voltage/clock scaling is the method that reduces both the dynamic power dissipation and the static power dissipation by decreasing voltage and clock dependently or independently.
  • The clock gating reduces the dynamic power dissipation by disconnecting the clock from an unused circuit block.
  • The power supply gating disconnects the supply power from unused circuit blocks, which are components of whole circuit. In clock/power supply gating methods, it is important to decide whether the block is used or not and to restore the blocks when they are used again.
  • The input signal selection affects the reduction of the leakage power dissipation. The input signals of CPU pins should be adjusted to minimize the usage of power when the system is suspended.

Voltage scaling is the key to achieve power reduction and energy reduction. As clear from the analysis of the three power dissipation elements, operating voltage plays a major role in power dissipation. Let's take an example to see how voltage/clock scaling can reduce power and energy. If operating voltage is down-scaled from 2.0V to 1.0V, operating frequency is linearly dependent on the operating voltage in practice. So let us assume clock frequency at 1.0V is half of the frequency at 2.0V. In this case, nearly 87.5% of power can be reduced theoretically. In terms of energy, the total energy for finishing a job need to be compared. Please note that energy is the integration of power dissipation over a period of time. The time taken to finish a job at 1.0V is twice as that of 2.0V. So the total energy required to finish a job will be reduced by 75%.

http://tree.celinuxforum.org/docs/PM_formula.jpg

http://tree.celinuxforum.org/docs/PM_DVS.jpg

Clock gating and power supply gating can be used to reduce power usage by unused blocks. It is important to predict correctly the idle period of a hardware block because incorrect prediction may lead to performance degradation due to the latency of reconnecting clock or power to the hardware blocks.

Power Management Architecture

In designing power management architecture for Linux, the followings are kept in mind.

  • To design a system-level optimization of power usage involving interactions among application, OS, and hardware.
  • To provide a generic power management framework for various hardware platforms

System-level power management is important for coordinating the performance and power dissipation of hardware components in a system. Recently, CPU chip vendors deploy dynamic clock/voltage scaling support in their processors to enable OS-level power management capability. The power reduction techniques offered by hardware components should be synthesized, managed, and adjusted to minimize the power dissipation of the whole system while the requirements of system should be satisfied as well. Existing applications need to be adapted to use the power management capability of operating system and such applications are said to be "Energy-Aware".

The power management architecture is designed to provide a generic framework for various hardware architectures. Hardware specific power control interfaces are abstracted by a power control layer. Power management can be implemented for various hardware platforms by adapting the machine-specific power control layer as necessary.

http://tree.celinuxforum.org/docs/PM_Arch.jpg

In this specification, power management technologies are classified into three categories; platform suspend/resume, device power management, and platform dynamic power management. Platform suspend/resume is aimed at major power state changes at infrequent intervals, while platform dynamic power management is aimed at subtle changes across a wider range of power states at frequent intervals. Platform suspend/resume technology is used for reducing most of power dissipation of a product while the product is idle for a long time. In contrast, dynamic power management is used for reducing power dissipation while a product is being used. Dynamic power management covers also reducing power for very short idle periods of time while a product is busy. Device power management is to suspend/resume devices in a platform, which is used by platform suspend/resume and dynamic power management technologies.

The rest of this specification is organized as follows. In Terminology section, general power management related terminologies are defined. Platform suspend/resume, device power management, and platform dynamic power management are described in separate sections. Work in Progress section describes important on-going projects which are not included in CELF 1.0 spec but need to be considered for next CELF specification.

Include3(PowerManagementDefinitionOfTerms_R2, "Terminology",1)

Include3(StaticPowerManagementSpecification_R2,"Platform Suspend/Resume",1)

Include3(DevicePowerManagementSpecification_R2,"Device Power Management",1)

Include3(DynamicPowerManagementSpecification_R2,"Platform Dynamic Power Management",1)

Include3(VariableSchedulingTimeouts,"Variable Scheduling Timeouts",1)

Work in Progress

Platform suspend/resume

Protocol between Energy-Aware Application and Policy Manager

  1. Energy-aware(EA) application SHOULD register itself to policy manager.
  2. Policy manager SHOULD send system suspend request to all applications registered as EA application.
  3. Energy-aware application SHOULD respond to the system suspend request from policy manager appropriately.
    1. If EA application agree to system suspend, it invokes its suspend handler.
      1. The suspend handler may store important data including user data to a non-volatile storage.
      2. The suspend handler SHOULD send acknowledgement to policy manager and SHOULD wait until it receives resume request from policy manager.
    2. If EA application disagree to system suspend, it SHOULD send negative acknowledgement to policy manager.
  4. If system inactivity which is longer than system timeout threshold is detected, policy manager MUST send system suspend request to EA applications and wait for responses from EA applications.
    1. The policy manager SHOULD provide user interface for initializing the system timeout threshold.
    2. The policy manager SHOULD initialize system timeout threshold to a default value.
    3. The policy manager MAY check device inactivity by periodically reading last access time of device.
  5. If a user has requested system suspend, policy manager SHOULD enforce every EA application to suspend itself and wait for responses from EA applications. An EA application which is enforced to suspend by policy manager SHOULD invoke its suspend handler unconditionally.

Device Power Management

Automatic Device Power Saving

  1. The policy manager set the length of inactivity period for each device.
  2. The period of device inactivity can be detected by PM-engine/device drivers and notified to policy manager via signal.

Dynamic Power Management

Energy-Aware(EA) Application Specification

This specification shall define requirements of energy-aware applications so that application can interact tightly with in-kernel PM-engine to control system power states dynamically adaptive to various application specific environments.

EA application may choose one appropriate operating state among system PM policy. The system policy may be given to the EA application by policy manager or hard-coded, which is dependent on design decisions by system administrator. If the system policy information should be given by policy manager, EA application need to set up a IPC mechanism with the policy manager while it starts up.

For real-time EA applications, the information regarding the real-time task scheduling such as the period of execution and their priorities should be given to in-kernel PM engine via some whatever existing API which we have to choose after extensive discussion on pros and cons of existing APIs. (Linux kernel need to support scheduling periodic real-time tasks.)

There are some cases that an EA application need to change system operating state according to the task's environment. This situation is highly dependent on system constraints which system administrator should know correctly. If a system administrator firmly believe that the operating state of an EA task need to be changed, the decision by system administrator should be respected and the in-kernel PM engine will proceed with the decision. It should be noted that system performance and power consumption efficiency might be greatly hampered if the decision of the system administrator is incorrect. So the system administrator should be very much considerate on changing application operating state.

Performance vs. Battery Lifetime Policy

1. A kernel SHOULD provide userspace interface for specifying requirements on the lower limit of battery lifetime. If the battery lifetime requirement exists, a kernel SHOULD set the operating state of the task to allocate the remaining energy resource amongst all tasks, based on the task priorities, to satisfy this requirement.

{{{#noprint Draft 0.3

Table Of Contents: TableOfContents3 #noprint}}}

Introduction

Audio, video, and graphics processing is at the core of many CE products. The AVG requirements for CE devices are different than those for PCs/Servers, notably with respect to footprint, input devices, interlacing, streaming, etc.. Multiple graphics planes and video planes may be combined using, e.g., alpha blending and animation.

Rationale

No single default/standard interfaces exist for AVG. Having a well defined, well supported interface for AVG devices will reduce fragmentation of solutions and encourage the CE community to develop solutions that apply to conforming interfaces, so that they can be deployed across a wider range of systems.

Terminology

Acronyms and terms

Term

Definition

ALSA

Advanced Linux Sound Architecture -- functional level audio API, now standard in 2.6 Linux kernels, replacing OSS.

API

Application Programmers Interface

ARIB

Association of Radio Industries and Businesses. Most relevant to AVG is the proposed graphics architecture proposed for High Definition TV Broadcast (the 5-plane model).

ATSC

Advanced Television Systems Committee. American standard body for digital television broadcasting.

Back-end Scaler

A Scaler which manipulates the graphics planes and data, but does not allow the host processor access to the (blended) end result, mainly for efficiency reasons.

CCIR 601

In 1982 CCIR 601 established a digital video standard, which uses the Y, Cr, Cb color space (often incorrectly referred to as YUV). Unlike YUV, Cr,Cb range [-0.5, -0.5]. A full conversion matrix is included below (*)

CE

Consumer Electronics: a class of devices used in the home or on the move. Includes DVD, DVR, PVR, PDA, TV, set-top box, cellular phones, etc.

DVB

Digital Video Broadcast: European standards body for digital television broadcasting.

DVD

Digital Versatile Disc: high capacity multimedia data storage medium.

DVR

Digital Video Recorder: a consumer electronic device.

FB,Framebuffer

Abstraction of video-out hardware with a low level (ioctl) API. Standard in >2.4 Linux kernel (see the /usr/src/linux/Documentation/fb kernel tree directory for more information).

Front-end Scaler

A Scaler which manipulates the graphics planes and data and allows the host processor access the (in-between and) end results.

HDTV

High Definition Television: provides a higher quality television broadcast, with progressive and interlaced ( 720p to 1080i ) video and support for 16:9 aspect (movie) ratio.

JPEG

Joint Photographic Experts Group: (lossy) still image compression standard.

MHP

Multimedia Home Platform: an API used together with MPEG-2 transmissions.

MIME

Multipurpose Internet Mail Extension: a standard for identifying the type of data contained in a file. MIME is an Internet protocol that allows sending binary files across the Internet as attachments to e-mail messages. This includes graphics, photos, sound, video files, and formatted text documents.

MP3

MPEG-1 Audio Layer 3: a popular audio compression standard.

MPEG-1/2/4

Moving Picture Experts Group: a compression standard for digital audio & video with varying levels of complexity and achievable compression ratios.

NTSC

National Television Systems Committee: American standard for analog television broadcasting.

PAL

Phase Alternating Line: American standard for analog television broadcasting.

PNG

Portable Network Graphics: (lossless) still image compression standard.

PVR

Personal Video Recorder: a consumer electronic device.

RGB[A]

Colorspace representation commonly used in computer graphics. It uses three orthogonal components -- Red, Green and Blue -- to represent colors in to human visible spectrum, e.g. by combining red and green as additive colors it can fool the eye into seeing "yellow" light. An optional A at the end denotes the presence of per-pixel alpha. See also CCIR 601.

Scaler

Graphics hardware accelerator which may scale and reformat (e.g. convert from YCC to RGB) graphics data and merge multiple independent graphics planes for final display.

V4L

Video for Linux: low level (ioctl) video input and overlay API, standard in 2.4. Originally designed for control of analog video capture and tuner cards, as well as parallel port and USB video cameras. Incorporated in many other higher level APIs such as DirectFB.

V4L2

Video for Linux, second version, made to be more flexible and extensible. Added specifications for digital tuner control and capture.

YCbCr[A]

Colorspace representation commonly used in analog and digital video broadcasts, and video compression technologies such as MPEG. It uses three orthogonal components, one for luminance (Y) and two for the color-difference signals (Cr,Cb). Since the eye is less sensitive to color than luminance, the color difference signals often get a smaller bandwidth allocated (or lower pixel resolution in the digital domain). An optional A at the end denotes the presence of per-pixel alpha. See also CCIR 601.

YIQ

Colorspace representation commonly used in North American TV broadcast and is similar to YUV (see definition of YUV). The relation with YUV is: I = 0.74 V - 0.27 U and Q = 0.48 V + 0.41 U

YUV

Colorspace representation commonly used in European TV broadcast. It is similar to YCbCr and often meant to be the same (incorrectly) with U referring to Cb and V referring to Cr. With Y (luminance) defined as Y=0.299 R + 0.587 G + 0.114 B, by definition, U=B-Y, thus U represents colors from blue (U>0) to yellow (U<0). Likewise V=R-Y, thus V represents colors from magenta (V>0) to Cyan (blue green) (V<0).

(*) RGB to YCbCr conversion matrix:

Y

0.299 0.587 0.114

R

Cr

=

0.500 -0.419 -0.081

G

Cb

-0.169 -0.331 0.500

B

Compliance classifiers

Terminology conventions are adopted here as they are defined in IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels" (by S. Bradner, March 1997). A compliance classifier from the following set may be used:

  • [M]ust, Required, Shall: This is the minimum set of requirements. The CELF based products are expected to comply with these requirements when expressed in unconditional form. A conditional requirement expressed in the form, "If X, then Y must be implemented", means that the requirement "Y" must be met when the conditional aspect "X" applies to a given implementation.
  • [S]hould, Recommended: Recommended items are optional items that are strongly recommended for inclusion in CELF based products. The difference between "recommended" items and "optional" items, below, is one of priority. When considering features for inclusion in a product, recommended items should be included first.
  • [O]ptional, May: Optional items are suggestions for features that will enhance the user experience or are offered as a less preferred choice relative to another recommended feature. If optional features are included, they should comply with the requirement to ensure interoperability with other implementations.
  • E[X]pressly Forbidden: This term means that an item must not be incorporated in a CELF based product.

Platforms

[O] Three target platforms are used or under consideration:

For the first two, the SystemSizeSpec_R2 page has a full description under "Definition - Platform".

Audio Specification

[O] No additional Audio specifications have been defined. ALSA, defined in kernel 2.6, may be used. Further evaluation is required before it can be considered for recommendation (see work in progress). Future extensions relate to AV streaming and synchronization.

Video-in/Capture Specification

[O] No additional Video input (capture) specifications have been defined. V4L2, as defined in kernel 2.6, may be used.

[O] Proprietary solutions may also be used for video capture and digital tuners if V4L2 does not suffice.

[O] DirectFB may be used as a higher level API.

Note: Video output can be seen as an (interlaced) sub-set of graphics. See graphics specification below for more details.

Video-out/Graphics Specification

[S] The standard Framebuffer is recommended for use in embedded CE devices.

[O] DirectFB may also be used in combination with the framebuffer.

Extensions to both are under consideration (see work in progress).

Graphics formats

[O] The framebuffer supports CLUT, RGB and RGBA packet data formats, but not YCbCr[A]. Hardware capable of accelerating the display YCbCr[A] packed data may develop their own extensions to the framebuffer for now.

[O] Also, the DirectFB framework which supports these formats may be used.

Multi-plane support

[O] Graphics hardware capable of multiple planes may be implemented with a single or multiple device drivers with one device per plane e.g. /dev/fb0, /dev/fb1,.../dev/fb5 for a 5 plane capable device. Front-end based scalers are recommended to use the DirectFB framework.

[O] Back-end scalers may add ioctl's to their framebuffer drivers.

Work in progress

Both DirectFB and the Framebuffer can be extended with YCbCr formats and multi-plane blending features commonly found in embedded CE devices. However, it is likely that only one of them will be supported in the future.

Framebuffer specification

YCbCr Format

Resolution Support

The recommended formats are:

  • 4:4:4 Equal number of samples of Y, Cb and Cr.
  • 4:2:2 Cb/Cr are subsampled by a factor of two horizontally.
  • 4:2:0 Cb/Cr are subsampled by a factor of two in both directions.
  • 4:1:1 Cb/Cr are subsampled by a factor of four horizontally (used in DV).

If any of these formats are used, the CCIR 601 standard must be used. It defines how the data is interleaved and the relative positions of the Cb/Cr samples in relation to the Y samples.

Memory representation

YCbCr may be stored in e.g a framebuffer in various ways:

  • packed YCbCrA 4:4:4 : 32-bit unit containing one pixel with alpha

  • packed YCbCr 4:2:2 : 16-bit unit, two successive units contain two horizontally adjacent pixels, no alpha

  • planar YCbCr[A] 4:2:2 : three [four] arrays, one for each component

  • semi-planar YCbCr 4:2:2 : two arrays, one with all Ys, one with Cb and Cr.

  • planar YCbCr[A] 4:2:0 : three [four] arrays, one for each component

  • semi-planar YCbCr 4:2:0 : two arrays, one with all Ys, one with U and Vs

Following CCIR601, only the packed formats are recommended, with the possible exception of a separate alpha plane in some cases (see ARIB [O6] proposal).

Font rendering

  • freetype [O5]

Basic 2D acceleration

  • lines (horz./vert. vs. anti-aliased lines)
  • rectangles (fill and copy)
  • pixmaps (bitblt, scaling)

Video format control

  • resolution
  • interlaced/progressive

Multi-plane support

  • Each plane is represented by... [/dev/fb0, /dev/fb1,...]
  • Additional API (ioctl) calls... [display order, placement, scaling,...]

DirectFB specification

DirectFB overview [G2] provides a list of currently supported features, summarized below.

Important Terminology

Surface

Memory region physically reserved for rendering pixels. Surfaces are used for regular rendering of pixels, sprites and so on.

Sub-surface

Sub-region of surface. No physical memory allocated.

Primary Surface

Visible screen in full screen mode.

Layer

Each layer is different video memory. They are alpha-blended and displayed.

Window/Windowstack

Each layer may have multiple window. Windowstack is a stack of windows. Each window has surface. Their locations and orders may be changed.

YCbCr Format

Resolution Support

Supported formats are:

  • 4:2:2 Cb/Cr are subsampled by a factor of two horizontally.
  • 4:2:0 Cb/Cr are subsampled by a factor of two in both directions.

Memory representation

  • packed YCbCr 4:2:2 : 16-bit unit, two successive units contain two horizontally adjacent pixels, no alpha

  • planar YCbCr 4:2:0 : three arrays, one for each component

Font rendering

  • DirectFB bitmap font
  • TrueType (using FreeType2)

  • No bold or italics support other than by specifying a different typeface from the same font family.(*)

(*) For example, 'Times New Roman Regular' and 'Times New Roman Italic' correspond to two different faces.

Basic 2D acceleration

  • lines (anti-aliased)
  • rectangles (fill and copy)
  • triangle (fill and copy)
  • pixmaps (bitblt, scaling)
  • Per-pixel alpha blending (a.k.a. texture alpha)
  • Per-plane alpha blending (a.k.a. alpha modulation)
  • Colorizing (a.k.a. color modulation)
  • Source and destination color keying

Video format control

  • resolution
  • interlaced/progressive support

Multi-plane support

  • DirectFB layers (not surfaces) support the concept of planes.
  • Layer API is provided through IDirectFBDisplayLayer Interface.

  • Opacity is available through IDirectFBDisplayLayer::SetOpacity.

  • IDirectFBDisplayLayer::SetScreenLocation() controls scaling of the plane. Back-End Scaler(BES) is used, for instance for Matrox. It requires hardware support.

  • Explicit Front-End Scaler(FES) is not available. Thus, stretched blit to the primary surface should be used.
  • To execute a specific graphics operation (e.g. blitting of a surface), the DirectFB driver will access the memory mapped io ports of the graphics hardware to submit the command to the acceleration engine (actual hardware acceleration is done entirely from user space).

GFX Card Driver

  • DirectFB abstracts the video driver through GFX driver.
  • Graphic operation is executed through IDirectFBSurface interface. The interface calls appropriate callback routine in gfxcard driver(src/core/gfxcard.c). The callback routine decides whether the video device has hardware acceleration capability or not, and invokes appropriate functions.
  • The following is the model used in the core gfxcard driver. Blit, DrawLine, DrawRect and similar operations are implemented in this way:

void dfb_gfxcard_OPERATION() 
{
        bool hw = false;
        lock();
        /* check if acceleration is available, and then acquire  */
        if (hardware_accel_available(OPERATION) && hardware_accel_acquire(OPERATION)) {
                hw = card->funcs.OPERATION();
        }
        /* if hardware acceleration is not available */
        if (!hw) {
                gAcquire();
                gOPERATION();
                gRelease();
        }
        unlock();
}

DirectFb benchmarks

You can refer 'DirectFB' benchmark on various environment from Benchmark section of EvaluateDirectFbTaskPage

References

G - Graphics/Video out:

V – Video in:

A – Audio in/out:

U – Users of AVG:

O – Other:

Note (1) - KD26 refers to the Linux 2.6.X kernel tree, which has a "Documentation" sub-directory.

Remaining Issues

See Work in progress.

Introduction

The goal of the real-time working group is to improve the real-time capabilities of the Linux operating system to address the range of real-time requirements for consumer electronics devices.

Rationale

Consumer electronics devices need to perform many functions interactively and smoothly to meet user-expectations. For example, streaming data needs to be presented to the user without interruptions that would degrade the user's experience. Likewise, a recording device needs to record streaming audio/video data without loss of data. Responses to interactive user commands need to be completed quickly enough that the interface seems responsive to the user.

As an illustration, consider a set-top box playing a movie. The flow of audio and video data through the system has real-time requirements. As each frame of data is accessed from a hard drive it is delivered to subsequent systems (such as decoders, decompressors, decryptors, etc.) which manipulate the data stream and prepare the data for output. The hardware controlling the television signal must receive each frame of data at a fixed frequency in order to present each image in sequence. If a process in the chain of handlers cannot run due to overload of the system or scheduling problems, a frame might be delayed and lost, or the delay might result in the appearance of “glitches” or jerkiness in the images presented to the user.

Scope

This specification is primarily concerned with the Linux kernel, but Linux systems often provide support for functional API's using a mixture of C-library and the Linux kernel system calls. This is especially true for many of POSIX API's, including those that are part of this specification. The appropriate support for the various POSIX functionality elements in this specification may or may not exist in the various C-libraries available for Linux.

Broadly speaking, this specification focuses on the following improvements to the Linux kernel; all designed to make Linux a better real-time operating system.

  • Enhance support for fixed priority preemptive scheduling.
    • From an operating system perspective, this implies that the operating system should allow the system designer/administrator to specify the priorities of different activities in the system. Additionally, the operating system should minimize priority inversion in the system.
  • Enhance coverage of POSIX real-time API's supported by Linux
    • POSIX API's, including various real-time API's have become de-facto standard in the operating system communities and are supported by many general purpose as well as specialized real-time operating systems. Good support for POSIX real-time API's provides a convenient, well-understood API for middleware and application developers.

The Real-Time Working Group recognizes that there is a strong community of developers who believe that the "correct way" to do real-time in Linux is to do it with a "real-time kernel" such as RTAI or RTLinux such that any "real-time task" is effectively prioritized above any Linux activity. This version of the specification has not focused on these "hybrid" techniques, but it does not prevent the use of these hybrid techniques either.

Context switch:

the act of replacing the running task A by another task B. The state of task A is saved, and A is placed in the ready queue; the state of task B is restored, and B becomes a running task.

Critical section:
a brief interval during which a task accesses shared data. During this interval, no other tasks are allowed to access the same data. One way of ensuring this is to prevent preemption during the critical section. If the critical section defers preemption for a bounded interval, the resulting priority inversion is bounded.
Deadline-monotonic priority setting:
the task with the shortest relative deadline is assigned the highest priority.
Deadline requirement:
a real-time requirement that requires the response to be completed within a fixed time interval from the triggering event. A

relative deadline is the duration of the above mentioned interval; an absolute deadline is the moment in time at which the response must be completed.

Fixed priority preemptive scheduling:

the task with the highest priority is always running. If a task with a higher priority becomes runnable, the running task will be preempted immediately. The priority of a task, process or Interrupt Service Routine (ISR) is explicitly determined at creation, or by an explicit set-priority command. No implicit priority changes by the scheduler are assumed. For an exception to this rule see Priority inheritance. Note: Fixed priority scheduling is typically designed to be used for a single coherent application.

Granularity:
the time range of a certain interval. We can talk about the granularity of a timing requirement, of a non-interruptible code segment, etc.
Hard deadline requirement:
missing the deadline is considered an error.
Hard real-time system:
system with hard real-time requirements.
Hybrid real-time system:
system with both hard and soft real-time requirements. CE systems are expected to be of this kind. The challenge in designing a hybrid real-time system is to get good soft real-time performance while meeting the hard real-time requirements. This is typically achieved by using a technique called reservation.
Interrupt latency:
time passed between interrupt occurrence and activation of interrupt handler.
Interrupt masking:
Making certain interrupts invisible to the software.
Interrupt response time (worst-case):
(worst-case) time passed between interrupt occurrence and either completion of interrupt service routine (ISR) or wake up of dependent task.
Jitter – absolute:
deviation of the occurrence of an event (e.g. completion of frame) from expected occurrence.
Jitter – relative:
deviation of the interval between two successive occurrences of an event (e.g. completion of frame) from expected interval.
Mutual exclusion:
prevent multiple tasks or ISRs from accessing the same data concurrently. Mutual exclusion is used to protect the integrity of the data.
Preemption:
a running thread or process can be temporarily suspended. The state of the thread or process (including e.g., program counter, and register values) is saved. Until the thread is resumed, it remains runnable (active, ready). When the process or thread is later resumed, the saved state is restored.
Priority inheritance:
if a high priority-task blocks for a critical section, a low-priority task that has holds the lock for the section gets a priority boost. It inherits the priority of the blocked task. This prevents the unbounded priority inversion that could occur if medium priority tasks would preempt the lower-priority task that holds the lock. Note that, with priority inheritance, the medium-priority tasks suffer priority inversion as well. But, and this is important in real-time systems, the priority inversion for all tasks is bounded (can be determined without knowing the exact run-time schedule)
Priority inversion:
the highest priority task is not running. There can be several reasons for priority inversion. One of them is the absence of full preemption. Priority inversion is one of the main reasons for deadlines being missed.
Real-time requirement:
a requirement on the completion time of a response, generally measured relative to the event that triggered the response.
Real-time system:
system with one or more real-time requirements.
Response time (worst-case):
(worst-case) time passed between event occurrence and completion of the response to that event. The event may be an interrupt. The response typically involves an interrupt handler and one or more synchronized tasks.
Runnable task:
(also ready/active task) a task that can run from a logical perspective, but is prevented from running physically.
Semaphore:
a synchronization primitive often used to achieve mutual exclusion.
Soft deadline:
missing deadlines is sometimes acceptable. Compared to hard deadlines, where there is no reason to consider the value of a late result, the value of a late result for a soft deadline is of interest. The value of the result may, for instance, decrease linearly after the deadline.
Soft real-time requirement:
soft deadline, or average-case response time requirement. Note that hard and soft real-time requirements are orthogonal to the temporal granularity that is required. Meeting a soft requirement in the microsecond domain may be more difficult than meeting a hard requirement in the milliseconds domain.
Soft real-time system:
system with soft real-time requirements

Introduction

Even though Linux allows preemptive priority scheduling of processes, the Linux kernel itself is non-preemptible through version 2.4.x. A preemptible kernel allows a (low-priority) process to be preempted even while it is executing in the kernel.

Rationale

Fixed priority preemptive scheduling for real-time tasks is considered a basic characteristic of real-time operating systems. This scheduling behavior is also specified in the POSIX real-time scheduling specifications. Linux has supported POSIX real-time scheduling classes (SCHED_FIFO and SCHED_RR) for a long time, but real-time tasks in Linux can still experience significant amounts of priority inversion. One major cause of this priority inversion has been that while Linux supports fixed priority preemptive scheduling, the Linux kernel itself has been non-preemptible up until version 2.4.x. Making the Linux kernel preemptible is a significant step towards enhancing the real-time capabilities of the Linux kernel.

Specifications

During normal operation of the system the kernel shall be preemptible except under the circumstances indicated below.

  1. Normal operation of the system shall include the execution of the system after the boot process is complete and before shutdown is initiated.
  2. Preemption may be disabled when the kernel is running inside a critical section.
  3. Preemption may be disabled when the kernel is running in a non process context.
  4. Preemption may be disabled when the kernel is being interactively debugged.

Notes (Informational and Non-Normative)

While the specification takes steps towards improving the real-time characteristics, the user still needs to be aware of the potential for significant priority inversion due to the possibilities of preemption being disabled in the kernel under various circumstances. There are various techniques to further improve the kernel preemptibility.

One such technique is to divide (large) critical sections in the kernel into multiple (shorter) critical sections. Various kernel patches that do this are often termed as "low-latency" or "lock-breaking" patches. Several such patches have been available for 2.4 Linux kernel. Many of those patches were adapted and integrated into 2.6 Linux kernel.

Another technique is to enable preemption within some critical sections by protecting the critical section using a semaphore or mutex (ideally with priority inheritance support).

References

Support for preemptible Linux kernel is integrated into the CELF kernel.

Patches for 2.4 Linux kernels are generally also available from http://kpreempt.sourceforge.net

Support for Linux kernel preemption is also integrated in 2.6 Linux kernels.

Introduction

The 2.4 Linux scheduler maintains the active queue as a list of processes sorted by priority. Inserting a process in this list is an O(n) operation, where n is the number of active (runnable) tasks. Since insertion in the active queue is a component of preemption time, this makes preemption time dependent on the number of active processes in the system. Schedulers with performance that is independent of the number of active processes have been available for years, and the standard Linux 2.6 scheduler meets that requirement.

Rationale

Preemption time is an important factor in real-time performance, and directly effects real-time performance metrics such as interrupt response time. When the scheduler can take time that is proportional to the number of tasks in the system, then the interrupt response time is adversely effected when there are a large number of tasks in the system. While many CE devices may not benefit from a constant-time scheduler (given that they often have a limited number of tasks), it is expected that higher end CE-devices may very well have a significant number of tasks, where using a constant-time scheduler would be a necessary requirement to achieve good real-time behavior.

Specification

The Linux kernel source SHALL include a scheduler whose performance is independent of the number of tasks (i.e., O(1)) in the system.

Notes

The reference O(1) scheduling mechanism is O(1) in the number of active tasks. It is not independent of the number of priorities. It is also worth noting that a kernel that uses a "constant-time" scheduler may still have context switching performance that depends on the number of tasks. This specification only requires that the algorithmic performance of the operations on the active queue (such as wakeup, schedule, etc.) does not depend on the number of tasks in the system. Other factors such as maintenance of the TLB, maintenance of the cache, demand paging working sets, and OS hints may cause large dependencies on the number or complexity of active processes. These issues are of great interest for real-time systems with small scheduling granularity, but are outside the scope of this specification.

It is also important to note that a constant-time scheduler offers no benefits when the number of active tasks in the system is known to be small. Furthermore, it is likely that a constant-time scheduler has higher overheads.

References

An O(1) scheduler is integrated into the CELF kernel.

The scheduler in 2.6 Linux kernels is also O(1). It maintains an array of double-ended linked lists, with each array entry corresponding to a priority. It can, thus, enqueue and dequeue tasks without a search that depends on the number of tasks. The O(1) scheduler in the CELF kernel is a backport of the 2.6 Linux kernel's O(1) scheduler.

Introduction

Interrupt service routines executing at hardware interrupt level (or hard-irq context, as it is called in Linux) are effectively prioritized above tasks in the system. Interrupt Threads allows an ISR to be executed within a kernel thread context.

Rationale

Even with a preemptible kernel, preemption is disabled when the kernel is executing in interrupt (hard-irq) context. When the interrupt load is small, this does not have a significant effect on the latencies for real-time tasks.

However, for various reasons, it may not always be possible to keep the interrupt load small. While system implementors are encouraged to keep interrupt service routines brief, this is not always possible. For example, sometimes a device does not support DMA properly, and a driver may have to move a significant amount of data in hard interrupt context. Or, a device that is generating very frequent requests may cause numerous brief interrupt service routines to sum to an extended amount of processing in the hard interrupt context. Whatever the reason, heavy use of interrupt context can adversely affect latencies for real-time tasks.

Especially in a system like Linux, where "off the shelf" device drivers are a major attraction, it is important to have a mechanism that makes unmodified interrupt service routines execute in a thread context. With this capability, a system designer can prioritize the execution of interrupt service routines lower than critical real-time tasks.

Specification

  1. The kernel SHALL provide a configurable option to execute the interrupt service routine in a kernel thread. With this option enabled, a separate kernel thread SHALL be used to service each interrupt line (IRQ).
  2. The kernel SHALL provide a "flag" that can be used by a device-driver to specify that a particular interrupt service routine should not be executed in a thread context.
  3. The kernel MAY provide configuration time specification of thread priorities for threads supporting the IRQ-thread option for each IRQ. When no such specification is provided, the thread priorities will default to SCHED_FIFO scheduling class with priority set to one less than the maximum real-time scheduling priority.
  4. No modifications SHOULD be required to device drivers to execute their interrupt service routine in thread context.

Notes

Device drivers may implement parts of their interrupt service routines in kernel threads, either by using the workqueue abstraction in 2.6 Linux (and backported to CELF 2.4 kernel), or by directly using kernel threads. This facility adds the flexibility of executing ISRs of unmodified device drivers in kernel threads. Additionally, it allows the system designer (except when expressly disallowed by the device driver) to determine whether the interrupt service routine should execute in hard-irq context or in thread context.

It is worth noting that executing interrupt service threads in kernel threads adds little or no value unless the Linux kernel is preemptible. Therefore, it is recommended that this facility be used in conjunction with preemptible kernel. Also, in most cases, it would be desirable to also use the SoftIRQ Threads facility as well.

References

Kernel patches that implement Interrupt Threads on 2.6 Linux kernel have been posted to the CELF-RTWG mailing list. These patches are also available through the CELF-RTWG public wiki pages.

Introduction

Linux uses a softirq mechanism to execute code in system context with interrupts enabled. This is often used by the Linux kernel as a way to execute functions that are not directly related to user tasks.

Rationale

The soft IRQ facility runs its load in interrupt state until the load becomes too great, then it schedules it in thread context at a low priority. Neither heavy use of interrupt mode nor hard-to-predict demotion of interrupt-priority work to a low priority is good practice for a real-time OS.

Specification

  • The kernel SHALL provide a configurable option to run the soft IRQ actions in one or more kernel threads.

References

The CELF kernel includes a mechanism to emulate Soft IRQ actions using a workqueue, which essentially executes the actions using a kernel thread.

Patches to execute Soft IRQ actions using kernel threads for 2.6 Linux kernel have been posted on the CELF-RTWG mailing list, and are also available on the CELF-RTWG public wiki site.

Introduction

The passage of time is, almost by definition, of interest to real-time software. Specific examples include:

  • Periodic threads with or without deadlines
  • Watchdog timers
  • Sporadic servers
  • Other CPU-consumption budgeting.
  • Deadlines for aperiodic processing

Rationale

The POSIX specification is mature and generally accepted. It includes a set of time-related APIs that provide a strong basis to build software that needs these services. The POSIX timers functions are adopted for this specification without modification.

Specification

  1. The kernel MUST conform to the POSIX specification IEEE Std 1003.1-2001 for timers. This includes functions marked with the following margin codes:
    • The TMR margin code for POSIX timers
    • The CS margin code for clock selection
    • The MON margin code for a monotonic clock
  2. The CPT margin code for process CPU time clocks is not required.
  3. The kernel timer support MAY include support for one or more clocks with high-resolution utilizing hardware counters or timers to achieve timer resolution with 100us or lower.

Notes

The list of required functions includes:

  • clock_gettime, clock_settime, and clock_getres
  • timer_create, timer_delete, timer_settime, timer_gettime, timer_getoverrun
  • nanosleep, clock_nanosleep

References

Support for POSIX timers is included in the CELF kernel. This also includes support for high-resolution timers on selected architectures.

Support for POSIX timers is also included in 2.6 Linux kernels. A patch for high-resolution timers is available at http://high-res-timers.sourceforge.net.

Introduction

Message passing is a convenient and powerful communication mechanism that is widely used by real-time applications.

Rationale

Linux has supported the System V Message Passing API for a long time, but the System V Message Passing facility does not provide for prioritized delivery of messages. Other Linux IPC mechanisms, often inherited from Unix, such as pipes, named pipes, Unix domain sockets, etc. have the same problem.

The message passing API defined in the POSIX specification is simple and widely accepted and supports prioritized delivery of messages.

Specification

The kernel MUST conform to the POSIX specification IEEE Std 1003.1-2001 for Message Queues. This includes functions marked with the following margin codes:

  • The MSG margin code for POSIX message queues functionality
  • The MSG_TMO margin code for POSIX message queues functionality with timeout capability

Notes

The list of required functions includes:

  • mq_open, mq_close, mq_unlink
  • mq_send, mq_timedsend
  • mq_receive, mq_timedreceive
  • mq_notify
  • mq_setattr, mq_getattr

References

There is some code for POSIX message passing in the CELF kernel, but it is clearly not functional. It appears to be a stale snapshot of the POSIX message passing patches available from http://www-users.mat.uni.torun.pl/~wrona/posix_ipc. This project has since made significant enhancements to the code, and support is available in the form of patches for both 2.4 and 2.6 Linux kernels. As of 4/30/2004, the message queue support has been merged into the 2.6.6 kernel tree, and necessary library support has been merged into glibc 2.3.4 tree.

Introduction

Priority inheritance protocol is the easiest-to-use standard priority inversion avoidance algorithm. It is widely supported by standard RTOSs, and priority inheritance is specified in POSIX.

Specification

Mutex locks in user state SHALL support priority inheritance protocol as specified in POSIX specification IEEE Std. 1003.1-2001 under the PRIO_INHERIT symbolic constant.

References

Priority inheritance protocol is supported by the Robust Fast Mutex project: http://developer.osdl.org/dev/robustmutexes/

This section represents some of the work that was actively discussed in the real-time working group, but is not being formally specified at this time. Nonetheless, these techniques are considered as useful extensions to the specifications and fall within the scope of this specification.

Interrupt priorities

This section represents interrupts that are prioritized, not the schedulable interrupt services routines addressed in the IRQ threads and Soft IRQ threads sections. In its simplest form prioritized interrupts are an issue only for the kernel’s interrupt dispatching code, more specifically, on the code that operates the PIC (Programmable Interrupt Controller). It lets the system be configured with a priority order on interrupts. While an interrupt is being serviced, that interrupt and all lower-priority interrupts are masked, but higher priority interrupts may preempt the ISR. This gives more control to a real-time application than the alternatives: masking all interrupts while ISRs execute, or masking only the interrupt that is being serviced. Patches have been submitted to LKML and CELF-RTWG mailing list that implement Interrupt priorities on 2.6.

An alternate approach to dealing with interrupt priorities is provided by the ADEOS project (http://www.opersys.com/adeos). ADEOS supports the creation of an interrupt pipeline through the use of ADEOS domains. Interrupts for a lower-priority domain are not serviced unless all higher priority domains relinquish control of the CPU. ADEOS can be used to implement interrupt handlers that reside in a domain that is higher priority than Linux domain. This can be used, for e.g., to achieve very low interrupt latencies for specific devices. Also, ADEOS can be used to implement higher level facilities such as an RTAI kernel that can be used to provide "hybrid" real-time solutions.

Prioritized wait queues

A real-time system with FIFO wait queues cannot be protected from priority inversion, but it may not make sense to simply require that all wait queues become priority queues. Priority queues are expensive. The implementation choices are O(n) with simple implementation, O(log n) for a balanced tree or heap, or O(1) time for an implementation like the standard O(1) scheduler.

One possibility is to require that all queues in the kernel (and possibly in kernel mode), be ordered on priority of the queue entries (by default, on the priority of the task that enqueued the entry). This is aggressive, but it is the correct approach from a strict real-time viewpoint. Requiring priority queues only for blocking POSIX functions would probably require fewer queues to become priority queues, and it might be a simple way to specify "the important queues."

{{{#noprint TableOfContents3 #noprint}}}

Introduction

Overview of "CE Linux"

  • Ten years ago, most people would have laughed at the idea of using Linux in embedded applications. Five years ago, some people started thinking about using Linux for non-PC applications. Today no one would be surprised at the idea of using Linux in embedded applications - in fact, there are already several real products in the field. What has changed? Some of the key changes are:
    1. CE products require PC-like feature
      • It is said that we are about to enter a new world with a new life style. "Ubiquitous life" is the concept frequently used. Although "Ubiquitous" may still be too broad, everyone would agree that digital CE products - such as cellular phones, digital cameras, PVRs, DVD-Rs - are part of our life. Such CE products require pc-like digital data computing - such as GUI, network, picture or movie compression/decompression and so on. From software development point of view, it is quite natural that CE software developers would want the same or similar environment as a PC.
      • If such an environment is NOT available, software developers would have to spend extra time, which impacts time-to-market and product cost badly.
    2. Open standard platform
      • If such CE products are not open to each other and have limited inter reaction or limited data sharing, the end-user benefit shall be limited. It is not good for user and it is not good for CE market either.
    3. Semiconductor technology
      • The price of memory (RAM) has dropped dramatically and constantly, and embedded processor speed has risen while the price has gone down. Please see the following chart to see the trend. Please note that the scale of the vertical is "logarithmic" scale.
      • Today's $10 embedded processor performs 10+ times faster than the one used in PC desktops 10 years ago. Therefore,even if Linux is still big and slow compared to a minimal RTOS, the relative disadvantage is becoming small.

http://tree.celinuxforum.org/docs/CPU_and_Memory_Trend.jpg

Although Linux looks best candidate for digital CE products, there are several issues we have to address and overcome - Realtime Performance, Bootup/Shutdown time, Power Management, Audio Video, Security, System Size and so on.

Introduction of this document

  • Having said that Linux has been used in some of the actual products, Linux has issues that can not be accepted by some CE products. Size is one such issue. The hardware configuration of CE products and PCs are very different. You probably will find big differences between CE products and enterprise PCs.
    • -

      CE Product example1

      CE Product example2

      Enterprise

      -

      Set Top Box(STB)

      Cellular Phone

      Desktop PC

      CPU(frequency)

      MIPS(30MHz)

      ARM(50MHz)

      Pentium(2,200MHz)

      RAM size

      32Mbyte

      8Mbyte

      512Mbyte

      Flash/ROM

      16Mbyte

      4Mbyte

      -

      Storage

      HDD 15Gbyte

      none

      HDD 80Gbyte

    In the CE market, cost competition is extremely tough. Extra memory costs extra. As CE products are varied with different feature, capability, performance and/or price. CE product system architects want to find out the best sweet spot among size, feature and some other related performance. The WG have examined the existing method and characterize each method.
  • The purpose of this document is;
    • Define a method to measure and compare the size between different Linux configurations and/or techniques which may reduce the size.
    • Define a set of standard mechanisms for reducing the system size and characterize each method -- Advantage and Disadvantage.
    Target audience for this document is;
    • CE System architects trying to understand if CE Linux is appropriate for their size constraints and the side effect by using the method.
    • OS developers looking to optimize for CE environments.
    • Commercial OS developer or tool developers looking to improve existing issue.

Rationale

  • The WG planed to take the following steps;
    • Profile Linux Size Issue
    • Define the comparison method
    • Examine the existing techniques and characterize each method
    • Invest new technique to see the numeric differences
    • Discussion on the possibility of subset feature
    • Invest on the tools
    We only have one profile data so far - we shall continue to collect more profile data - According to the profile, the ratio of kernel/userland is 37% which is very high number. But looking into the contents, kernel is 4% while userland/glibc is 28%. We probably have to prioritize userland issue. By the way, bigger surprise for me was that middleware needs 47%. As middleware is not SZWG scope, this topics shall be discussed at other places (maybe new WG). There are several parameters which are related to system size. XIP, for example, contribute RAM size reduction but require more ROM size and may impact execution speed negatively. We defined the items we compare and defined how to measure the number. We just finished examine the existing techniques and got the numeric number. Frankly speaking, I wonder how deeply we can analyze the data by the deadline of this draft but we'd like to open up all the data we have.

Terminology and Definition

Include3(SzwgTerminology_R2,"Terminology",2)

Definition

Platform

  • Since embedded CE products are varied - in sense of cpu ,hw configuration and so on - it is difficult to pick one platform. Instead of pick one platform as "standard", we selected one "primary" platform and several other as "case studies". TI/Omap Innovator was selected as "primary" platform.

Measurement Method

  • When we examine the technique, we have to evaluate several points. We need to clarify whether the technique is good for ROM or RAM. We need to clarify whether it is good for Kernel, File System or both. Also, we need to be careful about the side effect caused by the technique. We defined the following six(6) items to characterize the method.
    • Kernel ROM size
    • Kernel RAM size
    • FS ROM size
    • FS RAM size
    • Bootup Time
    • Execution Time

The following pages describe how to measure each item. SzwgMeasurementMethod

Include3(SzwgSpecTypicalboot_R2,"Typical Embedded Boot",1) Include3(SzwgSpecXip_R2,"Kernel XIP",1) Include3(SzwgSpecInitrd_R2,"Compress FS(initrd)",1) Include3(SzwgSpecCramfs_R2,"Compress FS(Cramfs)",1) Include3(SzwgSpecJffs2_R2,"Compress FS(jffs2)",1)

Work in Progress

Include3(SzwgClarification_R2,"Clarification of Linux Size Issue",2)

Candidate Projects

  • The followings are the candidate projects which we have not started yet.
    1. Application XIP
    2. Kernel Message Reduction
    3. Kernel Data Configuration
    4. Inline to function calls
    5. Symbol Weight Bridge
    6. Kernel Config Weight
    7. uClibC vs glibc
    8. Subset definition of Shared lib
    9. ARM Thumb, MIPS Snow, etc. Kernel should now support 100% ARM Thumb user space.( http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-February/019862.html )

    10. Compile Option -Os(Size Optimization)

This is the specification of Linux security technologies and features, of the Security Working Group of the CE Linux Forum.

{{{#noprint TableOfContents3 #noprint}}}

Introduction

The specifications of the Security Working Group deal with making consumer electronics products more secure, both from the consumers’ and the manufacturers’ point of view. The protections should cover

  • Data security,
  • Privacy protection,
  • System stability, and
  • Data integrity.

The purpose of this specification is to define requested or required features of Linux that improve the security of the system for such products. This version of the specification includes only one feature, a protected and persistent RAM file system.

Rationale

A consumer that buys and uses a CE product expects it to function properly. Additionally there is an implicit assumption that confidential data entered into the product will remain confidential. To this end the specifications help CE Linux attain that goal.

Terminology

The following is a list of terms used in this specification related to security technology and features.

Include3(SecurityTerms_R2)

Include3(PramFsSpecification_R2,"Protected RAM File System Specification",1)

Appendix

TableOfContents3

Note:

  1. The following number shall be used as normalizer. Other method shall be compared with the number.
  2. Comparing the number between different platforms doesn't make sense as different platform has different hw configuration. Our intention is to compare between the methods.

Typical Embedded Boot

TI/Omap Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    557

    100

    1251

    100

    2556

    100

    0

    100

    2521

    100

    TBF

    100

<!> Note - File System is located in ROM/Flash as ext2 file system.

KMC / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    687

    100

    1502

    100

    2640

    100

    0

    100

    9587

    100

    38.3

    100

<!> Note: The end point for the bootup time result is the dummy function celf_sz_boottime_dummy().

Renesas / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    654

    100

    1425

    100

    2644

    100

    0

    100

    3995

    100

    TBF

    100

NEC Electronics / VR5500A SOC Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    807

    100

    1637

    100

    3548

    100

    0

    100

    3494

    100

    TBF

    100

<!> Note: File System is located in ROM/Flash as ext2 file system.

Kernel XIP

TI/Omap Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    557

    100

    1251

    100

    2556

    100

    0

    100

    2521

    100

    TBF

    100

    XIP

    1150

    206

    207

    16

    2556

    100

    0

    -

    *1)

    *1)

    TBF

    TBF

<!> *1) Can't mount rootfilesytem on FlashROM using XIP kernel.

KMC / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    687

    100

    1502

    100

    2460

    100

    0

    100

    9587

    100

    38.3

    100

    XIP

    1367

    199

    277

    18

    2640

    100

    0

    -

    6677

    70

    5.6

    15

<!> Note: The end point for the bootup time result is the dummy function celf_sz_boottime_dummy().

Renesas / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    654

    100

    1425

    100

    2644

    100

    0

    100

    3995

    100

    TBF

    100

    XIP

    1317

    201

    245

    17

    2644

    100

    0

    -

    2082

    52

    TBF

    TBF

NEC Electronics / VR5500A SOC Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    807

    100

    1637

    100

    3548

    100

    0

    100

    3494

    100

    TBF

    100

    XIP

    1438

    178

    271

    17

    3548

    100

    0

    -

    2470

    71

    TBF

    TBF

Compress FS(initrd)

TI/Omap Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    557

    100

    1251

    100

    2556

    100

    0

    100

    2521

    100

    TBF

    100

    initrd

    565

    101

    1265

    101

    1189

    46

    2556

    -

    -

    -

    TBF

    TBF

KMC / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    687

    100

    1502

    100

    2640

    100

    0

    100

    9587

    100

    38.3

    100

    initrd

    678

    99

    1484

    99

    1276

    48

    2640

    -

    10988

    115

    37.3

    97

<!> Note: The end point for the bootup time result is the dummy function celf_sz_boottime_dummy().

Renesas / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    654

    100

    1425

    100

    2644

    100

    0

    100

    3995

    100

    TBF

    100

    initrd

    663

    101

    1446

    101

    1276

    48

    2644

    -

    -

    -

    TBF

    TBF

NEC Electronics / VR5500A SOC Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    807

    100

    1637

    100

    3548

    100

    0

    100

    3494

    100

    TBF

    100

    initrd

    816

    101

    1654

    101

    1249

    35

    3548

    -

    -

    -

    TBF

    TBF

Compress FS(Cramfs)

TI/Omap Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    557

    100

    1251

    100

    2556

    100

    0

    100

    2521

    100

    TBF

    100

    cramfs

    551

    99

    1272

    102

    1380

    54

    0

    -

    2513

    99.7

    TBF

    TBF

KMC / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    687

    100

    1502

    100

    2640

    100

    0

    100

    9587

    100

    38.3

    100

    cramfs

    697

    101

    1554

    103

    1472

    56

    0

    -

    9679

    101

    40.5

    106

<!> Note: The end point for the bootup time result is the dummy function celf_sz_boottime_dummy().

Renesas / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    654

    100

    1425

    100

    2644

    100

    0

    100

    TBF

    100

    TBF

    100

    cramfs

    645

    99

    1443

    101

    1507

    60

    0

    -

    TBF

    TBF

    TBF

    TBF

NEC Electronics / VR5500A SOC Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    807

    100

    1637

    100

    3548

    100

    0

    100

    3494

    100

    TBF

    100

    cramfs

    799

    99

    1653

    101

    1536

    43

    0

    -

    3494

    100

    TBF

    TBF

Compress FS(jffs2)

TI/Omap Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    557

    100

    1251

    100

    2556

    100

    0

    100

    2521

    100

    TBF

    100

    jffs2

    590

    106

    1326

    106

    1516

    59

    0

    -

    4831

    192

    TBF

    TBF

<!> *1) Unstable for mounting JFFS2 filesystem.

KMC / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    687

    100

    1502

    100

    2640

    100

    0

    100

    9587

    100

    38.3

    100

    jffs2

    740

    108

    1606

    107

    1600

    61

    0

    -

    10350

    108

    35.6

    93

<!> Note: The end point for the bootup time result is the dummy function celf_sz_boottime_dummy().

Renesas / SH4 Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    654

    100

    1425

    100

    2644

    100

    0

    100

    3995

    100

    TBF

    100

    jffs2

    690

    106

    1496

    105

    1644

    62

    0

    -

    6069

    152

    TBF

    TBF

NEC Electronics / VR5500A SOC Platform

  • Name of Method

    ROM for Kernel

    RAM for Kernel

    ROM for FS

    RAM for FS

    Boot Time

    Execution Speed

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    Size (Kbyte)

    ratio (%)

    actual (ms)

    ratio (%)

    actual

    ratio (%)

    Typical BT

    807

    100

    1637

    100

    3548

    100

    0

    100

    3494

    100

    TBF

    100

    jffs2

    844

    105

    1718

    105

    1726

    48

    0

    -

    5824

    167

    TBF

    TBF

CELF_Specification_V_1_0_R2 (last edited 2008-06-18 18:51:26 by 160)