Bootloader技术分析

嵌入式软件系统 嵌入式操作系统已经得到广泛应用 带操作系统的嵌入式软件体系一般分为： 引导加载程序 操作系统内核 文件系统（可选） 用户应用程序

PC 机的引导加载程序 BIOS+MBR BIOS的本质是一段固件程序（Firmware） MBR （master boot record主引导记录）是磁盘上的一段分区，位于磁盘的第一个扇区，大小为512B，包含了磁盘的分区信息以及系统引导代码，在单一的 MBR 中只能存储一个操作系统的引导记录，当需要多个操作系统时就会出现问题，需要更灵活的引导加载程序，比如Lilo和Grub 。

PC 机的引导加载程序 主引导记录本身要包含两类内容 —— 部分（或全部）引导加载程序以及分区表（其中包含有关于介质其余部分如何划分为分区的信息）。 当 BIOS 引导时，它会寻找硬盘驱动器第一个扇区（MBR）中存储的数据；BIOS 使用存储在 MBR 中的数据激活引导加载程序。

PC 机的引导加载程序 由于BIOS只能访问很少量的数据，所以大部分引导加载程序分两个阶段进行引导。在引导的第一个阶段中，BIOS引导一部分引导加载程序，即初始程序加载程序（initial program loader，IPL）。IPL 查询分区表，从而能够加载位于不同介质上任意位置的数据。通过这步操作来定位第二阶段引导加载程序（其中包含加载程序的其余部分）。 第二阶段引导加载程序是引导加载程序的主体，很多人认为这才是引导加载程序的真正部分。它包含有加载程序更占用磁盘空间的部分，比如用户界面和内核引导程序。从简单的命令行到范围广泛的 GUI。

PC 机的引导加载程序 引导加载程序通常配置为两种方式之一：要么是作为主引导加载程序（primary boot loader），要么是作为二级引导加载程序（secondary boot loader）。主引导程序是安装在 MBR上的第一阶段引导加载程序（见先前的描述）。二级引导加载程序 是安装在可引导分区的第一阶段引导加载程序，必须在 MBR 上安装单独的引导加载程序，并配置它将控制权转交给二级引导加载程序。 很多Linux引导加载程序提供了不同程度的交互，比如高级的 GUI 和加密的口令，以及通过选择操作系统进行引导的能力。这样，可以在具有多个物理磁盘的同一机器上共存多个操作系统，只使用一台机器就可同时拥有Linux和Windows。

PC 机的引导加载程序 GRUB 和 LILO 是在基于Intel的系统上引导Linux最常用的方法。作为操作系统装载程序，它们仅使用在计算机硬件中内建的基本 I/O 系统（或 BIOS）。 在多数基于 Intel 的计算机中，GRUB 和 LILO 要接受由 BIOS 所强加的限制。例如，多数 BIOSes 无法进入两个以上的硬盘，而且它们无法访问任一驱动器上在超越柱面 1023 以上所贮存的数据。但是，某些新的 BIOSes 没有这些限制。

PC 机的引导加载程序 所有 GRUB 和 LILO 在引导期间访问的数据 （包括 Linux 内核）位于 /boot 目录中。/boot 目录既可以是一个单独的小分区，也可能会驻留在根分区 (/)上。 在任一情况下，如果要使用 GRUB 或 LILO 来引导Linux系统， /boot 所驻留的分区一定要遵守以下条例： 1）在前两个IDE 驱动器上：如果有两个IDE（或 EIDE）驱动器， /boot 必须要位于其中之一， 两个驱动器的限制也包括任何在主IDE控制器上的IDE光盘驱动器。因此，如果在主控制器上有一个 IDE 硬盘，和一个光盘驱动器， /boot 必须仅能位于第一个硬盘，即便你在次IDE控制器上另有硬盘。

PC 机的引导加载程序 2）在第一个 IDE 或第一个 SCSI 驱动器上：如果你有一个 IDE（或 EIDE）驱动器以及一个或更多 SCSI 驱动器，/boot 必须位于IDE 驱动器上或 ID 为 0 的 SCSI 驱动器上。 3）在前两个 SCSI 驱动器上：如果你只有 SCSI 硬盘，/boot 必须位于 ID 为 0 或 1 的驱动器上。 4）分区完全在柱面 1023 之下：无论是以上哪一种配置，容有 /boot 的分区必须要全部位于柱面 1023 之下。如果容有 /boot 的分区位于柱面 1023 的两侧，所面对的情形可能是，GRUB 和 LILO 最初会起作用 （因为所有必需的信息都位于柱面 1023 之下）， 但是如果一个新内核被载入后驻留在柱面 1023 之上的话，它们将会失败。

