Chinaunix首页 | 论坛 | 博客
  • 博客访问: 271421
  • 博文数量: 22
  • 博客积分: 2490
  • 博客等级: 大尉
  • 技术积分: 752
  • 用 户 组: 普通用户
  • 注册时间: 2009-07-31 15:35
文章分类

全部博文(22)

文章存档

2011年(5)

2010年(43)

2009年(14)

我的朋友

分类: LINUX

2010-04-02 11:37:23

一 bootloader介绍

1.1 Bootloader移植的必要性
Bootloader是与系统硬件环境高度相关的初始化软件,它担负着初始化硬件和引导操作系统的双重责任。一些ARM平台可以共用同一种Bootloader,但是总的说来,每一个特定系统的Bootloader都会有所不同。Bootloader广泛用于有操作系统的手持终端设备、智能家电及机顶盒等嵌入式设备上,它负责完成硬件初始化、操作系统引导和系统配制等。Bootloader移植是在特定硬件平台上操作系统移植至关重要的一步。

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

1.3. Boot Loader的烧录和存储
系统加电或复位后,所有的CPU通常都从某个由CPU制造商预先安排的地址上取指令。比如,at91rm9200的CPU在复位时通常都从地址0x00000000取它的第一条指令。而MPC8260高端启动则时从0xfff00000开始取指。这个地址依据特定的CPU而定。通常片外启动时,基于CPU构建的嵌入式系统通常都有某种类型的固态存储设备(EEPROM或FLASH等,at91rm9200是0x10000000)被映射到这个预先安排的地址上。因此在系统加电后,CPU将首先执行Boot Loader程序。

那么bootloader最初是怎么烧写到flash中的呢?对于一个裸板怎么让它跑起来呢?有两种方式:

²      通过片内固化的loader加载bootloader:通常某些CPU内部ROM中固化了一段程序可以用于最初的程序下载,如AT91RM9200。这时下载的程序是在内部RAM中运行的,大小有一定限制,然后由这段程序继续交互下载真正要烧写到flash中的程序,将其保存在外部RAM中,最终烧写到flash中。

²      通过JTAG或者仿真器下载:通常这些烧录工具可以直接操作flash,对其进行编程烧录。需要专门的工具。这种情况多用于那些没有固化loader的CPU,如三星系列。

1.4 Boot Loader的操作模式(Operation Mode)
主机和目标机之间一般通过串口建立连接,BootLoader软件在执行时通常会通过串口来进行数据传输,如输出打印信息到串口,从串口读取用户控制字符。

大多数Boot Loader都包含两种不同的操作模式:启动加载模式和下载模式,这种区别仅对于开发人员才有意义。从最终用户的角度看,BootLoader的作用就是用来加载操作系统,而并不存在所谓的启动加载模式与下载工作模式的区别。

²      启动加载(Boot loading)模式:这种模式也称为自主模式bootstrap。也即Boot Loader将存储在目标板Flash中的内核和文件系统的镜像装载到SDRAM中,整个过程无需用户的介入。这种模式是BootLoader的正常工作模式,因此在嵌入式产品发布的时候,BootLoader显然必须工作在这种模式下。

²      下载Downloading模式:在这种模式下,目标机上的BootLoader将通过串口连接或网络连接等通信手段从宿主机Host下载文件,比如下载内核映像和根文件系统映像等。从主机下载的文件通常首先被BootLoader保存到目标机的RAM中,然后再被BootLoader写到目标机上的FLASH类固态存储设备中。BootLoader的这种模式通常在第一次安装内核与根文件系统时被使用;此外,以后的系统更新(bootloader自身也可以这样更新)也会使用Boot Loader的这种工作模式。工作于这种模式下的BootLoader通常都会向它的终端用户提供一些简单的命令行接口。

U-BOOT等这样功能强大的BootLoader通常同时支持这两种工作模式,而且允许用户在这两种工作模式之间进行切换。比如,U-BOOT在启动时处于正常的启动加载模式,但是它会延时几秒(在配置文件中可以设定)等待终端用户按下任意键而将其切换到下载模式(相当于bios下按del键可进入系统配置界面一样,设置从光盘启动可进行重装),如果在给定时间内没有用户按键,则U-BOOT继续启动,进行正常的启动加载。

