uboot启动流程

1. 链接脚本u-boot.lds

指定链接的首地址在哪里,哪一行代码是第一行。所以需要先编译。
uboot启动流程_第1张图片
打开该源码,可知u-boot的入口地址是_start;
可以搜索_start. 在文件 arch/arm/lib/vectors.S 中有定义:
uboot启动流程_第2张图片
uboot启动流程_第3张图片
如代码中定义的,这里面包含复位和中断向量表的起始地址;
继续回到u-boot.lds:
uboot启动流程_第4张图片
.text是代码段,中间有个__image_copy_start,可以通过全局搜索在
uboot启动流程_第5张图片
可以看到,是0x87800000,.vectors也存在这里,它是中断向量表,和裸机中断时一样的;
继续回到u-boot.lds:
uboot启动流程_第6张图片
对应的map为(复位和初始化CPU,就类似裸机开发必须要存放的两个,剩下的代码段就可以随意存放了):
uboot启动流程_第7张图片
继续回到u-boot.lds:
uboot启动流程_第8张图片
镜像拷贝结束,它和image_copy_start是成对的,因为需要重定位,所以要拷贝copy,搜索一下它的位置:
uboot启动流程_第9张图片
由图中可以看到它的镜像结束地址,不同的编译可能最后的低吗段结束不一样,这样就得到代码的大小了,差不多300多kb
继续回到u-boot.lds:
uboot启动流程_第10张图片
rel_dyn_start在map中的地址为:
image
(end就不找了),差不多30多k
__end段
uboot启动流程_第11张图片
再找找bss段
uboot启动流程_第12张图片
uboot启动流程_第13张图片
自此,我们每个段的地址都找到了,不同编译产生的地址是不一样的,除了开始的87800000

2. u-boot启动流程

刚才说到了,入口地址是_start,所以汇编从这里分析:
uboot启动流程_第14张图片

2.1 reset函数

上一张图是vector.S主要定义了一些中断向量表,我们找rest函数,是在start.s
uboot启动流程_第15张图片
由图中可以看到,reset是跳转函数,不用往下搜索了,跳着跳着还是回到下面的函数里了:
uboot启动流程_第16张图片
注:HYP模式是超级监视者模式,比超级管理员模式第一点,主要用来做一些虚拟化扩展
继续往下看:
uboot启动流程_第17张图片
如果没有定义这两个变量,就执行下面语句,#if后面都是注释的颜色,那肯定没有定义
uboot启动流程_第18张图片
这个寄存器如图所示:
uboot启动流程_第19张图片
综上所述:就是设置偏移为0,重定位向量表,再把中断向量表迁移到87800000
uboot启动流程_第20张图片
接下来有两个函数,一个看名字就知道是初始化cp15,比如关闭MMU啥的,这些都比较固定,就不分析了,
一个是cpu_init_crit,最后一个是main
cpu_init_crit是跳到lowlevel_init

2.2 lowlevel_init函数

函数 lowlevel_init 在文件 arch/arm/cpu/armv7/lowlevel_init.S 中定义
uboot启动流程_第21张图片
uboot启动流程_第22张图片
GENERATED_GBL_DATA_SIZE 256
uboot启动流程_第23张图片
uboot启动流程_第24张图片
uboot启动流程_第25张图片
总结:这个函数就是设置sp指针和R9寄存器,保存栈指针
接下来我们来看s_init

2.3 s_init函数

我们知道 lowlevel_init 函数后面会调用 s_init 函数,s_init 函数定义在文件arch/arm/cpu/armv7/mx6/soc.c
uboot启动流程_第26张图片
由图可知,相当于空函数

2.4 __main函数

