樹莓派3b+上電啟動流程的示例分析

這篇文章給大家分享的是有關(guān)樹莓派3b+上電啟動流程的示例分析的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

最近在玩樹莓派，覺得這個樹莓派的啟動過程有點意思。所以在收集很多信息之后，個人也進(jìn)行了一些實驗和總結(jié)。先看一段原始資料：

This is an in-detail account of the Raspberry Pi boot process collected from various sources, mainly from the official forums. First, you need to know the RPi does not boot up like a conventional desktop computer. The VideoCore a.k.a the Graphics processor actually boots before the ARM CPU! Anyway, before we get into the details here’s a diagram of the RPi highlighting the Broadcom BCM2835 SoC.
The SoC (or System-on-Chip) contains the ARM CPU, the VideoCore Graphics Processor, ROM (Read-Only-Memory) chips, the SDRAM and so many other things. Basically, think of a SoC as your Motherboard and CPU compressed together into a single chip.
When you power on your Raspberry Pi, the first bits of code to run is stored in a ROM chip in the SoC and is built into the Pi during manufacture! This is the called the first-stage bootloader. The SoC is hardwired to run this code on startup on a small RISC Core (Reduced Instruction Set Computer). It is used to mount the FAT32 boot partition in your SDCard so that the second-stage bootloader can be accessed. So what is this ‘second-stage bootloader’ stored in the SD Card? It’s ‘bootcode.bin’. You might have seen this file if you had mounted the SD Card in Windows. Now here’s something tricky. The first-stage bootloader has not yet initialized your ARM CPU (meaning CPU is in reset) or your RAM. So, the second-stage bootloader also has to run on the GPU. The bootloader.bin file is loaded into the 128K 4 way set associative L2 cache of the GPU and then executed. This enables the RAM and loads start.elf which is also in your SD Card. This is the third-stage bootloader and is also the most important. It is the firmware for the GPU, meaning it contains the settings or in our case, has instructions to load the settings from config.txt which is also in the SD Card. You can think of the config.txt as the ‘BIOS settings’ (as is mentioned in the forum). Some of the settings you can control are (thanks to dom):
arm_freq : frequency of ARM in MHz. Default 700.
gpu_freq : Sets core_freq, h364_freq, isp_freq, v3d_freq together.
core_freq : frequency of GPU processor core in MHz. Default 250.
h364_freq: frequency of hardware video block in MHz. Default 250.
isp_freq: frequency of image sensor pipeline block in MHz. Default 250.
v3d_freq: frequency of 3D block in MHz. Default 250.
sdram_freq: frequency of SDRAM in MHz. Default 400.
The start.elf also splits the RAM between your GPU and the ARM CPU. The ARM only has access the to the address space left over by the GPU address space. For example, if the GPU was allocated addresses from 0x000F000 – 0x0000FFFF, the ARM has access to addresses from 0×00000000 – 0x0000EFFF. (These are not real address ranges. It’s just for demonstration purposes). Now what’s even funnier is that the ARM core perceives 0×00005001 as it’s beginning address 0×00000000. In other words, if the ARM core requests the address 0×0000000, the actual address in RAM is 0×00005001. Edit: The physical addresses perceived by the ARM core is actually mapped to another address in the VideoCore (0xC0000000 and beyond) by the MMU (Memory Management Unit) of the VideoCore. The config.txt is loaded after the split is done so you cannot specify the splitting amounts in the config.txt. However, different .elf files having different splits exist in the SD Card. So, depending on your requirement, you can rename those files to start.elf and boot the Pi. (The forums mention of having this functionality in a dynamic fashion, but I don’t know whether they have implemented it yet) In the Pi, the GPU is King!
Other than loading config.txt and splitting RAM, the start.elf also loads cmdline.txt if it exists. It contains the command line parameters for whatever kernel that is to be loaded. This brings us to the final stage of the boot process. The start.elf finally loads kernel.img which is the binary file containing the OS kernel (DUH!?) and releases the reset on the CPU. The ARM CPU then executes whatever instructions in the kernel.img thereby loading the operating system.
After starting the operating system, the GPU code is not unloaded. In fact, start.elf is not just firmware for the GPU, It is a proprietary operating system called VideoCore OS. When the normal OS (Linux) requires an element not directly accessible to it, Linux communicates with VCOS using the mailbox messaging system.
Note: Special thanks to user dom in the official RPi forums and the community behind the official wiki.

這是Herman Hermitage大神分享出來的資料。

我來按照理解分析一下這個過程：

當(dāng)給樹莓派加電后，最先執(zhí)行保存在ROM中的代碼，這些代碼是芯片出廠的時候就設(shè)定的，通常被稱為 first-stage bootloader，這些代碼固化硬件內(nèi)部，可以認(rèn)為是SoC硬件的一部分。這部分代碼通常都是固化的，不可以修改也不可以進(jìn)行讀取。

