搜档网
当前位置:搜档网 › UBoot移植详细教程

UBoot移植详细教程

UBoot移植详细教程
UBoot移植详细教程

u-boot 移植步骤详解(必会)

1 U-Boot简介

U-Boot,全称Universal Boot Loader,是遵循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软件工程中心Wolfgang Denk[以下简称W.D]本人精湛专业水平和持着不懈的努力。当前,U-Boot项目正在他的领军之下,众多有志于开放源码BOOT LOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入,以支持更多的嵌入式操作系统的装载与引导。

选择U-Boot的理由:

①开放源码;

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

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

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

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

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

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

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

2 U-Boot主要目录结构

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

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

- cpu 与处理器相关的文件。如mpc8xx子目录下含串口、网口、LCD驱动及中断初始化等文件;

- driver 通用设备驱动,如CFI FLASH驱动(目前对INTEL FLASH支持较好)

- doc U-Boot的说明文档;

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

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

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

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

- post 上电自检文件目录。尚有待于进一步完善;

- rtc RTC驱动程序;

- tools 用于创建U-Boot S-RECORD和BIN镜像文件的工具;

3 U-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,定义为“#define AMD_ID_LV320B 0x22F922F9”。

(3)、对于“./borad/at91rm9200dk/flash.c”的修改,有以下的方面:

“void flash_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.接下来,修改”#define FLASH_BANK_SIZE 0x200000”为自己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”里面的

“#define PHYS_SDRAM_SIZE 0X200000”就可以了。注意,SIZE是以字节为单位的。(8)、还有一个地方要注意

就是按照目前的设定,一级boot把u_boot加载到了SDRAM的空间为:21F00000 -> 21F16B10,这恰好是SDRAM的高端部分。另外,BSS为21F1AE34。

(9)、编译后,可以写入flash了。

a.压缩这个u-boot.bin

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

压缩后的文件大小为:

43Kbytes

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

Boot.bin大约11kBytes,在flash的0x1000 0000 ~ 0x1000 3fff

5 U-Boot移植过程

①获得发布的最新版本U-Boot源码,与Linux内核源码类似,也是bzip2的压缩格式。可从U-Boot的官方网站https://www.sodocs.net/doc/de17035749.html,/projects/U-Boot上获得;

②阅读相关文档,主要是U-Boot源码根目录下的README文档和U-Boot官方网站的

DULG(The DENX U-Boot and Linux Guide)文档

http://www.denx.de/twiki/bin/view/DULG/Manual。尤其是DULG文档,从如何安装建立交叉开发环境和解决U-Boot移植中常见问题都一一给出详尽的说明;

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

https://www.sodocs.net/doc/de17035749.html,/lists/listinfo/u-boot-users。在移植U-Boot过程中遇有问题,在参考相关文档和搜索U-Boot-User邮件档案库

https://www.sodocs.net/doc/de17035749.html,/mailarchive/forum.php?forum_id=12898仍不能解决的情况下,第一时间提交所遇到的这些问题,众多热心的U-Boot开发人员会乐于迅速排查问题,而且很有可能,W.D本人会直接参与指导;

④在建立的开发环境下进行移植工作。绝大多数的开发环境是交叉开发环境。在这方面,DENX 和MontaVista均提供了完整的开发工具集;

⑤在目标板与开发主机间接入硬件调试器。这是进行U-Boot移植应当具备且非常关键的调试工具。因为在整个U-Boot的移植工作中,尤其是初始阶段,硬件调试器是我们了解目标板真实运行状态的唯一途径。在这方面,W.D本人和众多嵌入式开发人员倾向于使用BDI2000。一方面,其价格不如ICE调试器昂贵,同时其可靠性高,功能强大,完全能胜任移植和调试U-Boot。另外,网上也有不少关于BDI2000调试方面的参考文档。

⑥如果在参考开发板上移植U-Boot,可能需要移除目标板上已有的BOOT LOADER。可以根据板上BOOT LOADER的说明文档,先着手解决在移除当前BOOT LOADER的情况下,如何进行恢复。以便今后在需要场合能重新装入原先的BOOT LOADER。

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的烧写与调试了。对PPC 8xx系列的主板,可参考DULG 文档中TQM8xx的配置文件进行相应的修改。下面,笔者以美国Embedded Planet公司的RPXlite DW板为例,给出在嵌入式Linux交叉开发环境下的BDI2000参考配置文件以作参考:

; bdiGDB configuration file for RPXlite DW or LITE_DW

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

[INIT]

; init core register

WSPR 149 0x2002000F ;DER : set debug enable register

; WSPR 149 0x2006000F ;DER : enable SYSIE for BDI flash program WSPR 638 0xFA200000 ;IMMR : internal memory at 0xFA200000

WM32 0xFA200004 0xFFFFFF89 ;SYPCR

[TARGET]

CPUCLOCK 40000000 ;the CPU clock rate after processing the init list BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT) BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoints [HOST]

IP 173.60.120.5

FILE uImage.litedw

FORMAT BIN

LOAD MANUAL ;load code MANUAL or AUTO after reset

DEBUGPORT 2001

START 0x0100

[FLASH]

CHIPTYPE AM29BX8 ;;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)

CHIPSIZE 0x400000 ;;The size of one flash chip in bytes

BUSWIDTH 32 ;The width of the flash memory bus in bits (8 | 16 | 32) WORKSPACE 0xFA202000 ; RAM buffer for fast flash programming

FILE u-boot.bin ;The file to program

FORMAT BIN 0x00000000

ERASE 0x00000000 BLOCK

ERASE 0x00008000 BLOCK

ERASE 0x00010000 BLOCK

ERASE 0x00018000 BLOCK

[REGS]

DMM1 0xFA200000

FILE reg823.def

②U-Boot移植参考板。这是进行U-Boot移植首先要明确的。可以根据目标板上CPU、FLASH、SDRAM的情况,以尽可能相一致为原则,先找出一个与所移植目标板为同一个或同一系列处理器的U-Boot支持板为移植参考板。如RPXlite DW板可选择U-Boot源码中RPXlite板作为U-Boot移植参考板。对U-Boot移植新手,建议依照循序渐进的原则,目标板文件名暂时先用移植参考板的名称,在逐步熟悉U-Boot移植基础上,再考虑给目标板重新命名。在实际移植过程中,可用Linux命令查找移植参考板的特定代码,如grep –r RPXlite ./ 可确定出在U-Boot中与RPXlite板有关的代码,依此对照目标板实际进行屏蔽或修改。同时应不局限于移植参考板中的代码,要广泛借鉴U-Boot 中已有的代码更好地实现一些具体的功能。

