1）u-boot版本1.1.3，gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)

2）在Makefile中加入
bks2410_config : unconfig
 @./mkconfig $(@:_config=) arm arm920t bks2410 NULL s3c24x0
我把我的板子起名叫bks2410，可以依自己的喜好修改

3）建立board/bks2410目录，拷贝board/smdk2410下的文件到board/bks2410目录，将smdk2410.c更名为bks2410.c

4）cp include/configs/smdk2410.h include/configs/bks2410.h

5）将arm-linux-gcc的目录加入到PATH环境变量中，我的是目录/opt/eldk/usr/bin:/opt/eldk/bin

6）测试编译能否成功：
make bks2410_config
make all ARCH=arm
生成u-boot.bin就OK了

7）依照你自己开发板的内存地址分配情况修改board/bks2410/memsetup.S文件，我的程序：
#include <config.h>
#include <version.h>

#define BWSCON 0x48000000

/* BWSCON */
#define DW8    (0x0)
#define DW16    (0x1)
#define DW32    (0x2)
#define WAIT    (0x1<<2)
#define UBLB    (0x1<<3)

#define B1_BWSCON    (DW32)
#define B2_BWSCON    (DW16)
#define B3_BWSCON    (DW16 + WAIT + UBLB)
#define B4_BWSCON    (DW16)
#define B5_BWSCON    (DW16)
#define B6_BWSCON    (DW32)
#define B7_BWSCON    (DW32)

/* BANK0CON */
#if 0
#define B0_Tacs    0x0 /*  0clk */
#define B0_Tcos    0x0 /*  0clk */
#define B0_Tacc    0x7 /* 14clk */
#define B0_Tcoh    0x0 /*  0clk */
#define B0_Tah    0x0 /*  0clk */
#define B0_Tacp    0x0
#define B0_PMC    0x0 /* normal */
#endif

#define B0_Tacs    0x3 /*  0clk */
#define B0_Tcos    0x3 /*  0clk */
#define B0_Tacc    0x7 /* 14clk */
#define B0_Tcoh    0x3 /*  0clk */
#define B0_Tah    0x3 /*  0clk */
#define B0_Tacp    0x1
#define B0_PMC    0x0 /* normal */

/* BANK1CON */
#if 0
#define B1_Tacs    0x0 /*  0clk */
#define B1_Tcos    0x0 /*  0clk */
#define B1_Tacc    0x7 /* 14clk */
#define B1_Tcoh    0x0 /*  0clk */
#define B1_Tah    0x0 /*  0clk */
#define B1_Tacp    0x0
#define B1_PMC    0x0
#endif

#define B1_Tacs    0x3 /*  0clk */
#define B1_Tcos    0x3 /*  0clk */
#define B1_Tacc    0x7 /* 14clk */
#define B1_Tcoh    0x3 /*  0clk */
#define B1_Tah    0x3 /*  0clk */
#define B1_Tacp    0x3
#define B1_PMC    0x0

#define B2_Tacs    0x0
#define B2_Tcos    0x0
#define B2_Tacc    0x7
#define B2_Tcoh    0x0
#define B2_Tah    0x0
#define B2_Tacp    0x0
#define B2_PMC    0x0

#if 0
#define B3_Tacs    0x0 /*  0clk */
#define B3_Tcos    0x3 /*  4clk */
#define B3_Tacc    0x7 /* 14clk */
#define B3_Tcoh    0x1 /*  1clk */
#define B3_Tah    0x0 /*  0clk */
#define B3_Tacp    0x3     /*  6clk */
#define B3_PMC    0x0 /* normal */
#endif

#define B3_Tacs    0x0 /*  0clk */
#define B3_Tcos    0x0 /*  4clk */
#define B3_Tacc    0x7 /* 14clk */
#define B3_Tcoh    0x0 /*  1clk */
#define B3_Tah    0x0 /*  0clk */
#define B3_Tacp    0x0     /*  6clk */
#define B3_PMC    0x0 /* normal */

#define B4_Tacs    0x0 /*  0clk */
#define B4_Tcos    0x0 /*  0clk */
#define B4_Tacc    0x7 /* 14clk */
#define B4_Tcoh    0x0 /*  0clk */
#define B4_Tah    0x0 /*  0clk */
#define B4_Tacp    0x0
#define B4_PMC    0x0 /* normal */

#define B5_Tacs    0x0 /*  0clk */
#define B5_Tcos    0x0 /*  0clk */
#define B5_Tacc    0x7 /* 14clk */
#define B5_Tcoh    0x0 /*  0clk */
#define B5_Tah    0x0 /*  0clk */
#define B5_Tacp    0x0
#define B5_PMC    0x0 /* normal */

#define B6_MT    0x3 /* SDRAM */
#define B6_Trcd     0x1
#define B6_SCAN    0x1 /* 9bit */

#define B7_MT    0x3 /* SDRAM */
#define B7_Trcd    0x1 /* 3clk */
#define B7_SCAN    0x1 /* 9bit */

/* REFRESH parameter */
#define REFEN    0x1 /* Refresh enable */
#define TREFMD    0x0 /* CBR(CAS before RAS)/Auto refresh */
#define Trp    0x0 /* 2clk */
#define Trc    0x3 /* 7clk */
#define Tchr    0x2 /* 3clk */
#define REFCNT    1113 /* period=15.6us, HCLK=60Mhz, (2048+1-15.6*60) */
/**************************************/

_TEXT_BASE:
 .word TEXT_BASE

.globl memsetup
memsetup:
 /* memory control configuration */
 /* make r0 relative the current location so that it */
 /* reads SMRDATA out of FLASH rather than memory ! */
 adr     r0, SMRDATA
 /*ldr r1, _TEXT_BASE*/
 /*sub r0, r0, r1*/
 ldr r1, =BWSCON /* Bus Width Status Controller */
 add     r2, r0, #13*4
0:
 ldr     r3, [r0], #4
 str     r3, [r1], #4
 cmp     r2, r0
 bne     0b

 /* everything is fine now */
 mov pc, lr

 .ltorg
/* the literal pools origin */

SMRDATA:
    .word (0+(B1_BWSCON<<4)+(B2_BWSCON<<8)+(B3_BWSCON<<12)+(B4_BWSCON<<16)+(B5_BWSCON<<20)+(B6_BWSCON<<24)+(B7_BWSCON<<28))
    .word ((B0_Tacs<<13)+(B0_Tcos<<11)+(B0_Tacc<<8)+(B0_Tcoh<<6)+(B0_Tah<<4)+(B0_Tacp<<2)+(B0_PMC))
    .word ((B1_Tacs<<13)+(B1_Tcos<<11)+(B1_Tacc<<8)+(B1_Tcoh<<6)+(B1_Tah<<4)+(B1_Tacp<<2)+(B1_PMC))
    .word ((B2_Tacs<<13)+(B2_Tcos<<11)+(B2_Tacc<<8)+(B2_Tcoh<<6)+(B2_Tah<<4)+(B2_Tacp<<2)+(B2_PMC))
    .word 0x1f7c/*((B3_Tacs<<13)+(B3_Tcos<<11)+(B3_Tacc<<8)+(B3_Tcoh<<6)+(B3_Tah<<4)+(B3_Tacp<<2)+(B3_PMC))*/
    .word ((B4_Tacs<<13)+(B4_Tcos<<11)+(B4_Tacc<<8)+(B4_Tcoh<<6)+(B4_Tah<<4)+(B4_Tacp<<2)+(B4_PMC))
    .word ((B5_Tacs<<13)+(B5_Tcos<<11)+(B5_Tacc<<8)+(B5_Tcoh<<6)+(B5_Tah<<4)+(B5_Tacp<<2)+(B5_PMC))
    .word ((B6_MT<<15)+(B6_Trcd<<2)+(B6_SCAN))
    .word ((B7_MT<<15)+(B7_Trcd<<2)+(B7_SCAN))
    .word ((REFEN<<23)+(TREFMD<<22)+(Trp<<20)+(Trc<<18)+(Tchr<<16)+REFCNT)
    .word 0x31
    .word 0x30
    .word 0x30
   
