X86上執行Android[轉貼]

Lim,GeunSik剛剛在android-porting討論組中詳細闡述了這個方法。我先把方法放過來，不過還沒來得及驗證，他用的是ASUS Eee，估計效果和N810上的差不多的。一下所有步驟都是基于Fedora的，ubuntu用戶自行參考。

開發環境：
- Linux PC: Fedora 9 ( 2.6.25.6-55.fc9 i686)
. CPU: Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz ( Samsung
SENS R60 Laptop )
. RAM: Samsung DDR Ram
- Target: Eee PC (ASUS) and Samsung nettop NC01
- Reference: http://www.kandroid.org/board/board.php?board=androidsource&command=body&no=19

1. Linux發行版訊息

首先是驗證系統訊息

Fedora9$> uname -a
Linux fedora-invain9 2.6.25.6-55.fc9.i686 #1 SMP Tue Jun 10 16:27:49
EDT 2008 i686 i686 i386 GNU/Linux

Fedora9$> gcc –version and Fedora9$> gcc34 –version
Fedora9$> gcc –version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Fedora9$> gcc34 –version
gcc34 (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE

2. repo init 和 Sync 操作
- 首先下載Android for x86的完整源代碼。Eee pc 的 dev tree 在 “git://android.git.kernel.org/platform/vendor/asus/eee_701.git”.

Fedora9$> cd ~
Fedora9$> mkdir bin_x86 && cd bin_x86
Fedora9$> mkdir mydroid && cd mydroid
Fedora9$> repo init -u git://android.git.kernel.org/platform/manifest.git
-b cupcake
Fedora9$> repo sync
Fedora9$> vi ./.repo/local_manifest.xml





Fedora9$> repo sync
… A new repo command ( 1.8) is available.
… You should upgrade soon:

cp /home/invain/bin_x86/mydroid/.repo/repo/repo /home/invain/bin/
repo

Initializing project platform/vendor/asus/eee_701 …
remote: Counting objects: 33, done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 33 (delta 2), reused 33 (delta 2)
Unpacking objects: 100% (33/33), done.
From git://android.git.kernel.org/platform/vendor/asus/eee_701
* [new branch] cupcake -> korg/cupcake
* [new branch] master -> korg/master

3. 構建 x86 android

Fedora9$> export PATH=$PATH:/usr/sbin:/sbin (to use /sbin/tune2fs
command of e2fsprogs pack )
Fedora9$> TARGET_ARCH=x86 TARGET_PRODUCT=eee_701 DISABLE_DEXPREOPT=true CC=gcc34 CXX=g++34 make -j2 installer_img

build/core/product_config.mk:207: WARNING: adding test OTA key
============================================
TARGET_PRODUCT=eee_701
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=
============================================
build/core/main.mk:178: implicitly installing apns-conf_sdk.xml
…………… Below Omission ……………….

* 在構建中可能遇到一些問題，解決辦法是

- 用低版本gcc 替換 gcc-4.3 version. Ubuntu 8.04LT用的是GCC 4.2， Ubuntu 8.10是GCC 4.3，所以推荐用8.04來做build

- 如果你正在使用 GCC 4.3， 請照下面修改源代碼中的相關頭文件：

Fedora9$> vi external/srec/tools/thirdparty/OpenFst/fst/lib/../../fst/
lib/vector-fst.h
Fedora9$> vi external/srec/tools/thirdparty/OpenFst/fst/lib/symbol-
table.cpp
Fedora9$> vi frameworks/base/tools/aidl/aidl.cpp –> #include
, #include 

等等。

- Lim,GeunSik使用的是gcc 3.4

#> yum install compat-gcc*
#> rpm -qa  grep compat-gcc
compat-gcc-34-3.4.6-9.i386
compat-gcc-34-c++-3.4.6-9.i386
compat-gcc-34-g77-3.4.6-9.i386

Fedora9$> vi

Fedora9$> ls -lh out/target/product/eee_701/

total 770624
drwxrwxr-x 9 invain invain 4096 2008-12-24 16:05 .
drwxrwxr-x 3 invain invain 4096 2008-12-24 15:34 ..
-rw-rw-r– 1 invain invain 2606080 2008-12-24 15:50 boot.img
-rw-rw-r– 1 invain invain 57 2008-12-24 16:03 clean_steps.mk
drwxrwxr-x 4 invain invain 4096 2008-12-24 15:54 data
drwxrwxr-x 2 invain invain 4096 2008-12-24 15:50 grub
drwxrwxr-x 4 invain invain 4096 2008-12-24 16:05 installer
-rw-rw-r– 1 invain invain 406862848 2008-12-24 16:06 installer.img
-rw-rw-r– 1 invain invain 1951340 2008-12-23 19:18 kernel
drwxrwxr-x 12 invain invain 4096 2008-12-24 16:05 obj
-rw-rw-r– 1 invain invain 607384 2008-12-24 15:50 ramdisk.img
drwxrwxr-x 9 invain invain 4096 2008-12-24 15:50 root
drwxrwxr-x 4 invain invain 4096 2008-12-24 15:50 symbols
drwxrwxr-x 12 invain invain 4096 2008-12-24 15:53 system
-rw-rw-r– 1 invain invain 372056064 2008-12-24 16:05 system.img
-rw-rw-r– 1 invain invain 5156864 2008-12-24 16:04 userdata.img

Fedora9$> file out/target/product/eee_701/installer.img
./out/target/product/eee_701/installer.img: x86 boot sector; GRand
Unified Bootloader, stage1 version 0×3; partition 1: ID=0×83, active,
starthead 0, startsector 2048, 8878 sectors; partition 2: ID=0×83,
starthead 0, startsector 10926, 783728 sectors

Fedora9$> file out/target/product/eee_701/installer.img
File: `./out/target/product/eee_701/installer.img’
Size: 406862848 Blocks: 793552 IO Block: 4096 일반 파일
Device: fd00h/64768d Inode: 5349917 Links: 1
Access: (0664/-rw-rw-r–) Uid: ( 778/ invain) Gid: ( 778/
invain)
Access: 2008-12-24 16:08:21.000000000 +0900
Modify: 2008-12-24 16:06:05.000000000 +0900
Change: 2008-12-24 16:06:05.000000000 +0900

Fedora9$> file out/target/product/eee_701/system.img
./out/target/product/eee_701/system.img: Linux rev 0.0 ext2 filesystem
data

Fedora9$> file out/target/product/eee_701/userdata.img
./out/target/product/eee_701/userdata.img: Linux rev 0.0 ext2
filesystem data

Fedora9$> pushd out/target/product/eee_701/

Fedora9$> sudo mount -o loop boot.img /mnt

Fedora9#> popd
total 2519
-rw-rw-r– 1 invain invain 77 2008-12-24 15:50 cmdline
-rw-rw-r– 1 invain invain 1951340 2008-12-24 15:50 kernel
-rw-rw-r– 1 invain invain 607384 2008-12-24 15:50 ramdisk

Fedora9$> cat /mnt/test/cmndline
console=tty0 console=ttyS1,115200n8 console=tty0
androidboot.hardware=eee_701

Fedora9$> cp /mnt/test/ramdisk /tmp/ramdisk.gz
Fedora9$> pushd /tmp
Fedora9$> gunzip ramdisk.gz
Fedora9$> cpio -iv < ramdisk

Fedora9$> popd
init.goldfish.rc
init
data
init.eee_701.rc
proc
sbin
sbin/adbd
system
init.rc
default.prop
lib
lib/modules
lib/modules/atl2.ko
lib/modules/drm.ko
lib/modules/fbcon.ko
lib/modules/cfbimgblt.ko
lib/modules/i915.ko
lib/modules/cfbcopyarea.ko
lib/modules/bitblit.ko
lib/modules/softcursor.ko
lib/modules/font.ko
lib/modules/cfbfillrect.ko
dev
sys
2958 blocks

Fedora9$> file /tmp/init
/tmp/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, not stripped

4. 制作USB Pen Disk安裝包

- 在BIOS中把第一啟動設備設置成USB，然後

Fedora9$> dd if=out/target/product/eee_701/installer.img of=/dev/your_usb_disk（例如/dev/sda1）

好了，接下來可以用你的android USB Pen Disk來嘗試啟動了。Enjoy it。

最後友情提示一句，我還沒有試這種方法，不過反正也不會破壞什麼，有興趣的朋友可以試一下。

資料來源:
http://www.forwind.cn/2008/12/24/android-on-x8/
Howto build Android full source for X86 Architecture like EeePC(ASUS)

SystemC Modules and Processes(2)

階層架構(Hierarchy)
一個EXOR閘是由4個NAND閘(instance)組成。要達成這個目的，是在EXOR閘的建構式裏去連結實體化的NAND閘。
底下列出EXOR閘的範例程式：

#include "systemc.h"
#include "nand2.h"
SC_MODULE(exor2)
{
  sc_in<bool> A, B;
  sc_out<bool> F;

  nand2 n1, n2, n3, n4;

  sc_signal<bool> S1, S2, S3;

  SC_CTOR(exor2) : n1("N1"), n2("N2"), n3("N3"), n4("N4")
  {
    n1.A(A);
    n1.B(B);
    n1.F(S1);

    n2.A(A);
    n2.B(S1);
    n2.F(S2);

    n3.A(S1);
    n3.B(B);
    n3.F(S3);

    n4.A(S2);
    n4.B(S3);
    n4.F(F);
  }
};

程式說明：
這個程式看起來跟NAND閘的程式很像，但注意它有去include nand2.h的檔案，這是為了去使用NAND閘模組所必需的。

這個exor2模組被建立起來，並宣告這個模組的ports。請再注意一下，設計上是可以重複使用A,B及F的名字，因為它跟nand的層級是不同的。

在電路圖中你可以看到有許多的線用以連結每個NAND閘。而在SystemC裏線的表現方式則是用sc_signal S1,S2及S3。
sc_signal是一個類別(class)，它包含了樣版參數(template parameter)用以定義資料的型態，在這個例子中是使用bool的資料型態。
sc_signal是一個SystemC內建的通道(primitive channel)類別，內建的通道當然在SystemC class library裏。它的行為就如同VHDL裏的signal。

EXOR閘的建構式會比NAND閘再複雜一點，它必需實體化4個nand2來用。在port的定義之後，緊接著宣告實體化4個nand2:n1,n2,n3,n4。
每個實體化的nand2都必需要有個名字，所以我們在exor2建構式初使化時傳了4個"N1","N2","N3","N4"的名字，分別給n1,n2,n3,n4這4個nand2。

最後，將所有的ports所需要的連接線接起來。這樣子就完成了這個建構式了。

測試程式(Test bench)
要測試這個設計，當然就需要測試訊號的產生程式。這就必需要再寫另一個module，跟前面寫的module很類似。
但比較不同的是，在這裏我們是使用執行緒(thread)SC_THREAD，這個行程會在需要時進入休眠狀態。
底下列出這個Test bench的範例程式stim.h

#include "systemc.h"
SC_MODULE(stim)
{
  sc_out<bool> A, B;
  sc_in<bool> Clk;

  void StimGen()
  {
    A.write(false);
    B.write(false);
    wait();
    A.write(false);
    B.write(true);
    wait();
    A.write(true);
    B.write(false);
    wait();
    A.write(true);
    B.write(true);
    wait();
    sc_stop();
  }
  SC_CTOR(stim)
  {
    SC_THREAD(StimGen);
    sensitive << Clk.pos();
  }
};

程式說明：
這裏要注意的是最後它們呼叫sc_stop()，這個函式會讓整個模擬結束。

有了訊號產生程式後，我們還需要一個監控程式，用來監控我們想看到的訊號改變情況，這個程式相當簡單，我們先忽略這個部份，在這個範例裏監控程式檔名是mon.h。

底下列出top level的程式碼，它是寫在main.cpp裏，當然main.cpp必需include之前所寫的那些子模組(submodules)

#include "systemc.h"
#include "stim.h"
#include "exor2.h"
#include "mon.h"

int sc_main(int argc, char* argv[])
{
  sc_signal<bool> ASig, BSig, FSig;
  sc_clock TestClk("TestClock", 10, SC_NS,0.5);

  stim Stim1("Stimulus");
  Stim1.A(ASig);
  Stim1.B(BSig);
  Stim1.Clk(TestClk);

  exor2 DUT("exor2");
  DUT.A(ASig);
  DUT.B(BSig);
  DUT.F(FSig);

  mon Monitor1("Monitor");
  Monitor1.A(ASig);
  Monitor1.B(BSig);
  Monitor1.F(FSig);
  Monitor1.Clk(TestClk);

  sc_start();  // run forever

  return 0;

}

程式說明：
在top-level裏 signal被宣告成線(wire)來使用，時脈的產生則是用sc_clock；然後把所需要的模組都實體化必加以連結起來。

都做完後，必需呼叫sc_start()來啟動模擬，模擬會一直持續執行，一直到有人呼叫了sc_stop()後結束模擬。

底下列出輸出結果的範例：

       Time A B F
       0 s 0 0 1
     10 ns 0 0 0
     20 ns 0 1 1
     30 ns 1 0 1
     40 ns 1 1 0

如果你有注意看輸出結果，你應該會發生很詭異的事情，在第一行time 0s時，當時的A,B輸入為0，而F的輸出結為為1，這不應該是EXOR閘的正常輸出結果。
但在10ns之後，所有的結果都是對的了。在time 0s時到底發生了什麼事情了呢？

模擬(Simulation)
在SystemC library裏包含了一個模擬核心(simulation kernel)。它決定了那個行程(software threads)要被執行。
在time 0s時，所有的SC_METHOD及SC_THREAD將會隨機的被叫起來執行，一直到它們全都進入休眠(suppend)結束一個cycle。
SC_CTHREAD則是會在時脈一發生時就被執行。

上面的情況是由於組合電路的情況造成的

1. sc_clock在時間time 0s會發生的上升緣(rising edge )，因此所有的monitor及stimulus行程在此時都會執行(在這種情況下，並不知道誰會先被執行)


2. 在C++裏的變數並不見得都會被付與初使值(除非它們被宣告為靜態變數static)，因此才會造成F在time 0s時會出現1的情況


3. do_nand2 SC_METHOD在time 0s執行，而排程器也會去對F做更新，但是F是一個signal，它的內容並不能馬上被更新，因此當monitor在處理時，F的內容還會為1

在這個範例裏，改善的方式，可以去修改sc_clock讓它產生在第1個clock產生後延遲，如下：

sc_clock TestClk("TestClock", 10, SC_NS,0.5, 1, SC_NS);

加入的1, SC_NS兩個參數，定義了在第一個時脈發生後延遲1 ns，這會讓F的內容得以更新。
底下列出修改過後的執行結果：

       Time A B F
      1 ns 0 0 0
     11 ns 0 0 0
     21 ns 0 1 1
     31 ns 1 0 1
     41 ns 1 1 0

現在你可以看到F的輸出結果都是正確的了。

結論
結束這篇快速瀏覽modules及process，你已經看到了SystemC模擬核心及內建的sc_signal通道的重要性。
你也看到了一些基本實體化低階模組的範例，它包含了一個top-level模組，以及sc_main是如何被使用的。

資料來源：
http://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/

SystemC Modules and Processes(1)

這個章節包含了一個完整的基本設計用以展示如何在SystemC裏使用modules及processes.
為了淺顯易懂，它是屬於非常低階的設計，這種設計方式並不是一個你在做系統層級設計時所希望的。
主要的展示重點：

1. 建立階層架構


2. 使用內建的sc_signal通道


3. (特殊)ports


4. Processes(SC_METHOD, SC_THREAD, SC_CTHREAD)


5. 一個簡單的測試程式

SystemC的背景
為什麼要看Modules及Processes呢？這是因為System的主要目的是想要解決軟體及硬體的同時設計，並且希望能對大型的系統建立模型。
Process是程式裏的最小單位，系統裏的每個Process皆是平行運作的。機乎所有的高階系統層級設計(high-level system level design:SLD)工具都是以網絡行程(network of processes)的基礎模型(underlying model)來開發設計的。
SystemC提供了Processes(行程)來支援建構網絡裏的每個獨立(同時/平行)的程式碼區塊(pieces of code)。

SLD常會遇到大型的設計需求。為了滿足這個目的，它通常都是使用階層式(Hierarchy)的架構來設計。階層式架構在SystemC裏會以module來實現它，一個類別(class)和其它的modules的連接方式必需使用ports。
Modules允許被分割進行設計開發。Modules可能包含其它的processes以及實體化(instances)其它的modules。

一個設計範例
這個範例是以4個NAND閘組成1個EXOR閘。再次說明，這個範例並不是一個典型設計的風格，但是它可以很容易的讓大家了解SystemC。
範例電路圖如下：

第一步當然就是去建構NAND閘的模型囉。NAND閘是一種組合電路，它的輸出完全取決於輸入端，它完全沒有記憶功能，也不需要時脈。
所以這個模型(model)可以使用SystemC裏最簡單的process SC_METHOD 來設計。

SC_METHOD是一個簡單的C++函式，因此SystemC class library將它拿來展現processes的行為。
比較特別的：
SystemC class library包含了一個模擬核心(simulation kernel) - 處理每個模型的時間推移，以及當有輸入改變時呼叫函式去處理相應的輸出。
SC_METHOD需要定義function給它及觸發function的輸入值條件。(The function must be declared as an SC_METHOD and made sensitive to its inputs.)

底下是NAND閘的範例程式(nand.h)

#include "systemc.h"

SC_MODULE(nand2)          // declare nand2 sc_module

{
  sc_in<bool> A, B;       // input signal ports
  sc_out<bool> F;         // output signal ports

  void do_nand2()         // a C++ function
  {
    F.write( !(A.read() && B.read()) );
  }

  SC_CTOR(nand2)          // constructor for nand2
  {
    SC_METHOD(do_nand2);  // register do_nand2 with kernel
    sensitive << A << B;  // sensitivity list
  }
};

程式說明:

階層架構在SystemC裏是使用class sc_module來實現。sc_module 可能會被直接拿來使用，也可能會被使用巨集SC_MODULE指令所隱藏起來。
上面的範例裏就是使用SC_MODULE來建立一個sc_module名字叫nand2的類別物件。

接下來宣告輸入及輸出埠。一般來說，一個埠的宣告都是使用類別sc_port。
再進一步的例子，input ports還會需要使用sc_signal來宣告型態。如：

sc_port<sc_signal_in_if<bool>,1> A,B;

所以就如同你看到的，會有很多很多的形態耶。所以為了方便，也可以使用特別的ports.
sc_in就是一個特殊的埠用以快速的使用sc_signal。

ports可以是C++或SystemC的任何一種形態，範例裏是使用C++內建的bool形態。

再接下來介紹，input及output ports都包含了read()/write()的方法(methods)，使用它們來讀/寫埠的資料。
A和B都是被拿來讀資料的，do_nand2()是拿來計算的函式，而計算結果將透過write()寫入到F裏。

注意一下你也可以不使用read()/write()來讀/寫資料，用=來進行操做，如：

F = !(A && B);

但是使用read()/write()是比較好的作法，它比較容易讓C++的編譯程式進行分析。

在看完do_nand2()後，接著是建構式sc_module，它實體化了nand2這個物件。SystemC提供了簡單的方法來完成這件事，那就是SC_CTOR。
這個建構式處理的事情如下：

1. 建立階層(不過在這個範例中沒有)


2. 在simulation kernel裏註冊我們這個新的process


3. 宣告這個的觸發條件清單列表

它也可能在建構式裏做一些初使化的的行為 - 比如說：類別資料成員就可以在建構式裏進行初使化。

所以在上面的範例程式裏，建構式宣告了do_nand2是一個SC_METHOD，並且告訴kernel當port A/B值發生改變時去執行do_nand2()。

資料來源：
http://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/

神奇的隱形

隱形斗篷 - 日本大學的實驗





傳說中的「隱形斗篷」將於IEDM亮相

如果你是「星艦迷航記(Star Trek；或譯銀河飛龍)」系列影集的忠實粉絲就應該記得，總是扮演反派角色的羅慕倫人(Romulans)，最會用隱形裝置來藏太空船，令人防不勝防。

現在這種隱形裝置有可能成為現實，在近日於美國舉行的國際電子元件會議(IEDM)上，美國波士頓大學的研究人員將發表一種軟性、可實現隱形斗篷(防護罩)概念的「超常介質(metamaterial；或譯超物質)」技術。

據了解，波士頓大學將介紹一種安裝在聚亞醯胺( polyimide)基板上的軟性圓柱狀超常介質材料，以兆赫(terahertz，THz)速度運作。超常介質是一種「次波長(sub-wavelength)」複合材料，可用來合成金屬或是支援電介質(dielectrics)。

上述的超常介質結構是由200mm厚的金與10mm鈦黏著層，在聚亞醯胺基板上所組成；該基板是用液態聚亞醯胺透過旋轉塗佈(spin-coated)法，在塗佈了400nm厚的噴濺氮化矽薄膜的2吋矽晶圓上所形成。

該基板包含了純電子共振器與標準開環共振器(Split Ring Resonator)；軟性共振材料依次安裝在聚亞醯胺基板上，以製作大量的多層、非平面電磁複合物。這種複合材料就可用來做為於0.5 THz頻率下能隱形的遮罩。

(參考原文：Group demos metamaterials for invisible cloak，by Mark LaPedus)

資料來源:
http://www.eettaiwan.com/ART_8800556757_480102_NT_a5d84932.HTM

解讀「終極SoC」密碼──MEMS完全手冊

從實驗室中的基礎研究，到近來開始滲入消費性電子產品，微機電系統(MEMS)的廣泛應用已成為產業發展的一個重要趨勢，值得密切關注。為了讓讀者們更容易掌握MEMS領域發展趨勢，《電子工程專輯》收集了近來針對MEMS的相關報導與技術文章，製作了一份『解讀「終極SoC」密碼──MEMS完全手冊』電子書，歡迎有興趣的讀者踴躍下載或傳閱。

E Book Mems

View SlideShare document or Upload your own.

資料來源:
http://www.eettaiwan.com/ART_8800463781_480502_NT_973e8fb3.HTM

Soc ESL簡單介紹

這篇文章是希望能幫助大家了解現代嵌入式系統和SoC設計工具的概念及其使用方法，以期在SoC設計中實現電子系統級模擬及設計空間探索，為嵌入式的軟體和硬體作出最新最複雜的整合性現代設計。
內容包括
(1)什麼是ESL
(2)ESL和嵌入式系統SoC設計
(3)抽象模型建立與系統設計方法
(4)嵌入式系統軟硬體電子化設計工具鏈和流程
(5)工具鏈介紹以AndeSight為例
(6)ESL tool--Andes AndESLive 介紹
(7)展望
作者： 謝達人

20080701 Oe Andes Ta 02

View SlideShare document or Upload your own.

資料來源:
http://www.eettaiwan.com/ART_8800531764_676964_TA_efafd008.HTM

EFI - SEC(Security)階段

EFI - SEC(Security)階段

SEC階段是EFI的第一個執行階段，當電腦Power-On時就會進入此階段，原則上EFI只有這個部份會使用組合語言搭配C語言撰寫，此階段的重點目的是把CPU的SP(Stack Pointer)指到CPU內部的Cache中。

SEC階段主要功能

1. 掌控平台的restart事件


2. Real Mode to Protected Mode


3. 使用CPU Cache當做記憶體(Creates a temporary memory store)

因為在此階段時，北橋裏的Memory Controller還沒有初使化，尚無法使用系統記憶體，但C語言執行時需要Stack Area，因此暫時先拿Cache來做堆疊區。

4. 進入下個PEI階段(Passes handoff information to the PEI)

更詳細的參考資料可以看Intel® Platform Innovation Framework for EFI Architecture Specification - Draft for Review

Moblin Project:Fast Boot

http://moblin.org/projects/fast-boot

這是MID的官網，介紹了MID如何讓系統在５秒內開完機及Demo唷！

5秒開完的簡報檔
http://moblin.org/sites/all/files/u123/plumbers_fastboot.pdf

Demo影片
http://www.youtube.com/watch?v=s7NxCM8ryF8

真是超快的！