u-boot分析与使用

Posted 今天 天气真好

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了u-boot分析与使用相关的知识,希望对你有一定的参考价值。

文章目录

一、u-boot介绍

u-boot即通用的BootLoader,是遵循GPL条款的开放源代码项目。“通用”有两层含义:可以引导多种操作系统支持多种架构的CPU。他支持如下操作系统:Linux、VxWorks等,支持如下架构的CPU:PowerPC、MIPS、ARM、x86等。

u-boot有如下特性:
1.开放源码
2.支持多种嵌入式操作系统内核
3.支持多个处理器架构
4.丰富的设备驱动源码,如串口、以太网、sdram、flash等
5.支持NFS挂载,从flash中引导压缩或非压缩系统内核
6.上电自检功能

二、u-boot源码结构

u-boot版本情况:
网站:http://ftp.denx.de/pub/u-boot/

1、版本号变化:
2008年8月及以前按版本号命名:u-boot-1.3.4.tar.bz2(2008年8月更新)
2008年8月以后均按日期命名:u-boot-2011.06.tar.bz2(2011年6月更新)

2、目录结构变化:
u-boot目录结构主要经历过2次变化,u-boot版本第一次从u-boot-1.3.2开始发生变化,主要增加了api的内容;变化最大的是第二次,从2010.6版本开始。

u-boot-2010.03及以前版本
├── api 存放uboot提供的接口函数
├── board 根据不同开发板定制的代码,代码也不少
├── common 通用的代码,涵盖各个方面,已命令行处理为主
├── cpu 与体系结构相关的代码,uboot的重头戏
├── disk 磁盘分区相关代码
├── doc 文档,一堆README开头的文件
├── drivers 驱动,很丰富,每种类型的设备驱动占用一个子目录
├── examples 示例程序
├── fs 文件系统,支持嵌入式开发板常见的文件系统
├── include 头文件,已通用的头文件为主
├── lib_【arch】 与体系结构相关的通用库文件
├── nand_spl NAND存储器相关代码
├── net 网络相关代码,小型的协议栈
├── onenand_ipl
├── post 加电自检程序
└── tools 辅助程序,用于编译和检查uboot目标文件

从u-boot-2010.06版本开始把体系结构相关的内容合并,原先的cpu与lib_arch内容全部纳入arch中,并且其中增加inlcude文件夹;分离出通用库文件lib。

u-boot-2010.06及以后版本
├── api 存放uboot提供的接口函数
├── arch 与体系结构相关的代码,uboot的重头戏
├── board 根据不同开发板定制的代码,代码也不少
├── common 通用的代码,涵盖各个方面,已命令行处理为主
├── disk 磁盘分区相关代码
├── doc 文档,一堆README开头的文件
├── drivers 驱动,很丰富,每种类型的设备驱动占用一个子目录
├── examples 示例程序
├── fs 文件系统,支持嵌入式开发板常见的文件系统
├── include 头文件,已通用的头文件为主
├── lib 通用库文件
├── nand_spl NAND存储器相关代码
├── net 网络相关代码,小型的协议栈
├── onenand_ipl
├── post 加电自检程序
└── tools 辅助程序,用于编译和检查uboot目标文件

三、u-boot打补丁、编译、烧写

补丁主要是对源码进行修改的地方(patch),发布的时候只需要将补丁给别人即可。

以u-boot-1.1.6为例进行说明

先安装一下交叉编译工具如下:

1.对源码包进行解压缩
tar xjf u-boot-1.1.6.tar.bz2

2.打补丁
所谓的补丁其实就是我们在源码包上做了什么修改,把他单独列出来单独做成一个补丁,最后发布的时候把这个补丁给别人就行了

我们打开补丁文件可以看到:
–表示原来的代码,++表示修改后的代码
因此进行打补丁操作:
patch -p1 < …/u-boot-1.1.6_jz2440.patch

3.配置
因为会有很多单板,所以需要进行配置,使用命令make 100ask24x0_config,至于为什么后面再说。

4.编译
直接执行make命令,编译好之后会生出一个u-boot.bin,如下是编译成功之后的:

将u-boot.bin烧写到开发板启动,倒数计时之前按下空格键进入uboot

这里说一下几个常用的命令:
help:查看有哪些命令
?命令:查看命令怎么用
print:查看环境变量
setenv:设置环境变量
saveenv:保存
reset:重启

嵌入式系统:pc上电-->BootLoader-->引导Linux内核-->挂载根文件系统-->应用程序
BootLoader有很多种,现在使用的是uboot,最终目的是启动内核

