11_Uboot启动流程_3

目录

run_main_loop函数详解

cli_loop函数详解

cmd_process函数详解 

---

run_main_loop函数详解

uboot启动以后会进入3秒倒计时,如果在3秒倒计时结束之前按下按下回车键,那么就,会进入uboot的命令模式,如果倒计时结束以后都没有按下回车键,那么就会自动启动Linux内核,这个功能就是由run_main_loop函数来完成的。run_main_loop函数定义在文件common/board r.c中,函数内容如下:

第759行和第760行是个死循环, "for(;;)”和"while(1)”功能一样,死循环里面就一个main_loop 函数,main_loop函数定义在文件common/main.c 里面,代码如下: 

 第48行,调用bootstage_mark_name函数,打印出启动进度。第57行,如果定义了宏CONFIG_VERSION-VARIABLE的话就会执行函数setenv,设置换将变量ver的值为version_string,也就是设置版本号环境变量。version_string定义在文件cmd/version.c 中,定义如下:

 const char_weak version_string[] = U_BOOT_VERSION_STRING;

 U_BOOT_VERSION_STRING是个宏,定义在文件include/version.h,如下:

#define U_BOOT_VERSION_STRING U_BOOT_VERSION"(" U_BOOT_DATE "-"VU BOOT TIME""U BOOT TZ")" CONFIG IDENT STRING 

U_BOOT_VERSION定义在文件include/generated/version_autogenerated.h中,文件version_autogenerated.h 内如如下: 

 可以看出,U_BOOT_VERSION 为“U-boot 2016.03”,U_BOOT_DATE、U_BOOT TIME和

U_BOOT_TZ这定义在文件include/generated/timestamp_autogenerated.h中,如下所示:

宏CONFIG_IDENT_STRING为空,所以U_BOOT_VERSION_STRING为“U-Boot 2016.03(Apr 25 2019-21:10:53 +0800)",进入uboot命令模式,输入命令“version"查看版本号,如图所示: 

图中的第一行就是uboot版本号,和我们分析的一致。

接着回到示例代码32.2.9.2中,第60行,cli_init函数,跟命令初始化有关,初始化hushshell相关的变量。

第62行, run_preboot_environment_command函数,获取环境变量perboot的内容, perboot是一些预启动命令,一般不使用这个环境变量。

第68行, bootdelay_process函数,此函数会读取环境变量bootdelay和bootemd的内容,然后将bootdelay的值赋值给全局变量stored_bootdelay,返回值为环境变量bootemd的值。

第69行,如果定义了CONFIG_OF_CONTROL的话函数cli_process_fdt就会实现,如果没有定义CONFIG_OF_CONTROL的话函数cli_process_fdt直接返回一个false。在本uboot中没有定义CONFIG_OF_CONTROL,因此cli_process_fdt函数返回值为false。

第72行, autoboot_command函数,此函数就是检查倒计时是否结束?倒计时结束之前有没有被打断？此函数定义在文件common/autoboot.c中,内容如下:

 可以看出, autoboot_command函数里面有很多条件编译,条件编译一多就不利于我们阅读程序(所以正点原子的例程基本是不用条件编译的,就是为了方便大家阅读源码)宏CONFIG _AUTOBOOT_KEYED、CONFIG_AUTOBOOT_KEYED_CTRLC和CONFIG_MENUKEY这三个宏在I.MX6ULL里面没有定义,所以讲示例代码32.2.9.5进行精简,得到如下代码:

当一下三条全部成立的话,就会执行函数run_command_list。

1.stored_bootdelay不等于-1。

2.s不为空。

3.函数abortboot返回值为0。

stored_bootdelay等于环境变量bootdelay的值: s是环境变量bootemd的值,一般不为空,因此前两个成立,就剩下了函数abortboot的返回值, abortboot函数也定义在文件common/autoboot.c中,内容如下:

 因为宏CONFIG_AUTOBOOT_KEYE未定义,因此执行函数abortboot_normal,好吧,绕来绕去的!接着来看函数abortboot_normal,此函数也定义在文件common/autoboot.c中,内容如下:

 函数abortboot-normal同样很多条件编译,删除掉条件编译相关代码后abortboot_normal函数内容如下:

第3行的变量abort是函数abortboot normal的返回值,默认值为0。

第7行通过串口输出"Hit any key to stop autoboot"字样,如图所示:

 第9-21行就是倒计时的具体实现。

第14行判断键盘是否有按下,也就是是否打断了倒计时,如果键盘按下的话就执行相应的分支。比如设置abort为1,设置bootdelay为0等,最后跳出倒计时循环。

第26行,返回abort的值,如果倒计时自然结束,没有被打断abort就为0,否则的话abort的值就为1。

回到示例代码32.2.9.6的autoboot_command函数中,如果倒计时自然结束那么就执行函数run_command_list,此函数会执行参数s指定的一系列命令,也就是环境变量bootemd的命令,bootemd里面保存着默认的启动命令,因此linux内核启动!这个就是uboot中倒计时结束以后自动启动linux内核的原理。如果倒计时结束之前按下了键盘上的按键,那么run_command_list函数就不会执行,相当于autoboot_command是个空函数。

回到“遥远”的示例代码32.2.9.2中的main_loop函数中,如果倒计时结束之前按下按键,那么就会执行第74行的cli_loop函数,这个就是命令处理函数,负责接收好处理输入的命令。

cli_loop函数详解

cli_loop函数是uboot的命令行处理函数,我们在uboot中输入各种命令,进行各种操作就是有cli_loop来处理的,此函数定义在文件common/cli.c中,函数内容如下:

 在文件include/configs/mx6_common.h中有定义宏CONFIG_SYS_HUSH_PARSER,而正点原子的I.MX6ULL开发板配置头文件mx6ullevk.h里面会引用mx_common.h这个头文件,因此宏CONFIG_SYS_HUSH_PARSER有定义。

第205行调用函数parse_file_outer。

第207行是个死循环,永远不会执行到这里。

函数parse_file_outer定义在文件common/cli_hush.c中,去掉条件编译内容以后的函数内容如下:

第6行调用函数setup_file_in_str初始化变量input的成员变量。

第7行调用函数parse_stream_outer,这个函数就是hush shell的命令解释器,负责接收命令行输入,然后解析并执行相应的命令,函数parse_stream_outer定义在文件common/cli_hush.c中,精简版的函数内容如下:

第7~21行中的do-while循环就是处理输入命令的。

第9行调用函数parse_stream进行命令解析。

第14行调用run_list函数来执行解析出来的命令。

函数run_list会经过一系列的函数调用,最终通过调用cmd_process函数来处理命令,过程如下:

 第 5 行,run_list调用run_list_real函数。

第16行, run_list_real函数调用run_pipe_real函数。

第36行, run_pipe_real函数调用 cmd_process函数。

最终通过函数cmd_process来处理命令,接下来就是分析cmd_process函数。

 

cmd_process函数详解 

在学习cmd_process之前先看一下uboot中命令是如何定义的。uboot使用宏U_BOOT_CMD来定义命令,宏U_BOOT_CMD定义在文件include/command.h中,定义如下: 

 可以看出U_BOOT_CMD是U_BOOT_CMD_COMPLETE的特例, 将U_BOOT_CMD_COMPLETE的最后一个参数设置成NULL就是U_BOOT_CMD。宏U_BOOT_ CMD_COMPLETE如下:

宏U_BOOT_CMD_COMPLETE用到了ll_entry_declare和U-BOOT_CMD_MKENT_COMPLETE。ll_entry_declar定义在文件include/linker_lists.h中,定义如下: 

 _type为cmd_tbl_t,因此ll_entry_declare就是定义了一个cmd_tbl_t变量,这里用到了C语言中的“#”连接符符。其中的“##list”表示用_list的值来替换,"##_name”就是用_name的值来替换。