1.5 Bootloader与主机之间进行文件传输所用的通信设备及协议
最常见的情况就是,目标机上的BootLoader通过串口与主机之间进行文件传输,传输协议通常是kermit / xmodem / ymodem协议中的一种。但是,串口传输的速度是有限的,因此如果该Bootloader对目标板的网卡支持良好,还可以通过以太网连接并借助TFTP (Trivial File Transfer Protocol)协议来下载文件是个更好的选择。此时,主机方所用的软件也要考虑,比如,在通过以太网连接和TFTP协议来下载文件时,主机方必须有一个软件用来提供TFTP服务,如Windows平台上的tftpd.exe等或Linux下面的tftp服务器。

1.6 Bootloader的通用执行流程

从操作系统的角度看,Bootloader的总目标就是正确地调用内核来执行。另外,由于Bootloader的实现依赖于 CPU的体系结构,因此大多数Bootloader都分为stagel和stage2两大部分。依赖于CPU体系结构的代码,比如设备初始化代码等,通常都放在stagel中,而且通常都用汇编语言来实现,以达到短小精悍和高效的目的。而stage2则通常用C语言来实现,这样可以实现更复杂的功能,而且代码会具有更好的可读性和可移植性。

Bootloader的stagel为位置无关代码,通常在FLASH中运行。所有的指令为相对寻址,可以在任何位置运行。通常包括以下步骤(以执行的先后顺序):

Ø       硬件设备初始化(配置SDRAM存储控制器及IO),中断初始化;

Ø       为加载Bootloader的stage2准备RAM空间(这个地址由链接脚本指定,为运行域地址,通常为RAM的高端地址),测试内存空间是否有效;

Ø       拷贝Bootloader的stage2到RAM空间中;

Ø       设置好堆栈;

Ø       跳转到stage2的C入口点。

Bootloader的stage2通常被拷贝到RAM中运行,这样可以提高运行速度。通常包括以下步骤(以执行的先后顺序):

Ø       初始化本阶段要使用到的硬件设备;

Ø       检测系统内存映射(memory map);

Ø       没有用户干预时将kernel映像和根文件系统映像从flash读到RAM空间中;

Ø       为内核设置启动参数;

Ø       调用内核。

 U-boot基础

现在为Linux开放源代码Bootloader有很多,blob redbootU-BOOT等,其中U-BOOT是目前用来开发嵌入式系统引导代码使用最为广泛的Bootloader。它支持POWERPCARMMIPS X86等处理器,支持嵌入式操作系统有LinuxVxworksNetBSD等。

 

源代码目录结构

|-- board  平台依赖,存放电路板相关的目录文件

|-- common  通用多功能函数的实现

|-- cpu  平台依赖,存放cpu相关的目录文件

|-- disk  通用。硬盘接口程序

|-- doc  文档

|-- drivers  通用的设备驱动程序,如以太网接口驱动

|-- dtt

|-- examples  应用例子

|-- fs  通用存放文件系统的程序

|-- include  头文件和开发板配置文件,所有开发板配置文件放在其configs

|-- lib_arm  平台依赖,存放arm架构通用文件

|-- lib_generic  通用的库函数

|-- lib_i386  平台依赖,存放x86架构通用文件

|-- lib_m68k  平台依赖

|-- lib_microblaze  平台依赖

|-- lib_mips  平台依赖

|-- lib_nios   平台依赖

|-- lib_ppc平台依赖,存放ppc架构通用文件

|-- net  存放网络的程序

|-- post  存放上电自检程序

|-- rtc  rtc的驱动程序

