bootloader(xboot)起动流程分析

1.   引言

      本文先引用一段《Boot Loader 技术内幕》中的一段话来简介bootloader基本概念,再
通过xboot的实例分析来分析xboot接口。

作者: http://blog.csdn.net/dyron欢迎大家来讨论相关内容。

2.  BootLoader 的概念

      简单地说,Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小
程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到一
个合适的状态,以便为最终调用操作系统内核准备好正确的环境。

      通常,Boot Loader 是严重地依赖于硬件而实现的,特别是在嵌入式世界。因此,在嵌
入式世界里建立一个通用的 BootLoader 几乎是不可能的。尽管如此,我们仍然可以对 Boot
Loader 归纳出一些通用的概念来,以指导用户特定的 Boot Loader 设计与实现。

1. Boot Loader 所支持的 CPU 和嵌入式板

      每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持
多种体系结构的 CPU,比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。
除了依赖于 CPU 的体系结构外,Boot Loader 实际上也依赖于具体的嵌入式板级设
备的配置。这也就是说,对于两块不同的嵌入式板而言,即使它们是基于同一种 CPU
而构建的,要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上,
通常也都需要修改 Boot Loader 的源程序。

2. Boot Loader 的安装媒介(Installation Medium)

      系统加电或复位后,所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址
上取指令。比如,基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000
取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设
备(比如:ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在
系统加电后,CPU 将首先执行 Boot Loader 程序。

下图1就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像
的固态存储设备的典型空间分配结构图。


1 固态存储设备的典型空间分配结构
 

3. 用来控制 Boot Loader 的设备或机制

     主机和目标机之间一般通过串口建立连接,Boot Loader 软件在执行时通常会通过串口
来进行 I/O,比如:输出打印信息到串口,从串口读取用户控制字符等。

3.   Xboot简介

     由于我们项目使用了mmc卡做为主存储器件,故我们的bootloader前需要存放
mbr信息,故我们的bootloader固件由mbr+bootloader两部分组成。

Xboot的目录如下:

boot      mbr.bin             rules.mk
Changelog  mbr-xboot.bin       spl
config.mk  mkcompatibility.sh  x-boot.bin
mkconfig  x-boot.lds          include
msc-spl.bin  x-boot-msc.bin   Makefile
README

Boot目录下是主要的程序代码及开发板代码。

Include 目录下是程序的头文件。

Spl 是相应的环境脚本及制作mbr工具代码。

Xboot的目录结构相对简单, x-boot.lds是链接脚本。

4.   x-boot汇编启动分析

     下边我们就开始分析x-boot的启动流程, 首先看x-boot.lds文件,整个脚本内容
如下,看了脚本就会发现,x-boot还存在u-boot的影子,属抄袭作品:-) .

OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
{
    . = 0x00000000;

    . = ALIGN(4);
    .text       :
    {
      *(.text)
    }

    . = ALIGN(4);
    .rodata  : { *(.rodata) }

    . = ALIGN(4);
    .data  : { *(.data) }

    . = ALIGN(4);
    .sdata  : { *(.sdata) }

    _gp = ALIGN(16);

    __got_start = .;
    .got  : { *(.got) }
    __got_end = .;

    .sdata  : { *(.sdata) }

    __u_boot_cmd_start = .;
    .u_boot_cmd : { *(.u_boot_cmd) }
    __u_boot_cmd_end = .;

    uboot_end_data = .;
    num_got_entries = (__got_end - __got_start) >> 2;

    . = ALIGN(4);
    .sbss  : { *(.sbss) }
    .bss  : { *(.bss) }
    uboot_end = .;
} 

       在24行我们发现,ENTRY(_start)指定入口为_start,  接入寻找导出_start符号的文件,
发现是在boot/init/init.S中导出。

1 /*
 2  *  Startup Code for the X-Boot.
 3  *
 4  *  Copyright (c) 2005 - 2009   Ingenic Semiconductor Corp.
 5  *
 6  */
  7#include <config.h>
  8#include <regdef.h>
  9
 10    .set noreorder
 11
 12    .globl _start
 13    .text
 14_start:
 15    la  sp, TEXT_BASE       // set sp
 16     j   boot_main       // jump to c routine
 17    nop

     在init.S文件中的16行发现, 这段代码最终跳转到boot_main符号处执行c代码, 最