③U-Boot烧写地址。不同目标板,对U-Boot在FLASH中存放地址要求不尽相同。事实上,这是由处理器中断复位向量来决定的,与主板硬件相关,对MPC8xx主板来讲,就是由硬件配置字(HRCW)决定的。也就是说,U-Boot烧写具体位置是由硬件决定的,而不是程序设计来选择的。程序中相应U-Boot起始地址必须与硬件所确定的硬件复位向量相吻合;如RPXlite DW板的中断复位向量设置为0x00000100。因此,U-Boot 的BIN镜像文件必须烧写到FLASH的起始位置。事实上,大多数的PPC系列的处理器中断复位向量是0x00000100和0xfff00100。这也是一般所说的高位启动和低位启动的BOOT LOADER所在位置。可通过修改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=) arm arm7tdmi ev44b0ii

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

3. u-boot 的体系结构

1) 总体结构

u-boot 是一个层次式结构。从上图也可以看出,做移植工作的软件人员应当提供串口驱动(UART Driver),以太网驱动(Ethernet Driver),Flash 驱动(Flash 驱动),USB 驱动(USB Driver)。目前,通过USB 口下载程序显得不是十分必要,所以暂时没有移植USB 驱动。驱动层之上是u-boot 的应用,command 通过串口提供人机界面。我们可以使用一些命令做一些常用的工作,比如内存查看命令md。

Kermit 应用主要用来支持使用串口通过超级终端下载应用程序。TFTP 则是通过网络方式来下载应用程序,例如uclinux 操作系统。

2) 内存分布

在flash rom 中内存分布图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 将从0x0000 0000 处搬移到0x0C700000 处。特别注意的由于ev44b0ii uclinux 中断向量程序地址在0x0c00 0000 处,所以不能将程序下载到0x0c00 0000 出,通常下载到0x0c08 0000 处。

4. start.S 代码结构

1) 定义入口

一个可执行的Image 必须有一个入口点并且只能有一个唯一的全局入口,通常这个入口放在Rom(flash)的0x0 地址。例如start.S 中的

.globl _start

_start:

值得注意的是你必须告诉编译器知道这个入口,这个工作主要是修改连接器脚本文件(lds)。

2) 设置异常向量(Exception Vector)

异常向量表,也可称为中断向量表,必须是从0 地址开始,连续的存放。如下面的就包括了复位(reset),未定义处理(undef),软件中断(SWI),预去指令错误(Pabort),数据错误(Dabort),保留,以及IRQ,FIQ 等。注意这里的值必须与uclinux 的vector_base 一致。这就是说如果uclinux 中vector_base(include/armnommu/proc-armv/system.h)定义为0x0c00 0000,则HandleUndef 应该在

0x0c00 0004。

b reset //for debug

ldr pc,=HandleUndef

ldr pc,=HandleSWI

ldr pc,=HandlePabort

ldr pc,=HandleDabort

b .

ldr pc,=HandleIRQ

ldr pc,=HandleFIQ

ldr pc,=HandleEINT0 /*mGA H/W interrupt vector table*/

ldr pc,=HandleEINT1

ldr pc,=HandleEINT2

ldr pc,=HandleEINT3

ldr pc,=HandleEINT4567

ldr pc,=HandleTICK /*mGA*/

b .

b .

ldr pc,=HandleZDMA0 /*mGB*/

ldr pc,=HandleZDMA1

ldr pc,=HandleBDMA0

ldr pc,=HandleBDMA1

ldr pc,=HandleWDT

ldr pc,=HandleUERR01 /*mGB*/

b .

b .

ldr pc,=HandleTIMER0 /*mGC*/

ldr pc,=HandleTIMER1

ldr pc,=HandleTIMER2

ldr pc,=HandleTIMER3

ldr pc,=HandleTIMER4

ldr pc,=HandleTIMER5 /*mGC*/

b .

b .

ldr pc,=HandleURXD0 /*mGD*/

ldr pc,=HandleURXD1

ldr pc,=HandleIIC

ldr pc,=HandleSIO

ldr pc,=HandleUTXD0

ldr pc,=HandleUTXD1 /*mGD*/

b .

b .

ldr pc,=HandleRTC /*mGKA*/

b .

b .

b .

b .

b . /*mGKA*/

b .

b .

ldr pc,=HandleADC /*mGKB*/

b .

b .

b .

b .

b . /*mGKB*/

b .

b .

ldr pc,=EnterPWDN

作为对照:请看以上标记的值:

.equ HandleReset, 0xc000000

.equ HandleUndef,0xc000004

.equ HandleSWI, 0xc000008

.equ HandlePabort, 0xc00000c

.equ HandleDabort, 0xc000010

.equ HandleReserved, 0xc000014

.equ HandleIRQ, 0xc000018

.equ HandleFIQ, 0xc00001c

/*the value is different with an address you think it may be. *IntVectorTable */

.equ HandleADC, 0xc000020

.equ HandleRTC, 0xc000024

.equ HandleUTXD1, 0xc000028

.equ HandleUTXD0, 0xc00002c

.equ HandleSIO, 0xc000030

.equ HandleIIC, 0xc000034

.equ HandleURXD1, 0xc000038

.equ HandleURXD0, 0xc00003c

.equ HandleTIMER5, 0xc000040

.equ HandleTIMER4, 0xc000044

.equ HandleTIMER3, 0xc000048

.equ HandleTIMER2, 0xc00004c

.equ HandleTIMER1, 0xc000050

.equ HandleTIMER0, 0xc000054

.equ HandleUERR01, 0xc000058

.equ HandleWDT, 0xc00005c

.equ HandleBDMA1, 0xc000060

.equ HandleBDMA0, 0xc000064

.equ HandleZDMA1, 0xc000068

.equ HandleZDMA0, 0xc00006c

.equ HandleTICK, 0xc000070

.equ HandleEINT4567, 0xc000074

.equ HandleEINT3, 0xc000078

.equ HandleEINT2, 0xc00007c

.equ HandleEINT1, 0xc000080

.equ HandleEINT0, 0xc000084

3) 初始化CPU 相关的pll,clock,中断控制寄存器

依次为关闭watch dog timer,关闭中断,设置LockTime,PLL(phase lock loop),以及时钟。

这些值(除了LOCKTIME)都可从Samsung 44b0 的手册中查到。

ldr r0,WTCON //watch dog disable

ldr r1,=0x0

str r1,[r0]

ldr r0,INTMSK

ldr r1,MASKALL //all interrupt disable

str r1,[r0]

/*****************************************************

* Set clock control registers *

*****************************************************/

ldr r0,LOCKTIME

ldr r1,=800 // count = t_lock * Fin (t_lock=200us, Fin=4MHz) = 800

str r1,[r0]

ldr r0,PLLCON /*temporary setting of PLL*/

ldr r1,PLLCON_DAT /*Fin=10MHz,Fout=40MHz or 60MHz*/

str r1,[r0]

ldr r0,CLKCON

ldr r1,=0x7ff8 //All unit block CLK enable

