環境

system：2015-09-24-raspbian-jessie

RaspberryPi：Raspberry Pi 2

樹莓派啟動的相關問題

樹莓派啟動的相關問題，會從config.txt一直介紹到 Linux 如何啟動，啟動流程分析，自啟動指令碼實現。

要想理解樹莓派系統的執行機制，得先來看看樹莓派是如何啟動的。

boot

樹莓派的boot及其他github

https://github.com/raspberrypi

樹莓派的boot啟動過程

pi@raspberrypi ~ $ ls -a /boot/
.                       COPYING.linux     LICENSE.oracle
..                      fixup_cd.dat      overlays
bcm2708-rpi-b.dtb       fixup.dat         start_cd.elf
bcm2708-rpi-b-plus.dtb  fixup_db.dat      start_db.elf
bcm2708-rpi-cm.dtb      fixup_x.dat       start.elf
bcm2709-rpi-2
 
-b.dtb     issue.txt         start_x.elf
bootcode.bin            kernel7.img       System Volume Information
cmdline.txt             kernel.img
config.txt              LICENCE.broadcom

為了降低成本，樹莓派省去了傳統計算機用來儲存引導載入程式的板載儲存器(BIOS), 直接把載入程式放在了SD卡中。

樹莓派2具有一款博通的BCM2836系統晶片, 當啟動時，ARM Cortex-A7的CPU會處於復位狀態，由VideoCore IV GPU核心負責啟動系統。（所以大部分boot的啟動都是由GPU code來完成，而不是CPU）

• 第一階段, 從系統晶片中載入第一階段的啟動程式，這個啟動程式負責掛載在SD卡中的FAT32的檔案系統，從而讓他可以啟動第二階段的boot（bootcode.bin），這部分程式是寫死在在晶片中的，所以不能修改。
• 第二階段bootcode.bin則用來從SD卡上檢索GPU韌體（start.elf），然後執行它，從而啟動GPU
• start.elf啟動後，讀取存放系統配置的檔案config.txt。當config.txt檔案被載入解析之後, start.elf會讀取cmdline.txt和kernel.img. cmdline.txt包含核心執行的引數，而kernel.img將會被載入到處理器分配的共享記憶體中，當核心載入成功，處理器將結束復位狀態，核心開始正式執行，系統啟動正式開始。
• start.elf除了上面的，也會傳遞一些額外的引數給核心，比如DMA通道，GPU引數，MAC地址，eMMC時鐘速度、核心定址範圍等等

 	dma.dmachans=0x7f35
	bcm2708_fb.fbwidth=1280
	bcm2708_fb.fbheight=1024
	bcm2708.boardrev=0xe
	bcm2708.serial=0xd9b35572
	smsc95xx.macaddr=B8:27:EB:B3:55:72
	sdhci-bcm2708.emmc_clock_freq=250000000
	vc_mem.mem_base=0xec00000
	vc_mem.mem_size=0x10000000
	console=ttyAMA0,115200
	kgdboc=ttyAMA0,115200
	console=tty1
	root=/dev/mmcblk0p2
	rootfstype=ext4
	rootwait 

主流的linux核心可能並沒有這些引數

樹莓派的官網上也提供引導程程式的精簡版本（fixup_cd.dat,start_cd.elf，用於GPU記憶體只有16MB的時候，會損失部分CPU特性）和測試版本（fixup_x.dat, start_x.elf，這種版本可以使用額外的video codes）

由於這種寫死的程式加上從SD卡開始引導，這就讓樹莓派不會因為軟體的原因變成磚頭的（除非硬體損壞）

GPU bootloaders

目前的GPU軟體和韌體都是二進位制的檔案，Raspbian可以通過apt-get來升級，rip-update也是最簡單用來升級的方式，當然最新版本難免少不了一些bug，所以推薦還是使用穩定版本。

而目前的樹莓派的GPU bootloader是不開源的，所以不是像普通的是由CPU的bootloader來啟動。

而且由於樹莓派的啟動核心是VideoCore IV 是屬於博通的Broadcom BCM2836 這塊晶片是隻供樹莓派使用的，所以樹莓派基本沒有假的（想仿冒，但拿不到博通的這塊晶片，只好無奈了），也造成了基於樹莓派核心顯示卡的程式是無法移植到其他的晶片上去的。同時由於樹莓派的這種啟動方式，導致了樹莓派不是一個裸機ARM，就會出現了無法像微控制器一樣直接對樹莓派程式設計，也需要其核心引導之後進入系統才行。

總結