PC 机的Linux引导加载过程 启动过程 BIOS完成硬件检测、资源分配，然后将引导代码（512B）读入内存0x7c00中，然后跳转到0x7c00运行(将CPU控制权交给引导程序) 引导代码将自己搬移到0x90000，再跳转到该地址执行，然后将磁盘上的setup和内核映像读入内存0x90200，并跳转到setup运行 在setup中完成处理器设置、解压缩等操作，将内核解压到一个固定地址，然后跳转到该地址运行，从而进入到内核初始化过程

嵌入式系统中的引导程序 一般嵌入式系统没有BIOS 引导程序被称为Bootloader 引导程序完成硬件检测、资源分配和操作系统内核的引导（拷贝+跳转） Bootloader还需要完成映像下载、flash烧写、代码调试等功能 常用的开源Bootloader有u-boot、Blob、redboot、vivi等

Bootloader的特点 与硬件关系密切 与具体CPU类型有关 与系统的具体硬件实现（电路板）有关 与具体操作系统无关 通常保存在某种被映射到CPU某个指定地址（一般为0x00，reset的入口地址）的固态存储器中 一旦系统开始运行，Bootloader便不再起作用

Bootloader的特点 Bootloader启动可以是单阶段或多阶段，代码可以都在flash中运行，或者一部分在flash中运行，另一部分在ram中运行 一般bootloader至少有一部分在flash中运行，但有少数例外（需要处理器支持） 一般bootloader有“引导”和“下载”两种工作模式 还需要支持与主机（Host）之间的通信，一般为串口

采用两级启动方式的Bootloader Stage1:主要完成一些依赖于处理器体系结构的任务，通常用汇编语言完成 硬件设备初始化 为加载stage2准备RAM空间 将stage2代码复制到RAM空间，并设置堆栈 跳转到stage2的代码入口

采用两级启动方式的Bootloader Stage2:完成诸如命令处理等更加复杂的功能，通常用C语言完成 初始化本阶段需要用到的其他硬件设备 准备系统内存映射 将操作系统内核从Flash中搬移到RAM中 为内核设置启动参数 调用内核入口函数

Bootloader结构 处理器启动初始化代码及中断向量表 必要的设备管理机制和驱动函数 对传输协议的支持 由于需要完成“下载”功能，需要同主机之间进行文件传输，所以需要支持至少某种文件传输协议和相应的驱动程序，一般通过串口，需要支持xmodem/ymodem/zmodem等，当然通过网络也是一个较好的选择

Bootloader结构 由于bootloader在工作过程中（尤其是调试阶段）需要与开发者进行交互，所以提供一个用户界面是必要的，通常通过串口终端的方式来完成 有些bootloader支持压缩格式，也就是说可以在拷贝代码的过程中进行解压操作

Bootloader代码结构 一般的Bootloader的结构分成： 目标处理器相关代码，一般stage1的入口代码在此目录中 驱动代码，包括串口、网络、USB、以及ROM操作驱动 命令处理代码 其他代码

Bootloader —— vivi Mizi 为 Samsung 的 ARM开发板提供的一种ARM bootloader 支持autoboot模式和prompt模式 支持xmodem文件传输 提供flash的操作功能，以及load、part、param、boot等命令

Vivi代码结构 Arch：包含vivi支持的处理器 Drivers:包含了MTD和串口驱动程序 Init：包含main程序，stage2的入口点 Lib：与平台无关的公共的代码，比如memory操作、命令操作等 Include:所有头文件

目标板配置 处理器：samsung S3C2410X（ARM920T） 32M NandFlash，用作Boot 64M SDRAM，地址范围0x30000000—0x33ffffff

S3C2410不同boot方式的内存映射

从NandFlash启动的2410 S3c2410内置NandFlash控制器，支持NandFlash boot模式 在NandFlash boot时，系统自动拷贝NandFlash最初4K的代码到片内sram中作为启动代码 前4K代码完成stage1的工作

代码在存储区中的位置