str r1,[r0]

4) 初始化内存控制器

内存控制器,主要通过设置13 个从1c80000 开始的寄存器来设置,包括总线宽度,

8 个内存bank,bank 大小,sclk,以及两个bank mode。

/*****************************************************

* Set memory control registers *

*****************************************************/ memsetup:

adr r0,SMRDATA

ldmia r0,{r1-r13}

ldr r0,=0x01c80000 //BWSCON Address

stmia r0,{r1-r13}

5) 将rom 中的程序复制到RAM 中

首先利用PC 取得bootloader 在flash 的起始地址,再通过标号之差计算出这个程序代码的大小。这些标号,编译器会在连接(link)的时候生成正确的分布的值。取得正

确信息后,通过寄存器(r3 到r10)做为复制的中间媒介,将代码复制到RAM 中。

relocate:

/*

* relocate armboot to RAM

*/

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

ldr r2, _armboot_start

ldr r3, _armboot_end

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

ldr r1, _TEXT_BASE /* r1 <- destination address */

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

/*

* r0 = source address

* r1 = target address

* r2 = source end address

*/

copy_loop:

ldmia r0!, {r3-r10}

stmia r1!, {r3-r10}

cmp r0, r2

ble copy_loop

6) 初始化堆栈

进入各种模式设置相应模式的堆栈。

InitStacks:

/*Don't use DRAM,such as stmfd,ldmfd......

SVCstack is initialized before*/

mrs r0,cpsr

bic r0,r0,#0X1F

orr r1,r0,#0xDB /*UNDEFMODE|NOINT*/

msr cpsr,r1 /*UndefMode*/

ldr sp,UndefStack

orr r1,r0,#0XD7 /*ABORTMODE|NOINT*/

msr cpsr,r1 /*AbortMode*/

ldr sp,AbortStack

orr r1,r0,#0XD2 /*IRQMODE|NOINT*/

msr cpsr,r1 /*IRQMode*/

ldr sp,IRQStack

orr r1,r0,#0XD1 /*FIQMODE|NOINT*/

msr cpsr,r1 /*FIQMode*/

ldr sp,FIQStack

bic r0,r0,#0XDF /*MODEMASK|NOINT*/

orr r1,r0,#0X13

msr cpsr,r1 /*SVCMode*/

ldr sp,SVCStack

7) 转到RAM 中执行

使用指令ldr,pc,RAM 中C 函数地址就可以转到RAM 中去执行。

5. 系统初始化部分

1. 串口部分

串口的设置主要包括初始化串口部分,值得注意的串口的Baudrate 与时钟MCLK 有很大关系,是通过:rUBRDIV0=( (int)(MCLK/16./(gd ->baudrate) + 0.5) -1 )计算得出。这可以在手册中查到。其他的函数包括发送,接收。这个时候没有中断,是通过循环等待来判断是否动作完成。

例如,接收函数:

while(!(rUTRSTAT0 & 0x1)); //Receive data read

return RdURXH0();

2. 时钟部分

实现了延时函数udelay。

这里的get_timer 由于没有使用中断,是使用全局变量来累加的。

3. flash 部分

flash 作为内存的一部分,读肯定没有问题,关键是flash 的写部分。

Flash 的写必须先擦除,然后再写。

unsigned long flash_init (void)

{

int i;

u16 manId,devId;

//first we init it as unknown,even if you forget assign it below,it's not a problem for (i=0; i < CFG_MAX_FLASH_BANKS; ++i){

flash_info[i].flash_id = FLASH_UNKNOWN;

flash_info[i].sector_count=CFG_MAX_FLASH_SECT;

}

/*check manId,devId*/

_RESET();

_WR(0x555,0xaa);

_WR(0x2aa,0x55);

_WR(0x555,0x90);

manId=_RD(0x0);

_WR(0x555,0xaa);

_WR(0x2aa,0x55);

_WR(0x555,0x90);

devId=_RD(0x1);

_RESET();

printf("flashn");

printf("Manufacture ID=%4x(0x0004), Device

ID(0x22c4)=%4xn",manId,devId);

if(manId!=0x0004 && devId!=0x22c4){

printf("flash check faliluren");

return 0;

}else{

for (i=0; i < CFG_MAX_FLASH_BANKS; ++i){

flash_info[i].flash_id=FLASH_AM160T;/*In fact it is fujitu,I only don't want to modify common files*/

}

}

/* Setup offsets */

flash_get_offsets (CFG_FLASH_BASE, &flash_info[0]);

/* zhangyy comment

#if CFG_MONITOR_BASE >= CFG_FLASH_BASE

//onitor protection ON by default

flash_protect(FLAG_PROTECT_SET,

CFG_MONITOR_BASE,

CFG_MONITOR_BASE+monitor_flash_len-1,

&flash_info[0]);

#endif

*/

flash_info[0].size =PHYS_FLASH_SIZE;

return (PHYS_FLASH_SIZE);

}

flash_init 完成初始化部分,这里的主要目的是检验flash 的型号是否正确。

int flash_erase (flash_info_t *info, int s_first, int s_last)

{

volatile unsigned char *addr = (volatile unsigned char *)(info->start[0]);

int flag, prot, sect, l_sect;

//ulong start, now, last;

u32 targetAddr;

u32 targetSize;

/*zyy note:It is required and can't be omitted*/

rNCACHBE0=( (0x2000000>>12)<<16 )|(0>>12); //flash area(Bank0) must be non-cachable

area.

rSYSCFG=rSYSCFG & (~0x8); //write buffer has to be off for proper timing. if ((s_first < 0) || (s_first > s_last)) {

if (info->flash_id == FLASH_UNKNOWN) {

printf ("- missingn");

} else {

printf ("- no sectors to erasen");

}

return 1;

}

if ((info->flash_id == FLASH_UNKNOWN) ||

(info->flash_id > FLASH_AMD_COMP)) {

printf ("Can't erase unknown flash type - abortedn");

return 1;

}

prot = 0;

for (sect=s_first; sect<=s_last; ++sect) {

if (info->protect[sect]) {

prot++;

}

}

if (prot) {

printf ("- Warning: %d protected sectors will not be erased!n", prot);

} else {

printf ("n");

}

l_sect = -1;

/* Disable interrupts which might cause a timeout here */

flag = disable_interrupts();

/* Start erase on unprotected sectors */

for (sect = s_first; sect<=s_last; sect++) {

if (info->protect[sect] == 0) {/* not protected */

targetAddr=0x10000*sect;

if(targetAddr<0x1F0000)

targetSize=0x10000;

else if(targetAddr<0x1F8000)

targetSize=0x8000;

else if(targetAddr<0x1FC000)

targetSize=0x2000;

else

targetSize=0x4000;

F29LV160_EraseSector(targetAddr);

l_sect = sect;

if(!BlankCheck(targetAddr, targetSize))

printf("BlankCheck Errorn");

}

}