8）在board/bks2410加入NAND Flash读函数，建立nand_read.c，加入如下内容(copy from vivi)：
#include <config.h>

#define __REGb(x) (*(volatile unsigned char *)(x))
#define __REGi(x) (*(volatile unsigned int *)(x))
#define NF_BASE  0x4e000000
#define NFCONF  __REGi(NF_BASE + 0x0)
#define NFCMD  __REGb(NF_BASE + 0x4)
#define NFADDR  __REGb(NF_BASE + 0x8)
#define NFDATA  __REGb(NF_BASE + 0xc)
#define NFSTAT  __REGb(NF_BASE + 0x10)

#define BUSY 1
inline void wait_idle(void) {
    int i;

    while(!(NFSTAT & BUSY))
      for(i=0; i<10; i++);
}

#define NAND_SECTOR_SIZE 512
#define NAND_BLOCK_MASK  (NAND_SECTOR_SIZE - 1)

/* low level nand read function */
int
nand_read_ll(unsigned char *buf, unsigned long start_addr, int size)
{
    int i, j;

    if ((start_addr & NAND_BLOCK_MASK) || (size & NAND_BLOCK_MASK)) {
        return -1; /* invalid alignment */
    }

    /* chip Enable */
    NFCONF &= ~0x800;
    for(i=0; i<10; i++);

    for(i=start_addr; i < (start_addr + size);) {
      /* READ0 */
      NFCMD = 0;

      /* Write Address */
      NFADDR = i & 0xff;
      NFADDR = (i >> 9) & 0xff;
      NFADDR = (i >> 17) & 0xff;
      NFADDR = (i >> 25) & 0xff;

      wait_idle();

      for(j=0; j < NAND_SECTOR_SIZE; j++, i++) {
 *buf = (NFDATA & 0xff);
 buf++;
      }
    }

    /* chip Disable */
    NFCONF |= 0x800; /* chip disable */

    return 0;
}

9）修改board/bks2410/Makefile为
OBJS := bks2410.o flash.o nand_read.o

10）修改cpu/arm920t/start.S文件
在ldr pc, _start_armboot之前加入：
#ifdef CONFIG_S3C2410_NAND_BOOT
  bl    copy_myself
 
  @ jump to ram
  ldr   r1, =on_the_ram
  add  pc, r1, #0
  nop
  nop
  1:    b     1b          @ infinite loop
 
on_the_ram:
#endif

在_start_armboot: .word start_armboot之后加入：
#ifdef CONFIG_S3C2410_NAND_BOOT
copy_myself:
  mov r10, lr
