PC Booting 簡介

-

基於 BIOS 的開機流程簡介

描述基於 linux 的開機流程步驟, 適用於有 BIOS 的機器

  1. 開機的時候會執行 BIOS, BIOS 先對硬體做檢測. 在根據設定所指定的開機 device 去讀取 MBR(Master Boot Record). MBR 處於 device 的第一個 sector, 裡面包含了基本的 boot loader 與 partition table 資訊.
  2. 礙於 MBR 大小的限制(512 bytes = 446(basic boot loader code, e.g. boot.img) + 64(partition table)), boot loader 的會再去其他 sector 讀取完整的 boot loader 程式(e.g. core.img). 程式依據 MBR 或 GPT 來判斷放 boot loader 的位置[3][4].
    (1) 為MBR時候, 通常 boot loader 安裝於 MBR 與第一個 partition 之間.
    (2) 當為GPT, 則使用一個 Boot Partition 來存放 boot loader
  3. 當 boot loader 被執行後, 會去讀取 /boot/grub 裡面的設定來決定所要讀取的 OS 核心檔案 (kernel.img 和 initrd.img)
  4. initrd.img 裡面包含 kernel 所需的基本模組(mod), 當被掛載後 kernel 便可以去讀取外接裝置, 並視設定來決定是否有需要重掛載檔案系統
  5. 接著就執行第一支程式 e.g. initd or systemd

範例

範例1 [6]
  • Stage 1:

    boot.img is stored in the master boot record (MBR) or optionally in any of the volume boot records (VBRs), and addresses the next stage by an LBA48 address (thus, the 1024-cylinder limitation of GRUB legacy is avoided); at installation time it is configured to load the first sector of core.img.

  • Stage 1.5:

    core.img is by default written to the sectors between the MBR and the first partition, when these sectors are free and available. For legacy reasons, the first partition of a hard drive does not begin at sector 1 (counting begins with 0) but at sector 63, leaving 62 sectors of empty space not part of any partition or file system, and therefore not prone to any problems related with it. Once executed, core.img will load its configuration file and any other modules needed, particularly file system drivers; at installation time, it is generated from diskboot.img and configured to load the stage 2 by its file path.

  • Stage 2:

    files belonging to the stage 2 are all being held in the /boot/grub, which is a subdirectory of the /boot directory specified by the Filesystem Hierarchy Standard(FHS).

範例2 [7]

stage 1 = boot.img
stage 1.5 = diskboot.img + kernel.img + pc.mod + ext2.mod (the core image)
stage 2 = normal.mod+_chain.mod

The boot process for GRUB 2 then would be:
  • BIOS code reads MBR from a disk (looks at last 2 bytes to verify if MBR).
  • Starts executing bootloader code (boot.img).
  • This loads the first sector of the core image (diskboot.img), whose location was stored at a particular location in boot.img at GRUB install time and usually points to the core image located in the "DOS compat space" immediately after the MBR. diskboot.img in turn loads and executes the rest of the core image.
  • These core image modules know about the boot file system and can open the file system on the specified (at install time) partition. It looks for and loads modules there, including normal.mod
  • normal.mod loads the grub.cfg file and executes the statements, usually providing a menu to the user etc.

img 的功能描述

補充說明上述範例所提到的 img [2]
boot.img

On PC BIOS systems, this image is the first part of GRUB to start. It is written to a master boot record (MBR) or to the boot sector of a partition. Because a PC boot sector is 512 bytes, the size of this image is exactly 512 bytes.

The sole function of boot.img is to read the first sector of the core image from a local disk and jump to it. Because of the size restriction, boot.img cannot understand any file system structure, so grub-setup hardcodes the location of the first sector of the core image into boot.img when installing GRUB.

diskboot.img

This image is used as the first sector of the core image when booting from a hard disk. It reads the rest of the core image into memory and starts the kernel. Since file system handling is not yet available, it encodes the location of the core image using a block list format.

kernel.img

This image contains GRUB’s basic run-time facilities: frameworks for device and file handling, environment variables, the rescue mode command-line parser, and so on. It is rarely used directly, but is built into all core images.

core.img

This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the grub-mkimage program. Usually, it contains enough modules to access /boot/grub, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the file system at run-time. The modular design allows the core image to be kept small, since the areas of disk where it must be installed are often as small as 32KB.

See BIOS installation, for details on where the core image can be installed on PC systems.

*.mod

Everything else in GRUB resides in dynamically loadable modules. These are often loaded automatically, or built into the core image if they are essential, but may also be loaded manually using the insmod command (see insmod).

Reference

  • [1] M. Tim Jones, "Inside the Linux boot process", 2006
  • [2] "Where is the bootloader stored - in ROM, RAM, or elsewhere?", http://askubuntu.com/questions/173248/where-is-the-bootloader-stored-in-rom-ram-or-elsewhere
  • [3] "10 GRUB image files", https://www.gnu.org/software/grub/manual/html_node/Images.html
  • [4] "3.4 BIOS installation", https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html
  • [5] "2.2.3 開機流程中的 BIOS 與 UEFI 開機檢測程式", http://linux.vbird.org/linux_basic/0130designlinux.php#partition_bios_uefi
  • [6] "GNU_GRUB", https://en.wikipedia.org/wiki/GNU_GRUB
  • [7] "GRUB 2 boot process", http://www.pixelbeat.org/docs/disk/
  • [7] "bootloader", http://albert-oma.blogspot.tw/2011/12/bootloader.html