/* re-enable interrupts if necessary */

if (flag)

enable_interrupts();

/* wait at least 80us - let's wait 1 ms */

udelay (1000);

/*

*We wait for the last triggered sector

*/

if (l_sect < 0)

goto DONE;

DONE:

printf (" donen");

return 0;

}

int BlankCheck(int targetAddr,int targetSize)

{

int i,j;

for(i=0;i{

j=*((u16 *)(i+targetAddr));

if( j!=0xffff)

{

printf("E:%x=%xn",(i+targetAddr),j);

return 0;

}

}

return 1;

}

flash_erase 擦除flash,BlankCheck 则检查该部分内容是否擦除成功。

/*----------------------------------------------------------------------- *Write a word to Flash, returns:

* 0 - OK

* 1 - write timeout

* 2 - Flash not erased

*/

static int write_word (flash_info_t *info, ulong dest, ulong data)

{

volatile u16 *tempPt;

/*zhangyy note:because of compatiblity of function,I use low & hi*/

u16 low = data & 0xffff;

u16 high = (data >> 16) & 0xffff;

low=swap_16(low);

high=swap_16(high);

tempPt=(volatile u16 *)dest;

_WR(0x555,0xaa);

_WR(0x2aa,0x55);

_WR(0x555,0xa0);

*tempPt=high;

_WAIT();

_WR(0x555,0xaa);

_WR(0x2aa,0x55);

_WR(0x555,0xa0);

*(tempPt+1)=low;

_WAIT();

return 0;

}

wirte_word 则想flash 里面写入unsigned long 类型的data,因为flash 一次只能写入16bits,所以这里分两次写入。

Tiny6410_Uboot移植步骤详解

Uboot_for_Tiny6410_移植步骤详解 一、设计要求 1.目的 1)掌握U-boot剪裁编写 2)掌握交叉编译环境的配置 3)掌握U-boot的移植 2.实现的功能 1)U-boot编译成功 2)移植U-boot,使系统支持从NAND FLASH启动 二、设计方案 1.硬件资源 1)ARM处理器:ARM11芯片(Samsung S3C6410A),基于ARM1176JZF-S核设 计,运行频率533Mhz,最高可达 667Mhz 2)存储器:128M DDR RAM,可升级至 256M;MLC NAND Flash(2GB) 3)其他资源:具有三LCD接口、4线电阻 触摸屏接口、100M标准网络接口、标准DB9 五线串口、Mini USB2.0接口、USB Host 1.1、3.5mm音频输入输出口、标准TV-OUT

接口、SD卡座、红外接收等常用接口;另外 还引出4路TTL串口,另1路TV-OUT、 SDIO2接口(可接SD WiFi)接口等;在板的 还有蜂鸣器、I2C-EEPROM、备份电池、A D 可调电阻、8个中断式按键等。 2.软件资源 1)arm-linux-gcc-4.5.1(交叉编译) 2)u-boot-2010.09.tar.gz arm-linux-gcc-4.5.1-v6-vfp-20101103.t gz 三、移植过程 1.环境搭建 1)建立交叉编译环境 2)去这2个网站随便下载都可以下载得到最 新或者你想要的u-boot。( https://www.sodocs.net/doc/de17035749.html,/batch.viewl ink.php?itemid=1694 ftp://ftp.denx.de/pub/u-boot/ )

UBoot移植详解

u-boot 移植步骤详解 1 U-Boot简介 U-Boot,全称Universal Boot Loader,是遵循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软件工程中心Wolfgang Denk[以下简称W.D]本人精湛专业水平和持着不懈的努力。当前,U-Boot项目正在他的领军之下,众多有志于开放源码BOOT LOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入,以支持更多的嵌入式操作系统的装载与引导。 选择U-Boot的理由: ①开放源码; ②支持多种嵌入式操作系统内核,如Linux、NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS; ③支持多个处理器系列,如PowerPC、ARM、x86、MIPS、XScale; ④较高的可靠性和稳定性; ④较高的可靠性和稳定性; ⑤高度灵活的功能设置,适合U-Boot调试、操作系统不同引导要求、产品发布等; ⑥丰富的设备驱动源码,如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等; ⑦较为丰富的开发调试文档与强大的网络技术支持; 2 U-Boot主要目录结构 - board 目标板相关文件,主要包含SDRAM、FLASH驱动; - common 独立于处理器体系结构的通用代码,如内存大小探测与故障检测;

i.MX6UL -- Linux系统移植过程详解(最新的长期支持版本)

i.MX6UL -- Linux系统移植过程详解(最新的长期支持版本) ?开发平台:i.MX 6UL ?最新系统: u-boot2015.04 + Linux4.1.15_1.2.0 ?交叉编译工具:dchip-linaro-toolchain.tar.bz2 源码下载地址: U-Boot: (选择rel_imx_4.1.15_1.2.0_ga.tar.bz2) https://www.sodocs.net/doc/de17035749.html,/git/cgit.cgi/imx/uboot-imx.git/ Kernel: (选择rel_imx_4.1.15_1.2.0_ga.tar.bz2) https://www.sodocs.net/doc/de17035749.html,/git/cgit.cgi/imx/linux-2.6-imx.git/ 源码移植过程: 1、将linux内核及uBoot源码拷贝到Ubuntu12.04系统中的dchip_imx6ul目录下; 2、使用tar命令分别将uboot和kernel解压到dchip_imx6ul目录下; 3、解压后进入uboot目录下,新建文件make_dchip_imx6ul_uboot201504.sh,且文件内容如下: ################################################################### # Build U-Boot.2015.04 For D518--i.MX6UL By FRESXC # ################################################################### #!/bin/bash export ARCH=arm export CROSS_COMPILE=/dchip-linaro-toolchain/bin/arm-none-linux-gnueabi - make mrproper # means CLEAN make mx6ul_14x14_evk_defconfig make2>&1|tee built_dchip_imx6ul_uboot201504.out 4进入kernel目录下,新建文件make_dchip_imx6ul_linux4115120.sh,且文件内容如下: ###################################################################

uboot移植步骤介绍

uboot移植过程 1.修改Makefile 首先给要建立的S3C2410开发板取名为TE2410, 移植uboot时以smdk2410为模板, 修改Makefile #tar xvjf u-boot-1.1.3.tar.bz2 #cd u-boot-1.1.3 #vi Makefile scb9328_config : unconfig @./mkconfig $(@:_config=) arm arm920t scb9328 NULL imx smdk2400_config : unconfig @./mkconfig $(@:_config=) arm arm920t smdk2400 NULL s3c24x0 smdk2410_config : unconfig @./mkconfig $(@:_config=) arm arm920t smdk2410 NULL s3c24x0 SX1_config : unconfig @./mkconfig $(@:_config=) arm arm925t sx1 te2410_config : unconfig @./mkconfig $(@:_config=) arm arm920t te2410 NULL s3c24x0 蓝色字体是添加的内容。其中,te2410_config : unconfig意思是为TE2410建立一个编译项,@./mkconfig $(@:_config=) arm arm920t te2410 NULL s3c24x0中的arm表示CPU的架构是基于ARM体系结构的;arm920t表示CPU类型是arm920t;te2410是开发板的型号;NULL表示开发商或经销商的名称为空;s3c24x0表示是基于s3c24x0的片上系统。 2.在uboot的board目录下建立te2410开发板子目录 #cp –fr board/smdk2410 /board/te2410 #cd board/te2410 #mv smdk2410.c te2410.c 还要修改board/te2410/Makefile文件, OBJS := smdk2410.o flash.o -------- OBJS := te2410.o flash.o 3.在include/configs目录下建立te2410.h头文件 #cd include/configs #cp –fr smdk2410.h te2410.h 4.指定交叉编译器的路径 选择支持softfloatpoint的交叉编译器,在etc/bashrc文件中添加一行 export PATH=/home/newdisk/toolchain/gcc-3.4.5-glibc-2.3.6/arm-softfloat-linu x-gnu/bin:$PATH 其中, /home/newdisk/toolchain/gcc-3.4.5-glibc-2.3.6/arm-softfloat-linux-gnu /bin是交叉编译器路径

uboot移植实验

一、移植环境 ?主机:UBUNTU ?开发板:飞凌2440 ?编译器:arm-linux-gcc-4.3.2.tgz ?u-boot:u-boot-2009.03.tar.bz2

3)修改u-boot根目录下的Makefile文件。查找到smdk2410_config的地方,在他下面按照smdk2410_config的格式建立mini2440_config的编译选项,另外还要指定交叉编译器 4)测试编译新建的mini2440开发板项目