终跳到./boot/common/boot_main.c中的boot_main 函数开始执行, 这就进入了我们的C程序。

5.      xboot的C启动流程

     上章说到我们的pc指针进入了boot_main函数, 首先在738-761行设置开发板必要的
GPIO。 然后设置键盘及必要的gpio引脚。

     Xboot的启动相对简单,初始化引脚后,初始化MMC卡,进行检测开机逻辑, 都是各
厂商自己定制的内容,主要就是选择进入什么样的kernel模式,而进入kernel模式的选择
有多种,这里主要介绍一下通过内核参数来选择的方式。

6.      内核的参数传递

这里以BOOT_NORMAL为例,分析一下xboot的参数传递

下边是BOOTARGS_NORMAL的定义。

#define BOOTARGS_NORMAL             CONFIG_BOOTARGS
 
#define CONFIG_BOOTARGS        "mem=128M console=ttyS1,57600n8ip=off 
root=/dev/ram0 rw rdinit=/init"
 
在msc_boot.c的第56行,将启动参数赋值到cmdline中
static u8 cmdline[256] = CFG_CMDLINE;
 
将kernel从MMC拷贝到启动地址 0x80000000
#define CFG_KERNEL_DST    0x80000000   /* Load Linux kernel to this addr   */
do_msc((u8 *)CFG_KERNEL_DST, offset,size);
 
初始化kernel的启动参数与及randisk
int init_boot_linux(unsigned char*data_buf, unsigned int data_size)
 
因为我们的kernel并非正常的zImage, 而是由ramdisk+kernel打包成的boot.img, 故
在boot_linux中进行了分解,并设置了详细的参数。
 
首先从MMC读出的buf中读出2k的bootimginfo, 里边包含有kernel的地址大小与
ramdisk的地址大小, 启动命令行等信息.
memcpy(&bootimginfo, Bulk_Data_Buf,2048);
 
计算出kernel和ramdisk实际占用的大小。
kernel_actual = (bootimginfo.kernel_size +page_mask) & (~page_mask);
ramdisk_actual = (bootimginfo.ramdisk_size+ page_mask) & (~page_mask);
 
获得kernel与ramdisk在buf中的实际地址,填充到bootimginfo结构中.
bootimginfo.kernel_addr = (unsignedint)Bulk_Data_Buf;
bootimginfo.ramdisk_addr =bootimginfo.kernel_addr + kernel_actual;
 
从MMC中读取ramdisk到CFG_RAMDISK_DST处。
do_msc((u8 *)CFG_RAMDISK_DST,ramdisk_offset, ramdisk_actual);
 
填充启动kernel的参数结构及组成kernel 启动的cmdline
       param_addr= (u32 *)PARAM_BASE;
       param_addr[0]= 0;/* might be address of ascii-z string: "memsize" */
       param_addr[1]= 0;/* might be address of ascii-z string: "0x01000000" */
       param_addr[2]= 0;
       param_addr[3]= 0;
       param_addr[4]= 0;
       param_addr[5]= PARAM_BASE + 32;//0x80004020
       param_addr[6]= CFG_KERNEL_START;
       tmpbuf= (u8 *)(PARAM_BASE + 32);
 
跳转到kernel的启动地址,启动kernel
#define PARAM_BASE             0x80004000
(*kernel)(2, (char **)(PARAM_BASE + 16), (char*)PARAM_BASE);

     这里的第1个参数是指传入参数的个数, 第2个参数是指传入参数的内存地址, 第3
个参数是指环境变量的内存地址。 (在uboot中传递为4个参数,在xboot中这种实现似
乎不太符合标准。 待深入研究)

7.      本文结束语

     相对于uboot来讲,xboot的启动流程相对非常简化,命令行工具都去除掉了,但启动
速度确实大大优于uboot, 这也许就是君正选择xboot的原因吧,欢迎大家来讨论,
dyronchina@gmail.com



8. 补充内容, 回答网友yuenshu fong的问题

xboot的编译流程