@ reset NAND
  mov r1, #NAND_CTL_BASE
  ldr   r2, =0xf830           @ initial value
  str   r2, [r1, #oNFCONF]
  ldr   r2, [r1, #oNFCONF]
  bic  r2, r2, #0x800              @ enable chip
  str   r2, [r1, #oNFCONF]
  mov r2, #0xff         @ RESET command
  strb r2, [r1, #oNFCMD]
  mov r3, #0                   @ wait

1:add  r3, r3, #0x1
  cmp r3, #0xa
  blt   1b
2:ldr   r2, [r1, #oNFSTAT]      @ wait ready
  tst    r2, #0x1
  beq  2b
  ldr   r2, [r1, #oNFCONF]
  orr  r2, r2, #0x800              @ disable chip
  str   r2, [r1, #oNFCONF]

@ get read to call C functions (for nand_read())
  ldr   sp, DW_STACK_START       @ setup stack pointer
  mov fp, #0                    @ no previous frame, so fp=0

@ copy vivi to RAM
  ldr   r0, =UBOOT_RAM_BASE
  mov     r1, #0x0
  mov r2, #0x20000
  bl    nand_read_ll
  tst    r0, #0x0
  beq  ok_nand_read

#ifdef CONFIG_DEBUG_LL
  bad_nand_read:
  ldr   r0, STR_FAIL
  ldr   r1, SerBase
  bl    PrintWord
1:b     1b          @ infinite loop
  #endif

ok_nand_read:
#ifdef CONFIG_DEBUG_LL
  ldr   r0, STR_OK
  ldr   r1, SerBase
  bl    PrintWord
#endif

@ verify
  mov r0, #0
  ldr   r1, =UBOOT_RAM_BASE
  mov r2, #0x400     @ 4 bytes * 1024 = 4K-bytes
go_next:
  ldr   r3, [r0], #4
  ldr   r4, [r1], #4
  teq   r3, r4
  bne  notmatch
  subs r2, r2, #4
  beq  done_nand_read
  bne  go_next

notmatch:
#ifdef CONFIG_DEBUG_LL
  sub  r0, r0, #4
  ldr   r1, SerBase
  bl    PrintHexWord
  ldr   r0, STR_FAIL
  ldr   r1, SerBase
  bl    PrintWord
#endif
1:b     1b
done_nand_read:
#ifdef CONFIG_DEBUG_LL
  ldr   r0, STR_OK
  ldr   r1, SerBase
  bl    PrintWord
#endif
  mov pc, r10
@ clear memory
@ r0: start address
@ r1: length
  mem_clear:
  mov r2, #0
  mov r3, r2
  mov r4, r2
  mov r5, r2
  mov r6, r2
  mov r7, r2
  mov r8, r2
  mov r9, r2

clear_loop:
  stmia      r0!, {r2-r9}
  subs r1, r1, #(8 * 4)
  bne  clear_loop
  mov pc, lr

#endif @ CONFIG_S3C2410_NAND_BOOT

在文件的最后加入：
   .align     2
DW_STACK_START:
 .word      STACK_BASE+STACK_SIZE-4

11）修改include/configs/bks2410.h文件，添加如下内容：
/*
 * Nandflash Boot
 */
#define CONFIG_S3C2410_NAND_BOOT 1
#define STACK_BASE    0x33f00000
#define STACK_SIZE    0x8000
#define UBOOT_RAM_BASE    0x33f80000
/* NAND Flash Controller */
#define NAND_CTL_BASE            0x4E000000
#define bINT_CTL(Nb)        __REG(INT_CTL_BASE + (Nb))
/* Offset */
#define oNFCONF               0x00
#define oNFCMD                0x04
#define oNFADDR               0x08
#define oNFDATA               0x0c
#define oNFSTAT               0x10
#define oNFECC                0x14

12）重新编译u-boot
make all ARCH=arm

13）通过jtag将u-boot烧写到flash中就可以从NAND flash启动了

我的u-boot启动信息：

U-Boot 1.1.3 (May  6 2006 - 18:13:59)

U-Boot code: 33F80000 -> 33F967C4  BSS: -> 33F9AAAC
RAM Configuration:
Bank #0: 30000000 64 MB
Flash: 512 kB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
BKS2410 #

U-Boot在基于ADSP BF533的嵌入式Linux系统上的移植

1 引言

Boot Loader(内核引导程序)是在操作系统内核运行之前运行的一段自举程序，用于初始化硬件设备、改变处理器运行模式、重组中断向量和建立内存空间映射图，从而将系统的软硬件带到一个合适的状态或者用户定制的特定状态，以便为最终加载操作系统内核准备好正确的环境[1]。

嵌入式Linux系统常用的Boot Loader有arm-boot、redboot、U-Boot等。U-Boot (全称Universal Boot Loader)是当前比较流行的遵循GPL条件的开放源码项目。U-Boot具有源码公开的特点，开发人员可根据自身需要进行裁减；支持多种处理器和嵌入式操作系统内核；具有多种设备驱动源码：支持种引导方式；具有功能强大且成熟、稳定等诸多优点，故在嵌入式系统开发过程中广泛采用。U-Boot严重依赖于底层硬件，不同的CPU或嵌入式板极设备需要不同的U-Boot，因此，在嵌入式系统中建立通用的U-Boot是非常困难的，故U-Boot需针对开发板量身定做。

2 开发平台

2.1 BF533简介

Blackfin系列DSP是ADI公司与Intel联合开发推出的第一款高性能、低功耗第四代定点DSP产品，融合了Analog Devices/Intel公司的微信号结构(MSA)。它将一个32位RISC型指令集和双16位乘法累加(MAC)信号处理功能与通用型微控制器所具有的易用性组合在一起。这种组合使Blackfin处理器能够在信号处理和控制处理应用中发挥最佳的性能。且Blackfin处理器通过将工业标准接口与高性能的信号处理内核相结合在一起,用户可以快速设计出节省成本的解决方案，而且无需昂贵的外部组件。

本开发系统采用BF533，BF533是主频高达600 MHz、峰值处理能力为1.2 GMI/s的高性能Blackfin处理器。BF533内核包含2个16位MAC、2个40位ALU、4个8位视频ALU以及1个40位移位器。另外，BF533还包括1个UART口、1个SPI口、2个串行口(SPORT)、4个通用定时器(其中3个具有PWM功能)、1个实时时钟、看门狗定时器以及1个并行外设接口。外部存储器控制器可与SDRAM、SRAM、Flash和ROM实现无缝连接[2]。

2.2 系统硬件平台简介

本系统的开发板硬件系统如图1所示。

目标板以Blackfin嵌入式处理器为核心，数据地址线复用到SDRAM、Flash、USB、Ethernet，并通过FPGA实现逻辑控制。此外，将UART端口转换为RS232端口引出。其中SDRAM的地址为0x00000000～0x02000000，Flash的地址为0x20000000～0x20300000。

宿主机采用Window和Suse10.0双操作系统，采用串行接口和以太网连接宿主机和目标板，程序先在宿主机上编译，然后下载至目标板上运行，目标板的终端被重定向到串行接口，由宿主机输出。

2.3 开发环境的建立

2.3.1 在宿主机上设置终端

大部分嵌入式系统在宿主机大多都采用kermit或minaicom实现与目标板的通信，本系统采用inicom。minicom是Linux下一个类似于Windows超级终端的友好串口通信程序。在终端输入bash#minicom-s进入minicom设置画面，设置串口波特率、有效数据位、停止位以及奇偶校验位分别为57 600、8 bit、1位停止位以及无奇偶校验位等。

2.3.2安装交叉编译器

交叉编译是在一个架构下编译另外一个架构的目标文件。要从http：//blackfin.uclinux.org网站上下载Blackfin ToolChain，然后安装并修改环境变量PATH，使其包含ToolChain的安装目录。

3 U-Boot启动两阶段

U-Boot代码一般分为stage1和stage2两大部分。stage1依赖于cpu体系结构如设备初始化代码，常用汇编语言编写以达到短小精悍,提高系统运行效率的目的。它主要包括cpu/bf533目录下的start.s。stage2一般采用C语言编写实现复杂功能，这样代码则具有更好的可读性和可移植性，主要包括lib blackfin/board.c文件和common/main．c文件中main_loop函数。

stagel从cpu入口函数cpu/bf533/start.s开始,通常包含以下步骤：

(1)基本硬件的初始化，为随后执行kernel准备好基本的硬件环境。包括：屏蔽所有中断，引导装载程序的执行过程中不必执行任何中断，中断屏蔽可通过写cpu的中断屏蔽寄存器或状态寄存器实现；设置cpu的速度和时钟频率，初始化pll；RAM初始化，初始化内存控制器的各个寄存器；初始化UART，向串口打印U-Boot的字符信息；关闭cpu内部指令，数据cache。

(2) 为加载U-Boot的stage2准备RAM空间，通常将stage2置于整个RAM空间的最顶层1 MB空间。

(3)拷贝U-Boot的stage2到RAM。判断是否是Flash运行,如果是就将stage2的代码拷贝到TEXT BASE处。将stage2安排到RAM空间的最顶层1 MB是较推荐的方法。

(4)设置堆栈指针sp为C语言代码执行做好准备。

(5)跳转到stage2的C语言代码入口点。

stage2主要包括lib-blackfin/board.c中board_init_f、board_init_r函数以及common/main.C中main_loop函数。通常包含以下步骤：

(1)初始化此阶段需用的硬件设备，由board_init_f和board_init_r函数实现。

(2)内存映射检测。

(3)加载内核并为内核设置启动参数。

(4)调用内核。

4 U-BOOt的移植

4.1 U-Boot方法与要点

移植U-Boot简便的方法是从U-Boot支持的开发板中选择一个与其目标板接近的开发板进行修改。需修改的是与硬件相关的部分,涉及到两个层面：针对CPU的移植，由于U-Boot_1.1.3支持BF533，故只需做第二层面的移植：针对目标板硬件的移植。在移植前，需仔细阅读U-Boot/readme文件，该文件对目录结构和如何移植作了简要介绍。从移植U-Boot的最小要求、U-Boot能够正常启动的角度出发,选择BF533的STAMP板为模板,相关源代码在/board/stamp目录下，结合U-Boot的启动流程，主要修改文件如下：

(1)与目标板相关的代码部分：在board下创建mybf533目录，无需从头开始，参考与目标板相似的STAMP板在mybf533目录下创建mybf533.c、mybf533.h、flash.c、config.mk、Makefie等文件。需要修改/board/mybf533/config.mk：

TFEXT_BASE用于设置程序编译链接的起始地址即将U-Boot的stage2拷贝到SDRAM的TEXT_BASE处，即SDRAM最顶层一段存储区。修改board/mybf533/Makefile：



(2)与CPU相关的代码部分：U-Boot_1.1.3/epu文件中含有BF533的目录，其中包含start.s、cpu.c、cpu.h、interrupt.c、init_sdram.s等。故不需要建立与cpu相关的文件目录。

(3)与头文件相关的代码：在include/configs创建mybf533.h，参考include/configs/stamp.h，如下：



Flash的修改与具体型号和容量有关，修改过程中参考Flash擦除数据命令、特定寄存器的写入地址以及扇区的大小和位置。

与SDRAM相关设置：




注意：最后一行要用Tab键开头表示命令。其中blackfin表示CPU的种类.bf533是cpu bf533对应的代码目录，mybf533是目标板对应的目录。这样可使用make mybf533_config配置自身的开发板。

其他修改视情况而定。如根据SDRAM大小修改cplb表，根据需要修改堆栈大小。如drivers/cfi_flash.c中flash_init()函数,cpu/bf533/ints.c中init_IRQ()函数等。

修改完毕后就可以采用如以下命令编译U-Boot：bash＄>make clean，bash＄>make mrproper，bash＄>make mybf533_config，bash＄>make。

编译完后U-Boot_1.1.3生成U-Boot的二进制文件U-Boot.bin(U-Boot.bin只能用于更新)。执行bash＄>bfin-uclinux-objcopy-I binary-Oihex U-Boot.bin,生成可在Windows下首次烧写到Flash的十六进制文件U-Boot.hex。

4.2 U-Boot的烧写

第一次下载U-Boot到目标板或者当U-Boot不能正常启动时。必须通过JTAG或者ADI ICE将U-Boot下载到目标板。在此可将ADI公司的仿真器与Visual DSP++环境相连,通过Visual DSP++,在TOOLS-->Flash Programmer下执行Flash驱动程序M25P64.dxe，选择"Erase all"-->Load Flie烧写U-Boot.hex文件到Flash中。

移植成功后，打开终端minicom复位开发板，若串口能输出正确的启动信息．则表明移植基本成功。启动后，如果在设定的时间内，串口没有接收到按键。U-Boot将自动加载操作系统内核和文件系统。若设定时间内串口接收到按键，则U-Boot停止自动加载,进入命令行，可看到U-Boot的提示符"mybf533>"，查看Flash信息，调试或手动加载内核。

生成新的U-Boot.bin文件后。可通过Ethernet或者串口更新U-Boot。因为网络的传输速度远比串口快，故一般选择网络传输。将新生成的U-Boot.bin拷贝到宿主机根目录下的tftpboot目录(前提是已经创建tftp sever),在目标板出现U-Boot提示符后。按任意键进入下载模式：
mybf533>tftp 0x1000000 U-Boot.bin

0x1000000为SDRAM默认的下载地址空间,用于U-Boot的升级、调试。当需要升级或者修改U-Boot,可将新的U-Boot从SDRAM烧写到。Flash,覆盖原来的U-Boot，以减少烧写Flash的次数。在烧写以前最好测试一下所下载的U-Boot能否正常运行：

如果不正确，应重复执行Erase all和Copy命令，直到正确为止。至此，U-Boot移植的步骤已基本完成。

5 结束语

U-Boot是一个功能强大的Boot loader。前期移植工作是嵌入式系统开发的首要环节。但其移植不可避免的存在一些难以预料的问题。嵌入式开发人员应该在了解U-Boot的工作机理、移植条件后,根据目标板和具体情况灵活裁减U-Boot以提高操作系统移植的稳定性，缩短移植周期，降低产品成本。

本文结合U-Boot的运行机理以及U-Boot移植的基本要求，研究了U-Boot在基于BF533的嵌入式系统上的移植。本文的移植是在不改变U-Boot框架前提下，对嵌入式目标板和CPU相关代码进行修改，实现了成功移植且移植后的U-Boot能够在目标板上稳定运行，为后续开发奠定了良好的基础。

基于Blackfin嵌入式系统的U-boot分析与调试

引言

       Boot loader代码是CPU芯片复位后进入操作系统之前执行的一段代码，主要用于完成硬件启动到操作系统启动的过渡，从而为操作系统提供基本的运行环境。Boot loader代码与CPU的内核结构、具体型号、应用系统配置及操作系统有关，其功能类似于PC机的BIOS程序。

       Blackfin DSP是美国模拟器件公司与Intel联合开发的第4代DSP产品，是专为通信和互联网应用而设计的通用DSP芯片，适合处理互联网中的大量图像、声音、文本和数据流，以及汽车电子中的可视系统、宽带无线系统、消费类多媒体电子、数字摄像机、多通道VoIP、安全和监督、机顶盒和视频电话会议等。 本文对基于Blackfin 561微处理器构建的嵌入式开发板EZKIT561的U-boot第一和第二阶段的具体工作流程进行了分析，画出了各阶段的流程图，同时在U-boot第一阶段代码中加入LED指示程序来跟踪第一阶段的执行情况；而在U-boot第二阶段，则在代码的相应位置添加了向串口的打印信息，以跟踪U-boot在此阶段的执行情况。

       1 Blackfin DSP简介

       ADI公司推出的Blackfin处理器是专为嵌人式音频、视频、通信计算要求和功耗约束条件而设计的新型16～32位嵌入式处理器。Blackfin处理器由ADI和Intel联合开发，主要基于微信号架构(MSA)。它将一个32位RISC型指令集和双16位乘法累加(MAC)信号处理功能与通用型微控制器所具有的易用性组合在一起。这种处理特征使得Blackfin处理器在信号处理和控制处理应用中均能发挥上佳作用，因而在许多场合可免除增设单独异类处理器。

       2 Boot loader及U-boot简介

       2．1 Boot loader简介

       Boot loader是用于初始化目标板硬件，可给嵌入式操作系统提供板上硬件资源信息，并进行装载、引导嵌人式操作系统运行的固件。最终，Boot Loader会把操作系统内核映像加载到RAM中，并将系统控制权传递给它。

       大多数Boot Loader都包含两种不同的操作模式： "启动加载"模式和"下载模式"。

       启动加载(Boot loading)模式也称"自主"(Autonomous)模式。即Boot Loader从目标机上的某个固态存储设备上将操作系统加载到RAM中运行。这种模式是Boot Loader的正常工作模式，因此在嵌入式产品发布的时侯，Boot Loader显然必须工作在这种模式下。

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

       2．2 U-boot简介
       U-Boot(全称U niversal Boot Loader)是遵循GPL条款的开放源码项目。其源码目录和编译形式与Linux内核相似。事实上，不少U-Boot源码就是相应的Linux内核源程序的简化，尤其是一些设备的驱动程序，这一点从U-Boot源码的注释中就能体现。目前支持的目标操作系统有OpenBSD，NetBSD，FreeBSD，4．4BSD，Linux，SVR4，Esix，Solaris，Irix，VxWorks，LynxOS，pSOS，QNX，RTEMS，ARTOS；这是U-Boot中Universal的一层含义，另外一层含义是U-Boot除了支持PowerPC系列处理器外，还能支持Black-fin、MIPS、x86、ARM、NIOS、XScale等诸多处理器。上述两个特点正是U-Boot项目的开发目标，即支持尽可能多的嵌入式处理器和嵌人式操作系统。U-Boot的主要目录结构如表1所列。

       3 基于Blackfin DSP的U-boot运行分析

       大多数Boot loader都分为stagel和stage2两大部分，U-boot也是如此。

       3．1 U-boot的stagel阶段

       依赖于CPU体系结构的代码(比如设备初始化代码等)，通常都放在stage1中，该代码可用blackfin DSP汇编语言来实现，以达到短小精悍的目的。实际操作可在位于U-boot 1．1．3＼cpu＼bf533中的Start．S和Startl．S文件中实现，而且是从Start．S开始运行，此阶段的程序流程图如图1所示。

       stage1的步骤以执行的先后主要包括硬件设备初始化、为加载Boot Loader的stage2准备RAM空间、拷贝Boot Loader的stage2到RAM空间、设置堆栈、跳转到stag2的C入口等。

       3．2 U-boot的stage2阶段

       通常stage2可用C语言来实现更复杂的功能，该代码具有更好的可读性和可移植性。Stage2实现的主要功能包括初始化本阶段要使用到的硬件设备，检测系统内存映射(memory map)，将ker-nel映像和根文件系统映像从flash上读到RAM空间中，为内核设置启动参数，以及调用内核等。

       而基于ADSP-BF561 EZKIT-Lite评估板的U-boot在该阶段的启动时，首先在第一阶段结束后，调用＼U-boot 1．1．3＼1ib_blackfin＼board．c文件中的board_init_f()函数并执行。

       然后再调用board．c文件中的board_init_r()函数并按先后顺序执行，其流程图如图2所示。

       之后，再在board_init_r函数的最后调用＼U-boot 1．1．3＼common＼main．c中的main_loop()函数。在执行过程中，系统会首先对自动启动内核进行倒计时，倒计时的时间由环境变量bootdelay的设定值决定。由于先前已经对串口进行了初始化，所以会在windows超级终端打印"ezkit：>"，这样，mainloop()函数的执行将产生两条分支：一是等待u-boot的自启动命令执行，即执行bootcmd环境变量所设定的自动运行的命令(比如setenvbootcmd bootm 0x2000 0000)，引导flash特定地址中的嵌入式操作系统；二是在u-boot的自启动命令执行前按下任意键，以进入u-boot的命令行。在此状态下可以查看和修改环境变量、下载更新U-boot和内核镜像文件、对flash进行擦写操作或通过命令启动操作系统(如bootm 0x2000 0000)；

       4 基于评估板的U-boot启动跟踪调试

       4．1 第一阶段跟踪调试

       由于U-boot的启动过程分为两个阶段，第一阶段在串口初始化之前无法获得字符串提示信息。这样，第一阶段的运行过程似乎就没办法掌握．但是，EZKIT561开发板提供16个用户可编程的LED，所以就可以通过这16个LED来了解u-boot在第一阶段的具体执行过程，即在U-boot第一阶段的几个不同的代码处添加LED指示程序。

       ADSP-BF561有48个双向通用可编程I／O引脚。这些可编程引脚具有实现SPI接口的特殊功能。每一个可编程引脚均能通过操作一系列的标志控制寄存器、标志状态寄存器和标志中断寄存器来进行独立控制。由于一共有48个通用可编程I／O引脚，所以可将以上寄存器分成三组，每组可对16个通用可编程I／O引脚进行操作。

       通过参考EZKIT56 1原理图可知，LED 5～20与PF 32～47 pins相连，可以跟踪堆栈配置。设计时可使用以下寄存器进行控制。

       (1)FIO2_DIR寄存器

       这是一个16位寄存器，若将其中的某一位设置为1，那么相应的PF引脚就可作为输出；反之，则为输入。其相关设置代码如下：

       (2)FIO2_FLAG_D

       这也是一个16位寄存器，对其写操作时，可指定相应的PF引脚状态；而当进行读操作时，则返回相应的PF引脚的值。它的每一位都控制着一个LED灯。其相关设置代码如下：

w [p0]=r0；
ssync；

       添加的跟踪堆栈配置程序的流程图如图3所示。修改代码后即可在U-boot文件夹路径下依次输入以下命令：make clean、make mrproper、make ezkit561 config和make，然后再利用bfin-u．clinux-objcopy将生成的U-boot．bin转换为U-boot．hex，最后通过VDSP＋＋开发环境中TOOL下的flashprogrammer将u-boot．hex烧写到flash中，同时进行复位操作以观察LED的变化。

       本设计希望在堆栈配置前使LED 13、LED 14亮，其它LED灭，持续时间为1 s；而在堆栈分配之后使LED 11、LED 12亮，其它LED灭，持续时间为1 s。其实际的观察结果是，在复位之后，LED 13、LED 14持续亮1 s，接着LED 11、LED 12持续亮1秒，可见其完全达到了预期目标。

       4．2 第二阶段跟踪调试

       第二阶段是在进人C函数之后，就进行串口的初始化。之后，便可通过向串口打印信息来实时跟踪所启动的执行流程，以了解程序目前执行的具体部分或运行到哪一个阶段出现了问题。

       下面以打印串口初始化完成信息为例。首先在U-boot第二阶段找到串口初始化的代码，即U-boot／lib-blackfin／board．c文件的serial．init()函数，然后在此函数之后添加printf("serial initializationis ok!＼n")以实现打印。其程序代码如下：

       修改代码后的编译和下载步骤如前所示，调试时使用的串行通信软件是windows自带的"超级终端"程序，所选择的"每秒位数" (即波特率)为57600，传输文件使用的通信协议为Kermit协议。配置好超级终端后，按下开发板上的复位键．终端便可显示出系统启动过程的相关信息。系统复位后，第一行显示的是"serial initializa-tion is ok!"。这便是自行添加的打印语句，其主要功能是提示串口初始化已完成。

       由于第二阶段可以通过串口打印信息，且在相关的每一阶段均可添加相关的printf句来实现打印提示信息，所以跟踪及调试都比较容易。

       5 结束语

       通过分析基于Blackfin 561微处理器构建的嵌入式开发板EZKIT561的U-boot代码，以期对Boot Loader的启动过程有一个比较深入的理解，文章还通过一些调试方法对其运行阶段进行跟踪，以便对将来在开发板上的ucLinux移植和进一步的视频编解码工作进行准备。

图1  Bootloader网络启动方式示意图

http://www.linuxforum.net/forum/showflat.php?Cat=&Board=embedded&Number=651003&page=0&view=collapsed&sb=5&o=0&fpart=1#Post651082

再读bootm源码，现象正常！

呵呵 ， 原来 tftp download到是否是 hdr->ih_load(0x30008000) 确实是有说道的。
原来对bootm源码有个地方理解错了， bootm 会根据 hdr->ih_comp 判断是否需要解压， 对于
mkimage -C none 的是不需要解压的。

1> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008040 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8040
这种情况 ，只能把 uImage download到 30008000的位置上 ，否则 从 30008040
是启动不了的。
2> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008000 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8000
这种情况download地址随便。
如果 tftp 下载地址==0x30008000 ， 就从 0x30008040 启动就肯定OK 。
详细的请看代码。
研究了一下 u-boot-1.2.0 里面的 bootm的实现代码： do_bootm_linux() 函数 ，
原来由于我用mkimage的的时候的选项是 -C none ， 所以下面的判断中 hdr->ih_comp ＝
IH_COMP_NONE
通过再读一遍代码， 也弄明白了上次问的问题， 就是 u－boot里面的解压和
内核自解压的区别： u-boot 里面的解压实际上是bootm 实现的 ， 把 mkimage -C bzip2
或者gzip 生成的 uImage进行解压 ； 而kernel的自解压是对zImage进行解压，
发生在bootm解压之后。

呵呵 ， 原来 tftp download到是否是 hdr->ih_load(0x30008000) 确实是有说道的。
原来对bootm源码有个地方理解错了， bootm 会根据 hdr->ih_comp 判断是否需要解压， 对于
mkimage -C none 的是不需要解压的。

1> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008040 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8040
这种情况 ，只能把 uImage download到 30008000的位置上 ，否则 从 30008040
是启动不了的。
2> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008000 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8000
这种情况download地址随便。
如果 tftp 下载地址==0x30008000 ， 就从 0x30008040 启动就肯定OK 。
详细的请看代码。
研究了一下 u-boot-1.2.0 里面的 bootm的实现代码： do_bootm_linux() 函数 ，
原来由于我用mkimage的的时候的选项是 -C none ， 所以下面的判断中 hdr->ih_comp ＝
IH_COMP_NONE
通过再读一遍代码， 也弄明白了上次问的问题， 就是 u－boot里面的解压和
内核自解压的区别： u-boot 里面的解压实际上是bootm 实现的 ， 把 mkimage -C bzip2
或者gzip 生成的 uImage进行解压 ； 而kernel的自解压是对zImage进行解压，
发生在bootm解压之后。

switch (hdr->ih_comp) {
case IH_COMP_NONE:
if(ntohl(hdr->ih_load) == addr) { //如果你是tftp 到 0x30008000那么这里就命中了。
printf (" XIP %s ... ", name); //tftp download 这里， 确实打印出来了。
} else { //否则随便download到一个地址， 流程就进入这里了。
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) //这个条件编译不成立
size_t l = len;
void *to = (void *)ntohl(hdr->ih_load);
void *from = (void *)data;
printf (" Loading %s ... ", name);
while (l > 0) {
size_t tail = (l > CHUNKSZ) ? CHUNKSZ : l;
WATCHDOG_RESET();
memmove (to, from, tail);
to += tail;
from += tail;
l -= tail;
}
#else/* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */
------------------------实际执行的是这里---------------------------------
memmove ((void *) ntohl(hdr->ih_load), (uchar *)data, len);
//从这里就可以看出一旦 tftpdownload到一个任意地址， bootm 都会把
//它（去掉header后的kernel搬运到0x30008000 的位置上，因此entry
//point 肯定要是 0x30008000 ，但是对于tftp 恰好download到
//0x30008000 的位置上的时候， 你会发现上面的代码中，就donothing
//了，因此就必须从 0x30008040

#endif/* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
}
break;
case IH_COMP_GZIP:
printf (" Uncompressing %s ... ", name);
if (gunzip ((void *)ntohl(hdr->ih_load), unc_len, // 把它解压到ih_load的位置上去
(uchar *)data, &len) != 0) {
puts ("GUNZIP ERROR - must RESET board to recover\n");
SHOW_BOOT_PROGRESS (-6);
do_reset (cmdtp, flag, argc, argv);
}
break;
.....
省略了 gzip和 bzip2的处理 ， // 这里也说明 和 zImage的自解压是不一样的。
gzip : mkimage -C gzip ;
bzip2 mkimage -C bzip2 .
他是只uImage 本身被压缩了
default:
if (iflag)
enable_interrupts();
printf ("Unimplemented compression type %d\n", hdr->ih_comp);
SHOW_BOOT_PROGRESS (-7);
return 1;
}
//解压完毕，对于我得板子来说，是解压到 0x8000的位置上去了，这是个物理地址
puts ("OK\n");
SHOW_BOOT_PROGRESS (7);

armlinux的bootloader启动代码分析

Author : balancesli
mail : balancesli@thizlinux.com.cn

前阶段做了一次基于at91rm9200引导部分的技术分析，主要采用了u-boot，这里只面向使用at91rm9200板子的
的朋友做个简单的推敲，希望起到抛砖引玉的作用.

关键词 :
u-boot: 一个开源的面向多个目标平台(ppc, mips, arm, x86)的bootloader.
at91rm9200 : Atmel 公司生产的基于arm9核的Soc处理器.

以下先给出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

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

这里要提及的是at91rm9200内部本身有128k的片内rom,其固化了一个bootloader和uploader, 用来支持程序的
下载和引导,而且其内部固化的程序提供了很多内部服务接口(Internel Service)供我们来使用，例如Xmodem，Tempo
DataFlash, CRC, Sine服务接口，这样我们就可以利用它所提供的Service interface API完成程序的下载。
这里主要介绍Xmodem接口服务。

at91rm9200内部固化的代码在设计上采用了面向对象的设计方法，如下:


typedef struct _AT91S_Service
{
char data;
char (*MainMethod)();
char (*ChildMethod)();
}AT91S_Service, *AT91PS_Service;

char AT91F_MainMethod()
{

}
char AT91F_ChildMethod()
{

}

/*init the Service */
AT91PS_Service AT91F_OpenDevice(AT91PS_Service pService)
{
pService->data = 0;
pService->MainMethod = AT91F_MainMethod;
pService->ChildMethod = AT91F_ChildMethod;
}

//使用方法如下
AT91S_Service service;
AT91PS_Service pService = AT91F_OpenDevice(&service);
pService->AT91F_MainMethmod();
.....

通过如上代码片断可以看出它采用了类似面向对象的设计方法。
其实如果各位朋友接触过的话或者看过这本书的话，应该很容易便接受它。
下面以Xmodem服务为例子介绍:

at91rm9200内部提供的服务包含了几个服务对象, 这些对象在片内启动xmodem协议Host端和Targe端通讯时会用到.

typedef struct _AT91S_RomBoot
{
const unsigned int version;
// Peripheral descriptors
const AT91S_MEMCDesc MEMC_DESC;
const AT91S_STDesc SYSTIMER_DESC;
const AT91S_Pio2Desc PIOA_DESC;
const AT91S_Pio2Desc PIOB_DESC;
const AT91S_USART2Desc DBGU_DESC;
const AT91S_USART2Desc USART0_DESC;
const AT91S_USART2Desc USART1_DESC;
const AT91S_USART2Desc USART2_DESC;
const AT91S_USART2Desc USART3_DESC;
const AT91S_TWIDesc TWI_DESC;
const AT91S_SPIDesc SPI_DESC;

// Objects entry
const AT91PF_OpenPipe OpenPipe;
const AT91PF_OpenSBuffer OpenSBuffer;
const AT91PF_OpenSvcUdp OpenSvcUdp;
const AT91PF_OpenSvcXmodem OpenSvcXmodem;
const AT91PF_OpenCtlTempo OpenCtlTempo;
const AT91PF_OpenDfuDesc OpenDfuDesc;
const AT91PF_OpenUsbDesc OpenUsbDesc;
const AT91PF_OpenSvcDataFlash OpenSvcDataFlash;
const AT91PF_SVC_CRC16 CRC16;
const AT91PF_SVC_CRCCCITT CRCCCITT;
const AT91PF_SVC_CRCHDLC CRCHDLC;
const AT91PF_SVC_CRC32 CRC32;
// Array
const AT91PS_SVC_CRC_BIT_REV Bit_Reverse_Array;
const AT91PS_SINE_TAB SineTab;
const AT91PF_Sinus Sine;
} AT91S_RomBoot;

//AT91S_Pipe
typedef struct _AT91S_Pipe
{
// A pipe is linked with a peripheral and a buffer
AT91PS_SvcComm pSvcComm;
AT91PS_Buffer pBuffer;

// Callback functions with their arguments
void (*WriteCallback) (AT91S_PipeStatus, void *);
void (*ReadCallback) (AT91S_PipeStatus, void *);
void *pPrivateReadData;
void *pPrivateWriteData;

// Pipe methods
AT91S_PipeStatus (*Write) (
struct _AT91S_Pipe *pPipe,
char const * pData,
unsigned int size,
void (*callback) (AT91S_PipeStatus, void *),
void *privateData
);

AT91S_PipeStatus (*Read) (
struct _AT91S_Pipe *pPipe,
char *pData,
unsigned int size,
void (*callback) (AT91S_PipeStatus, void *),
void *privateData
);

AT91S_PipeStatus (*AbortWrite)(struct _AT91S_Pipe *pPipe);
AT91S_PipeStatus (*AbortRead)(struct _AT91S_Pipe *pPipe);
AT91S_PipeStatus (*AbortRead)(struct _AT91S_Pipe *pPipe);
AT91S_PipeStatus (*Reset)(struct _AT91S_Pipe *pPipe);
char (*IsWritten)(struct _AT91S_Pipe *pPipe, char const *pVoid);
char (*IsReceived) (struct _AT91S_Pipe *pPipe, char const *pVoid);
} AT91S_Pipe;

//AT91S_Buff
typedef struct _AT91S_SBuffer
{
AT91S_Buffer parent;
char *pRdBuffer;
char const *pWrBuffer;
unsigned int szRdBuffer;
unsigned int szWrBuffer;
unsigned int stRdBuffer;
unsigned int stWrBuffer;
} AT91S_SBuffer;

// AT91S_SvcTempo
typedef struct _AT91S_SvcTempo
{

// Methods:
AT91S_TempoStatus (*Start) (
struct _AT91S_SvcTempo *pSvc,
unsigned int timeout,
unsigned int reload,
void (*callback) (AT91S_TempoStatus, void *),
void *pData);
AT91S_TempoStatus (*Stop) (struct _AT91S_SvcTempo *pSvc);

struct _AT91S_SvcTempo *pPreviousTempo;
struct _AT91S_SvcTempo *pNextTempo;

// Data
unsigned int TickTempo; //* timeout value
unsigned int ReloadTempo;//* Reload value for periodic execution
void (*TempoCallback)(AT91S_TempoStatus, void *);
void *pPrivateData;
AT91E_SvcTempo flag;
} AT91S_SvcTempo;

// AT91S_CtrlTempo
typedef struct _AT91S_CtlTempo
{
// Members:

// Start and stop for Timer hardware
AT91S_TempoStatus (*CtlTempoStart) (void *pTimer);
AT91S_TempoStatus (*CtlTempoStop) (void *pTimer);

// Start and stop for Tempo service
AT91S_TempoStatus (*SvcTempoStart) (
struct _AT91S_SvcTempo *pSvc,
unsigned int timeout,
unsigned int reload,
void (*callback) (AT91S_TempoStatus, void *),
void *pData);
AT91S_TempoStatus (*SvcTempoStop) (struct _AT91S_SvcTempo *pSvc);
AT91S_TempoStatus (*CtlTempoSetTime)(struct _AT91S_CtlTempo *pCtrl, unsigned int NewTime);
AT91S_TempoStatus (*CtlTempoGetTime)(struct _AT91S_CtlTempo *pCtrl);
AT91S_TempoStatus (*CtlTempoIsStart)(struct _AT91S_CtlTempo *pCtrl);
AT91S_TempoStatus (*CtlTempoCreate) (struct _AT91S_CtlTempo *pCtrl,struct _AT91S_SvcTempo *pTempo);
AT91S_TempoStatus (*CtlTempoRemove) (struct _AT91S_CtlTempo *pCtrl,struct _AT91S_SvcTempo *pTempo);
AT91S_TempoStatus (*CtlTempoTick) (struct _AT91S_CtlTempo *pCtrl);

// Data:

void *pPrivateData; // Pointer to devived class
void const *pTimer; // hardware
AT91PS_SvcTempo pFirstTempo;
AT91PS_SvcTempo pNewTempo;
} AT91S_CtlTempo;



//以下代码是上面几个对象的使用范例，通过这样就可以完成Host端和Targe端之间的xmodem通讯,并可以下载代码了。

AT91S_RomBoot const *pAT91;
AT91S_SBuffer sXmBuffer;
AT91S_SvcXmodem svcXmodem;
AT91S_Pipe xmodemPipe;
AT91S_CtlTempo ctlTempo;

AT91PS_Buffer pXmBuffer;
AT91PS_SvcComm pSvcXmodem;
unsigned int SizeDownloaded;

/* Init of ROM services structure */
pAT91 = AT91C_ROM_BOOT_ADDRESS;//这里取得内部ROM服务的入口地址

/* Tempo Initialization */
pAT91->OpenCtlTempo(&ctlTempo, (void *) &(pAT91->SYSTIMER_DESC));
ctlTempo.CtlTempoStart((void *) &(pAT91->SYSTIMER_DESC));

/* Xmodem Initialization */
pXmBuffer = pAT91->OpenSBuffer(&sXmBuffer);
pSvcXmodem = pAT91->OpenSvcXmodem(&svcXmodem, (AT91PS_USART)AT91C_BASE_DBGU, &ctlTempo);
pAT91->OpenPipe(&xmodemPipe, pSvcXmodem, pXmBuffer);
xmodemPipe.Read(&xmodemPipe, (char *)AT91C_UBOOT_BASE_ADDRESS, AT91C_UBOOT_MAXSIZE,
AT91F_XmodemProtocol, 0);
while(XmodemComplete !=1);



//上面部分主要针对at91rm9200片内启动时我们可以使用的片内接口服务介绍，玩H9200的朋友可以参考一下便知道缘由。

下面主要介绍at91rm9200片外启动时所使用的bootloader-->u-boot.

一. bootloader
BootLoader(引导装载程序)是嵌入式系统软件开发的非常重要的环节，它把操作系统和硬件平台衔接在一起，
是跟硬件体系密切相关的。



1.1 典型的嵌入式系统软件部分Image memory layout : bootloader , bootloader param, kernel, rootfs.

1.2 引导模式 : 1. bootstrap或download
2. autoboot
1.3 u-boot简介 :
u-boot是由Wolfgang Denk开发，它支持(mips, ppc, arm, x86)等目标体系，
可以在http://sourceforge.net 上下载获得源码，

1.4 u-boot源代码目录结构

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命名.

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程序入口点.

disk：设备分区处理代码。

doc：u-boot相关文档。


drivers：u-boot所支持的设备驱动代码, 网卡、支持CFI的Flash、串口和USB总线等。

fs: u-boot所支持支持文件系统访问存取代码， 如jffs2.

include：u-boot head文件，主要是与各种硬件平台相关的头文件，
如include/asm-arm/arch-at91rm9200/, include/asm-arm/proc-armv

net：与网络有关的代码，BOOTP协议、TFTP协议、RARP协议代码实现.

lib_arm：与arm体系相关的代码。(这里我们主要面向的是ARM体系，所以该目录是我们主要研究对象)

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

1.5 u-boot的功能介绍

　u-boot支持SCC/FEC以太网、OOTP/TFTP引导、IP和MAC的功能.
读写Flash、DOC、IDE、IIC、EEROM、RTC
支持串行口kermit和S-record下载代码, 并直接从串口下载并执行。

在我们生成的内核镜像时，要做如下处理.
1. arm-linux-objcopy -O binary -R.note -R.comment -S vmlinux linux.bin
2. gzip -9 linux.bin
3. mkimage -A arm -O linux -T kernel -C gzip -a 0xc0008000 -e 0xc0008000 -n
"Linux-2.4.19-rmk7” -d linux.bin.gz uImage

即在Linux内核镜像vmLinux前添加了一个特殊的头，这个头在include/image.h中定义，
typedef struct image_header
{
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;

当u-boot引导时会对这个文件头进行CRC校验，如果正确，才会跳到内核执行.

如果u-boot启动以后会出现
u-boot>
敲入help, 会出现大量的命令提示，Monitor command
go - start application at address 'addr'
run - run commands in an environment variable
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
tftpboot- boot image via network using TFTP protocol
and env variables "ipaddr" and "serverip"
(and eventually "gatewayip")
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd'
loads - load S-Record file over serial line
loadb - load binary file over serial line (kermit mode)
md - memory display
mm - memory modify (auto-incrementing)
nm - memory modify (constant address)
mw - memory write (fill)
cp - memory copy
cmp - memory compare
crc32 - checksum calculation
imd - i2c memory display
imm - i2c memory modify (auto-incrementing)
inm - i2c memory modify (constant address)
imw - i2c memory write (fill)
icrc32 - i2c checksum calculation
iprobe - probe to discover valid I2C chip addresses
iloop - infinite loop on address range
isdram - print SDRAM configuration information
sspi - SPI utility commands
base - print or set address offset
printenv- print environment variables
setenv - set environment variables
saveenv - save environment variables to persistent storage
protect - enable or disable FLASH write protection
erase - erase FLASH memory
flinfo - print FLASH memory information
bdinfo - print Board Info structure
iminfo - print header information for application image
coninfo - print console devices and informations
ide - IDE sub-system
loop - infinite loop on address range
mtest - simple RAM test
icache - enable or disable instruction cache
dcache - enable or disable data cache
reset - Perform RESET of the CPU
echo - echo args to console
version - print monitor version
help - print online help
? - alias for 'help'

u-boot支持大量的命令可用, 这里就不作介绍，大家有兴趣可以看看u-boot 的README文档
3.3 对u-boot-1.0.0的修改和移植

1.6 关于u-boot的移植如下，由于u-boot的软件设计体系非常清晰，它的移植工作并不复杂，
相信各位的代码阅读功力不错的话，参照如下就可以完成。

If the system board that you have is not listed, then you will need
to port U-Boot to your hardware platform. To do this, follow these
steps:

1. Add a new configuration option for your board to the toplevel
"Makefile" and to the "MAKEALL" script, using the existing
entries as examples. Note that here and at many other places
boards and other names are listed in alphabetical sort order. Please
keep this order.

2. Create a new directory to hold your board specific code. Add any
files you need. In your board directory, you will need at least
the "Makefile", a ".c", "flash.c" and "u-boot.lds".

3. Create a new configuration file "include/configs/.h" for
your board

4. If you're porting U-Boot to a new CPU, then also create a new
directory to hold your CPU specific code. Add any files you need.

5. Run "make _config" with your new name.

6. Type "make", and you should get a working "u-boot.srec" file

7. Debug and solve any problems that might arise.
[Of course, this last step is much harder than it sounds.]

为了使u-boot-1.0.0支持新的开发板，一种简便的做法是在u-boot已经支持的开发板中参考选择一种较接近板的进行修改,
幸运的是在u-boot-1.0.0中已经有了at91rm9200的支持。

1.7 与at91rm9200相关的u-boot代码

在include/configs/at91rm9200dk.h 它包括开发板的CPU、系统时钟、RAM、Flash系统及其它相关的配置信息。
在include/asm-arm/AT91RM9200.h, 该文件描述了H9200寄存器的结构及若干宏定义。
具体内容要参考相关处理器手册。
在cpu/at91rm9200/目录下别为cpu.c、interrupts.c和serial.c等文件.
在board/at91rm9200dk/目录下分别为flash.c、at91rm9200dk.c, config.mk, Makefile,u-boot.lds

flash.c : u-boot读、写和删除Flash设备的源代码文件。由于不同开发板中Flash存储器的种类各不相同，
所以，修改flash.c时需参考相应的Flash芯片手册。它包括如下几个函数：
unsigned long flash_init (void )，Flash初始化；
void flash_print_info (flash_info_t *info)，打印Flash信息；
int flash_erase (flash_info_t *info， int s_first， int s_last)，Flash擦除；
volatile static int write_dword (flash_info_t *info， ulong dest， ulong data)，Flash写入；
int write_buff (flash_info_t *info， uchar *src， ulong addr， ulong cnt)，从内存复制数据。

u-boot.lds :linker scripte, 设置u-boot中各个目标文件的连接地址.

网口设备控制程序

　　在drivers/目录中网口设备控制程序cs8900, bcm570x等, 还可以添加其他网卡驱动
int eth_init (bd_t *bd) : 初始化网络设备；
void eth_halt (void) : 关闭网络设备；
int eth_send (volatile void *packet，int len) : 发送数据包；
int eth_rx (void) : 接收数据包。

Makefile

　　在u-boot-1.0.0/Makefile中
at91rm9200dk_config : unconfig
./mkconfig $(@:_config=) arm at91rm9200 at91rm9200dk

1.8 编译u-boot

　 make at91rm9200_config
Configuring for at91rm9200 board...
make all
生成三个文件：u-boot.bin, u-boot, u-boot.srec

u-boot.bin is a raw binary image
u-boot is an image in ELF binary format
u-boot.srec is in Motorola S-Record format (objcopy -O srec -R.note -R.comment -S [inputfile] [outfile]


以上工作完成我们可以通过串口将u-boot.bin下载到主板的SDRAM中，它会自动执行， 并出现uboot>
这里我们可以通过串口把boot.bin, u-boot.bin.gz下载到主板，再用u-boot的提供的写flash功能分别
把boot.bin, u-boot.bin.gz写入到flash中，完成以上工作后，对主板跳线选择片外启动，
板子复位后会自动启动u-boot.




二.loader.bin, boot.bin, u-boot.bin代码执行流分析.

以上三个文件时at91rm9200启动所需要的三个bin,他们的实现代码并不难。
如果是你是采用at91rm9200的评估版，应该能得到其源码。

2.1 loader.bin 执行流程,这个文件主要在片内启动从串口下载代码时会用到
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)

2.2 boot.bin执行流程 该文件会在从片内启动时被下载到板子上，以后还会被烧写到片外Flash中，以便在片外启动时
用它来引导并解压u-boot.gz，并跳转到u-boot来执行。
boot/entry.S
b main --> crt0.S --> copydata --> clearbss --> b boot

T91F_DBGU_Printk(" ");
AT91F_DBGU_Printk("************************************** ");
AT91F_DBGU_Printk("** Welcome to at91rm9200 ** ");
AT91F_DBGU_Printk("************************************** ");

boot/misc.s /* unzip uboot.bin.gz */
----> decompress_image(SRC,DST,LEN) --> gunzip

//jump to ubootBaseAddr exec 这里跳转到解压u-boot.gz的地址处直接开始执行u-boot
asm("mov pc,%0" : : "r" (DST));

2.3 uboot.bin执行流程
u-boot/cpu/at91rm9200/start.S
start --->reset
---> copyex ---> cpu_init_crit
---> /* set up the stack */ --> start_armboot
u-boot/lib_arm/board.c

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,
checkboard,
NULL,
};

---> start_armboot ---> call init_sequence
---> flash_init --> display_flash_config
---> nand_init ---> AT91F_DataflashInit
---> dataflash_print_info --> env_relocate
---> drv_vfd_init --> devices_init --> jumptable_init
---> console_init_r --> misc_init_r --> enable_interrupts
---> cs8900_get_enetaddr --> board_post_init -->

u-boot/common/main.c
for (;;)
{ /* shell parser */
main_loop () --> u_boot_hush_start --> readline
--> abortboot
-->printf("Hit any key to stop autoboot: %2d ", bootdelay);
}

以上是at91rm9200启动并进入u-boot的执行流分析。后面u-boot还会将uImage解压到特定的位置并开始执行内核代码。

三. 综述
总之, 不同厂商的出的Soc片子在启动方式大都提供片内和片外启动两种方式，一般都是在片内固化一段小程序
方便于程序开发而已，在其DataSheet文档中有详尽的描述。若是对at92rm9200有兴趣或玩过的朋友，可以与我共同探讨相互学习。