到此为止,u-boot对自己的mini2440开发板还没有任何用处,以上的移植只是搭建了一个mini2440开发板u-boot的框架,要使其功能实现,还要根据mini2440开发板的具体资源情况来对u-boot源码进行修改。 3. 根据u-boot启动流程图的步骤来分析或者修改添加u-boot源码,使之适合mini2440开发板(注:修改或添加的地方都用红色表示)。 1)mini2440开发板u-boot的stage1入口点分析。 一般在嵌入式系统软件开发中,在所有源码文件编译完成之后,链接器要读取一个链接分配文件,在该文件中定义了程序的入口点,代码段、数据段等分配情况等。那么我们的my2440开发板u-boot的这个链接文件就是cpu/arm920t/u-boot.lds,打开该文件部分代码如下:

知道了程序的入口点是_start,那么我们就打开mini2440开发板u-boot第一个要运行的程序cpu/arm920t/start.S(即u-boot的stage1部分),查找到_start的位置如下: 从这个汇编代码可以看到程序又跳转到start_code处开始执行,那么再查找到start_code 处的代码如下:

嵌入式Linux之我行 史上最牛最详细的uboot移植,不看别后悔

嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解(一) 嵌入式Linux之我行,主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验,二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处,谢请指正。 ?共享资源,欢迎转载:https://www.sodocs.net/doc/de17035749.html, 一、移植环境 ?主机:VMWare--Fedora 9 ?开发板:Mini2440--64MB Nand,Kernel:2.6.30.4 ?编译器:arm-linux-gcc-4.3.2.tgz ?u-boot:u-boot-2009.08.tar.bz2 二、移植步骤 本次移植的功能特点包括: ?支持Nand Flash读写 ?支持从Nor/Nand Flash启动 ?支持CS8900或者DM9000网卡 ?支持Yaffs文件系统 ?支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程,如下图。

u-boot的stage1代码通常放在cpu/xxxx/start.S文件中,他用汇编语言写成;u-boot的stage2代码通常放在lib_xxxx/board.c文件中,他用C语言写成。各个部分的流程图如下:

2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持,可以查看board目录的一些子目录,如:board/samsung/目录下就是对三星一些ARM 处理器的支持,有smdk2400、smdk2410和smdk6400,但没有2440,所以我们就在这里建立自己的开发板项目。 1)因2440和2410的资源差不多,主频和外设有点差别,所以我们就在board/samsung/下建立自己开发板的项目,取名叫my2440 2)因2440和2410的资源差不多,所以就以2410项目的代码作为模板,以后再修改

uboot移植笔记

u-boot-2015-01移植笔记 一、修改编译器路径 修改顶层Makefile文件,查找CROSS_COMPILE =,注释掉if判断,增加一行CROSS_CMPILE = arm-linux- (根据编译器不同这个自行添加,在这里感谢胡茂晓同学)。 二、复制平台相近board 1、进入board子目录下的samsung子目录,复制trats2文件夹为自己平台名字的文件夹(这里笔者使用iTop4412)。 2、进入iTop4412子目录,修改为。 3、修改Makefile,将trats2改为iTop4412。 三、修改板子相应配置 1、从源码根目录下进入include/configs目录,复制为。 2、从源码根目录下进入configs目录,复制trats2_defconfig为iTop4412_defconfig。 3、修改iTop4412_defconfig,将CONFIG_DEFAULT_DEVICE_TREE="exynos4412-trats2"改为CONFIG_DEFAULT_DEVICE_TREE="exynos4412-iTop4412"。

四、增加自己的Device Tree Source 1、从源码根目录下进入arch/arm/Dts目录,复制 exynos4412- 。 2、修改当前目录下的Makefile文件,将 dtb-$(CONFIG_EXYNOS4) += \ \ \ \ \ 修改成 dtb-$(CONFIG_EXYNOS4) += \ \ \ \ \ \

五、制作顶层.config文件 1、在源码根目录下使用命令make menuconfig(貌似刚支持图形界面配置)。 2、先配置基本的,Architecture select 选项选择ARM architecture,architecture选项的子选项Target select选择Samsun EXYNOS;EXYNOS board select选项选择Exynos4412 Trat2 board。 3、在Device Tree Control选项下,y(yes)Run-time configuration via Device Tree,选择Provider of DTB for control 为Embedded DTB for DT control,在Default Device Tree for DT control选项下输入exynos4412-iTop4412,退出。 4、保存退出,在源码根目录下会生成.config文件,需要用命令ls –a 查看。 5、在源码根目录下使用命令vim .config,修改.config文件。将CONFIG_SYS_BOARD="trats2" 修改成CONFIG_SYS_BOARD="iTop4412";将CONFIG_SYS_CONFIG_NAME="trats2"修改成CONFIG_SYS_CONFIG_NAME="iTop4412";将CONFIG_DEFAULT_DEVICE_TREE=""修改成CONFIG_DEFAULT_DEVICE_TREE="exynos4412-iTop4412"。(注意:每次使用make menuconfig后都要修改本条)