对于Windows。Bios是从硬盘(C盘。D盘)上读入内核
对于Linux,启动内核是首先从flash上读出内核放到SDRAM上。然后才是启动内核
flash上的内容从哪里来?网络下载或者usb下载,因此uboot也要支持网卡或者usb,可以看到uboot源码目录下有一个driver目录
里面就是有支持nand,网卡,usb等驱动程序

因此uboot要实现的功能:
1.可以读flash。同样也可以加入写flsah功能,网卡,usb功能(为了开发方便)
2.要初始化SDRAM:还要初始化时钟,初始化串口等等…
3.启动内核

因此总结最后的uboot功能:
1.硬件(单板)相关的初始化
关看门狗,初始化时钟,初始化SDRAM
2.从flash上读出内核
3.启动内核
最后为了开发方便往往加入一些功能:如读写flash,网卡,usb,串口等

总的来说uboot就是一个单片机程序

四、uboot功能、结构,结合Makefile进行分析

为什么要先配置再make编译?
因为在uboot里面就有说明,也就是在README里面

1.分析配置过程 make 100ask24x0_config
可以看到: make 100ask24x0_config的时候相当于执行下面的命令

再搜索一下MKCONFIG,可以看到:

SRCTREE:source tree源文件目录下有一个mkconfig,可以发现我们前面编译成功之后会生成一个mkconfig

而$(@:_config=)的作用是将100ask24x0_config后面的config去掉,也就是说最终执行的命令是:
./mkconfig 100ask24x0 arm arm920t 100ask24x0 NULL s3c24x0

然后分析mkconfig文件的作用:
(1)确定开发板的名称BOARD_NAME,

在Linux脚本里面。可以下面符号进行表示

./mkconfig 100ask24x0 arm arm920t 100ask24x0 NULL s3c24x0
    $0       $1       $2   $3       $4        $5     $6

因此上面的意思就是BOARD_NAME = “100ask24x0”

(2)创建到平台/开发板相关的头文件的链接

先判断源代码目录与目标文件目录是否一致,不满足的时候指向else分支,先进去include目录,删除asm文件(这是上一次配置时建立的链接文件),然后再次建立asm文件,并将它链接向asm-$2(即asm-arm)目录。

再往下看如下:

第六项不为空,则执行ln -s arch-S3c24x0 asm-asm/arch

(3)创建顶层Makefile包含的文件include/config.mk

echo用于打印操作,>表示新建一个文件,>>表示把内容追加进去

即会生成一个配置文件config.mk,显示config.mk内容为:
ARCH:arm
CPU:arm920t
BOARD:100ask24x0
SOC:s3c24x0

(4)常见创建单板相关的头文件include/config.h
里面的内容就是:
#include <configs/100ask24x0.h>

显然100ask24x0.h这就是我们的配置文件,在这里面我们要去配置支持什么东西,比如是否支持某些命令

以上就是我们分析mkconfig文件的过程

总结配置具体做了什么:
1.确定board_name = $1
2.创建到平台/开发板相关头文件的链接 asm-arm
3.创建顶层Makefile包含的文件include/config.mk
4.创建开发板相关的头文件include/config.h

2.分析编译过程:直接执行make
继续分析Makefile

包含上面配置生成的include/config.mk,其中定义了ARCH CPU BOARD VENDOR SOC等变量的值

指定交叉编译工具链:arm-linux-

包含顶层目录的config.mk文件

然后看到:

cpu就是arm920t 即OBJS = cpu/arm920t/start.o,这是OBJS的第一个值

为了方便直接分析,不分析Makefile的话,可以直接执行make命令,在make命令的最后面就是相关的链接命令
可以看到链接的时候用到了链接脚本u-boot.lds以及代码段的基地址33F80000,然后准备start.o原材料以及库,最后输出u-boot,如下:

基地址33F80000:uboot运行的时候应该位于33F80000这里

原材料怎么组织成一个u-boot? ---->分析链接脚本
目录:board/100ask24x0/u-boot.lds,内容如下:

看到第35行,cpu/arm920t/start.o被放在程序的最前面,所以u-boot的入口点就在cpu/arm920t/start.s

分析uboot就是从start.s入手就可以知道uboot的流程是什么

综上:分析Makefile可以发现:
1.第一个文件:cpu/arm920t/start.s
2.链接地址:board/100ask24x0/u-boot.lds以及一个33F80000(512k)这个地址(-Ttest) 最终是在基地址(0)+0x33F80000这里开始运行

TEXT_BASE在board/100ask24x0/config.mk中定义:

uboot太大的话超过512k的话是可以修改TEXT_BASE