uboot启动流程_第27张图片
上面分析可知,该进入main函数了_main 函数定义在文件 arch/arm/lib/crt0.S 中
uboot启动流程_第28张图片
uboot启动流程_第29张图片
我们再看board_init_f_alloc_reserve这个函数,此函数定义在文件common/init/board_init.c 中
uboot启动流程_第30张图片
uboot启动流程_第31张图片
uboot启动流程_第32张图片
uboot启动流程_第33张图片
gd_t 是个结构体,在 include/asm-generic/global_data.h 里面有定义,gd_t里面还有一个bd_t也是非常重要的函数
我们再回到89行crt0.S,board_init_f_init_reserve函数,
uboot启动流程_第34张图片
此时和上面对起来了
uboot启动流程_第35张图片
我们再回到crt0.S,
uboot启动流程_第36张图片
这里借助bd计算出新的gd位置,然后将其保存在r9里面,bd可以直接获得,而gd紧挨着bd,所以减去gd大小就是gd的新地址
这里面有个问题,就是bd的大小可以直接获得
uboot启动流程_第37张图片
接下来可以重定位代码
在整个ddr中,从87800000开始,是uboot的代码,要将这部分代码移植到高地址,也就是最下面,这样把其他的代码考到87800000上就还是会运行,因为uboot去高地址了
here函数中:
重定位中断向量表;
调用函数 c_runtime_cpu_setup,此函数定义在文件 arch/arm/cpu/armv7/start.S
uboot启动流程_第38张图片
关闭ICache和DCache
uboot启动流程_第39张图片
这段代码清除bss段
uboot启动流程_第40张图片
uboot启动流程_第41张图片
由图可知,board_init_r函数要传递两个参数r0,r1

2.5 board_init_f函数

  • 初始化一系列外设,比如串口、定时器,或者打印一些消息等。
  • 初始化 gd 的各个成员变量,uboot 会将自己重定位到 DRAM 最后面的地址区域,也就是将自己拷贝到 DRAM 最后面的内存区域中。这么做的目的是给 Linux 腾出空间,防止 Linux kernel 覆盖掉 uboot,将 DRAM 前面的区域完整的空出来。在拷贝之前肯定要给 uboot 各部分分配好内存位置和大小,比如 gd 应该存放到哪个位置,malloc 内存池应该存放到哪个位置等等。这些信息都保存在 gd 的成员变量中,因此要对 gd 的这些成员变量做初始化。最终形成一个完整的内存“分配图”,在后面重定位 uboot 的时候就会用到这个内存“分配图”。
    uboot启动流程_第42张图片
    再看一下init_sequence_f
    整理一下