http://segmentfault.com/a/1190000000465449

文章中作者提到了，樹莓派的各種問題，其實總體來說，樹莓派在填坑，至少最大的坑螢幕，是在9月份填了的。樹莓派不開源，他不是硬體開源，但已經做的非常好了，雖然硬體不開源，但是這維持住了他的生存，而太多的硬體開源往往很快就會被更好更開源的硬體取代了，而樹莓派非完全開源則是為它維持了一線生機，讓他在硬體開源的競爭中存活到了現在，讓他沒有仿冒品，沒有完全相容品，保證了社群的人不會因此而有過多的流動，同時也保證了供應商的利益。從樹梅派的各種硬體產品來看，樹莓派也在搭建一個生態圈，一個只屬於樹莓派和相容樹莓派硬體/軟體的平臺，並且由此可以進一步完善教育市場，讓樹莓派最終能成為一個完善的教育平臺，來推廣生產。所以總體上來說樹莓派是不錯的，各項支援都強於其他的開源硬體平臺。

ARM的boot啟動流程

對於PC機，其開機後的初始化處理器配置、硬體初始化等操作是由BIOS（Basic Input /Output System）完成的，但對於嵌入式系統來說，出於經濟性、價格方面的考慮一般不配置BIOS，啟動時用於完成初始化操作的這段程式碼被稱為Bootloader程式，因此整個系統的載入啟動任務就完全由Bootloader 來完成。

簡單地說，通過這段程式，可以初始化硬體裝置、建立記憶體空間的對映圖（有的CPU沒有記憶體對映功能如S3C44B0），從而將系統的軟硬體環境設定在一個合適的狀態，以便為最終呼叫作業系統核心、執行使用者應用程式準備好正確的環境。

Bootloader依賴於實際的硬體和應用環境，因此要為嵌入式系統建立一個通用、標準的Bootloader是非常困難的。Bootloader也依賴於具體的嵌入式板級裝置的配置，這也就是說，對於兩塊不同的嵌入式主機板而言，即使它們是基於同一 CPU 而構建，要想讓執行在一塊板子上的 Bootloader 程式也能執行在另一塊板子上，通常都需要修改 Bootloader 的源程式。

系統加電覆位後，幾乎所有的 CPU都從由復位地址上取指令。比如，基於 ARM7TDMI核心的CPU在復位時通常都從地址 0x00000000處取它的第一條指令。而以微處理器為核心的嵌入式系統通常都有某種型別的固態儲存裝置（比如EEPROM、FLASH等）被對映到這個預先設定好的地址上。因此在系統加電覆位後，處理器將首先執行存放在復位地址處的程式。通過整合開發環境可以將Bootloader定位在復位地址開始的儲存空間內，因此Bootloader是系統加電後、作業系統核心或使用者應用程式執行之前，首先必須執行的一段程式程式碼。對於嵌入式系統來說，有的使用作業系統，也有的不使用作業系統，比如功能簡單僅包括應用程式的系統，但在系統啟動時都必須執行Bootloader，為系統執行準備好軟硬體執行環境。

系統的啟動方式

系統的啟動通常有兩種方式

• 一種是可以直接從Flash啟動（Nor Flash）
• 另一種是可以將壓縮的記憶體映像檔案從Flash（為節省Flash資源、提高速度）中複製、解壓到RAM，再從RAM啟動。(Nand Flash)

啟動程式碼

當電源開啟時，一般的系統會去執行ROM（應用較多的是Flash）裡面的啟動程式碼。這些程式碼是用匯編語言編寫的，其主要作用在於初始化CPU和板上的必備硬體如記憶體、中斷控制器等。有時候使用者還必須根據自己板子的硬體資源情況做適當的調整與修改。

系統啟動程式碼完成基本軟硬體環境初始化後，對於有作業系統的情況下，啟動作業系統、啟動記憶體管理、任務排程、載入驅動程式等，最後執行應用程式或等待使用者命令；對於沒有作業系統的系統直接執行應用程式或等待使用者命令。

啟動程式碼是用來初始化電路以及用來為高階語言寫的軟體做好執行前準備的一小段組合語言，在商業實時作業系統中，啟動程式碼部分一般被稱為板級支援包，英文縮寫為BSP。它的主要功能就是：電路初始化和為高階語言編寫的軟體執行做準備。

系統啟動主要的過程如下：