总结一下u-boot的编译流程
(1)首先编译cpu/arm920t/start.o,对于不同的cpu还有可能编译cpu/$(cpu)下的其他文件
(2)对平台/开发板相关的每个目录、每个通用目录都是用他们各自的Makefile生成相应的库
(3)将1.2步骤生成的.o和,a文件按照board/100ask24x0/config.mk文件中指定的代码段起始地址、board/100ask24x0/u-boot.lds链接脚本进行链接
(4)第三步得到的是elf格式的u-boot,后面Makefile会将它转换为二进制格式、srec格式

五、u-boot分析之源码阶段

1.start.s
(1)设置为svc管理模式 b reset
(2)关闭看门狗
(3)屏蔽所有的中断,也就是关中断

(4)初始化SDRAM
cpu相关的初始化 cpu_init_crit
条件是当前代码的地址(如果是nand的话就是0,如果是通过仿真器直接下载到SDRAM里面去的话就是他的链接地址33f80000)与TEXT_BASE(33f80000)不相等的话,也就是
说明SDRAM还没有初始化,则执行cpu_init_crit
在cpu_init_crit里面:
1.先清cache
2.关mmu
3.lowlevel_init 初始化存储控制器,经过这个初始化之后我们的内存才可以使用

(5)设置栈 调用C函数的话就必须设置栈,所谓设置栈也就是将sp指向某块内存
(6)初始化时钟
(7)重定位relocate 把代码从flash里面读到SDRAM里面的链接地址去
(8)清bss段 bss:未初始化的或者初始化为0的静态变量或者全局变量,既然都为0,那么就没必要保存在程序里面了,免得浪费空间

(9)调用c函数start_armboot 更复杂的功能就在这里实现

以上都是硬件初始化。针对的是2440,可能换了一款单板或者换了一款CPU就不相同,但是总体上还是一样的,功能相似。所有以上就是uboot的第一阶段

第二阶段就是从start_armboot实现

(1)初始化本阶段要使用到的硬件设备
最主要的是设置系统时钟、初始化串口,因为需要从串口来看打印信息
board/100ask24x0/100ask24x0.c

board_init函数改变时钟,同时还保存了机器类型ID,这在调用内核的时候会传递给内核。

串口相关的初始化在cpu/arm920t/s3c24x0/serial.c中实现

(2)检测系统内存映射
同样在board/100ask24x0/100ask24x0.c中

第一个即指定开发板的起始地址为0x30000000,大小为0x40000000。

(3)u-boot命令的格式
内核的启动时通过命令来实现额,u-boot中每个命令都是通过U_BOOT_CMD宏来定义。
在include/command.h中定义,格式如下:

#define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \\
cmd_tbl_t __u_boot_cmd_##name Struct_Section = #name, maxargs, rep, cmd, usage, help

具体参数函数在后面讲解

对于我们的u-boot:最终目的是启动内核
1.从flash上读出内核
因此要满足flash读写功能
2.启动内核

分析lib_arm/board.c文件下的start_armboot函数:

void start_armboot (void)

		mem_malloc_init (_armboot_start - CFG_MALLOC_LEN);
		nand_init();		/* go init the NAND */
		env_relocate():环境变量初始化  uboot下可以使用print打印环境变量

bootcmd就是自动启动时执行的命令
bootdelay就是执行自动启动的等待秒数

环境变量从哪里来?
对于环境变量,可以是默认写死的,也可以是从flash上保存中读到
这样uboot启动的时候会先去flash上看看有没有可用的环境变量,如果有的话就使用flash上的环境变量,没有的话就使用默认的

start_armboot–>flash_init, nand_init -->env_relocate -->main_loop(放在一个死循环里面),这也就是为什么我们在uboot界面输入命令,然后解析,然后输出;然后再输入

在main_loop中有一个很重要的语句:
s = getenv(“bootcmd”)去获取环境变量; 可以使用print来查看bootcmd
bootcmd=nand read.jffs2 0x33007Fc0 kernel: bootm 0x33007Fc0

里面涉及到两条命令
1.从nand flash上面把内核读到0x33007Fc0这个内存里面来:nand read.jffs2 0x33007Fc0 kernel kernel是一个分区
2.启动的时候就从0x33007Fc0这里开始启动:bootm 0x33007Fc0

如果倒数计时到0的时候没按下空格就会执行run_command(s,0);意思就是去执行bootcmd命令,也就是启动内核
如果按下了空格,后面就会进入一个死循环,主要是uboot控制界面,用来解析读取用户按下的数据,会有一个去读串口信息的函数readline,然后运行run_command

