UBoot移植详解.docx

UBoot移植详解.docx

《UBoot移植详解.docx》由会员分享，可在线阅读，更多相关《UBoot移植详解.docx（20页珍藏版）》请在冰豆网上搜索。

UBoot移植详解

u－boot移植步骤详解

1U-Boot简介 

U-Boot，全称UniversalBootLoader，是遵循GPL条款的开放源码项目。

从FADSROM、8xxROM、PPCBOOT逐步发展演化而来。

其源码目录、编译形式与Linux内核很相似，事实上，不少U-Boot源码就是相应的Linux内核源程序的简化，尤其是一些设备的驱动程序，这从U-Boot源码的注释中能体现这一点。

但是U-Boot不仅仅支持嵌入式Linux系统的引导，当前，它还支持NetBSD,VxWorks,QNX,RTEMS,ARTOS,LynxOS嵌入式操作系统。

其目前要支持的目标操作系统是OpenBSD,NetBSD,FreeBSD,4.4BSD,Linux,SVR4,Esix,Solaris,Irix,SCO,Dell,NCR,VxWorks,LynxOS,pSOS,QNX,RTEMS,ARTOS。

这是U-Boot中Universal的一层含义，另外一层含义则是U-Boot除了支持PowerPC系列的处理器外，还能支持MIPS、x86、ARM、NIOS、XScale等诸多常用系列的处理器。

这两个特点正是U-Boot项目的开发目标，即支持尽可能多的嵌入式处理器和嵌入式操作系统。

就目前来看，U-Boot对PowerPC系列处理器支持最为丰富，对Linux的支持最完善。

其它系列的处理器和操作系统基本是在2002年11月PPCBOOT改名为U-Boot后逐步扩充的。

从PPCBOOT向U-Boot的顺利过渡，很大程度上归功于U-Boot的维护人德国DENX软件工程中心WolfgangDenk[以下简称W.D]本人精湛专业水平和持着不懈的努力。

当前，U-Boot项目正在他的领军之下，众多有志于开放源码BOOTLOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入，以支持更多的嵌入式操作系统的装载与引导。

选择U-Boot的理由：

①开放源码； 

②支持多种嵌入式操作系统内核，如Linux、NetBSD,VxWorks,QNX,RTEMS,ARTOS,LynxOS； 

③支持多个处理器系列，如PowerPC、ARM、x86、MIPS、XScale； 

④较高的可靠性和稳定性； 

④较高的可靠性和稳定性； 

⑤高度灵活的功能设置，适合U-Boot调试、操作系统不同引导要求、产品发布等； 

⑥丰富的设备驱动源码，如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等； 

⑦较为丰富的开发调试文档与强大的网络技术支持； 

2U-Boot主要目录结构~~ 

-board目标板相关文件，主要包含SDRAM、FLASH驱动； 

-common独立于处理器体系结构的通用代码，如内存大小探测与故障检测； 

-cpu与处理器相关的文件。

如mpc8xx子目录下含串口、网口、LCD驱动及中断初始化等文件； 

-driver通用设备驱动，如CFIFLASH驱动（目前对INTELFLASH支持较好） 

-docU-Boot的说明文档； 

-examples可在U-Boot下运行的示例程序；如hello_world.c,timer.c； 

-includeU-Boot头文件；尤其configs子目录下与目标板相关的配置头文件是移植过程中经常要修改的文件； 

-lib_xxx处理器体系相关的文件，如lib_ppc,lib_arm目录分别包含与PowerPC、ARM体系结构相关的文件； 

-net与网络功能相关的文件目录，如bootp,nfs,tftp； 

-post上电自检文件目录。

尚有待于进一步完善； 

-rtcRTC驱动程序； 

-tools用于创建U-BootS-RECORD和BIN镜像文件的工具； 

3U-Boot支持的主要功能 

U-Boot可支持的主要功能列表 

系统引导支持NFS挂载、RAMDISK（压缩或非压缩）形式的根文件系统 

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

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

支持目标板环境参数多种存储方式，如FLASH、NVRAM、EEPROM； 