/*****************去掉条件编译语句后的 init_sequence_f***************/
static init_fnc_t init_sequence_f[] = { 
	setup_mon_len,  //__bss_end-_start是整个代码的长度, 镜像大小,大约600-700k,也是要拷贝的的代码大小
	initf_malloc, // 里面设置了malloc大小0x400
	initf_console_record, //因为uboot没有定义,返回0
	arch_cpu_init, //初始化架构有关的工作,CPU级别
	initf_dm,  // 驱动初始化
	arch_cpu_init_dm,  //该函数未实现
	mark_bootstage, /* need timer, go after init dm */ 
	board_early_init_f,  //板子一些早期初始化配置,初始化串口IO等
	timer_init, /* initialize timer */ 
	board_postclk_init,  //设置vddsoc电压
	get_clocks, //获取时钟,对于I.MX获取SD卡外设时钟
	env_init, /* initialize environment */ 
	init_baud_rate, /* initialze baudrate settings */ 
	serial_init, /* serial communications setup */ 
	console_init_f, /*设置 gd->have_console 为 1,打开控制台,初始化之前是把环境放在缓冲区里,这个为1时正好打印 */ 
	display_options, /* 通过串口输出一些信息 */ 
	// 需要开启debug,在configs/mx6ull_evk里面define
	display_text_info, /* ,打印一些文本信息,如果开启 UBOOT 的 DEBUG 功能的话就
会输出 text_base、bss_start、bss_end */ 
	print_cpuinfo, /* CPU信息 */ 
	show_board_info,  // 打印板子信息
	INIT_FUNC_WATCHDOG_INIT //初始化看门狗
	INIT_FUNC_WATCHDOG_RESET //复位看门狗
	init_func_i2c,  //初始化i2c
	announce_dram_init,  //输出字符串“DRAM”
	/* TODO: unify all these dram functions? */
	dram_init, /* 并不是初始化DRAM只是设置这个值为512M ,是通过读取SD卡的配置信息初始化dram*/ 
	post_init_f, //用来完成测试 
	INIT_FUNC_WATCHDOG_RESET
	testdram, //测试ddr,空函数
	INIT_FUNC_WATCHDOG_RESET
	INIT_FUNC_WATCHDOG_RESET
	/*
	* Now that we have DRAM mapped and working, we can
	* relocate the code and continue running from DRAM.
	*
	* Reserve memory at end of RAM for (top down in that order):
	* - area that won't get touched by U-Boot and Linux (optional)
	* - kernel log buffer
	* - protected RAM
	* - LCD framebuffer
	* - monitor code
	* - board info struct
	*/
	setup_dest_addr, //设置gd->ram_size,gd->ram_top,gd->relocaddr这三个的值
	//gd->ram_size = 0X20000000 //ram 大小为 0X20000000=512MB
	//gd->ram_top = 0XA0000000//ram最高地址为 0X80000000+0X20000000=0XA0000000
	//gd->relocaddr = 0XA0000000 //重定位后最高地址为 0XA0000000,拷贝的地址 
	reserve_round_4k, //gd->relocaddr四字节对齐,本来就4k对齐,所以不需要了
	reserve_mmu, //留出mmu区域(内存映射单元),0x4000,所以要减去
	//gd->arch.tlb_size= 0X4000 //MMU 的 TLB 表大小
	//gd->arch.tlb_addr=0X9FFF0000 //MMU 的 TLB 表起始地址,64KB 对齐以后
	//gd->relocaddr=0X9FFF0000 //relocaddr 地址
	reserve_trace, //留出调试跟踪的内存,没有用到
	reserve_uboot, //reserve_uboot, 留出重定位后的 uboot 所占用的内存区域,uboot 所占用大小由gd->mon_len 所指定,留出 uboot 的空间以后还要对 gd->relocaddr 做 4K 字节对齐,并且重新设置 gd->start_addr_sp
	//gd->mon_len = 0XA8EF4
	//gd->start_addr_sp = 0X9FF47000
	//gd->relocaddr = 0X9FF47000, 从这开始定死了,把8780000的代码拷贝到这里,拷贝大小为0xA8EF4,此时定义的是relocaddr,接下来变化的就是start_addr_sp
	
	reserve_malloc, //留出 malloc 区域,调整 gd->start_addr_sp 位置,malloc 区域由宏TOTAL_MALLOC_LEN 定义
	//TOTAL_MALLOC_LEN=0X1002000
	//gd->start_addr_sp=0X9EF45000 //0X9FF47000-16MB-8KB=0X9EF45000
	reserve_board, //留出板子 bd 所占的内存区,bd 是结构体 bd_t,bd_t 大小为80 字节
	//gd->start_addr_sp=0X9EF44FB0
	//gd->bd=0X9EF44FB0
	setup_machine, //setup_machine,设置机器 ID,linux 启动的时候会和这个机器 ID 匹配,如果匹配的话 linux 就会启动正常。但是!!I.MX6ULL 不用这种方式了,这是以前老版本的 uboot 和linux 使用的,新版本使用设备树了,因此此函数无效。
	reserve_global_data,// 保留出 gd_t 的内存区域,gd_t 结构体大小为 248B
	//gd->start_addr_sp=0X9EF44EB8 //0X9EF44FB0-248=0X9EF44EB8
	//gd->new_gd=0X9EF44EB8
	reserve_fdt, //留出设备树相关的内存区域,I.MX6ULL 的 uboot 没有用到
	reserve_arch, //空函数
	reserve_stacks,//留出栈空间,先对 gd->start_addr_sp 减去 16,然后做 16 字节对其。如果使能 IRQ 的话还要留出 IRQ 相应的内存,在本 uboot 中并没有使用到 IRQ
	//gd->start_addr_sp=0X9EF44E90
	setup_dram_config, //函数设置 dram 信息,就是设置 gd->bd->bi_dram[0].start 和gd->bd->bi_dram[0].size,后面会传递给 linux 内核,告诉 linux DRAM 的起始地址和大小
	show_dram_config, //显示dram信息
	display_new_sp, //显示新的 sp 位置,也就是 gd->start_addr_sp,不过要定义宏 DEBUG
	INIT_FUNC_WATCHDOG_RESET//
	reloc_fdt, //函数用于重定位 fdt,没有用到
	setup_reloc, //设置 gd 的其他一些成员变量,供后面重定位的时候使用,并且将以前的 gd(R9) 拷贝到 gd->new_gd 处。需要使能 DEBUG 才能看到相应的信息输出,这里是在new——gd里有,r9此时还是内部ram里面的地址呢
	NULL,
};

最后的内存分布图:
uboot启动流程_第43张图片

2.6 relocate_code函数