UBOOT分析移植

ARM 平台下的U-boot 移植 u-boot 移植 嵌入式BootLoader 的引导过程 图 1-1给出了嵌入式系统中的一般的引导过程,一般来说,引导程序都是保存在非易失的存储介质(如Flash 等)中,因为引导程序运行的时候需要对数据进行读写操作,所以引导程序的RW 段必须放到RAM 中,所以一般的引导程序初始化的第一件事情就是要在初始化完内存控制器后将其RW 段拷贝到RAM 中,同时开辟一段内存用于其ZI 段。如果引导过程是放置在不可原位执行的存储介质,如NAND Flash 上的时候,引导程序还必须将其自身也拷贝到RAM 中。 一般来说大概的步骤可以分为两个步骤: Stage1 ? 硬件设备初始化(内存控制器的设置); ? 为加载BootLoader 的stage2部分的代码准备RAM 空间; ? 拷贝BootLoader 的stage2部分的代码到RAM 空间中,并跳转执行; ? 设置好堆栈,Heap 等; ? 跳转到 stage2 的 C 入口点; Stage2 ? 初始化本阶段要使用到的硬件设备(net ,flash 等); ? 将OS 映像从 flash 上读到 RAM 空间中; ? 为OS 设置启动参数; ? 跳转到OS 内核image 的入口点。 图1-1 嵌入式系统引导

u-boot简介 U-Boot是由开源项目PPCBoot发展起来的,ARMboot并入了PPCBoot,和其他一些arch 的Loader合称U-Boot。2002年12月17日第一个版本U-Boot-0.2.0发布,同时PPCBoot 和ARMboot停止维护。 U-Boot支持的处理器构架包括PowerPC(MPC5xx, MPC8xx, MPC82xx, MPC7xx,MPC74xx, 4xx), ARM(ARM7,ARM9,StrongARM,Xscale),MIPS (4Kc,5Kc),x86等等,U-Boot (Universal Bootloader)是在GPL下资源代码最完整的一个通用Boot Loader。 U-Boot提供两种操作模式:启动加载(Boot loading)模式和下载(Downloading)模式,并具有大型Boot Loader的全部功能。主要特性为: ●SCC/FEC以太网支持 ●BOOTP/TFTP引导 ●IP,MAC预置功能 ●在线读写FLASH,DOC, IDE,IIC,EEROM,RTC ●支持串行口kermit,S-record下载代码 ●识别二进制、ELF32、pImage格式的Image,对Linux引导有特别的支持 ●监控(minitor)命令集:读写I/O,内存,寄存器、内存、外设测试功能等 ●脚本语言支持(类似BASH脚本) ●支持WatchDog,LCD logo,状态指示功能等 U-Boot的功能是如此之强大,涵盖了绝大部分处理器构架,提供大量外设驱动,支持多个文件系统,附带调试、脚本、引导等工具,特别支持Linux,为板级移植做了大量的工作。U-Boot的完整功能性和后续不断的支持,使系统的升级维护变得十分方便。 u-boot的目录树结构 1.1.1 Borad目录 包括大量的Board dependent files的代码文件,每一个开发板都以一个子目录出现在当前目录中,每个board目录下至少包括这样几个文件 1.config.mk:其中至少包括TEXT_BASE这个一个Makefile的变量,这个变量指出了被编译的可执行uboot image应该放在RAM中的位置,也就是该image的执行位置;2.flash.c:这里主要还是对NorFlash的操作,flash的基本操作; 3.lowlevel_init.S:提供lowlevel_init函数供u-boot在第一阶段调用,一般是针对SDRAM 控制器的初始化,如设置SDRAM的刷新率,等待时钟等,一般来说,如果需要将第二阶段代码和数据拷贝到SDRAM中,这个操作是必须的; 4.Makefile:编译board目录下的代码所使用的makefile; 5.board.c:和板级相关的初始化函数,如设置GPIO,设置时钟,设置总线时序等;6.u-boot.lds:针对开发板的情况编写的连接脚本,通过连接脚本,一般应该将u-boot的stage1的代码放在image的开始的地方; 1.1.2Common目录 该目录下实现uboot支持的命令和公用函数,每一条命令都对应一个文件。例如bootm 命令对应就是cmd_bootm.c。

Uboot_for_mini6410_移植步骤详解

这是u-boot-2010.09 针对友善之臂MINI6410移植的最基础版本,只包含了就基本的系统引导,NAND读写,DM9000网卡等等。但是这个足够开发的方便使用。今后会陆续添加原先我为mini2440添加的所有功能。 但是此次移植并非我的功劳,首先基本的移植是由Alex Ling 完成的,你可以在这里看到他提交的补丁,但是编译后无法使用,可能是因为host系统不同,对脚本的解析不同,使得spl部分的生成出现问题,只需修改一下nand_spl目录下目标板目录的中config.mk中的 PAD_TO := $(shell expr $$[$(TEXT_BASE) + 4096]) 即可。 DM9000的驱动没有太大的问题(修改了一点可能出现问题的地方,感谢肖工指教),但是原本的u-boot并没有调整所有SROM控制器的配置(其中包括连接DM9000所使用的bank1的总线),我使用了友善带的u-boot的参数配置了一下就好了。 一:https://www.sodocs.net/doc/de17035749.html,/batch.viewlink.php?itemid=1694 ftp://ftp.denx.de/pub/u-boot/ 去这2个网站随便下载都可以下载得到最新或者你想要的u-boot。现在我将下载u-boot-2010-09,这个也就是最新的版本啦。 下载后把它解压,然后得到u-boot-2010-09的文件夹,然后进去,并且做下面几件事情:1:进入arch这个文件夹,把出arm外的前部文件夹删掉 2:进入board这个文件夹,把除samsung外前部文件夹删掉 3:进入include/configs,把除smdk6400.h外的所有文件删除。 4: 把顶层目录下有一个叫onenand_ipl的文件夹删除掉,因为没有用到。 5:进入nand_spl/board,把除samsung外全部文件删除掉。 6:再进入arch/arm/cpu文件夹,把除arm1176外其他文件夹删除掉。 7:再进入arch/arm/include/asm文件夹,把除arch-s3c64xx文件外带arch-XX的文件夹删除8:再进入board/samsung文价夹下,把除smdk6400外其他文价夹删除掉。 至此已经把没用到或者不想见到它的文件夹跟文件删除掉了。爽吧。 二: 1:在顶层的目录下找到Makefile文件,并且打开,因为vi或者vim没用习惯而是改用gedit。lwf@lwf-desktop:/home/u-boot-2010.12$ sudo gedit Makefile 在这个Makefile你会找到: ######################################################################### ## ARM1176 Systems ######################################################################### smdk6400_noUSB_config \ smdk6400_config : unconfig @mkdir -p $(obj)include $(obj)board/samsung/smdk6400 @mkdir -p $(obj)nand_spl/board/samsung/smdk6400