CRC32校验，可校验FLASH中内核、RAMDISK镜像文件是否完好； 

设备驱动串口、SDRAM、FLASH、以太网、LCD、NVRAM、EEPROM、键盘、USB、PCMCIA、PCI、RTC等驱动支持； 

上电自检功能SDRAM、FLASH大小自动检测；SDRAM故障检测；CPU型号； 

特殊功能XIP内核引导； 

4移植前的准备 

（1）、首先读读uboot自带的readme文件，了解了一个大概。

（2）、看看common.h，这个文件定义了一些基本的东西，并包含了一些必要的头文件。

再看看flash.h，这个文件里面定义了flash_info_t为一个struct。

包含了flash的一些属性定义。

并且定义了所有的flash的属性，其中，AMD的有：

AMD_ID_LV320B，定义为“#defineAMD_ID_LV320B0x22F922F9”。

（3）、对于“./borad/at91rm9200dk/flash.c”的修改，有以下的方面：

“voidflash_identification（flash_info_t*info）”这个函数的目的是确认flash的型号。

注意的是，这个函数里面有一些宏定义，直接读写了flash。

并获得ID号。

（4）、修改：

”./board/at91rm9200dk/config.mk”为 

TEXT_BASE=0x21f80000为TEXT_BASE=0x21f00000（当然，你应该根据自己的板子来修改，和一级boot的定义的一致即可）。

（5）、再修改”./include/configs/at91rm9200dk.h”为 

修改flash和SDRAM的大小。

（6）、另外一个要修改的文件是：

./borad/at91rm9200dk/flash.c。

这个文件修改的部分比较的多。

a．首先是OrgDef的定义，加上目前的flash。

b．接下来，修改”#defineFLASH_BANK_SIZE0x200000”为自己flash的容量 

c．在修改函数flash_identification（flash_info_t*info）里面的打印信息，这部分将在u-boot启动的时候显示。

d．然后修改函数flash_init（void）里面对一些变量的赋值。

e．最后修改的是函数flash_print_info（flash_info_t*info）里面实际打印的函数信息。

f．还有一个函数需要修改，就是：

“flash_erase”，这个函数要检测先前知道的flash类型是否匹配，否则，直接就返回了。

把这里给注释掉。

（7）、接下来看看SDRAM的修改。

这个里面对于“SIZE”的定义都是基于字节计算的。

只要修改”./include/configs/at91rm9200dk.h”里面的 

“#definePHYS_SDRAM_SIZE0X200000”就可以了。

注意，SIZE是以字节为单位的。

（8）、还有一个地方要注意 

就是按照目前的设定，一级boot把u_boot加载到了SDRAM的空间为：

21F00000->21F16B10，这恰好是SDRAM的高端部分。

另外，BSS为21F1AE34。

（9）、编译后，可以写入flash了。

a．压缩这个u-boot.bin 

“gzip–cu-boot.bin>u-boot.gz” 

压缩后的文件大小为：

43Kbytes 

b．接着把boot.bin和u-boot.gz烧到flash里面去。

Boot.bin大约11kBytes，在flash的0x10000000~0x10003fff 

5U-Boot移植过程 

①获得发布的最新版本U-Boot源码，与Linux内核源码类似，也是bzip2的压缩格式。

可从U-Boot的官方网站 

②阅读相关文档，主要是U-Boot源码根目录下的README文档和U-Boot官方网站的DULG（TheDENXU-BootandLinuxGuide）文档http:

//www.denx.de/twiki/bin/view/DULG/Manual。

尤其是DULG文档，从如何安装建立交叉开发环境和解决U-Boot移植中常见问题都一一给出详尽的说明； 

③订阅U-Boot用户邮件列表 

④在建立的开发环境下进行移植工作。

绝大多数的开发环境是交叉开发环境。

在这方面，DENX和MontaVista均提供了完整的开发工具集； 

⑤在目标板与开发主机间接入硬件调试器。

这是进行U-Boot移植应当具备且非常关键的调试工具。

因为在整个U-Boot的移植工作中,尤其是初始阶段，硬件调试器是我们了解目标板真实运行状态的唯一途径。