目前分析的uboot代码还没有拷贝到gd->relocaddr中,这个函数是拷贝用的
调用这个函数之前,参数r0=0x9ff47000
image
此函数定义在文件 arch/arm/lib/relocate.S 中
uboot启动流程_第44张图片
uboot启动流程_第45张图片
这里面有一个问题:
我原来的函数的地址(没拷贝之前)在那,有另一个函数会调用它,但是你把它拷贝走了再调用,就没了,全局变量引用也会出问题。uboot对于这个处理方法,就是位置无关方法,借助.rel.dyn段
uboot启动流程_第46张图片
uboot启动流程_第47张图片
uboot启动流程_第48张图片
uboot启动流程_第49张图片
如上图可知:
borad_init 调用 rel_test 函数,用到了 bl 指令,而 bl 指令时位置无关指令,bl 指令是相对寻址的(pc+offset),因此 uboot 中函数调用是与绝对位置无关的。
再来看一下函数 rel_test 对于全局变量 rel_a 的调用,第 2 行设置 r3 的值为 pc+12 地址处的值,因为ARM流水线的原因,pc寄存器的值为当前地址+8,因此pc = 0X87804184 + 8 = 0X8780418C, r3=0X8780418C+12=0X87804198,第 7 行就是0X87804198 这个地址,0X87804198 处的值为0X8785DA50。根据第 17 行可知,0X8785DA50 正是变量 rel_a 的地址,最终 r3=0X8785DA50。
uboot启动流程_第50张图片
并没有直接读取变量的地址,而是借助了另一个地址,间接读取,+8+12偏移地址,也就是说这个过程也没有用到绝对地址;
继续往下:
uboot启动流程_第51张图片
这个段的作用是,给需要偏移的加上label,判断是label之后就要偏移了
uboot启动流程_第52张图片
uboot启动流程_第53张图片

2.7 relocate_vectors函数

中断向量表偏移
uboot启动流程_第54张图片
第 29 行,如果定义了 CONFIG_CPU_V7M 的话就执行第 30~36 行的代码,这是 Cortex-M内核单片机执行的语句,因此对于 I.MX6ULL 来说是无效的。
第 38 行,如果定义了 CONFIG_HAS_VBAR 的话就执行此语句,这个是向量表偏移,CortexA7是支持向量表偏移的。而且,在.config 里面定义了 CONFIG_HAS_VBAR,因此会执行这个分支。
第 43 行,r0=gd->relocaddr,也就是重定位后 uboot 的首地址,向量表肯定是从这个地址开始存放的。
第 44 行,将 r0 的值写入到 CP15 的 VBAR 寄存器中,也就是将新的向量表首地址写入到寄存器 VBAR 中,设置向量表偏移。

2.8 board_init_r函数

第 32.2.5 小节讲解了 board_init_f 函数,在此函数里面会调用一系列的函数来初始化一些外设和 gd 的成员变量。但是 board_init_f 并没有初始化所有的外设,还需要做一些后续工作,这些后续工作就是由函数 board_init_r 来完成的,board_init_r 函数定义在文件common/board_r.c
uboot启动流程_第55张图片

