Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Difference between revisions of "System Size Spec"

From eLinux.org
Jump to: navigation, search
m (Bot (Edward's framework))
 
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
<pre>#noprint
 
[[TableOfContents3]]
 
#noprint</pre>
 
 
 
== Introduction ==
 
== Introduction ==
 
=== Overview of "CE Linux" ===
 
=== Overview of "CE Linux" ===
  Ten years ago, most people would have laughed at the idea of using
+
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:  
  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:  
+
  
 
# CE products require PC-like feature
 
# 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.
+
* 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.
+
* If such an environment is NOT available, software developers would have to spend extra time, which impacts time-to-market and product cost badly.
 
# Open standard platform
 
# 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.
+
* 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.
 
# Semiconductor technology
 
# 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.
+
* 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.
+
* 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
 
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.  
+
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 ===
 
=== Introduction of this document ===
  
  Having said that Linux has been used in some of the actual products, Linux has
+
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.
  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]].
+
 
{|  
 
{|  
 
|- bgcolor="80C0C0"
 
|- bgcolor="80C0C0"
Line 65: Line 52:
 
|}
 
|}
  
  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.
+
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;   
+
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 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.
 
** Define a set of standard mechanisms for reducing the system size and characterize each method -- Advantage and Disadvantage.
Line 74: Line 61:
 
** OS developers looking to optimize for CE environments.
 
** OS developers looking to optimize for CE environments.
 
** Commercial OS developer or tool developers looking to improve existing issue.
 
** Commercial OS developer or tool developers looking to improve existing issue.
 +
 
== Rationale ==
 
== Rationale ==
  The WG planed to take the following steps;
+
The WG planed to take the following steps;
 
*** Profile Linux Size Issue
 
*** Profile Linux Size Issue
 
*** Define the comparison method
 
*** Define the comparison method
Line 83: Line 71:
 
*** Invest on the tools
 
*** 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).
+
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.  
+
 
 +
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 ==
 
== Terminology and Definition ==
 
  
 
=== Definition ===
 
=== Definition ===
 +
See [[Szwg Terminology|Size Terminology]]
 +
 
==== Platform ====
 
==== 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.
+
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
+
Primary Platform
**** TI/Omap Innovator [[SzwgPlatform1]]
+
* TI/Omap Innovator [[Szwg Platform 1]]
  Case Study Platform  
+
Case Study Platform  
**** KMC SH4  [[SzwgPlatform2]]
+
* KMC SH4  [[Szwg Platform 2]]
**** Renesas SH4  [[SzwgPlatform3]]
+
* Renesas SH4  [[Szwg Platform 3]]
**** NEC Electronics VR5500A Core SOC [[SzwgPlatform4]]
+
* NEC Electronics VR5500A Core SOC [[Szwg Platform 4]]
  
 
==== Measurement Method ====
 
==== 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.
+
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 ROM size
***** Kernel RAM size
+
* Kernel RAM size
***** FS ROM size
+
* FS ROM size
***** FS RAM size
+
* FS RAM size
***** Bootup Time
+
* Bootup Time
***** Execution Time
+
* Execution Time
  
 
The following pages describe how to measure each item. [[Szwg Measurement Method]]
 
The following pages describe how to measure each item. [[Szwg Measurement Method]]
  
 
+
* [[Szwg Spec Typicalboot|Typical Embedded Boot]]
 
+
* [[Szwg Spec Xip|Kernel XIP]]
 
+
 
+
 
+
  
 
== Work in Progress ==
 
== Work in Progress ==
  
 
=== Candidate Projects ===
 
=== Candidate Projects ===
  The followings are the candidate projects which we have not started yet.
+
The followings are the candidate projects which we have not started yet.
 
## Application XIP
 
## Application XIP
 
## Kernel Message Reduction
 
## Kernel Message Reduction
Line 133: Line 120:
 
## 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 )
 
## 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 )
 
## Compile Option -Os(Size Optimization)
 
## Compile Option -Os(Size Optimization)
 +
 +
[[Category:Consumer Electronics Linux| ]]

Latest revision as of 00:09, 3 December 2009

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.
  1. 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.
  1. 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

Definition

See Size Terminology

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

Case Study 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. Szwg Measurement Method

Work in Progress

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)