Vivi的存储器区域_ROM VIVI_ROM_BASE: 使用Bon分区，起始区域保存vivi代码，然后是Kernel和rootfs映像，除vivi起始为VIVI_ROM_BASE外，其他的起始地址可变 VIVI_PRIV_ROM_BASE： 保存Bon分区表 Vivi参数表 linux系统启动参数（commandline）

Vivi的存储器区域_RAM RAM_BASE: RAM起始地址，低地址留给内核使用，高地址由vivi使用 VIVI使用的RAM空间: Vivi在RAM中的起始地址VIVI_RAM_BASE Vivi使用的堆地址：HEAP_BASE 2410使用的MMU地址：MMU_TABLE_BASE Vivi参数地址：VIVI_PRIV_RAM_BASE Vivi使用的栈地址：STACK_BASE

U-boot简介 起源于PPC-BOOT 是一种通用的Bootloader 开源，高度模块化 驱动程序丰富、命令操作灵活

U-BOOT代码结构 Board:与目标板相关代码 Common:命令的实现代码 Cpu:与目标处理器相关代码 Drivers:各种驱动程序 Fs:支持的文件系统 Lib_arm:ARM平台的公共接口代码

CPU相关文件 Cpu.c 和cpu核相关的操作，注意对于某一个系列的cpu来说，这个文件一般是公共的 Start.s 入口点 Autoconfig.h 自动设置文件 Interrupts.c 这个文件定义了中断处理相关操作

Board相关文件 lowlevel_init.S 用于初始化一些周边设备，主要是存储器 Smdk2410.c 用于板级系统初始化 Flash.c 是板级系统的Flash驱动函数所在 在此目录中，包含了整个系统的 .lds文件 .lds文件，它定义了整个程序编译之后的连接过程，决定了一个可执行程序的各个段的存储位置。

Lib_arm中的相关文件 Armlinux.c arm系统引导内核的函数所在文件 _umodsi3.s和_udivsi3.s 用于arm的算术运算 Cache.c和div0.c board.c 包含了stage2的入口点

U-boot所使用的文件格式 U-boot的tools目录提供一个工具mkimage用来将elf格式的image文件转成uImage Vmlinux elf格式 zImage和bzImage 经过压缩的image 用objcopy可以将elf转成bin文件 BIN文件是 raw binary 文件，这种文件只包含机器码。 ELF文件除了机器码外，还包含其它额外的信息，如段的加载地址，运行地址，重定位表，符号表等。 所以ELF文件的体积比对应的BIN文件要大。 编译完uboot后生成： u-boot         ELF文件可用来调试 u-boot.bin     BIN文件用来烧在Flash上 编译linux生成： vmlinux        ELF文件可用来调试 vmlinux.bin    BIN文件，没直接用过 zImage/vmlinuz/bzimage 将vmlinux.bin压缩，并加上一段解压代码得到的，不可和bootloader共存？ uImage          uboot专用的内核镜像，在zImage前加了一个64字节的头，描述内核版本、加载地址生成时间，文件大小等等。 其0x40后的内容和zImage一样，它是由uboot的工具mkImage生成的。  uImage相对于zImage的优点在于：uImage可以和uboot共存。

U-boot下载映像的制作过程 编译内核，得到vmlinux文件 使用objcopy得到二进制文件linux.bin ${CROSS_COMPILE}-objcopy -O binary \ -R .note -R .comment \ -S vmlinux linux.bin 压缩二进制文件linux.bin，得到linux.bin.gz 使用u-boot工具mkimage将压缩文件打包，加入load地址、解压地址等信息

Bootloader的作用 对于无OS的arm，可以将其用作一般的单片机使用。不带OS的arm另外一种开发方式就是用Bootloader来引导应用程序的下载，如通过串口或网口（具体实现依赖于Bootloader的代码功能）。

Bootloader的作用 要在arm上运行OS，就必须要有Bootloader了。之所以依赖Bootloader引导内核，是因为ARM无法完成大系统映像的下载工作，而Bootloader下载可以有更多的自由度，可以制定内核映像和文件系统映像的下载地址等。 Bootloader的职责包括硬件检测、硬件初始化和加载kernel，这些工作按照功能可以分为两个部分：硬件检测和初始化功能实现作为stage1；加载kernel作为stage2。stage1完全依赖于硬件，这一部分用汇编语言实现；stage2与操作系统有关，一般用C语言来实现。