init_fnc_t init_sequence_r[] = {
	initr_trace, //如果定义了宏 CONFIG_TRACE 的话就会调用函数 trace_init,初始化和调试跟踪有关的内容
	initr_reloc, // 标记重定位完成
	initr_caches, // 初始化cache,并使能cache
	initr_reloc_global_data, // 初始化重定位后的gd相关成员变量
	initr_barrier, // I.MX没用到
	initr_malloc, // 初始化malloc区域
	initr_console_record, // 初始化控制台的,也没用到
	bootstage_relocate, // 启动状态重定位
	initr_bootstage, // 初始化启动状态
	board_init, /* Setup chipselects */ //板级初始化,包括 74XX 芯片,I2C、FEC、USB 和 QSPI 等。这里执行的是 mx6ull_alientek_emmc.c 文件中的 board_init 函数
	stdio_init_tables, //stdio相关初始化
	initr_serial, //初始化串口
	initr_announce, // 与调试有关,通知已在ram运行
	INIT_FUNC_WATCHDOG_RESET// 看门狗
	INIT_FUNC_WATCHDOG_RESET//
	INIT_FUNC_WATCHDOG_RESET//
	power_init_board, // 初始化电源,没有用到
	initr_flash, // flash初始化,如果有宏定义了才要初始化,没有定义就不需要了
	INIT_FUNC_WATCHDOG_RESET//
	initr_nand, // 初始化nand
	initr_mmc, // 初始化emmc
	initr_env, // 初始化环境
	INIT_FUNC_WATCHDOG_RESET//
	initr_secondary_cpu, // 初始化其他cpu,单核不需要
	INIT_FUNC_WATCHDOG_RESET// 
	stdio_add_devices, // 输入输出设备初始化,如lcd
	initr_jumptable, // 初始化跳表
	console_init_r, /* fully init console as a device *///控 制 台 初 始 化 , 初 始 化 完 成 以 后 此 函 数 会 调 用stdio_print_current_devices 函数来打印出当前的控制台设备
	INIT_FUNC_WATCHDOG_RESET //
	interrupt_init, // 初始化中断
	initr_enable_interrupts, // 使能中断
	initr_ethaddr, // 初始化网络MAC
	board_late_init, //board_late_init 函数,板子后续初始化,此函数定义在文件 mx6ull_alientek_emmc.c中,如果环境变量存储在 EMMC 或者 SD 卡中的话此函数会调用 board_late_mmc_env_init 函数初始化 EMMC/SD
	INIT_FUNC_WATCHDOG_RESET //
	INIT_FUNC_WATCHDOG_RESET//
	INIT_FUNC_WATCHDOG_RESET//
	initr_net, // 初始化网络设备
	INIT_FUNC_WATCHDOG_RESET//
	run_main_loop, //  主循环,处理命令
};
	

2.9 run_main_loop函数

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

2.10 cli_loop函数

uboot启动流程_第59张图片
uboot启动流程_第60张图片
uboot启动流程_第61张图片
uboot启动流程_第62张图片
uboot启动流程_第63张图片
uboot启动流程_第64张图片
uboot启动流程_第65张图片
uboot启动流程_第66张图片
uboot启动流程_第67张图片

2.12 cmd_process函数

在学习cmd_process 之前先看一下uboot中命令是如何定义的。uboot使用宏U_BOOT_CMD来定义命令,宏 U_BOOT_CMD 定义在文件 include/command.h 中
uboot启动流程_第68张图片
uboot启动流程_第69张图片
uboot启动流程_第70张图片
uboot启动流程_第71张图片
uboot启动流程_第72张图片
uboot启动流程_第73张图片
uboot启动流程_第74张图片
uboot启动流程_第75张图片
当我们在 uboot 的命令行中输入“dhcp”这个命令的时候,最终执行的是 do_dhcp 这个函数。总结一下,uboot 中使用 U_BOOT_CMD 来定义一个命令,最终的目的就是为了定义一个cmd_tbl_t 类型的变量,并初始化这个变量的各个成员。uboot 中的每个命令都存在.u_boot_list段中,每个命令都有一个名为 do_xxx(xxx 为具体的命令名)的函数,这个do_xxx 函数就是具体的命令处理函数。
uboot启动流程_第76张图片
uboot启动流程_第77张图片

3. u-boot启动linux内核函数过程

3.1 images全局变量

uboot启动流程_第78张图片

typedef struct bootm_headers {
	/*
	* Legacy os image header, if it is a multi component image
	* then boot_get_ramdisk() and get_fdt() will attempt to get
	* data from second and third component accordingly.
	*/
	image_header_t *legacy_hdr_os; /* image header pointer */
	image_header_t legacy_hdr_os_copy; /* header copy */
	ulong legacy_hdr_valid;
	......
	#ifndef USE_HOSTCC
	image_info_t os; /* OS 镜像信息 */
	ulong ep; /* OS 入口点 */

	ulong rd_start, rd_end; /* ramdisk 开始和结束位置 */

	char *ft_addr; /* 设备树地址 */
	ulong ft_len; /* 设备树长度 */

	ulong initrd_start; /* initrd 开始位置 */ 
	ulong initrd_end; /* initrd 结束位置 */
	ulong cmdline_start; /* cmdline 开始位置 */
	ulong cmdline_end; /* cmdline 结束位置 */
	bd_t *kbd;
	#endif

	int verify; /* getenv("verify")[0] != 'n' */

	#define BOOTM_STATE_START (0x00000001)
	#define BOOTM_STATE_FINDOS (0x00000002)
	#define BOOTM_STATE_FINDOTHER (0x00000004)
	#define BOOTM_STATE_LOADOS (0x00000008)
	#define BOOTM_STATE_RAMDISK (0x00000010)
	#define BOOTM_STATE_FDT (0x00000020)
	#define BOOTM_STATE_OS_CMDLINE (0x00000040)
	#define BOOTM_STATE_OS_BD_T (0x00000080)
	#define BOOTM_STATE_OS_PREP (0x00000100)
	#define BOOTM_STATE_OS_FAKE_GO (0x00000200)/*'Almost' run the OS*/
	#define BOOTM_STATE_OS_GO (0x00000400)
	int state;

	#ifdef CONFIG_LMB
	struct lmb lmb; /* 内存管理相关,不深入研究 */
	#endif
} bootm_headers_t;