在这方面，W.D本人和众多嵌入式开发人员倾向于使用BDI2000。

一方面，其价格不如ICE调试器昂贵，同时其可靠性高，功能强大，完全能胜任移植和调试U-Boot。

另外，网上也有不少关于BDI2000调试方面的参考文档。

⑥如果在参考开发板上移植U-Boot，可能需要移除目标板上已有的BOOTLOADER。

可以根据板上BOOTLOADER的说明文档，先着手解决在移除当前BOOTLOADER的情况下，如何进行恢复。

以便今后在需要场合能重新装入原先的BOOTLOADER。

6.U-Boot移植方法 

当前，对于U-Boot的移植方法，大致分为两种。

一种是先用BDI2000创建目标板初始运行环境，将U-Boot镜像文件u-boot.bin下载到目标板RAM中的指定位置，然后，用BDI2000进行跟踪调试。

其好处是不用将U-Boot镜像文件烧写到FLASH中去。

但弊端在于对移植开发人员的移植调试技能要求较高，BDI2000的配置文件较为复杂。

另外一种方法是用BDI2000先将U-Boot镜像文件烧写到FLASH中去，然后利用GDB和BDI2000进行调试。

这种方法所用BDI2000的配置文件较为简单，调试过程与U-Boot移植后运行过程相吻合，即U-Boot先从FLASH中运行，再重载至RAM中相应位置，并从那里正式投入运行。

唯一感到有些麻烦的就是需要不断烧写FLASH。

但考虑到FLASH常规擦写次数基本为10万次左右，作为移植U-Boot，不会占用太多的次数，应该不会为FLASH烧写有什么担忧。

同时，W.D本人也极力推荐使用后一种方法。

笔者建议，除非U-Boot移植资深人士或有强有力的技术支持，建议采用第二种移植方法。

7.U-Boot移植主要修改的文件 

从移植U-Boot最小要求－U-Boot能正常启动的角度出发，主要考虑修改如下文件：

①<目标板>.h头文件，如include/configs/RPXlite.h。

可以是U-Boot源码中已有的目标板头文件，也可以是新命名的配置头文件；大多数的寄存器参数都是在这一文件中设置完成的； 

②<目标板>.c文件，如board/RPXlite/RPXlite.c。

它是SDRAM的驱动程序，主要完成SDRAM的UPM表设置，上电初始化。

③FLASH的驱动程序，如board/RPXlite/flash.c，或common/cfi_flash.c。

可在参考已有FLASH驱动的基础上，结合目标板FLASH数据手册，进行适当修改； 

④串口驱动，如修改cpu/mpc8xx/serial.c串口收发器芯片使能部分。

8.U-Boot移植要点 

①BDI2000的配置文件。

如果采用第二种移植方法，即先烧入FLASH的方法，配置项只需很少几个，就可以进行U-Boot的烧写与调试了。

对PPC8xx系列的主板，可参考DULG文档中TQM8xx的配置文件进行相应的修改。

下面，笔者以美国EmbeddedPlanet公司的RPXliteDW板为例，给出在嵌入式Linux交叉开发环境下的BDI2000参考配置文件以作参考：

;bdiGDBconfigurationfileforRPXliteDWorLITE_DW 

;-------------------------------------------- 

[INIT] 

;initcoreregister 

WSPR1490x2002000F;DER:

setdebugenableregister 

;WSPR1490x2006000F;DER:

enableSYSIEforBDIflashprogram 

WSPR6380xFA200000;IMMR:

internalmemoryat0xFA200000 

WM320xFA2000040xFFFFFF89;SYPCR 

[TARGET] 

CPUCLOCK40000000;theCPUclockrateafterprocessingtheinitlist 

BDIMODEAGENT;theBDIworkingmode（LOADONLY|AGENT） 

BREAKMODEHARD;SOFTorHARD,HARDusesPPChardwarebreakpoints 

[HOST] 

IP173.60.120.5 

FILEuImage.litedw 

FORMATBIN 

LOADMANUAL;loadcodeMANUALorAUTOafterreset 

DEBUGPORT2001 

START0x0100 