留言

張貼留言

這個網誌中的熱門文章

yocto recipe : (1) 撰寫 recipe

-
此篇文章介紹如何透過 yocto 的 utilities 來產生 recipe. 而完成的 recipe 又如何加入到 image. yocto 相關工具介紹 有三個適用於 layer 與 recipe 相關的 utilities. bitbake-layers: 負責 (1) 建立 layer. (2) 修改 bblayers.conf. (3) 查看 layer 底下的 recipes recipetool: 用於建立一個 recipe 和新增/修改 recipe. 這邊 recipe 在 yocto 即是 xx.bb 或 xx.bbappend 檔案 devtool: 定位在開發測試上. devtool 會建立一個獨立的 workspace layer. 讓開發者於此建立/修改 recipe 與 patch source code. 在不修改原有設定下與現有 layers 進行整合測試. 完畢之後可以再透過 devtool 新增或更新到 layer 裡 利用 utilities 撰寫 recipe 的時候. 要確保所屬的 layer 是存在於 bblayer.conf. 不然執行 bitbake [recipe basename] 會找不到相關的 recipe. yocto 事前準備 以 core-image-miniaml recipe 為例子. core-image-miniaml 會產生系統所需的 image 相關檔案. 接著利用 bitbake-layers 建立自己的 layer 於 build 目錄底下. 再透過 bitbake-layers 把 layer 加入到 bblayers.conf 設定檔. [ yijyun@localhost poky ] $ . oe-init-build-env [ yijyun@localhost build ] $ bitbake core-image-minimal [ yijyun@localhost build ] $ bitbake-layers create-layer meta-layer [ yijyun@localhost build ] $ bitbake-layers add-
閱讀完整內容

yocto recipe : (2) 撰寫 bbappend

-
前言 xxx.bb 檔案是用來描述一個 recipe. 然而 xxx.bb 會因為 patch codes、新增 tasks、等等的因素修改. 這邊介紹如何使用 xxx.bbappend[1] 檔案. 以不修改 xxx.bb 的情況下擴充需求. 文章將以 patch codes 為例子, 並個別以 devtool 工具和手動的方式示範. bbapend 簡介 .bbappend 是擴充 .bb 的方式. 藉由 .bbappend 來新增 tasks、patch code、新增/修改變數等等諸此之類的事. 其名稱必須跟所要修改的相同, 而版本號則依據需求寫. 舉例: bb file 名稱: giflib_5.1.4.bb bbappend 名稱: giflib_5.1.4.bbappend 或 giflib_%.bbappend. %: 表示萬用字元 使用 .bbappend 的情況, 我個人認為有以下情況再使用 (1) 當 recipe 已存在 yocto 最基本的 layer, 不應隨便修改. 舉例: u-boot_2017.09.bb 存在於 yocto 的 meta layer (2) 某些 layers 會共用此 recipe 的情況下. 舉例: meta-raspberrypi 與 meta-ti 分別各自使用自己的 xserver-xf86-config_0.1.bbappend 來對 yocto meta layer 的 xserver-xf86-config_0.1.bb 做擴充修改. bbappend 範例 事前準備 用 giflib [4] 作為測試程式. 先下載 giflib-5.1.4.tar.bz2. 接著使用 bitbake-layer 建立 meta-custom layer, 再透過 recipetool 把產生的 giflib_5.1.4.bb 存放於此 layer. # 執行 oe-init-build-env 進行 yocto 編譯環境設定 [ yijyun@localhost poky ] $ . oe-init-build-env # 建立 3rd-pkgs, 並把 giflib 放至此 [ yijyun@localhost build ] $
閱讀完整內容

yocto recipe : (3) 使用 External Source 來編譯軟體

-
Yocto 有提供許多 fetch code 的方式[3], 大都是以抓取外網的方式. 雖然很齊全, 但是開發時候多少需要以本機上的 source code 作為來源進行編譯. 這邊就紀錄如何讓 yocto 直接抓取本機上的 source code 使用本機上的 source code 這邊介紹兩種方式. 使用硬碟上的 source code, 而不是透過 yocto fetch 去網路上抓取 (1) git fetcher: 基於 git fetcher, 僅修改 src_uri 參數, 就可以用本機上的 source code (2) external source: 基於 externalsrc class. 有兩種方式達成: (1) 於 recipe 直接新增 external source 變數 (2)於 local.conf 新增特定 recipe 的 external source 參數. 事前準備 於 build 目錄底下建立 3rd-pkgs. 把下載的 giflib 程式碼放置於此 [ yijyun@localhost build ] $ pwd /media/disk1-1/Github/poky/build [ yijyun@localhost build ] $ ls 3rd-pkgs/ giflib-5.1.4.tar.bz2 新增 meta-test 於 yocto. 並在此 meta-layer 底下新增 giflib 目錄. 存放之後的 bb files [ yijyun@localhost build ] $ bitbake-layers create-layer meta-test [ yijyun@localhost build ] $ bitbake-layers add-layer meta-test [ yijyun@localhost build ] $ mkdir meta-test/recipes-example/giflib git fetcher 使用 git fetcher 有兩個重點: src_uri 的 protocol 參數需要改為 file. S 的路徑要改為 S="
閱讀完整內容