1. 啟動程式碼的第一步是設定中斷和異常向量。
2. 完成系統啟動所必須的最小配置，某些處理器晶片包含一個或幾個全域性暫存器，這些暫存器必須在系統啟動的最初進行配置。
3. 設定看門狗，使用者設計的部分外圍電路如果必須在系統啟動時初始化，就可以放在這一步。
4. 配置系統所使用的儲存器，包括Flash，SRAM和DRAM等，併為他們分配地址空間。如果系統使用了DRAM或其它外設，就需要設定相關的暫存器，以確定其重新整理頻率，資料匯流排寬度等資訊，初始化儲存器系統。有些晶片可通過暫存器程式設計初始化儲存器系統，而對於較複雜系統通常整合有MMU來管理記憶體空間。
5. 為處理器的每個工作模式設定棧指標，ARM處理器有多種工作模式，每種工作模式都需要設定單獨的棧空間。
6. 變數初始化，這裡的變數指的是在軟體中定義的已經賦好初值的全域性變數，啟動過程中需要將這部分變數從只讀區域，也就是Flash拷貝到讀寫區域(SRAM)中，因為這部分變數的值在軟體執行時有可能重新賦值。還有一種變數不需要處理，就是已經賦好初值的靜態全域性變數，這部分變數在軟體執行過程中不會改變，因此可以直接固化在只讀的Flash或EEPROM中。
7. 資料區準備，對於軟體中所有未賦初值的全域性變數，啟動過程中需要將這部分變數所在區域全部清零。
8. 最後一步是呼叫高階語言入口函式，比如main函式等。

啟動過程中的初始化程式就是初始化CPU內部各個關鍵的暫存器、配置外圍硬體電路相關暫存器、建立中斷向量表等，然後跳轉到一般由高階語言編寫的主函式的應用程式程式碼去執行，對外圍非boot啟動的裝置進一步初始化，這樣就可以利用高階語言來編寫完成系統設計所要求的各種功能。

總結

初始化的過程對大多數初學者來說，比較難理解的是中斷的處理和一些少見的操作符號，這些符號多是一些巨集定義或系統用於在記憶體空間中對各個段的定位識別符號號。

x86的boot啟動流程

x86構架下一般都會有BIOS與CMOS，CMOS是記錄各項硬體引數且嵌入在主機板上面的儲存器，BIOS則是一個寫入到主機板上的一個軟體程式。這個BIOS就是在啟動的時候，計算機系統會主動執行的第一個程式了！

BIOS叫做“基本輸入輸出系統”（Basic Input/Output System），簡稱為BIOS（而實際上現在的BIOS並非是固化的，經常可以聽到修電腦什麼的，會說刷BIOS，其實BIOS在現在的系統中已經是可以讀寫的，只是一般來說修改BIOS並不能帶來什麼特別的好處，微星和華碩的高階一些的主機板目前都有自動更新BIOS的功能，主要是控制和管理一些額外的介面：比如水冷、風冷、超頻、燈光等等的控制介面而已）。

啟動後BIOS程式首先檢查，計算機硬體能否滿足執行的基本條件，這叫做”硬體自檢”（Power-On Self-Test），縮寫為POST（對於剛配好的機器，第一次需要硬體自檢，在穩定後，不變更機器硬體的情況下，是可以關閉硬體自檢的，更新硬體的時候再開啟自檢就可以了）。

之後會去分析計算機裡面有哪些儲存裝置，BIOS會依據使用者的配置去讀取得能夠啟動的硬碟， 並且到該硬盤裡面去讀取第一個磁區的MBR位置。 MBR這個僅有446 bytes的硬碟容量裡面會放置最基本的啟動管理程式， 接下來就是MBR內的啟動管理程式的工作了。

這個啟動管理程式的目的是在載入(load)核心檔案， 由於啟動管理程式是作業系統在安裝的時候所提供的，所以他會認識硬碟內的檔案系統格式，因此就能夠讀取核心檔案， 然後接下來就是核心檔案的工作。

簡單的說，整個啟動流程到作業系統之前的動作應該是這樣的：

• BIOS：啟動主動執行的程式，會認識第一個可啟動的裝置；
• MBR：第一個可啟動裝置的第一個磁區內的主要啟動記錄區塊，內含啟動管理程式；
• 啟動管理程式(boot loader)：一支可讀取核心檔案來執行的軟體；
• 核心檔案：開始作業系統的功能。

由上面的說明我們會知道，BIOS與MBR都是硬體本身會支援的功能，至於Boot loader則是作業系統安裝在 MBR 上面的一套軟體了。由於MBR僅有446 bytes而已，因此這個啟動管理程式是非常小而美的。 這個boot loader的主要任務有以下這些專案：

