经过上一篇系统移植之uboot源代码简要分析(1)对uboo进行分析后,我们知道BootLoader的第二阶段启动(BL2)从start_armboot处开始执行,start_armboot函数定义在“lib_arm/board.c”中
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
int mmc_exist = 0;
...
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) /*返回值必须为0,否则初始化失败,系统初始化终止*/
{
hang ();
}
}
init_fnc_t **init_fnc_ptr是一个二级指针,指向的内容为以下的数组init_sequence,该数组存储的是各类初始化函数的地址,start_armboot通过
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr)
循环逐个调用init_sequence数组中的初始化函数,完成对系统的初始化。
init_fnc_t *init_sequence[] = {
cpu_init, /* basic cpu dependent setup */
#if defined(CONFIG_SKIP_RELOCATE_UBOOT)
reloc_init, /* Set the relocation done flag, must
do this AFTER cpu_init(), but as soon
as possible */
#endif
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 */
#if defined(CONFIG_DISPLAY_CPUINFO)
print_cpuinfo, /* display cpu info (and speed) */
#endif
#if defined(CONFIG_DISPLAY_BOARDINFO)
checkboard, /* display board info */
#endif
#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
init_func_i2c,
#endif
dram_init, /* configure available RAM banks */
display_dram_config,
NULL,
};
另外,我们在start_armboot函数中可以见到很多个“gd_t”类型,该类型是定义于“include/asm-arm/globle_data.h”,是uboot的全局变量类型,
typedef struct global_data {
bd_t *bd;
unsigned long flags;
unsigned long baudrate;
...
void **jt; /* jump table */
} gd_t;
在include/asm-arm/globle_data.h的最后,我们发现一段比较难懂的C语句
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
这句话的意思是指定R8保存变量gd的地址,并声明该值是volatile(易变的),然后用“DECLARE_GLOBAL_DATA_PTR”表示它。
在gd_t类型结构体中,我们需要重点关注“bd_t”这个类型结构体(开发板信息结构体),它与我们的移植的关联很大。这个结构体定义在“include/asm-arm/uboot.h”中↓
typedef struct bd_info {
int bi_baudrate; /* serial console baudrate (串口控制台波特率)*/
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet adress */
struct environment_s *bi_env;
ulong bi_arch_number; /* unique id for this board (机器码,即开发板ID,当且仅当ID在内核中存在且正确时候,才可进行启动)*/
ulong bi_boot_params; /* where this board expects params uboot传递给内核的参数的地址*/
struct /* RAM configuration DRAM的起始地址和大小*/
{
ulong start;
ulong size;
}bi_dram[CONFIG_NR_DRAM_BANKS];
/*CONFIG_NR_DRAM_BANKS是允许的DRAM的数量*/
#ifdef CONFIG_HAS_ETH1
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#endif
} bd_t;/*开发板信息结构体*/
回到start_armboot函数
经过for循环调用各个初始化函数完成基础硬件的初始化,以及SOC的其他初始化(此处不累赘,对我们理解uboot启动流程没有太大影响)之后,程序进入”main_loop()”
main_loop函数定义于:common/main.c
/* main_loop() can return to retry autoboot, if so just run it again. */
for (;;) {
main_loop ();
}
main_loop的执行流程:
我们知道BootLoader有两种启动流程
1. 启动加载(boot loading)模式:
常用于已发布的产品上,整个过程不需要用户介入。
2. 下载(downloading)模式:
开发人员可以使用各种命令,通过串口连接或者网络连接等通信手段从主机(host)下载文件。常用协议:x/y/z modem协议、TFTP、nfs协议、USB。
进入main_loop后,执行流程如上图main_loop的执行流程所示。
函数首先读取环境参数bootdelay和bootcmd,然后判断bootdelay秒内串口是否有输入,
1>有输入,进入downloading模式
2>无输入,进入boot loading模式,启动加载内核;
~(启动内核–>是通过环变量bootcmd中存放的内核相关启动命令来启动内核的,这些命令有以下一些:
print(printenv):打印环境变量;
set(setenv):设置环境变量
saveenv:保存环境变量;
tftp:通过TFTP服务下载TFTP服务器目录下的文件到内存中
go:执行内存中的二进制代码
bootm:启动内存中的内核镜像文件zImage
…
)
那么这些内核启动命令是如何定义的呢?↓
内核启动命令定义于“include/command.h”中,类型定义方式如下
/* uboot命令结构体 */
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)简单使用信息 */
#ifdef CFG_LONGHELP
char *help; /* Help message (long)详细帮助信息 */
#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
};
/*将uboot命令结构体声明为cmd_tbl_t*/
typedef struct cmd_tbl_s cmd_tbl_t;
好,接下来我们分析启动命令具体是如何定义的
/*
* Command Flags:
*/
#define CMD_FLAG_REPEAT 0x0001 /*repeat last command */
#define CMD_FLAG_BOOTD 0x0002 /* command is from bootd */
/*
*1.这段宏定义具体意思:如果Struct_Section没被使用(unused),则
*将Struct_Section连接到启动命令段(".u_boot_cmd")中
**.u_boot_cmd定义于链接脚本uboot.lds中*
*/
#define Struct_Section __attribute__ ((unused,section (".u_boot_cmd")))
#ifdef CFG_LONGHELP /*如果定义了详细帮助信息*/
/*
*2.定义一个带参宏U_BOOT_CMD,表示后面的定义
*2.1)"##"连接符号,表示将__u_boot_cmd和name连接成为__u_boot_cmd_name
*2.2)Struct_Section 将“__u_boot_cmd_name”到“.u_boot_cmd”启动代码段
*/
#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}
/**/
#else /* no long help info 没有详细帮助信息 */
#define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \
cmd_tbl_t __u_boot_cmd_##name Struct_Section = {#name, maxargs, rep, cmd, usage}
#endif /* CFG_LONGHELP */
到”common/command.c”中可以查看具体定义了哪些命令。
我们再来看看“bootm”命令具体是如何启动内存中的内核镜像文件zImage的。
bootm命令定义在“common/cmd_bootm.c”
因为uboot是通用型BootLoader,可知uboot可以支持多种操作系统的启动,因此bootm命令需要根据具体操作系统分支执行,
switch (os) {
default: /* handled by (original) Linux case */
case IH_OS_LINUX:
#ifdef CONFIG_SILENT_CONSOLE
fixup_silent_linux();
#endif
do_bootm_linux (cmdtp, flag, argc, argv, &images);
break;
...
#ifdef CONFIG_ARTOS
case IH_OS_ARTOS:
do_bootm_artos (cmdtp, flag, argc, argv, &images);
break;
#endif
}
我们使用是操作系统为Linux,选择分支为“IH_OS_LINUX”,接下来调用“do_bootm_linux (cmdtp, flag, argc, argv, &images);”进行启动。
do_bootm_linux函数定义于lib_arm/bootm.c 中
void do_bootm_linux (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
bootm_headers_t *images)
{
ulong initrd_start, initrd_end;
ulong ep = 0;
bd_t *bd = gd->bd;
char *s;
int machid = bd->bi_arch_number; /*获取机器ID*/
void (*theKernel)(int zero, int arch, uint params);
int ret;
...
cleanup_before_linux ();
/*
*将参数:0,机器ID,uboot传递给内核的参数的地址
*传递thekernel函数,进而启动内核。
*/
theKernel (0, machid, bd->bi_boot_params);
/*
*至此,uboot的全部工作完成,接下来由内核接管系统。
*/
/* does not return */
return;
error:
do_reset (cmdtp, flag, argc, argv);
return;
}
系统移植之uboot源代码简要分析如上,与各位道嵌友交流,若有谬误还望指教,谢谢!