因此不管是按下还是不按下,最终执行的函数都是run_command()
因此uboot的核心就是这些命令:run_command,分析这些命令的实现才可以知道内核的启动流程

六、u-boot分析之命令实现

程序根据输入的命令字符串(name)找到对应的函数(func)进行执行

uboot中肯定会有一个命令结构体name,func,run_conmand根据名字在结构体(cmd_tbl_s)中进行查找匹配,匹配的话就会调用命令对应的函数

struct cmd_tbl_s 
	char		*name;		/* Command Name			*/名字
	int		maxargs;	/* maximum number of arguments	*/最大有多少个参数
	int		repeatable;	/* autorepeat allowed?		*/是否可重复:也就是再次回车是不是还能执行上一次的命令
					/* Implementation function	*/
	int		(*cmd)(struct cmd_tbl_s *, int, int, char *[]);处理函数
	char		*usage;		/* Usage message	(short)	*/短的帮助信息  比如执行help
#ifdef	CFG_LONGHELP
	char		*help;		/* Help  message	(long)	*/长的帮助信息  比如help某个命令
#endif
#ifdef CONFIG_AUTO_COMPLETE
	/* do auto completion on the arguments */
	int		(*complete)(int argc, char *argv[], char last_char, int maxv, char *cmdv[]);
#endif
;

argc = parse_line()提取参数解析命令
如:md.w 0
argv[0] = “md.w” 命令
argv[1] = “0” 参数

七、uboot启动内核

启动也就是怎么通过bootcmd的两条命令来读出内核,启动内核

两条命令如下:
(1)nand read.jffs2 0X30007FC0 kernel:从nand上读内核(从kernel分区读)到0X30007FC0这个地址
分区:
在pc上每一个硬盘前面都有一个分区表
但是对于嵌入式Linux来说,flash上没有分区表,但是为什么又会分为boot区,环境变量区(也就是uboot的那些参数),kernel区,根文件系统(root)区?
因为这是在源码里面写死的(在配置文件100ask24x0.h),注意关心的不是分区的名字,而是这些分区的起始地址和大小

#define MTDPARTS_DEFAULT "mtdparts=nandflash0:256k@0(bootloader)," \\  从0开始的256k是BootLoader
                            "128k(params)," \\						  接下来的128K是环境变量
                            "2m(kernel)," \\			                  接下来的2M是kernel
                            "-(root)"		                          剩下的是root

可以在uboot下使用mtb命令来进行查看分区

至于说为什么用jffs2,因为这样可以使得后面的长度不需要页对齐

对于flash上存的内核,称为UImage,而UImage就是一个头部加上真正的内核
头部:

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;

关心的是load和ep

(2)bootm 0X30007FC0:从0X30007FC0这个地址启动;对应do_bootm()这个函数,所做的工作:

(1)读出头部,移动内核到加载地址(合适的地方)
bootm会先去读出他的头部(头部为64字节),得到他的加载地址和入口地址。memmove (&header, (char *)addr, sizeof(image_header_t));
如果发现当前内核不是位于他的加载地址的话,就会把这个内核移动到这个加载地址。
最后跳到入口地址去执行。memmove ((void *) ntohl(hdr->ih_load), (uchar *)data, len); data就是内核真正所在的地址

(2)启动;即do_bootm_linux()函数,所做的工作:
1.uboot告诉内核一些启动参数------>设置启动参数
在某个地址(与内核约定好)按照某种格式保存数据,内核起来之后就去这个地址读取数据
这里的格式就是TAG,地址对于开发板来说是0X30000100
以下进行举例说明:
setup_start_tag (bd);
setup_memory_tags (bd);
setup_commandline_tag (bd, commandline);
setup_end_tag (bd);

char *commandline = getenv (“bootargs”);
对于bootargs:是传递给内核的启动参数,存放在commandline字符串中
print boorargs:根文件系统位于第4个flash分区,第一个应用程序(init)是谁,内核打印信息(console)从哪里打印出来

2.跳到入口地址启动内核:
theKernel = (void (*)(int, int, uint))ntohl(hdr->ih_ep);头部会指向一个入口地址
theKernel (0, bd->bi_arch_number, bd->bi_boot_params);
第一个参数:0
第二个参数:机器ID 看支不支持这个单板
第三个参数:参数的起始地址,即0X30000100

输入boot命令实际上就是执行bootcmd的命令,启动内核

以上是关于u-boot分析与使用的主要内容,如果未能解决你的问题,请参考以下文章

u-boot分析与使用

u-boot分析与使用

u-boot下延时程序失效的bug调试

u-boot

linux4.10.8 内核移植---环境搭建及适配单板。

u-bootmakefile