• 提供選單：使用者可以選擇不同的啟動專案，這也是多重啟動的重要功能！
• 載入核心檔案：直接指向可啟動的程式區段來開始作業系統；
• 轉交其他loader：將啟動管理功能轉交給其他loader負責。

第三點表示你的計算機系統裡面可能具有兩個以上的啟動管理程式呢！ 我們的硬碟只有一個MBR，但是啟動管理程式除了可以安裝在MBR之外， 還可以安裝在每個分割槽的啟動磁區(boot sector)

多系統啟動

我們舉一個例子來說，假設你的個人計算機只有一個硬碟，裡面切成四個分割槽，其中第一、二分割槽分別安裝了Windows及Linux， 你要如何在啟動的時候選擇用Windows還是Linux啟動呢？假設MBR內安裝的是可同時認識Windows/Linux作業系統的啟動管理程式

• 每個分割槽都擁有自己的啟動磁區(boot sector)
• 系統槽為第一及第二分割槽，
• 實際可啟動的核心檔案是放置到各分割槽內的！
• loader只會認識自己的系統槽內的可啟動核心檔案，以及其他loader而已；
• loader可直接指向或者是間接將管理權轉交給另一個管理程式。

MBR的啟動管理程式提供兩個選單，選單一(M1)可以直接載入Windows的核心檔案來啟動； 選單二(M2)則是將啟動管理工作交給第二個分割槽的啟動磁區(boot sector)。當使用者在啟動的時候選擇選單二時， 那麼整個啟動管理工作就會交給第二分割槽的啟動管理程式了。 當第二個啟動管理程式啟動後，該啟動管理程式內僅有一個啟動選單，因此就能夠使用Linux的核心檔案來啟動。

linux初啟動

當bootloader開始讀取核心檔案後，接下來， Linux 就會將核心解壓縮到主記憶體當中， 並且利用核心的功能，開始測試與驅動各個周邊裝置，包括儲存裝置、CPU、網路卡、音效卡等等。 此時 Linux 核心會以自己的功能重新偵測一次硬體，而不一定會使用 BIOS 檢測到的硬體資訊！核心此時才開始接管 BIOS 後的工作，核心檔案會被放置到 /boot 裡面，並且取名為 /boot/vmlinuz。

[root@www ~]# ls --format=single-column -F /boot
config-2.6.18-92.el5      <==此版本核心被編譯時選擇的功能與模組配置檔
grub/                     <==就是啟動管理程式 grub 相關資料目錄
initrd-2.6.18-92.el5.img  <==虛擬檔案系統檔！
System.map-2.6.18-92.el5  <==核心功能放置到記憶體位址的對應表
vmlinuz-2.6.18-92.el5     <==就是核心檔案啦！最重要者！

此版本的 Linux 核心為 2.6.18-92.el5版本。為了硬體開發商與其他核心功能開發者的便利， 因此 Linux 核心是可以透過動態載入核心模組的，這些核心模組就放置在 /lib/modules/ 目錄內。 由於模組在根目錄內 (要記得 /lib 不可以與 / 分別放在不同的 partition ！)， 因此在啟動的過程中核心必須要掛載根目錄，這樣才能夠讀取核心模組提供載入驅動程式的功能。 而且為了擔心影響到磁碟內的檔案系統，因此啟動過程中根目錄是以只讀的方式來掛載的。

虛擬檔案系統

一般來說，有些硬體的驅動會被編譯成模組，某特通用的會被編譯進linux中，成為核心的一部分。 因此 U盤, SATA, SCSI… 等硬碟裝置的驅動程式通常都是以模組的方式來存在的。 現在來思考一種情況，假設你的 linux 是安裝在 SATA 磁碟上面的，你可以透過 BIOS 的 INT 13 取得 boot loader 與 kernel 檔案來啟動，然後 kernel 會開始接管系統並且檢測硬體及嘗試掛載根目錄來取得其他的驅動程式。

問題是，核心根本不認識 SATA 硬碟，所以需要載入 SATA 硬碟的驅動程式， 否則根本就無法掛載根目錄。但是 SATA 的驅動程式在 /lib/modules 內，無法掛載根目錄又怎麼讀取到 /lib/modules/ 內的驅動程式？在這個情況之下，可以透過虛擬檔案系統來處理這個問題。