xboot的编译流程如下:
根据 ALL = $(X_BOOT) $(X_BOOT_NAND) $(X_BOOT_SD) $(X_BOOT_MSC)
首先编译x-boot.bin
$X_BOOT_NAND   X_BOOT_SD未定义,所以跳过
然后到X_BOOT_MSC: $(X_BOOT_MSC):  $(MSC_SPL) $(X_BOOT) MBR
它依赖于$(MSC_SPL) $(X_BOOT) MBR

先编译 MSC_SPL, 接着会调用make -s -C spl msc-spl.bin
进入spl/Makefile


msc-spl.bin
$(obj)msc-spl.bin:  $(obj)msc-spl
        $(OBJDUMP) -Dz $< > $(obj)msc-spl.dump
        $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
        cp msc-spl.bin $(TOPDIR)

#define JZ_MSCBOOT_CFG       0x4d53504c
msc-spl.bin首先依赖于msc-spl, 直接编译并链接__LIBS, 注意这里调用了LDFLAGS, 又是x-boot.lds, 
这个LDFLAGS内有一个TEXT_BASE, 地址是0x80000200.  


$(obj)msc-spl:      depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)
        $(LD) $(LDFLAGS) $(__OBJS) \
            --start-group $(__LIBS) --end-group \
            -o $@
现在生成了msc-spl, 返回msc-spl.bin的编译选项
$(OBJDUMP) -Dz $< > $(obj)msc-spl.dump, 将msc-spl生成msc-spl.dump
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@   将msc-spl生成msc-spl.bin
cp msc-spl.bin $(TOPDIR)   复制到顶层目录


X_BOOT在之前已编译过,暂时跳过
编译MBR, 使用gcc spl/tools/mbr_creater/mbr_creater.c -o spl/tools/mbr_creater/mbr_creater
spl/tools/mbr_creater/mbr_creater mbr.bin


现在返回
$(X_BOOT_MSC):  $(MSC_SPL) $(X_BOOT) MBR
        $(MAKE) -C spl pad
        cat spl/msc-spl-pad.bin boot/x-boot.bin > x-boot-msc.bin
        cat mbr.bin x-boot-msc.bin > mbr-xboot.bin


现在生成pad, 调用spl/tools/msc-spl-pad.sh生成8k的msc-spl-pad.bin
返回X_BOOT_MSC, 调用cat生成x-boot-msc.bin,再将mbr.bin打进去,就生成了mbr-xboot.bin


mbr-xboot.bin组成格式
mbr[512byte] + msc-spl-pad.bin[8k] + x-boot.bin
msc-spl-pad.bin入口地址是0x80000200, 正好跳过前边512字节的mbr.

  • 3
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 7
    评论
Bootloader的工作流程可以概括为以下几个步骤: 1. 重置和初始化:当计算机启动时,硬件负责将系统复位到初始状态,并进行一些基本的初始化操作,如设置寄存器、加载固件等。 2. 启动设备选择:Bootloader负责确定从哪个设备加载操作系统或其他引导程序。这通常通过读取配置文件或用户输入来确定启动设备,如硬盘、光盘、USB闪存驱动器或网络等。 3. 存储介质访问:一旦确定了启动设备,Bootloader会使用适当的驱动程序和协议来访问存储介质,读取存储介质上的引导程序或操作系统内核。 4. 引导加载:Bootloader通过加载引导程序或操作系统内核的特定位置(如内存地址)将其从存储介质复制到计算机内存中。 5. 内存管理:在加载引导程序或内核之前,Bootloader会进行一些内存管理操作,如初始化内存分页机制、设置内存保护等。 6. 引导参数传递:一些Bootloader可以传递参数或配置信息给操作系统内核。这些参数可以包括启动选项、硬件配置、内核参数等。 7. 控制权转移:一旦引导程序或内核加载完成,Bootloader会将控制权转移到引导程序或内核的入口点,从而启动操作系统或其他引导程序的执行。 需要注意的是,Bootloader的工作流程可能因计算机体系结构、硬件平台和操作系统而有所不同。不同的Bootloader可能有不同的功能和特性,因此其具体工作流程可能会有所差异。以上是一个一般性的Bootloader工作流程的概述。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值