宏U_BOOT_CMD_MKENT_COMPLETE定义在文件include/command.h中,内容如下:

 上述代码中的“#”表示将name传递过来的值字符串化,U-BOOT_CMD_MKENT_COMPLETE又用到了宏_CMD_HELP和-CMD_COMPLETE,这两个宏的定义如下:

 可以看出,如果定义了宏CONFIG_AUTO_COMPLETE和CONFIG_SYS_LONGHELP的话,CMD COMPLETE和CMD_HELP就是取自身的值,然后在加上一个‘,’。CONFIG_AUTO_COMPLETE和CONFIG_SYS_LONGHELP这两个宏有定义在文件mx6_common.h中。

U_BOOT_CMD宏的流程我们已经清楚了(一个U_BOOT_CMD 宏就如此的绕来绕去的!),我们就以一个具体的命令为例,来看一下 U_BOOT_CMD经过展开以后究竟是个什么模样的。以命令dhep为例,dhcp命令定义如下:

 将其展开,结果如下:

从示例代码32.2.11.7可以看出,dhep命令最终展开结果为: 

 第1行定义了一个cmd_tbl_t类型的变量,变量名为_u_boot_list_2_cmd_2_dhcp,此变量4字节对齐。

第2行,使用_attribute_关键字设置变量_u_boot_list_2_cmd_2_dhep存储在

u_boot_list_2_cmd_2_dhcp 段中。u-boot.lds 链接脚本中有一个名为“.u_boot_list"的段,所有.uboot_list开头的段都存放到.u_boot.list中,如图所示:

因此,第2行就是设置变量_u_boot_list_2_cmd_2_dhep的存储位置。

第3-6 行,cmd_tbl_t 是个结构体,因此第3-6行是初始化emd_tbl_t这个结构体的各个成员变量。cmd_tbl_t结构体定义在文件include/command.h中,内容如下:

 结合实例代码32.2.11.8,可以得出变量_u_boot_list_2_cmd_2_dhep的各个成员的值如下所示:

当我们在uboot的命令行中输入"dhep”这个命令的时候,最终执行的是do-dhep这个函数。总结一下, uboot中使用U BOOT CMD来定义一个命令,最终的目的就是为了定义一个cmd_tbl_t类型的变量,并初始化这个变量的各个成员。uboot中的每个命令都存储在.u_boot_list段中,每个命令都有一个名为do_xxx(xxx为具体的命令名)的函数,这个do_xxx函数就是具体的命令处理函数。

了解了uboot 中命令的组成以后,再来看一下cmd_process函数的处理过程,cmd_process函数定义在文件common/command.c中,函数内容如下:

第507行,调用函数find_cmd在命令表中找到指定的命令,find_cmd 函数内容如下: 

参数cmd就是所查找的命令名字, uboot中的命令表其实就是cmd_tbl_t结构体数组,通过函数ll_entry_start得到数组的第一个元素,也就是命令表起始地址。通过函数ll_entry_count得到数组长度,也就是命令表的长度。最终通过函数find_cmd_tbl在命令表中找到所需的命令,每个命令都有一个name成员,所以将参数cmd与命令表中每个成员的name字段都对比一下,如果相等的话就说明找到了这个命令,找到以后就返回这个命令。

回到示例代码32.2.11.10的cmd_process函数中,找到命令以后肯定就要执行这个命令了,第533行调用函数cmd call来执行具体的命令, cmd call函数内容如下:

 在前面的分析中我们知道, cmd_tbl_t的cmd成员就是具体的命令处理函数,所以第494行调用cmdtp的cmd成员来处理具体的命令,返回值为命令的执行结果。

cmd_process中会检测cmd_tbl的返回值,如果返回值为CMD_RET_USAGE的话就会调用cmd_usage函数输出命令的用法,其实就是输出cmd_tbl_t的usage成员变量。