Bootloader的工作模式 在开发时，通常使用各种命令操作Bootloader，一般通过串口来连接PC和开发板，可以在串口上输入各种命令、观察运行结果、烧写内核和文件系统等。这也只是对开发人员才有意义，用户使用产品时是不用串口来控制Bootloader的。从这个观点看，bootloader可以分为以下两种工作模式： 启动加载模式 上电后，Bootloader从板子上的某个固态存储设备上将操作系统加载到RAM运行，这个过程没有用户的介入。

Bootloader的工作模式 下载模式 这种模式下，开发人员使用各种命令，从主机上将文件（内核映像、文件系统映像）下载到目标机上。板子与主机间传输文件时，可以用串口的xmodem/ymodem/zmodem协议，它们使用简单，只是速度比较慢；还可以使用tftp、nfs协议来传输；或者使用USB传输。

Bootloader的烧写（固化） 如何将Bootloader烧写（固化）到非易失性存储介质中去呢？（Nor Flash，Nand Flash等） 具体要分以下几种情况：

Bootloader的烧写（固化） 1、使用编程器将Bootloader烧写到falsh中: 将Bootloader写入Flash，然后将烧写完毕的Flash插入板子上，这是针对Flash还没有插入板子的情形。编程器也叫device programmer，是对非易失性存储介质和其他电可编程设备进行编程的工具。传统的编程器，需要把Flash（举例）从电路板上取下来，插到编程器的接口上，以完成擦除和烧写。现在的编程器发展的方向是ISP（In-System Programming，在系统可编程），就是指电路板上的空白器件可以编程写入最终用户代码，而不需要从电路板上取下器件。

Bootloader的烧写（固化） 2、使用ADS软件和ARM仿真器： 先将编译后的Flash烧写程序加载到SDRAM中，运行Flash烧写程序，在指定Flash烧写的起始地址后，Flash烧写程序将从电脑上把编译好的Bootloader映像烧写到Flash的指定位置。

Bootloader的烧写（固化） 3、使用Bootloader： 这是针对Bootloader已经驻留在Flash的情形，可以通过Bootloader烧Bootloader，Bootloader之所以具有这种功能，是由Bootloader的分段执行特性决定的，当Bootloader在Flash中执行时，主要是把自身剩余的代码复制到SDRAM中，然后进入到SDRAM运行后就可以反过来更新Flash中的Bootloader映像了。如果Bootloader不分段一直在Flash中执行，同时又更新Flash中的数据，这样将造成逻辑错误。

Bootloader的烧写（固化） 4、处理器支持从ROM启动

Bootloader的烧写（固化） 比如，Cirrus Logic 的EP93XX系列，它内部集成了一个BootROM，固化代码初始化串口，支持从串口下载数据。那么在Host端只需要相应的开发一个相同串口协议的download程序，就可以完成bootloader（EP93XX系列使用的是Redboot）烧写到Falsh里【注：这里的编程器就可以认为是download+RS-232交叉线】，然后从Falsh启动，有Redboot进行下面的工作。因为Redboot实现了串口传输协议和TFTP协议，就可以通过RS-232来进行控制，通过Ethernet完成大的映象文件如kernel和fs的下载固化。

Bootloader的烧写（固化） ATMEL的AT91RM9200内部也集成了一个ROM，固化代码，同样初始化串口，启动串口传输协议Xmodem，等待输入【注：这里的编程器就可以认为是loader+RS-232交叉线】。官方提供的loader就是完成把U-boot下载固化到flash里面。因为kernel和fs比较大，可以采用压缩，官方提供boot来完成从flash启动后自动解压过程。这样，从flash启动就慢了许多。

Bootloader的烧写（固化） 5、处理器不支持从ROM启动 还有些厂商为了节省ROM空间，提高集成度，不支持从ROM启动模式。比如三星公司的S3C2410等。这样一种简单的方法就是采用JTAG下载线作为编程器的硬件连接，完成其Bootloader（如Vivi）的烧写。在Windows环境下，针对JTAG硬件连接，编程器的软件有JFlash（JTAG for Flash），SJF，Flash Programmer等，还是比较丰富的。在Linux环境下，有JFlash的Linux版本【注：在Linux下，这里的编程器就可以认为是JFlash+JTAG下载线，S3C2410是提供JTAG接口的】。