开发环境：Nanopi-neo-plus2
软件版本：uboot-2017
软件版本：linux-4.14
买这个板子有一段时间了，并没有全身心的投入在上面，有时间了的话就搞一搞，
这篇随笔算是对这个版本的 uboot 启动流程做个大概的梳理和记录，体系结构相关的内容不作分析。
我这里会从 SPL(Secondary programloader) 阶段开始入手，按流程整理出 SPL 是怎样一步一步启动的 uboot，
而 uboot 又是怎样加载并启动的 kernel。
废话不多说，以内容为重点来打通整体脉络。
一、从SPL入口点开始：
阅读uboot源码时需注意：源码中存在众多 CONFIG_SPL_BUILD 宏的区分，使用了该宏的代码段，只有在 SPL 阶段时才会被编译进程序。
[ start.S armV8 ]
_start:
b reset
reset:
...
bl lowlevel_init
...
bl _main
[ lowlevel_init.S armV8 ]
ENTRY(lowlevel_init)
ldr w0, =CONFIG_SPL_STACK
bic sp, x0, #0xf
stp x29, x30, [sp, #-16]!
bl s_init
ENDPROC(lowlevel_init)
[ crt0_64.S arm/lib ]
ENTRY(_main)
ldr x0, =(CONFIG_SPL_STACK)
bic sp, x0, #0xf
...
mov x18, x0
bl board_init_f_init_reserve
mov x0, #0
bl board_init_f
...
mov x0, x18 /* gd_t */
ldr x1, [x18, #GD_RELOCADDR] /* dest_addr */
b board_init_r /* PC relative jump */
ENDPROC(_main)
[ Board.c mach-sunxi ]
void board_init_f(ulong dummy)
{
spl_init();
preloader_console_init();
#ifdef CONFIG_SPL_I2C_SUPPORT
/* Needed early by sunxi_board_init if PMU is enabled */
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
#endif
sunxi_board_init();
#ifdef CONFIG_SPL_BUILD
spl_mem_test();
#endif
}
[ spl.c spl ]
void board_init_r(gd_t *dummy1, ulong dummy2)
{
...
board_boot_order(spl_boot_list);
if (boot_from_devices(&spl_image, spl_boot_list,
ARRAY_SIZE(spl_boot_list))) {
puts("SPL: failed to boot from all boot devices
");
hang();
}
switch (spl_image.os) {
case IH_OS_U_BOOT:
debug("Jumping to U-Boot
");
break;
#ifdef CONFIG_SPL_OS_BOOT
case IH_OS_LINUX:
debug("Jumping to Linux
");
spl_fixup_fdt();
spl_board_prepare_for_linux();
jump_to_image_linux(&spl_image);
#endif
default:
debug("Unsupported OS image.. Jumping nevertheless..
");
}
...
if (CONFIG_IS_ENABLED(ATF_SUPPORT)) {
debug("loaded - jumping to U-Boot via ATF BL31.
");
bl31_entry();
}
debug("loaded - jumping to U-Boot...
");
spl_board_prepare_for_boot();
jump_to_image_no_args(&spl_image);
}
[ spl.c spl ]
board_boot_order(spl_boot_list);
==>
boot_source = readb(SPL_ADDR + 0x28);
switch (boot_source) {
case SUNXI_BOOTED_FROM_MMC0:
return BOOT_DEVICE_MMC1;
case SUNXI_BOOTED_FROM_NAND:
return BOOT_DEVICE_NAND;
case SUNXI_BOOTED_FROM_MMC2:
return BOOT_DEVICE_MMC2;
case SUNXI_BOOTED_FROM_SPI:
return BOOT_DEVICE_SPI;
};
[ spl.c spl ]
static int boot_from_devices(struct spl_image_info *spl_image,
u32 spl_boot_list[], int count)
{
loader = spl_ll_find_loader(spl_boot_list[i]);
==>
struct spl_image_loader *drv =
ll_entry_start(struct spl_image_loader, spl_image_loader);
const int n_ents =
ll_entry_count(struct spl_image_loader, spl_image_loader);
struct spl_image_loader *entry;
for (entry = drv; entry != drv + n_ents; entry++) {
if (boot_device == entry->boot_device)
return entry;
}
...
if (loader && !spl_load_image(spl_image, loader))
return 0;
}
代码中使用了 ll_entry_start 宏，就可以联想到 ll_entry_declare 声明，随后通过搜索可找到
#define SPL_LOAD_IMAGE(__name)
ll_entry_declare(struct spl_image_loader, __name, spl_image_loader)
宏定义，进一步找到
#define SPL_LOAD_IMAGE_METHOD(_name, _priority, _boot_device, _method)
SPL_LOAD_IMAGE(_method ## _priority ## _boot_device) = {
.name = _name,
.boot_device = _boot_device,
.load_image = _method,
}
我们假设设备以SD卡的方式启动，SD对应着 BOOT_DEVICE_MMC1，那么通过搜索 SPL_LOAD_IMAGE_METHOD 筛选 BOOT_DEVICE_MMC1 就可以定位到驱动的本源，即
[ spl_mmc.c spl ]
SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
继续分析启动流程
spl_load_image(spl_image, loader) ==>int spl_mmc_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) { ... spl_boot_mode(bootdev->boot_device); return MMCSD_MODE_RAW; ... /* 通过宏 CONFIG_SPL_OS_BOOT 选择，spl直接启动OS还是启动uboot，这里返回1，启动uboot */ spl_start_uboot() return 1; ... mmc_load_image_raw_sector(spl_image, mmc, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR); ... mmc_load_legacy(spl_image, mmc, sector, header); spl_parse_image_header(spl_image, header); spl_set_header_raw_uboot(spl_image); spl_image->size = CONFIG_SYS_MONITOR_LEN; spl_image->entry_point = CONFIG_SYS_UBOOT_START; spl_image->load_addr = CONFIG_SYS_TEXT_BASE; spl_image->os = IH_OS_U_BOOT; spl_image->name = "U-Boot";
...
}
回到 board_init_r 继续分析，spl_image->os 赋值为 IH_OS_U_BOOT ，所以 break 直接跳出；接下来有执行ATF的bl31部分（这部分暂不做分析），最后执行 jump_to_image_no_args 跳转到 spl_image->entry_point ，也就是正式的uboot阶段。
if (CONFIG_IS_ENABLED(ATF_SUPPORT)) {
debug("loaded - jumping to U-Boot via ATF BL31.
");
bl31_entry();
}
debug("loaded - jumping to U-Boot...
");
spl_board_prepare_for_boot();
jump_to_image_no_args(&spl_image);
至此，SPL 的生命阶段正式结束。
二、继续分析 UBOOT：
Makefile 通过宏的区分编译出两个执行程序 spl、uboot.
SPL 已经在上述分析完毕，BOOT 在启动初期与 SPL 大同小异，这里只是分析比较大的变动。
直接定位到 _main，由于不再有 CONFIG_SPL_BUILD 宏的限制，这里的程序代码就发生了变化。
[ crt0_64.S ]
ENTRY(_main)
ldr x0, =(CONFIG_SPL_STACK)
bic sp, x0, #0xf
...
mov x18, x0
bl board_init_f_init_reserve
mov x0, #0
bl board_init_f
...
/* Add in link-vs-relocation offset */
ldr x9, [x18, #GD_RELOC_OFF] /* x9 <- gd->reloc_off */
add lr, lr, x9 /* new return address after relocation */
ldr x0, [x18, #GD_RELOCADDR] /* x0 <- gd->relocaddr */
b relocate_code
...
mov x0, x18 /* gd_t */
ldr x1, [x18, #GD_RELOCADDR] /* dest_addr */
b board_init_r /* PC relative jump */
ENDPROC(_main)
[ board_f.c common ]
void board_init_f(ulong boot_flags)
{
... ///< 初始化CPU、Timer、Serial、板级信息及内存分配、布局等
}
[ relocate.S arm/lib ]
ENTRY(relocate_code)
... ///< 这部分代码比较关键，个人觉得和之前总结的动态编译较为类似，这里不再分析
///< 有兴趣可以参考下这篇博文：blog.csdn.net/ooonebook/article/details/53047992
ENDPROC(relocate_code)
[ board_r.c common ]
void board_init_r(gd_t *new_gd, ulong dest_addr)
{
... ///< 初始化化各种软硬件资源
run_main_loop
==>
for (;;)
main_loop();
}
[ main.c common ]
void main_loop(void)
{
const char *s;
...
s = bootdelay_process();
==>
s = env_get("bootcmd"); ///< 取得 bootcmd 环境变量信息，
==>
"bootcmd=" CONFIG_BOOTCOMMAND " "
#define CONFIG_BOOTCOMMAND "run distro_bootcmd"
... ///< 自动启动脚本
if (cli_process_fdt(&s)) ///< fdt中的 bootcmd 可覆盖上步中赋值的 s
cli_secure_boot_cmd(s);
autoboot_command(s); ///< 在 bootdelay 时间内没有任何操作的话，则自动执行上述 s，脚本最终会执行到用户的 boot.scr 里面的内容
///< 我在这里使用的是( bootm FIT )的启动方式，而 boot.scr 中默认为( booti image initramfs fdt )，所以将该内容注释掉
cli_loop(); ///< 进入到控制台，可手动执行boot中自带的指令
...
}
执行到这里，在默认的情况下会执行 boot.scr 脚本中的代码，最终会使用 booti 指令来启动 kernel.
三、关于 FIT 方式启动
[ FIT 制作过程 ]
1.initramfs 制作,制作过程可见链接
2.在 kernel 源码下建立FIT文件夹，加入imgae、fdt、initramfs
3.构建 its 文件，内容例如下
[ image.its ]
/dts-v1/;
/ {
description = "U-Boot fitImage for plnx_aarch64 kernel";
#address-cells = <1>;
images {
kernel@0 {
description = "Linux Kernel";
data = /incbin/("./FIT/Image");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "none";
load = <0x46080000>;
entry = <0x46080000>;
hash@1 {
algo = "sha1";
};
};
fdt@0 {
description = "Flattened Device Tree blob";
data = /incbin/("./FIT/sun50i-h5-nanopi-neo-plus2.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
hash@1 {
algo = "sha1";
};
};
ramdisk@0 {
description = "ramdisk";
data = /incbin/("./FIT/rootfs.cpio.gz");
type = "ramdisk";
arch = "arm64";
os = "linux";
compression = "none";
hash@1 {
algo = "sha1";
};
};
};
configurations {
default = "config@0";
config@0 {
description = "Boot Linux kernel with FDT blob + ramdisk";
kernel = "kernel@0";
fdt = "fdt@0";
ramdisk = "ramdisk@0";
hash@1 {
algo = "sha1";
};
};
};
};
使用此 its 打包成 image 文件
mkimage -f image.its kernel.img
kernel.img 打包完成后可以放到 SD 卡的 boot 分区中，它是 fat32 文件系统。
然后，在 boot.scr 脚本中可去除关于 加载 fdt、ramdist、booti 等相关指令，我们已做好集成，而无需一一地进行加载。最后在脚本中加入以下两条指令，即可完成系统的启动。
fatload mmc 0 0x47000000 kernel.img
bootm 0x47000000
在这里提醒一下,image 中的 load、entry 地址需要注意。起初实验时，我将这两个值都配置为和 booti 一样的地址：0x46080000，但是始终无法进入 kernel，没有任何打印输出。
最后无奈，开始从源码对比 bootm 与 booti 的不同点在哪里，其中一点在 booti_setup 源码中的注释吸引了我的关注，代码如下：
static int booti_setup(bootm_headers_t *images) { ... /* * Prior to Linux commit a2c1d73b94ed, the text_offset field * is of unknown endianness. In these cases, the image_size * field is zero, and we can assume a fixed value of 0x80000. */ if (ih->image_size == 0) { puts("Image lacks image_size field, assuming 16MiB "); image_size = 16 << 20; text_offset = 0x80000; } else { image_size = le64_to_cpu(ih->image_size); text_offset = le64_to_cpu(ih->text_offset); } ... }
这里面如果 image_size 为 0 的话，那么就会将 kernel 的 load 点加上 0x80000 的 offset，我尝试在 its 的 load、entry 点加上这个 offset，重新打包测试，kernel 就可以正常的启动了。
果然这个地址乱填还真的不行。
四、bootm 启动 FIT 流程简要分析
[ bootm.c ]
int do_bootm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
... ///< 子命令处理
return do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START |
BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER |
BOOTM_STATE_LOADOS |
BOOTM_STATE_RAMDISK |
BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
BOOTM_STATE_OS_GO, &images, 1);
}
[ bootm.c ]
int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int states, bootm_headers_t *images, int boot_progress)
{
bootm_start(cmdtp, flag, argc, argv);
bootm_find_os(cmdtp, flag, argc, argv); ///< 这里 case IMAGE_FORMAT_FIT, 获取 FIT 中的 kernel 资源信息
bootm_find_other(cmdtp, flag, argc, argv); ///< 提取其它资源信息 ramdisk、fdt 等
bootm_load_os(images, &load_end, 0); ///< 加载 kernel 资源，如果采用了压缩格式，会涉及到 bootm_decomp_image
boot_ramdisk_high(&images->lmb, images->rd_start, ///< 重定位 ramdisk 至高地址区
rd_len, &images->initrd_start, &images->initrd_end);
boot_relocate_fdt(&images->lmb, &images->ft_addr, ///< 重定位 fdt
&images->ft_len);
boot_fn = bootm_os_get_boot_func(images->os.os); ///< 这里返回 do_bootm_linux 地址
boot_fn(BOOTM_STATE_OS_PREP, argc, argv, images); ///< 调用 boot_prep_linux
boot_selected_os(argc, argv, BOOTM_STATE_OS_GO, images, boot_fn); ///< 调用 boot_jump_linux
}
[ bootm.c ]
int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
boot_prep_linux(images);
==>
image_setup_linux(images)
boot_relocate_fdt(lmb, of_flat_tree, &of_size);
image_setup_libfdt(images, *of_flat_tree, of_size, lmb);
fdt_initrd(blob, *initrd_start, *initrd_end);
fdt_setprop_uxx(fdt, nodeoffset, "linux,initrd-start", (uint64_t)initrd_start, is_u64); ///< 在 fdt 中加入 initrd-start 信息，以便于 kernel 初始化时可以找到 initramfs.
fdt_setprop_uxx(fdt, nodeoffset, "linux,initrd-end", (uint64_t)initrd_end, is_u64);
boot_jump_linux(images, flag);
==>
armv8_switch_to_el2((u64)images->ft_addr, ///< fdt 入口点
0, 0, 0,
images->ep, ///< kernel 入口点
ES_TO_AARCH64);
}
[ transition.S armV8 ]
ENTRY(armv8_switch_to_el2)
switch_el x6, 1f, 0f, 0f
0:
cmp x5, #ES_TO_AARCH64
b.eq 2f
/*
* When loading 32-bit kernel, it will jump
* to secure firmware again, and never return.
*/
bl armv8_el2_to_aarch32
2:
/*
* x4 is kernel entry point or switch_to_el1
* if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
* When running in EL2 now, jump to the
* address saved in x4.
*/
br x4 ///< 我这里 CONFIG_ARMV8_SWITCH_TO_EL1 未定义，所以直接跳转至内核入口
1:
armv8_switch_to_el2_m x4, x5, x6
ENDPROC(armv8_switch_to_el2)
到这里，如果执行正常的话，那么 uboot 就会将手上的军统大权完完全全地交给了 kernel，它也是完成了自己最重要的任务 --- 引导内核。
五、kernel 解析 initrd 地址
uboot 将 initrd 的地址写入了 fdt，在 kernel 里又是怎样解析的呢？我们继续分析，可以从 start_kernel 一点点梳理到 early_init_dt_check_for_initrd，奥秘就在这里。
[ fdt.c ]
static void __init early_init_dt_check_for_initrd(unsigned long node)
{
...
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
start = of_read_number(prop, len/4);
prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
end = of_read_number(prop, len/4);
__early_init_dt_declare_initrd(start, end);
==>
initrd_start = start;
initrd_end = end;
}
[ initramfs.c ]
static int __init populate_rootfs(void)
{
...
unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
...
}
这里 unpack_to_rootfs 所用到的参数，即为 uboot 在配置 fdt 的 bootargs 时所写入的地址。有了它，根目录就可以正常地被挂载，系统即可以正常操作。
流程分析结束。
之前也分析过类似的流程，但还是第一次将完整的过程记录下来。
仅以此文记录那些年分析过的启动流程。^_^