uboot启动流程_第79张图片

3.2 do_bootz函数

bootz 命令的执行函数为 do_bootz,在文件 cmd/bootm.c
uboot启动流程_第80张图片

3.3 bootz_start函数

uboot启动流程_第81张图片
uboot启动流程_第82张图片
先看看bootz_setup:
uboot启动流程_第83张图片
bootm_find_images:
uboot启动流程_第84张图片

3.4 do_bootm_states函数

do_bootz最后调用的就是函数do_bootm_states,而且在bootz_start中也调用了do_bootm_states函数,看来do_bootm_states函数还是个香饽饽。此函数定义在文件common/bootm.c 中
uboot启动流程_第85张图片
uboot启动流程_第86张图片
uboot启动流程_第87张图片
uboot启动流程_第88张图片
uboot启动流程_第89张图片
uboot启动流程_第90张图片
uboot启动流程_第91张图片
uboot启动流程_第92张图片

3.5 bootm_os_get_boot_func函数

do_bootm_states 会调用 bootm_os_get_boot_func 来查找对应系统的启动函数
uboot启动流程_第93张图片
uboot启动流程_第94张图片
uboot启动流程_第95张图片

3.6 do_bootm_linux函数

经过前面的分析,我们知道了 do_bootm_linux 就是最终启动 Linux 内核的函数,此函数定义在文件 arch/arm/lib/bootm.c
uboot启动流程_第96张图片
uboot启动流程_第97张图片
第 293 行,变量 machid 保存机器 ID,如果不使用设备树的话这个机器 ID 会被传递给Linux内核,Linux 内核会在自己的机器 ID 列表里面查找是否存在与 uboot 传递进来的machid 匹配的项目,如果存在就说明 Linux 内核支持这个机器,那么 Linux 就会启动!如果使用设备树的话这个 machid 就无效了,设备树存有一个“兼容性”这个属性,Linux 内核会比较“兼容性”属性的值(字符串)来查看是否支持这个机器。
第 295 行,函数 kernel_entry,看名字“内核_进入”,说明此函数是进入 Linux 内核的,也就是最终的大 boos!!此函数有三个参数:zero,arch,params,第一个参数 zero 同样为0;第二个参数为机器 ID;第三个参数 ATAGS 或者设备树(DTB)首地址,ATAGS 是传统的方法,用于传递一些命令行信息啥的,如果使用设备树的话就要传递设备树(DTB)。 第 299 行,获取 kernel_entry 函数,函数 kernel_entry 并不是 uboot 定义的,而是 Linux 内核定义的,Linux 内核镜像文件的第一行代码就是函数 kernel_entry,而 images->ep 保存着Linux内核镜像的起始地址,起始地址保存的正是 Linux 内核第一行代码!
uboot启动流程_第98张图片
第 315~318 行是设置寄存器 r2 的值?为什么要设置 r2 的值呢?Linux 内核一开始是汇编代码,因此函数 kernel_entry 就是个汇编函数。向汇编函数传递参数要使用 r0、r1 和 r2(参数数量不超过 3 个的时候),所以 r2 寄存器就是函数 kernel_entry 的第三个参数。
第 316 行,如果使用设备树的话,r2 应该是设备树的起始地址,而设备树地址保存在 images的 ftd_addr 成员变量中。
第 317 行,如果不使用设备树的话,r2 应该是 uboot 传递给 Linux 的参数起始地址,也就是环境变量 bootargs 的值,
第 328 行,调用 kernel_entry 函数进入 Linux 内核,此行将一去不复返,uboot 的使命也就完成了,它可以安息了!
uboot启动流程_第99张图片

你可能感兴趣的:(uboot启动流程)