黄刚--uboot在mini2440上的移植

u-boot-2009.08在2440上的移植详解(黄刚) u-boot-2009.08在2440上的移植详解(一) 嵌入式Linux之我行,主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验,二希望能给想入门嵌入式Linux的朋友提供方便。如有错误之处,谢请指正。 共享资源,欢迎转载: 一、移植环境 主机:VMWare--Fedora 9 开发板:Mini2440--64MB Nand, 编译器: u-boot: 二、移植步骤 本次移植的功能特点包括: 支持Nand Flash读写 支持从Nor/Nand Flash启动 支持CS8900或者DM9000网卡 支持Yaffs文件系统 支持USB下载(还未实现) 1. 了解u-boot主要的目录结构和启动流程,如下图。

u-boot的stage1代码通常放在cpu/xxxx/start.S文件中,他用汇编语言写成; u-boot的stage2代码通常放在lib_xxxx/board.c文件中,他用C语言写成。 各个部分的流程图如下:

2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持,可以查看board目录的一些子目录,如:board/samsung/目录下就是对三星一些ARM处理器的支持,有smdk2400、smdk2410和smdk6400,但没有2440,所以我们就在这里建立自己的开发板项目。 1)因2440和2410的资源差不多,主频和外设有点差别,所以我们就在board/samsung/下建立自己开发板的项目,取名叫my2440 #tar -jxvf u-boot-2009.08.tar.bz2 //解压源码

最新Uboot移植步骤 5:NorFlash

最新Uboot移植步骤5:NorFlash 显示Flash:***failed***,说明norflash未识别,我们搜索“Flash:” 进入第一个查看 找到这个判断条件,如果flash_size>0则输出flash大小,否则输出 *** failed *** ### ERROR ### Please RESET the board ###

其中hang函数导致程序无法继续向下执行,我们只实现了nand启动肯定在这会卡住,所以我们不用这个hang 函数,直接输出flash未识别的信息就好了,改动如下: 现在来找norflash未识别的原因,进入flash_init函数 看见这样一段代码 可知,有2个函数可以检测flash的大小如果flash_detect_legacy函数不行再使用flash_get_size函数,先进入flash_detect_legacy函数看下,其结构如下: 该函数有2个,使用哪一个由宏CONFIG_FLASH_CFI_LEGACY决定,搜索该宏:

很明显,前面我们都是使用该函数进行大小检测的,而该函数无法识别flash,那我们使用新方法进行检测,进入新方法查看: 发现有很多可用调试信息,我们看看如何起用这些调试信息: 发现只要定义了_DEBUG即可启用调试信息,我们定义该宏: 在文件开始发现注释: 我们直接定义DEBUG即可,

配置,编译,下载到板子norflash: 重新上电从norflash启动,输出如下: 我们查看JEDEC PROBE:从哪来

查看norflash手册,看读取的设备ID是否正确 可以看到输出的厂家设备ID是正确的, 说明下面这个函数读取正确 那就是 函数出现错误,我们进入该函数查看:

uboot-1.1.4DM9000移植过程(成功)

作者:lgj 时间:2010年5月9日 实验内容:把移植到mini2440的uboot-1.1.4的网卡驱动由CS8900改为DM9000 Uboot原来就有DM9000的驱动代码,只要把头文件定义为选择DM9000,修改初始化函数就行了。 步骤: 1.DM9000的片选是nCS4,所以它接到SDRAM的Blank4。之前看了网上一些资料,说要修改board/utu2440/lowlevel_init.S文件,其实不用修改保持原来那样就行了。 #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) #define REFCNT 1113 2.修改/include/configs/xx2440.h文件,这里定义了使用哪个网卡 /* * Hardware drivers屏蔽CS8900 */ #if 0 #define CONFIG_DRIVER_CS8900 1 /* we have a CS8900 on-board */ #define CS8900_BASE 0x19000300 #define CS8900_BUS16 1 /* the Linux driver does accesses as shorts */ #endif 定义DM9000 #define CONFIG_DRIVER_DM9000 1 #define CONFIG_DM9000_BASE 0x20000000 #define DM9000_IO CONFIG_DM9000_BASE #define DM9000_DATA (CONFIG_DM9000_BASE+4) #define CONFIG_DM9000_USE_16BIT 网上很多资料说要改成0x20000300但是我的板是0x20000000 3.修改dm9000x.c

Uboot启动流程分析和移植介绍

基于MPC83xx 的U-boot 启动流程分析和移植 董 闯 北京邮电大学信息与通信工程学院,北京(100876) E-mail :donix.dong@https://www.sodocs.net/doc/de17035749.html, 摘 要:本文首先引入Bootloader 的概念,接着介绍U-boot 这种引导程序,并以Freescale 32位微处理器MPC83xx 为例,结合代码详细分析了U-boot 的启动的各个阶段及最终引导Linux 内核的过程,最后,建立交叉编译环境,针对TC8313E 目标板,给出U-boot 移植与编译的基本步骤。 关键词:U-boot;MPC83xx;交叉编译;移植;嵌入式系统 中图分类号:TP393.05 1.引言 引导程序(Bootloader)是系统加电后运行的第一段软件代码,类似于PC 机中的引导加载程序BIOS 。虽然引导程序仅在系统启动时运行非常短的时间,但对于嵌入式系统来说,这是一个非常重要的组成部分。通过这段小程序,初始化必要的硬件设备,创建内核需要的一些信息并将这些信息传递给内核,从而将系统的软、硬件环境配置到一个合适的状态,最终调用操作系统内核,真正起到引导和加载内核的作用。 2. U-boot 介绍 目前,嵌入式领域里出现了很多种类的Bootloader ,如Armboot 、Blob 、Redboot 、vivi 和U-boot 等,其中U-boot 是使用最广泛,功能最完善的。 U-boot (Universal Boot Loader)是从PPCBOOT 发展演化而来[1] ,其源码目录、编译形式与Linux 内核很相似,事实上,不少U-boot 源码就是相应的Linux 内核源程序的简化,尤其是一些设备的驱动程序,这从U-boot 源码的注释中就能体现。U-boot 中Universal 有两层含义,一是U-boot 除了支持PowerPC 系列的处理器外,还能支持MIPS 、x86、ARM 、NIOS 、XScale 等诸多常用系列的处理器;另外一层含义则是U-boot 不仅仅支持嵌入式Linux 操作系统的引导,还支持OpenBSD, NetBSD, FreeBSD, SVR4, Solaris, VxWorks, LynxOS, pSOS, lrix, RTEMS, QNX, ARTOS 等操作系统的引导。这两个特点正是U-boot 项目的开发目标,即支持尽可能多的嵌入式处理器和嵌入式操作系统。就目前来看,U-boot 对PowerPC 系列处理器支持最为丰富,对Linux 的支持最完善。 3. U-boot 启动流程分析 大多数Bootloader 都分为阶段1(stage1)和阶段2(stage2)两大部分,U-boot 也不例外。依赖于CPU 体系结构的代码(如CPU 初始化代码等)通常都放在阶段1 中,这些代码一般由汇编语言实现,有些CPU 还会在这个阶段调用部分的C 函数,例如MPC83xx ;U-boot 的阶段2则用于实现复杂的功能,这部分功能通常用C 语言来实现,具有更好的可读性和移植性。下面结合MPC83xx 的启动流程进行分析: 3.1 U-boot 的stage1 https://www.sodocs.net/doc/de17035749.html, 中国科技论文在线