虛擬檔案系統 (Initial RAM Disk) 一般使用的檔名為 /boot/initrd ，這個檔案的功能是，他也能夠透過 bootloader 來載入到記憶體中， 然後這個檔案會被解壓縮並且在記憶體當中模擬成一個根目錄， 且此模擬在記憶體當中的檔案系統能夠提供一個可執行的程式，透過該程式來載入啟動過程中所最需要的核心模組， 通常這些模組就是 U盤, RAID, LVM, SCSI 等檔案系統與磁碟介面的驅動程式，等載入完成後， /sbin/init 來開始後續的正常啟動流程。

bootloader 可以載入 kernel 與 initrd ，然後在記憶體中讓 initrd 解壓縮成為根目錄， kernel 就能夠藉此載入適當的驅動程式，最終釋放虛擬檔案系統，並掛載實際的根目錄檔案系統， 就能夠開始後續的正常啟動流程。

CentOS 5.x 的 initrd 檔案內容

# 1. 先將 /boot/initrd 複製到 /tmp/initrd 目錄中，等待解壓縮：
[root@www ~]# mkdir /tmp/initrd
[root@www ~]# cp /boot/initrd-2.6.18-92.el5.img /tmp/initrd/
[root@www ~]# cd /tmp/initrd
[root@www initrd]# file initrd-2.6.18-92.el5.img
initrd-2.6.18-92.el5.img: gzip compressed data, ...
# 原來是 gzip 的壓縮檔！因為是 gzip ，所以副檔名給他改成 .gz 吧！

# 2. 將上述的檔案解壓縮：
[root@www initrd]# mv initrd-2.6.18-92.el5.img initrd-2.6.18-92.el5.gz
[root@www initrd]# gzip -d initrd-2.6.18-92.el5.gz
[root@www initrd]# file initrd-2.6.18-92.el5
initrd-2.6.18-92.el5: ASCII cpio archive (SVR4 with no CRC)
#  cpio 的命令壓縮成的檔案，解壓縮看看！

# 3. 用 cpio 解壓縮
[root@www initrd]# cpio -ivcdu < initrd-2.6.18-92.el5
[root@www initrd]# ll
drwx------ 2 root root    4096 Apr 10 02:05 bin
drwx------ 3 root root    4096 Apr 10 02:05 dev
drwx------ 2 root root    4096 Apr 10 02:05 etc
-rwx------ 1 root root    1888 Apr 10 02:05 init
-rw------- 1 root root 5408768 Apr 10 02:00 initrd-2.6.18-92.el5
drwx------ 3 root root    4096 Apr 10 02:05 lib
drwx------ 2 root root    4096 Apr 10 02:05 proc
lrwxrwxrwx 1 root root       3 Apr 10 02:05 sbin -> bin
drwx------ 2 root root    4096 Apr 10 02:05 sys
drwx------ 2 root root    4096 Apr 10 02:05 sysroot
# 看！是否很像根目錄！尤其也是有 init 這個執行檔！務必看一下許可權！
# 接下來看看 init 這個檔案內有啥咚咚？

# 4. 觀察 init 檔案內較重要的執行專案
[root@www initrd]# cat init
#!/bin/nash                  <==使用類似 bash 的 shell 來執行
mount -t proc /proc /proc    <==掛載記憶體的虛擬檔案系統
....(中間省略)....
echo Creating initial device nodes
mknod /dev/null c 1 3        <==建立系統所需要的各項裝置！
....(中間省略)....
echo "Loading ehci-hcd.ko module"
insmod /lib/ehci-hcd.ko      <==載入各項核心模組，就是驅動程式！
....(中間省略)....
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro hdc2 <==嘗試掛載根目錄啦！
....(底下省略)....

透過上述執行檔的內容，我們可以知道 initrd 有載入模組並且嘗試掛載了虛擬檔案系統。 接下來就能夠順利的執行啦！那麼是否一定需要 initrd 呢？

不一定！需要 initrd 最重要的原因是，當啟動時無法掛載根目錄的情況下， 此時就一定需要 initrd ，例如你的根目錄在特殊的磁碟介面 (U盤, SATA, SCSI) ， 或者是你的檔案系統較為特殊 (LVM, RAID) 等等，才會需要 initrd。

如果你的 Linux 是安裝在 IDE 介面的磁碟上，並且使用預設的 ext2/ext3 檔案系統， 那麼不需要 initrd 也能夠順利的啟動進入 Linux 的！（實際上是指如果其驅動在核心之中，則不需要initrd可以直接載入驅動進行啟動）

在核心完整的載入後，接下來，就是要開始執行系統的第一個程式： /sbin/init。

The end

轉載：https://www.chenyanmo.com/?p=815