[FLASH] 

CHIPTYPEAM29BX8;;Flashtype（AM29F|AM29BX8|AM29BX16|I28BX8|I28BX16） 

CHIPSIZE0x400000;;Thesizeofoneflashchipinbytes 

BUSWIDTH32;Thewidthoftheflashmemorybusinbits（8|16|32） 

WORKSPACE0xFA202000;RAMbufferforfastflashprogramming 

FILEu-boot.bin;Thefiletoprogram 

FORMATBIN0x00000000 

ERASE0x00000000BLOCK 

ERASE0x00008000BLOCK 

ERASE0x00010000BLOCK 

ERASE0x00018000BLOCK 

[REGS] 

DMM10xFA200000 

FILEreg823.def 

②U-Boot移植参考板。

这是进行U-Boot移植首先要明确的。

可以根据目标板上CPU、FLASH、SDRAM的情况，以尽可能相一致为原则，先找出一个与所移植目标板为同一个或同一系列处理器的U-Boot支持板为移植参考板。

如RPXliteDW板可选择U-Boot源码中RPXlite板作为U-Boot移植参考板。

对U-Boot移植新手，建议依照循序渐进的原则，目标板文件名暂时先用移植参考板的名称，在逐步熟悉U-Boot移植基础上，再考虑给目标板重新命名。

在实际移植过程中，可用Linux命令查找移植参考板的特定代码，如grep–rRPXlite./可确定出在U-Boot中与RPXlite板有关的代码，依此对照目标板实际进行屏蔽或修改。

同时应不局限于移植参考板中的代码，要广泛借鉴U-Boot中已有的代码更好地实现一些具体的功能。

③U-Boot烧写地址。

不同目标板，对U-Boot在FLASH中存放地址要求不尽相同。

事实上，这是由处理器中断复位向量来决定的，与主板硬件相关，对MPC8xx主板来讲，就是由硬件配置字（HRCW）决定的。

也就是说，U-Boot烧写具体位置是由硬件决定的，而不是程序设计来选择的。

程序中相应U-Boot起始地址必须与硬件所确定的硬件复位向量相吻合；如RPXliteDW板的中断复位向量设置为0x00000100。

因此，U-Boot的BIN镜像文件必须烧写到FLASH的起始位置。

事实上，大多数的PPC系列的处理器中断复位向量是0x00000100和0xfff00100。

这也是一般所说的高位启动和低位启动的BOOTLOADER所在位置。

可通过修改U-Boot源码<目标板>.h头文件中CFG_MONITOR_BASE和board/<目标板>/config.mk中的TEXT_BASE的设置来与硬件配置相对应。

④CPU寄存器参数设置。

根据处理器系列、类型不同，寄存器名称与作用有一定差别。

必须根据目标板的实际，进行合理配置。

一个较为可行和有效的方法，就是借鉴参考移植板的配置，再根据目标板实际，进行合理修改。

这是一个较费功夫和考验耐力的过程，需要仔细对照处理器各寄存器定义、参考设置、目标板实际作出选择并不断测试。

MPC8xx处理器较为关键的寄存器设置为SIUMCR、PLPRCR、SCCR、BRx、ORx。

⑤串口调试。

能从串口输出信息，即使是乱码，也可以说U-Boot移植取得了实质性突破。

依据笔者调试经历，串口是否有输出，除了与串口驱动相关外，还与FLASH相关的寄存器设置有关。

因为U-Boot是从FLASH中被引导启动的，如果FLASH设置不正确，U-Boot代码读取和执行就会出现一些问题。

因此，还需要就FLASH的相关寄存器设置进行一些参数调试。

同时，要注意串口收发芯片相关引脚工作波形。

依据笔者调试情况，如果串口无输出或出现乱码，一种可能就是该芯片损坏或工作不正常。

⑥与启动FLASH相关的寄存器BR0、OR0的参数设置。

应根据目标板FLASH的数据手册与BR0和OR0的相关位含义进行合理设置。

这不仅关系到FLASH能否正常工作，而且与串口调试有直接的关联。

⑦关于CPLD电路。