first-stage bootloader的主要工作是加載位于SD卡上第一個分區(qū)的bootloader（稱為second-stage bootloader ），也就是SD卡的第一個FAT32分區(qū)的根目錄下尋找一個叫bootcode.bin的二進(jìn)制文件。那么這個時候，其實CPU并沒有啟動，執(zhí)行這個動作的其實是SOC封裝里的GPU。這就是非常奇怪的地方！一般來說我們理解都是CPU負(fù)責(zé)產(chǎn)生數(shù)據(jù)，然后交給GPU去做運算，怎么GPU倒反客為主了呢？但是樹莓派就是這樣設(shè)定的！并且GPU性能可以超過CPU。接著GPU將bootcode.bin讀取到128KB大小的二級緩存(L2 Cache)，并開始執(zhí)行bootcode.bin。這是第二階段。

當(dāng)然當(dāng)然，這還沒有結(jié)束，緊接著，執(zhí)行第三階段。bootcode.bin的主要工作是初始化ram，并把start.elf（也位于SD卡的第一分區(qū)）加載到內(nèi)存中。start.elf就是third-stage bootloader。那么第三階段結(jié)束。

第三階段載入運行的start.elf的功能就是加載位于SD卡中的config.txt。該文件可以理解為BISO，詳細(xì)記錄了配置信息。

arm_freq : frequency of ARM in MHz. Default 700.
gpu_freq : Sets core_freq, h364_freq, isp_freq, v3d_freq together.
core_freq : frequency of GPU processor core in MHz. Default 250.
h364_freq: frequency of hardware video block in MHz. Default 250.
isp_freq: frequency of image sensor pipeline block in MHz. Default 250.
v3d_freq: frequency of 3D block in MHz. Default 250.
sdram_freq: frequency of SDRAM in MHz. Default 400.
start.elf把ram空間劃分為2部分：CPU訪問空間和GPU訪問空間。SoC芯片只訪問屬于GPU地址空間的內(nèi)存區(qū)，例如，GPU的物理內(nèi)存地址空間為0x000F000 – 0x0000FFFF，CPU的物理內(nèi)存地址空間為0x00000000 – 0x0000EFFF，如果GPU訪問0x0000008，那么它訪問的物理地址為0x000F008。（實際上，ARM處理器的mmu部件把GPU的內(nèi)存空間映射到0xC0000000 開始）。config.txt在內(nèi)存地址空間分配完成后才加載，因此，不可以在config.txt中更改內(nèi)存地址的配置。然而，可以通過配置多個elf文件來讓start.elf和config.txt支持多種配置空間。start.elf還從SD卡的第一個分區(qū)中加載cmdline.txt（如果cmdline.txt存在的話）。該文件保存的是啟動kernel（不一定是Linux的內(nèi)核）的參數(shù)。至此，SoC進(jìn)入了boot的最后階段，start.efl把kernel.img，ramdisk，dtb加載到內(nèi)存的預(yù)定地址，然后向cpu發(fā)出重啟信號，因此cpu就可以從內(nèi)存的預(yù)定地址執(zhí)行kernel的代碼，就進(jìn)入了軟件定義的系統(tǒng)啟動流程。

分析樹莓派的啟動過程也是非常有意思的。一般玩過嵌入式Linux的都知道，一般的啟動流程都是在CPU中進(jìn)行：

第一階段：bootloader（固化代碼，引導(dǎo)Uboot）

第二階段：Uboot(初始化必要的外設(shè)，并引導(dǎo)啟動kernel)

第三階段：kernel（初始化外設(shè)，進(jìn)入文件系統(tǒng)rootfs）

然而BCM2835 SoC整個過程都是GPU來辦事，啟動過程為：

第一階段：bootloader(固化代碼，加載sd卡中的bootcode.bin文件)

第二階段：bootcode.bin(初始化ram，并加載SD卡中的start.elf文件)

第三階段: start.elf（配置CPU與GPU的地址空間，主頻，并加載Linux內(nèi)核）

特別說明一下：GPU

GPU(Graphics Processing Unit)是圖形處理單元，一般是用來加速處理圖像算法的，可以進(jìn)行復(fù)雜運算，需要配合CPU來使用。CPU負(fù)責(zé)提供數(shù)據(jù)，傳遞給GPU計算，然后再收集GPU的計算結(jié)果。GPU一般是不能獨立執(zhí)行代碼的。但是Broadcom已經(jīng)做到第五代了叫VideoCore IV。是具有代碼處理能力的。由此，個人覺得GPU遲早一天要取代CPU或者兩者進(jìn)行融合，充分體現(xiàn)處理器的價值！

感謝各位的閱讀！關(guān)于“樹莓派3b+上電啟動流程的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！