`-- tools  工具

 

详细实例:

²      board开发板相关的源码,不同的板子对应一个子目录,内部放着主板相关代码。 Board/at91rm9200dk/at91rm9200.c, config.mk, Makefile, flash.c ,u-boot.lds都和具体开发板的硬件和地址分配有关。

 

²      common:与体系结构无关的代码文件,实现了u-boot所有命令,其中内置了一个shell脚本解释器(hush.c, a prototype Bourne shell grammar parser), busybox中也使用了它。

 

²      cpu:与cpu相关代码文件,其中的所有子目录都是以u-boot支持的cpu命名

cpu/at91rm9200/at45.c, at91rm9200_ether.c, cpu.c, interrupts.c serial.c, start.S, config.mk, Makefile等。其中:

cpu.c负责初始化CPU、设置指令Cache和数据Cache等;

interrupt.c负责设置系统的各种中断和异常,比如快速中断、开关中断、时钟中断、软件中断、预取中止和未定义指令等;

start.S负责u-boot启动时执行的第一个文件,它主要是设置系统堆栈和工作方式,为跳转到C程序入口点做准备;

at91rm9200_ether.cserial.c很重要,这是系统能够下载资源的前提。

 

²      disk:设备分区处理代码。

²      docu-boot相关文档。

 

²      driversu-boot所支持的设备驱动代码网卡、支持CFIFlash、串口和USB总线等。

²      fs: u-boot所支持文件系统访问存取代码, jffs2

 

²      includeu-boot head文件,主要是与各种硬件平台相关的头文件,如include/asm-arm/arch-at91rm9200/AT91RM9200.h(硬件寄存器名称及地址的定义), hardware.h 内存及flash地址以及IO物理地址和虚拟地址的定义),include/asm-arm/proc-armv(与具体的CPU无关,无需移植)。

 

²      net:与网络有关的代码,BOOTP协议、TFTP协议、RARP协议代码实现无需移植。

 

²      lib_arm:与arm体系相关的代码。

²      tools:编译后会生成mkimage工具,用来对生成的raw bin文件加入u-boot特定的image_header.

 

支持的主要功能

主要功能如下:

²      系统引导,支持NFS挂载RAMDISK(压缩或非压缩)形式的根文件系统;

²      支持NFS挂载、从FLASH中引导压缩或非压缩系统内核;

²      基本辅助功能,强大的操作系统接口功能;可灵活设置、传递多个关键参数给操作系统,适合系统在不同开发阶段的调试要求与产品发布,尤对Linux支持最为强劲;

²      支持目标板环境参数多种存储方式,如FLASHNVRAMEEPROM

²      CRC32校验,可校验FLASH中内核、RAMDISK镜像文件是否完好;

²      设备驱动,串口、SDRAMFLASH、以太网、LCDNVRAMEEPROM、键盘、USBPCMCIAPCIRTC等驱动支持;

²      上电自检功能 SDRAMFLASH大小自动检测;SDRAM故障检测;CPU型号;

²      特殊功能,XIP内核引导。

 

U-boot命令介绍及环境变量

²      ?得到所有命令列表

²      Helphelp usb, 列出USB功能的使用说明

²      ping:注意只能开发板PING别的机器(AT91RM9200不支持,需要进行配置)

²      setenv: 设置环境变量

Ø       setenv serverip 192.168.0.1

Ø       setenv ipaddr 192.168.0.56

Ø       setenv bootcmd ‘tftp 32000000 vmlinux; kgo 32000000’

²      saveenv:保存环境变量。在设置好环境变量以后, 保存变量值

²      tftptftp 32000000 vmlinux, serverIP=环境变量中设置的serverip)中/tftpboot/下的vmlinux通过TFTP读入到物理内存32000000

²      bootp- 通过网络用 BootP/TFTP 协议来启动映象

²      tftpboot- 通过网络用 TFTP 协议、设置服务器和客户机的 IP 地址进行映象文件传送

²      kgo: 起动没有压缩的linux内核,kgo 32000000AT91RM9200不支持)

²      bootm:起动UBOOT  TOOLS制作的压缩LINUX内核, bootm 3200000

²      protect FLASH进行写保护或取消写保护,protect on 1:0-3(就是对第一块FLASH0-3扇区进行保护)protect off 1:0-3取消写保护

²      erase删除FLASH的扇区, erase 1:0-2(就是对每一块FLASH0-2扇区进行删除)

²      cp 在内存中复制内容, cp 32000000 0 40000(把内存中0x32000000开始的0x40000字节复制到0x0)

²      mw RAM中的内容写操作, mw 32000000 ff 10000(把内存0x32000000开始的0x10000字节设为0xFF)

²      md 修改RAM中的内容, md 32000000(内存的起始地址)

²      flinfo 列出flash的信息

²      loadb 准备用KERMIT协议接收来自kermit或超级终端传送的文件。

²      nfs nfs 32000000 192.168.0.12:aa.txt,把192.168.0.12(LINUX NFS文件系统)中的NFS文件系统中的aa.txt 读入内存0x32000000处。

 

最常用的几个命令如下:

²      go- 在地址 'addr' 处开始程序执行

²      run- 运行一个环境变量所定义的命令

²      bootm- 内存中进行运行经过mkimage加工的程序映象

²      loadb- 通过串口线(kermit mode) 来装载二进制文件

²      printenv- 打印环境变量

²      setenv- 设置环境变量

²      saveenv保存环境变量到内存

²      tftp-通过网络下载文件

²      protecteraseflash读写

 

下面是 U-BOOT 中的简单环境变量

²      baudrate波特率

²      bootdelay         boot 延迟

²      bootcmd   Boot 命令

²      bootargs   Boot 参数,传递给内核

²      bootfile 默认下载启动的内核映象

²      ipaddr       客户机 IP 地址

²      serverip    服务器地址

²      loadaddr   装载地址

²      ethaddr     网卡 MAC 地址

 

U-Boot的启动流程分析

和大多数的Bootloader一样,U-BOOT的启动分为两个阶段两个部分,依赖于CPU体系结构的代码主要放在stage1,且用汇编来实现,而stage2则通常用C语言来实现,这样可以实现复杂的功能,而且具有更好的可读性和可移植性。

 

下面分别分析一下这两个阶段的启动流程:

第一阶段:基本的硬件初始化,为第二阶段程序运行建立环境(cpu/ at91rm9200/start.s文件的代码部分):

××××××××××××××××××××××××××××

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")

OUTPUT_ARCH(arm)

ENTRY(_start) // 程序的入口在/cpu/××××/start.s中定义

SECTIONS

{

        . = 0x00000000; // 程序链接的地址

 

        . = ALIGN(4);

        .text      :

        {

          cpu/at91rm9200/start.o  (.text)

          *(.text)

        }

 

        . = ALIGN(4);

        .rodata : { *(.rodata) }

 

        . = ALIGN(4);

        .data : { *(.data) }

 

        . = ALIGN(4);

        .got : { *(.got) }

 

  __u_boot_cmd_start = .;

  .u_boot_cmd : { *(.u_boot_cmd) }

  __u_boot_cmd_end = .;

 

        armboot_end_data = .; //代码段结束地址

 

        . = ALIGN(4);

        .bss : { *(.bss) }

 

        armboot_end = .;  //整个U-boot印象的结束地址

}

××××××××××××××××××××××××××××

 

在此需要定义程序入口,由于一个可执行的Image必须要有一个入口点,并且只能有一个全局入口,通常这个入口就在ROM (flash)0x0地址,因此,必须通知编译器以使其知道这个入口,该工作可通过修改连接器脚本u-boot.lds来完成,该阶段需要依次完成的工作一般包括:

²      CPU自身的初始化,它包括:CPU运行模式的设置(管理模式)、设置异常的入口地址和异常处理函数、运行时钟频率的设置等工作。

²      初始化GPIO和内存控制器。

²      为拷贝Stage2准备RAM空间。

²      进行自拷贝,将U-BOOTStage2拷贝到RAM中。

²      设置好堆栈。

²      跳转到Stage2的入口,从而转到RAM中执行,该工作是调用指令ldr pc, start armboot来完成的。

××××××××××××××××××××××××××

1.1.2开始,u-boot有初始化SDRAM并拷贝自己到SDRAM运行的代码,而之前的版本就没有这个功能(详细查看下代码??的确如此,因此对于以前的版本TEXT_BASE没有起作用?实际测试下??)board/ at91rm9200dkconfig.mk文件(TEXT_BASE = 0x21f0000032M RAM的设置,为第二阶段程序在RAM中的运行地址)用于设置程序编译连接的起始地址,在程序中要特别注意与地址相关指令的使用

Board/at91rm9200dk/config.mk

TEXT_BASE = 0x21f00000u-boot将被载入SDRAM高端部分

注意,对于不同的系统RAM大小可能不一样,要根据实际情况调整

/config.mk

ifdef BOARD

sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk     include board specific rules

endif

CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS)              \

        -D__KERNEL__ -DTEXT_BASE=$(TEXT_BASE)     

LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE) $(PLATFORM_LDFLAGS)

export      TEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS CPPFLAGS CFLAGS AFLAGS

 

对于U-Boot 1.1.2以前的版本,并没有自拷贝的部分,若flash中首地址存放的是非压缩的u-boot.bin的,则启动部分是一直运行在flash中的;但对于AT91RM9200来说,他通常有三个文件loader.bin, boot.bin, u-boot.binflash中首先运行的是boot.bin其将压缩的u-boot.bin.gz解压拷贝到TEXT_BASE处运行,此时已经在RAM中了,因此也无需实现自拷贝了。

 

对于U-Boot 1.1.2以后的版本,若像AT91RM9200boot.bin这样的过渡程序,则将u-boot.bin.gz解压到RAM中,此时运行地址和链接地址相同,无需拷贝;若没有,则u-boot.bin将在flash中执行初始化部分,然后将自身拷贝到RAM中执行。

// 比较运行地址和链接地址,如果当前已经在RAM中运行了,则无需拷贝到RAM

relocate:                               /* relocate U-Boot to RAM           */

        adr     r0, _start              /* r0 <- current position of code   */

        ldr     r1, _TEXT_BASE          /* test if we run from flash or RAM */

        cmp     r0, r1                  /* don't reloc during debug         */

        beq     stack_setup

 

        ldr     r2, _armboot_start

        ldr     r3, _bss_start

        sub     r2, r3, r2              /* r2 <- size of armboot            */

        add     r2, r0, r2              /* r2 <- source end address         */

 

copy_loop:

        ldmia   r0!, {r3-r10}           /* copy from source address [r0]    */

        stmia   r1!, {r3-r10}           /* copy to   target address [r1]    */

        cmp     r0, r2                  /* until source end addreee [r2]    */

        ble     copy_loop

 

当程序在Flash中运行时,执行程序跳转时必须要使用相对跳转指令,而不能使用绝对地址的跳转(即直接对PC操作)。如果使用绝对地址,那么,程序的取指是相对于当前PC位置向前或者向后的32MB空间内,而不会跳入SDRAM

×××××××××××××××××××××××××××××

 

在上述操作运行完成后,就进入到/lib_arm/board.c 中的start_armboot()函数运行,并建立起了一个基本的环境,此时的物理内存空间的分布就变成了如图所示的情况。

转入boatloader stage2的系统内存布局

 

第二阶段:运行U-BOOT的主体部分

该阶段以程序跳转到lib_arm/board.c中的start_armboot函数为标志,该函数同时也是C语言的开始函数,是整个启动代码的主体函数,同时还是整个U-BOOT的主体函数,该函数主要完成以下工作:

²      调用一系列的初始化函数,初始化本阶段使用到的硬件,如:

×××××××××××××××××××

init_fnc_t *init_sequence[] = {

        cpu_init,           /* basic cpu dependent setup */

        board_init,                /* basic board dependent setup */

        interrupt_init,            /* set up exceptions */

        env_init,           /* initialize environment */

        init_baudrate,           /* initialze baudrate settings */

        serial_init,         /* serial communications setup */

        console_init_f,          /* stage 1 init of console */

        display_banner,         /* say that we are here */

        dram_init,         /* configure available RAM banks */

        display_dram_config,

#if defined(CONFIG_VCMA9)

        checkboard,

#endif

        NULL,

};

×××××××××××××××××××××

env_init:设置环境变量,初始化环境;

init_baudrate:设置串口的波特率;

serial_init:设置串口的工作方式;

dram_init:设置SDRAM的起始地址和大小;

     

²      检查存储器分配和使用情况:获取flashbank分区情况、是否擦除、是否上锁等信息为以后flash相关命令使用;初始化系统内存分配函数,供后面的代码使用malloc等函数,U-BOOT没有使用其他现成的库所有函数的实现均在文件中),如果系统有液晶等显示设备,一并在此分配显示内存。

²      打印内存,flash、环境变量设置等信息。

²      等待几秒时间,如果有键盘输入,则进入命令模式,接收用户输入的命令并解释执行(如启动操作系统,更新flash内容)。

²      如果在给定的时间内没有用户输入或者在执行命令操作时收到了用户要求启动内核的命令(boot)则将把操作系统内核和根文件系统映像文件从flash中拷贝到RAM中相应位置,并在设置内核启动参数后跳转到内核映像的首地址处执行。

×××××××××××××××××××××××××××××

U-BOOT调用 Linux 内核的方法是直接跳转到内核的第一条指令处,也即直接跳转到 MEM_START0x8000地址处。在跳转时,要满足下列条件:

a) CPU寄存器的设置:R00R1=机器类型 ID,本系统的机器类型ID193R2=启动参数标记列表在RAM中的起始基地址; 

b) CPU模式:必须禁止中断(IRQsFIQs)CPU必须工作在SVC模式;

c) CacheMMU的设置:MMU 必须关闭;指令Cache可以打开也可以关闭;数据Cache必须关闭。

系统采用下列代码来进入内核函数:

void (*theKernel)(int zero, int arch);

theKernel = (void (*)(int, int))ntohl(hdr->ih_ep);

theKernel(0, bd->bi_arch_number);其中,hdrimage_header_t类型的结构体,hdr->ih_epentry point,指向内核的第一条指令地址,即Linux操作系统下的/kernel/arch/arm/boot/compressed/head.S汇编程序theKernel()函数调用应该不会返回,如果该调用返回,则说明出错。

×××××××××××××××××××××××××××××

 U-BOOTAT91RM9200上的移植

的启动方式

在这里我主要介绍通过片内引导和片外引导片内引导通常主要采用串口下载并引导u-boot,并将程序被烧写到 Flash上,然后就可以通过跳线的方式从片外引导执行已经烧写到片外Flash上的引导程序(bootloader)

 

3.1.1 片内引导

1)       片内引导的基本原理

系统上电,检测BMS,选择系统的启动方式,如果BMS为高电平,则系统从片内ROM启动。AT91RM9200的内部ROM上电后被映射到了0x00x100000,在这两个地址处都可以访问到ROM。由于9200ROM中固化了一个BOOTLOAER程序。所以PC0X0处开始执行这个BOOTLOAER(准确的说应该是一级BOOTLOADER)。这个BOOTLOADER依次完成以下步骤:

²      PLL SETUP。设置PLLB产生48M时钟频率提供给USB DEVICE。同时DEBUG USART也被初始化为48M的时钟频率。

²      相应模式下的堆栈设置

²      检测主时钟源(Main oscillator

²      中断控制器(AIC)的设置

²      变量的初始化

²      跳到主函数

 

完成以上步骤后,我们可以认为BOOT过程结束,接下来的就是LOADER的过程,或者也可以认为是装载二级BOOTLOERAT91RM9200按照DATAFLASHEEPROM、连接在外部总线上的8位并行FLASH的顺序依次来找合法的BOOT程序。所谓合法的指的是在这些存储设备的开始地址处连续的存放的32个字节,也就是8条指令必须是跳转指令或者装载PC的指令,其实这样规定就是把这8条指令当作是异常向量表来处理。必须注意的是第6条指令要包含将要装载的映像的大小。关于如何计算和写这条指令可以参考用户手册。一旦合法的映像找到之后,则BOOT程序会把找到的映像搬到内部SRAM中去,所以映像的大小是非常有限的,不能超过16K的大小。当BOOT程序完成了把合法的映像搬到SRAM的任务以后,接下来就进行存储器的REMAP,经过REMAP之后,SRAM从映设前的0X200000地址处被映设到了0X0地址并且程序从0X0处开始执行。而ROM这时只能在0X100000这个地址处看到了。至此9200就算完成了一种形式的启动过程。

 

如果BOOT程序在以上所列的几种存储设备中未找到合法的映像,则自动初始化DEBUG USART口和USB DEVICE口以准备从外部载入映像,大多数情况都是如此。DEBUG口的初始化包括设置参数115200 8 N 1以及运行XMODEM协议。对USB DEVICE进行初始化以及运行DFU协议。现在用户可以从外部(假定为PC平台)载入你的映像了。在PC平台下,以WIN2000为例,你可以用超级终端来完成这个功能,但是还是要注意你的映像的大小不能超过13K。一旦正确从外部装载了映像,接下来的过程就是和前面一样重映设然后执行映像了。

 

注意:通常所说的片内引导是指没有烧写合法的印象的情况下,但并不意外着烧些了合法印象的情况下不能采用片内引导的方式。通常第一次下载了启动印象后就会选择片外启动的方式了。并且烧些的印象通常6条指令都不含将要装载的映像的大小,所以片内启动时一般不能运行这些印象。关于片内引导的详细过程可以参看at91rm9200的芯片说明书――引导程序一章。

 

Boot program Flow Diagram

Device Setup

|

Boot SPI DataFlash Boot --> Download from DataFlash --> run

|

TWI EEPROM Boot --> Download from EEPROM --> run

|

Parallel Boot --> Download from 8-bit Device -->

|

| Xmodem protocol

| |---DBGU Serial Download ---------------------> run

|____|

| DFU protocol

|-----USB download -----------------------> run

at91rm9200片内引导流程图

 

2)       at91rm9200片内引导u-boot的实现过程

at91rm9200内部本身有128k的片内rom,其固化了一个bootloaderuploader,其他存储设备上没有合法的映象时,片内引导将启动uploaderuploader开启xmodem协议,等待用户上传程序,上传的程序将载入片内SRAM,重映射,然后pc跳转到片内SRAM执行上传的用户程序,即loader.bin

注:片内SRAM只有16k,除去3-4k片内启动程序的占用的部分数据空间,因此下载的程序大小限制在12k内。

 

裸板只能用片内引导方式,载入一个12k以内的小程序loader.bin到内部SRAM运行,而这个小程序初始化SDRAM,再把u-boot.bin下载到SDRAM的高端运行(u-boot大于12k,不能直接下载的原因就在于此)pc跳到SDRAMu-boot位置运行u-bootu-boot启动后再用u-boot自己的命令把boot.bin u-boot.gz下载到SDRAM的低端,再用flash烧写命令烧到flash去,以后就可以片外flash启动了。

 

3.1.2 片外引导

如果BMS为低电平,则AT91RM9200会从片外的FLASH启动,这时片外的FLASH的起始地址就是0X0,要求已经在此地址烧些了启动映象了,接下来的过程和片内启动的过程是一样的,只不过这时就需要自己写启动代码了,至于怎么写,大致的内容和ROMBOOT差不多,不同的硬件设计可能有不一样的地方,但基本的都是一样的。由于片外FLASH可以设计的大,所以这里编写的BOOTLOADER可以一步到位,也就是说不用像片内启动可能需要BOOT好几级了

 

对于AT91RM9200,通常选择在flash的首地址处放的是boot.bin,由其将u-boot.bin.gz解压到高端RAM中,再运行真正的u-boot.bin,也就是实际的启动映象。

 

代码执行流分析

以上三个文件是at91rm9200启动所需要的三个bin,他们的实现代码并不难。

3.2.1 loader.bin

执行流程,这个文件主要在片内启动从串口下载U-boot.bin代码时会用到,一般固化在CPU的内部ROM中,用户无需改动。

loader/entry.S init cpu

b main ---> crt0.S

--> copydata --> clearbss --> b boot

main.c --> boot -->

/*Get internel rom service address*/

/* Init of ROM services structure */

pAT91 = AT91C_ROM_BOOT_ADDRESS;

/* Xmodem Initialization */

--> pAT91->OpenSBuffer

--> pAT91->OpenSvcXmodem

/* System Timer initialization */

---> AT91F_AIC_ConfigureIt

/* Enable ST interrupt */

AT91F_AIC_EnableIt

AT91F_DBGU_Printk("XMODEM: Download U-BOOT ");

Jump.S

// Jump to Uboot BaseAddr exec

Jump((unsigned int)AT91C_UBOOT_BASE_ADDRESS) 跳到下载的U-boot.bin执行

 ××××××××××××××××××××××××××××××××××

lader.bin主要有3个功能,初始化SDRAM,启动xmodem接收u-boot并写到SDRAM中,pc跳转到SDRAM运行。

 

xmodem的实现

只需要接收部分,发送部分用win下的超级终端等工具就可。先找来协议文档,熟悉协议,看看现有的xmodem协议源码。协议本身并不复杂,只是它的握手部分实现有点技巧。接收端要不停的发送字符“C”到串口,发送端收到“C”后发送数据SOH?

阅读(2788) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~