目标板上是否有CPLD电路丝毫不会影响U-Boot的移植与嵌入式操作系统的正常运行。

事实上，CPLD电路是一个集中将板上电路的一些逻辑关系可编程设置的一种实现方法。

其本身所起的作用就是实现一些目标板所需的脉冲信号和电路逻辑，其功能完全可以用一些逻辑电路与CPU口线来实现。

⑧SDRAM的驱动。

串口能输出以后，U-Boot移植是否顺利基本取决于SDRAM的驱动是否正确。

与串口调试相比，这部分工作更为核心，难度更大。

MPC8xx目标板SDRAM驱动涉及三部分。

一是相关寄存器的设置；二是UPM表；三是SDRAM上电初始化过程。

任何一部分有问题，都会影响U-Boot、嵌入式操作系统甚至应用程序的稳定、可靠运行。

所以说，SDRAM的驱动不仅关系到U-Boot本身能否正常运行，而且还与后续部分相关，是相当关键的部分。

⑨补充功能的添加。

在获得一个能工作的U-Boot后，就可以根据目标板和实际开发需要，添加一些其它功能支持。

如以太网、LCD、NVRAM等。

与串口和SDRAM调试相比，在已有基础之上，这些功能添加还是较为容易的。

大多只是在参考现有源码的基础上，进行一些修改和配置。

另外，如果在自主设计的主板上移植U-Boot，那么除了考虑上述软件因素以外，还需要排查目标板硬件可能存在的问题。

如原理设计、PCB布线、元件好坏。

在移植过程中，敏锐判断出故障态是硬件还是软件问题，往往是关系到项目进度甚至移植成败的关键，相应难度会增加许多。

下面以移植u-boot到44B0开发板的步骤为例，移植中上仅需要修改和硬件相关的部分。

在代码结构上：

1）在board目录下创建ev44b0ii目录，创建ev44b0ii.c以及flash.c,memsetup.S,u-boot.lds等。

不需要从零开始，可选择一个相似的目录，直接复制过来，修改文件名以及内容。

我在移植u-boot过程中，选择的是ep7312目录。

由于u-boot已经包含基于s3c24b0的开发板目录，作为参考，也可以复制相应的目录。

2）在cpu目录下创建arm7tdmi目录,主要包含start.S，interrupts.c以及cpu.c,serial.c几个文件。

同样不需要从零开始建立文件，直接从arm720t复制，然后修改相应内容。

3）在include/configs目录下添加ev44b0ii.h，在这里放上全局的宏定义等。

4）找到u-boot根目录下Makefile修改加入 

ev44b0ii_config:

unconfig 

@./mkconfig$（@:

_config=）armarm7tdmiev44b0ii 

5）运行makeev44bii_config,如果没有错误就可以开始硬件相关代码移植的工作 

3.u-boot的体系结构 

1）总体结构 

u-boot是一个层次式结构。

从上图也可以看出，做移植工作的软件人员应当提供串口驱动（UARTDriver）,以太网驱动（EthernetDriver）,Flash驱动（Flash驱动）,USB驱动（USBDriver）。

目前，通过USB口下载程序显得不是十分必要，所以暂时没有移植USB驱动。

驱动层之上是u-boot的应用，command通过串口提供人机界面。

我们可以使用一些命令做一些常用的工作，比如内存查看命令md。

Kermit应用主要用来支持使用串口通过超级终端下载应用程序。

TFTP则是通过网络方式来下载应用程序，例如uclinux操作系统。

2）内存分布 

在flashrom中内存分布图ev44b0ii的flash大小2M（8bits）,现在将0-40000共256k作为u-boot的存储空间。

由于u-boot中有一些环境变量，例如ip地址，引导文件名等，可在命令行通过setenv配置好,通过saveenv保存在40000-50000（共64k）这段空间里。

如果存在保存好的环境变量，u-boot引导将直接使用这些环境变量。

正如从代码分析中可以看到，我们会把flash引导代码搬移到DRAM中运行。

下图给出u-boot的代码在DRAM中的位置。

引导代码u-boot将从0x00000000处搬移到0x0C700000处。

特别注意的由于