uboot移植整理

1.Make 编译uboot出错: …… …… board.c:138: error: inline function 'coloured_LED_init' cannot be declared weak board.c:140: error: inline function 'red_LED_on' cannot be declared weak board.c:142: error: inline function 'red_LED_off' cannot be declared weak board.c:144: error: inline function 'green_LED_on' cannot be declared weak board.c:146: error: inline function 'green_LED_off' cannot be declared weak board.c:148: error: inline function 'yellow_LED_on' cannot be declared weak board.c:150: error: inline function 'yellow_LED_off' cannot be declared weak make[1]: *** [board.o] 错误1 make[1]:正在离开目录`/opt/u-boot-1.3.4/lib_arm' make: *** [lib_arm/libarm.a] 错误2 开始编译的时候会出现上面的错误,继续移植操作这个错误将消失。或者注释掉出错行。 ****挂载文件系统时候的错误:************ …… …… TCP cubic registered NET: Registered protocol family 17 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or unknown-block(2,0) Please append a correct "root=" boot option; here are the available partitions: 1f00 16 mtdblock0 (driver?) 1f01 2048 mtdblock1 (driver?) 1f02 4096 mtdblock2 (driver?) 1f03 2048 mtdblock3 (driver?) 1f04 4096 mtdblock4 (driver?) 1f05 10240 mtdblock5 (driver?) 1f06 24576 mtdblock6 (driver?) 1f07 16384 mtdblock7 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) [] (unwind_backtrace+0x0/0xf0) from [] (panic+0x54/0x17c) 解决方法:保证传入的命令行参数正确无误,保证NFS配置成功,rootfs正确,可以重启机器试试。 错误:error: common/libcommon.a(main.o) uses FPA instructions, whereas u-boot does not /opt/opt/FriendlyARM/toolschain/4.4.3/bin/.arm-none-linux-gnueabi-ld: failed to merge target specific data of file common/libcommon.a(main.o)

的linuuboot移植

嵌入式Linux之我行——在2440上的移植详解(一) 嵌入式Linux之我行,主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验,二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处,谢请指正。 共享资源,欢迎转载: 一、移植环境 主机:VMWare--Fedora 9 开发板:Mini2440--64MB Nand, 编译器: u-boot:二、移植步骤 本次移植的功能特点包括: 支持Nand Flash读写 支持从Nor/Nand Flash启动 支持CS8900或者DM9000网卡 支持Yaffs文件系统 支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程,如下图。

u-boot的stage1代码通常放在cpu/xxxx/文件中,他用汇编语言写成; u-boot的stage2代码通常放在lib_xxxx/文件中,他用C语言写成。各个部分的流程图如下:

2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持,可以查看board目录的一些子目录,如:board/samsung/目录下就是对三星一些ARM处理器的支持,有smdk2400、smdk2410和smdk6400,但没有2440,所以我们就在这里建立自己的开发板项目。 1)因2440和2410的资源差不多,主频和外设有点差别,所以我们就在board/samsung/下建立自己开发板的项目,取名叫my2440 #tar -jxvf /../../

根据u-boot启动流程图的步骤来分析或者修改添加u-boot源码,使之适合my2440开发板(注:修改或添加的地方都用红色表示)。 1)my2440开发板u-boot的stage1入口点分析。 一般在嵌入式系统软件开发中,在所有源码文件编译完成之后,链接器要读取一个链接分配文件,在该文件中定义了程序的入口点,代码段、数据段等分配情况等。那么我们的my2440开发板u-boot的这个链接文件就是cpu/arm920t/,打开该文件部分代码如下:

UBOOT移植验

U-BOOT移植实验 u-boot简介 u-boot是德国DENX小组的开发用于多种嵌入式CPU的bootloader程序, u-boot不仅仅支持嵌入式Linux系统的引导,当前,它还支持NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS嵌入式操作系统。u-boot除了支持PowerPC系列的处理器外,还能支持MIPS、 x86、ARM、NIOS、XScale等诸多常用系列的处理器。 u-boot源码目录介绍 u-boot的启动过程 1 启动流程 我们一般把bootloader都分为阶段1(stage1)和阶段2(stage2)两大部分,依赖于CPU体系结构的代码(如CPU初始化代码等)通常都放在阶段1中且通常用汇编语言实现,而阶段2则通常用C语言来实现,这样可以实现复杂的功能,而且有更好的可读性和移植性。 1 阶段1,汇编代码,对于s3c2410是cpu/arm920t/start.s文件。 主要流程如下:

关闭看门狗 禁掉所有中断 设置以CPU的频率 把自己拷贝到RAM 配置内存区控制寄存器 配置的栈空间 进入C代码部分 2 阶段2是C语言代码,在lib_arm/board.c中的start_armboot是C语言开始的函数,也是整个启动代码中C语言的主函数。这个函数调用一系列的初始化函数,然后进入主UBOOT命令行,进入命令循环(即整个boot的工作循环),接受用户从串口输入的命令,然后进行相应的工作。 当用户输入启动linux的命令的时候,u-boot会将kernel 映像(zImage)和从nand flash 上读到RAM 空间中,为内核设置启动参数,调用内核,从而启动linux。 u-boot移植要点: 我们可以总结出bootloader的两大功能: 1 是下载功能,既通过网口、串口或者USB口下载文件到RAM中。 2 是对flash芯片的读写功能。 u-boot对S3C2410已经有了很好的支持,我们在移植过程中主要是完善u-boot对nand flash的读写功能。 u-boot移植前的准备工作: 1 下载源码,建立工作目录 Uboot的源码可以从以下网址下载: https://www.sodocs.net/doc/de17035749.html,/u-boot/u-boot-1.1.4.tar.bz2?modtime=1134752480&big_m irror=0 我们这里下载的是u-boot-1.1.4.tar.bz2 建立工作目录: mkdir /root/build_uboot cd /root/build_uboot 把下载的源码拷贝到该目录,解压; tar jxvf u-boot-1.1.4.tar.bz2 mv u-boot-1.1.4 u-boot

相关主题