{{{#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.

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.
- Primary Platform
  - TI/Omap Innovator SzwgPlatform1
  Case Study Platform
  - KMC SH4 SzwgPlatform2
  - Renesas SH4 SzwgPlatform3
  - NEC Electronics VR5500A Core SOC SzwgPlatform4

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)