U-Boot学习(7):内核启动之bootz启动zImage源码分析

在上一节中,我们分析了U-BOOT初始化的流程,最后就是进入U-Boot的命令行中执行了,如果用户没有任何操作,则经过固定延时后将执行默认的bootcmd环境变量里的指令,那这里面肯定就是启动内核了。在U-BOOT简介及命令行指令详解中,我们知道最后执行的应该是bootz指令,那本节就来看一下这个指令如何启动内核的。

1 bootz的执行时机

首先我们来看一下在U-Boot命令行中输入bootz后会执行到什么函数中。在cmd/bootz.c中,我们发现了下面的声明:
在这里插入图片描述
这个指令定义也会注册到cli_loop中,在U-Boot输入bootz命令时,就会执行do_bootz函数。

1.1 do_bootz函数

下面就来看一下do_bootz函数:
在这里插入图片描述
在这个函数中,首先我们执行了bootz_start函数,看样子应该是根据我们提供的参数做一些初始化处理。

接着执行bootm_disable_interrupts关闭中断。在执行 bootz 命令启动加载操作系统之前,U-Boot处于加载操作系统的状态,在这个阶段需要手动关闭中断,确保中断不会干扰到关键的操作。但实际上在ARM中这个函数的实现为空。

最后调用do_bootm_states,这里一方面是告诉U-Boot我们启动的是Linux,另一方面第五个参数为启动需要执行的状态,包括BOOTM_STATE_OS_PREPBOOTM_STATE_OS_FAKE_GOBOOTM_STATE_OS_GO

  • 其中BOOTM_STATE_RAMDISK用于实现RAM的文件系统,这里没有执行

所以接下来我们就来分析一下bootz_startdo_bootm_states函数。

2 bootz_start函数

完整函数如下:
在这里插入图片描述

2.1 bootm_headers_t结构体

在分析这个函数之前,我们发现有一个bootm_headers_timages变量在这里经常用到,使用到的bootm_headers_t变量在bootm.c中有声明:

bootm_headers_t images;

完整结构体声明如下:

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;

	/*
	 * The fit_ members are only used with FIT, but it involves a lot of
	 * #ifdefs to avoid compiling that code. Since FIT is the standard
	 * format, even for SPL, this extra data size seems worth it.
	 */
	const char	*fit_uname_cfg;	/* configuration node unit name */

	void		*fit_hdr_os;	/* os FIT image header */
	const char	*fit_uname_os;	/* os subimage node unit name */
	int		fit_noffset_os;	/* os subimage node offset */

	void		*fit_hdr_rd;	/* init ramdisk FIT image header */
	const char	*fit_uname_rd;	/* init ramdisk subimage node unit name */
	int		fit_noffset_rd;	/* init ramdisk subimage node offset */

	void		*fit_hdr_fdt;	/* FDT blob FIT image header */
	const char	*fit_uname_fdt;	/* FDT blob subimage node unit name */
	int		fit_noffset_fdt;/* FDT blob subimage node offset */

	void		*fit_hdr_setup;	/* x86 setup FIT image header */
	const char	*fit_uname_setup; /* x86 setup subimage node name */
	int		fit_noffset_setup;/* x86 setup subimage node offset */

#ifndef USE_HOSTCC
	image_info_t	os;		/* os image info */
	ulong		ep;		/* entry point of OS */

	ulong		rd_start, rd_end;/* ramdisk start/end */

	char		*ft_addr;	/* flat dev tree address */
	ulong		ft_len;		/* length of flat device tree */

	ulong		initrd_start;
	ulong		initrd_end;
	ulong		cmdline_start;
	ulong		cmdline_end;
	struct bd_info		*kbd;
#endif

	int		verify;		/* env_get("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;

#if defined(CONFIG_LMB) && !defined(USE_HOSTCC)
	struct lmb	lmb;		/* for memory mgmt */
#endif
} bootm_headers_t;
  1. Legacy Image Header
    • legacy_hdr_os:指向传统OS镜像头部的指针。
    • legacy_hdr_os_copy:用于存储OS镜像头部的备份。
    • legacy_hdr_valid:标志变量,指示legacy_hdr_os中的头部是否有效。
  2. FIT Format Members
    • fit_uname_cfg:指向配置节点的名称(适用于FIT格式)。
    • fit_hdr_osfit_hdr_rdfit_hdr_fdtfit_hdr_setup:指向FIT格式中OS、initramdisk、FDTblob和x86setup镜像头部的指针。
    • fit_uname_osfit_uname_rdfit_uname_fdtfit_uname_setup:分别是FIT格式中OS、initramdisk、FDTblob和x86setup镜像节点的名称。
    • fit_noffset_osfit_noffset_rdfit_noffset_fdtfit_noffset_setup:分别是FIT格式中OS、initramdisk、FDTblob和x86setup镜像节点的偏移。
  3. Image Information and Execution Pointers
    • os:存储OS镜像信息的结构体。
    • ep:存储OS的入口点。
    • rd_startrd_end:RAMdisk的起始和结束地址。
    • ft_addrft_len:FlatDeviceTree(平面设备树)的地址和长度。
    • initrd_startinitrd_end:initramdisk的起始和结束地址。
    • cmdline_startcmdline_end:命令行的起始和结束地址。
    • kbd:键盘设备的信息。
  4. Verification and Boot State Variables
    • verify:标志变量,指示是否进行引导镜像的验证。
    • state:用于跟踪引导过程的状态,通过定义的宏表示不同的引导状态。
  5. Logical Memory Block(LMB)
    • lmb:用于内存管理的结构体。仅在配置启用LMB且非主机编译环境下可用。

该结构体主要用于存储引导过程中各个阶段的头部信息,包括传统的OS镜像头部和FIT格式的头部信息。这些信息在引导过程中被不同的部分使用,以确保正确加载和执行操作系统。

2.2 do_bootm_states:BOOTM_STATE_START

do_bootm_states这里states参数为BOOTM_STATE_START,执行流程大概如下:

do_bootm_states
	ret = bootm_start(cmdtp, flag, argc, argv);
	boot_fn = bootm_os_get_boot_func(images->os.os);
	...

实际上只执行了bootm_start函数,后面的boot_fn执行后续引导函数,但在BOOTM_STATE_START状态下没有执行。

2.2.1 bootm_start

在这里插入图片描述
这个函数就是重置images变量,然后调用一些函数来填充images里的一些参数,最后设置当前images的状态为BOOTM_STATE_START

其中boot_start_lmb函数,lmb的意思是Logical Memory Block,这个函数的作用是通过环境变量获取引导过程中可用内存的起始地址和大小,然后赋值给images中的相关变量。这里执行了boot_start_lmb函数,在2 bootz_start中函数就不会执行下面这一行了:

lmb_reserve(&images->lmb, images->ep, zi_end - zi_start);

所以等会就不分析这个函数了。

2.3 bootz_setup

函数如下:
在这里插入图片描述
这个函数比较简单了,就是zImage镜像有一个固定的头,固定头有一些固定的字段:

#define	LINUX_ARM_ZIMAGE_MAGIC	0x016f2818
#define	BAREBOX_IMAGE_MAGIC	0x00786f62

判断这两个字段其一是否匹配,若匹配则表示这段内存中保存了zImage,我们就把zImage所在内存的头尾赋值startend变量。

我们可以看一下zImage的二进制:
在这里插入图片描述
我们可以发现头信息中有LINUX_ARM_ZIMAGE_MAGIC

2.4 bootm_find_images

由于我们没有使用ram disk,再去掉没有执行的宏定义,该函数如下:
在这里插入图片描述
实际上就是获取设备树文件的相关信息,然后做一些内存检测。

3 do_bootm_states:启动内核

现在回到do_bootz函数最后的do_bootm_states函数中,由前面的2.2 do_bootm_states:BOOTM_STATE_START可知,在bootz_start中执行了这个函数,但是参数是BOOTM_STATE_START

而在这里states参数为BOOTM_STATE_OS_PREP|BOOTM_STATE_OS_FAKE_GO|BOOTM_STATE_OS_GO

为了方便分析,这里我把与这三个states无关的代码删掉了,函数如下
在这里插入图片描述

3.1 bootm_os_get_boot_func

首先来看一下bootm_os_get_boot_func函数,这个函数很简单:
在这里插入图片描述
其中boot_os的定义如下:
在这里插入图片描述
do_bootz中,我们已经设置images->os.osIH_OS_LINUX了。所以bootm_os_get_boot_func返回的就是do_bootm_linux函数。

3.2 boot_prep_linux

我们继续往下分析代码:
在这里插入图片描述
这里就是执行boot_fn函数,实际上就是do_bootm_linux函数。看一下这个函数:
在这里插入图片描述
由于我们的参数是BOOTM_STATE_OS_PREP,所以这里仅执行了boot_prep_linux(images)。由函数名可以猜测出,这是为了准备启动Linux而初始化一些参数。看一下这个函数:

static void boot_prep_linux(bootm_headers_t *images)
{
	char *commandline = env_get("bootargs");

	if (CONFIG_IS_ENABLED(OF_LIBFDT) && images->ft_len) {
#ifdef CONFIG_OF_LIBFDT
		debug("using: FDT\n");
		if (image_setup_linux(images)) {
			panic("FDT creation failed!");
		}
#endif
	} else if (BOOTM_ENABLE_TAGS) {
		debug("using: ATAGS\n");
		setup_start_tag(gd->bd);
		if (BOOTM_ENABLE_SERIAL_TAG)
			setup_serial_tag(&params);
		if (BOOTM_ENABLE_CMDLINE_TAG)
			setup_commandline_tag(gd->bd, commandline);
		if (BOOTM_ENABLE_REVISION_TAG)
			setup_revision_tag(&params);
		if (BOOTM_ENABLE_MEMORY_TAGS)
			setup_memory_tags(gd->bd);
		if (BOOTM_ENABLE_INITRD_TAG) {
			/*
			 * In boot_ramdisk_high(), it may relocate ramdisk to
			 * a specified location. And set images->initrd_start &
			 * images->initrd_end to relocated ramdisk's start/end
			 * addresses. So use them instead of images->rd_start &
			 * images->rd_end when possible.
			 */
			if (images->initrd_start && images->initrd_end) {
				setup_initrd_tag(gd->bd, images->initrd_start,
						 images->initrd_end);
			} else if (images->rd_start && images->rd_end) {
				setup_initrd_tag(gd->bd, images->rd_start,
						 images->rd_end);
			}
		}
		setup_board_tags(&params);
		setup_end_tag(gd->bd);
	} else {
		panic("FDT and ATAGS support not compiled in\n");
	}

	board_prep_linux(images);
}

如果使能了OF_LIBFDTBOOTM_ENABLE_TAGS就执行对应的if分支,大概都是根据GD或命令行参数填充全局变量params,它定义如下:

static struct tag *params;

struct tag {
	struct tag_header hdr;
	union {
		struct tag_core		core;
		struct tag_mem32	mem;
		struct tag_videotext	videotext;
		struct tag_ramdisk	ramdisk;
		struct tag_initrd	initrd;
		struct tag_serialnr	serialnr;
		struct tag_revision	revision;
		struct tag_videolfb	videolfb;
		struct tag_cmdline	cmdline;

		/*
		 * Acorn specific
		 */
		struct tag_acorn	acorn;

		/*
		 * DC21285 specific
		 */
		struct tag_memclk	memclk;
	} u;
};

3.3 boot_selected_os

最后do_bootm_states就执行boot_selected_os了,从注释可以看出来,这里就会启动Linux内核了,如果正常启动,这个函数就不会返回了。
在这里插入图片描述
该函数实际上也是调用boot_fn(do_bootm_linux)函数,如果成功的话函数就不会再返回了:
在这里插入图片描述
在来看一下do_bootm_linux函数:
在这里插入图片描述
这次就是执行第三个if分支的boot_jump_linux(images, flag)函数了,从函数名可以看出,就是最终我们跳转运行Linux内核的函数。

3.3.1 boot_jump_linux

最后就来看一下这个函数,为了代码简洁,省略了不会执行的部分:
在这里插入图片描述
首先我们从GD中获取machine id赋值给machid,然后从环境变量中获取machid对比一下是否一致。接下来的bootstage_mark是输出boot进度的函数。

3.3.1.1 announce_and_cleanup

在这里插入图片描述
这里实际上就是做一些清除函数,比如在U-Boot中我们初始化了USB,我们就要关闭。和所有的BootLoader一样,上电时系统是什么状态,在运行APP前就要恢复什么状态。否则可能会影响后续Linux内核程序的运行。具体可以参考我的这篇文章单片机中BootLoader的严谨实现详解

3.3.1.2 kernel_entry

最后我们就执行:

kernel_entry(0, machid, r2);

前面我们设置了:

kernel_entry = (void (*)(int, int, uint))images->ep;

这个函数实际上是Linux内核中的第一行代码,类似于:

static void (*farewellBootloader)(void) = 0;
farewellBootloader = (void (*)(void))appEntry;
farewellBootloader();

这样就跳转到Linux中执行代码了。至于这边传了三个参数,分别作为r0r1r2寄存器的值,传递给Linux内核使用。

至于Linux内核如何使用这些参数,后续我们分析Linux内核启动源码的时候再来看。

<think>好的,我现在要详细解释U-Boot启动流程。首先,我需要回忆U-Boot的基本结构和启动阶段。U-Boot是嵌入式系统中常用的引导加载程序,负责初始化硬件并加载操作系统。它的启动流程涉及多个阶段,每个阶段有不同的任务。 首先,启动流程通常从CPU上电开始,执行固化在ROM中的代码,比如芯片厂商提供的Boot ROM。这个阶段会初始化最基本的硬件,如时钟、内存控制器,然后加载SPL(Secondary Program Loader)。SPL是U-Boot的一部分,负责在内存初始化之前运行,因为它可能需要从存储设备(如MMC、NAND)加载完整的U-Boot到内存中。 接下来是SPL的执行。SPL需要初始化必要的外设,比如DRAM控制器,然后从存储介质中读取完整的U-Boot镜像到内存中。这里可能会有不同存储设备的处理,比如SD卡、eMMC、NOR/NAND Flash等,需要根据具体的板级配置来初始化对应的驱动。 一旦完整的U-Boot被加载到内存中,控制权就转交给U-Boot的start.S,这是U-Boot的入口点。start.S通常用汇编语言编写,负责设置CPU模式(如切换到SVC模式)、关闭中断、设置堆栈指针等底层初始化工作。然后会调用board_init_f函数,进行早期的板级初始化,比如内存分配、全局数据结构的设置。 board_init_f之后,会进行重定位,将U-Boot自身从加载地址复制到链接地址,这通常在内存的高端地址。重定位完成后,调用board_init_r函数,进行更复杂的板级初始化,包括设备驱动初始化、环境变量加载、命令行接口准备等。此时,U-Boot会初始化各种子系统,如串口、网络、存储设备等,以便用户可以交互。 最后,U-Boot进入主循环,等待用户输入命令或者执行自动启动流程。自动启动时,U-Boot会根据环境变量(如bootcmd)加载内核镜像到内存,传递启动参数,并跳转到内核的入口点。 在这个过程中,我需要确认每个阶段的具体任务是否正确,比如SPL的作用,重定位的必要性,以及不同板级配置的差异。可能还需要考虑不同架构(如ARM、MIPS)之间的差异,但假设问题主要针对ARM架构。此外,需要注意U-Boot的配置选项,比如是否启用SPL,不同的存储介质处理方式等。如果有错误或遗漏的地方,需要修正,比如是否在board_init_f之前有其他初始化步骤,或者重定位的具体实现细节。同时,要确保术语准确,比如正确区分SPL和U-Boot proper,以及各初始化函数的调用顺序。</think>以下是对U-Boot启动流程的深度技术解析,按执行顺序分为六个关键阶段: ``` [启动流程架构图] ROM Code → SPL → TPL(可选) → U-Boot Proper → Kernel → OS │ │ └─MLO─────┘(针对OMAP等特殊架构) ``` ### 一、ROM Bootloader阶段 1. **触发条件**: - 芯片复位向量(ARM架构通常为0x00000000或0xFFFF0000) - 通过BOOT引脚选择启动介质(NAND/SD/eMMC等) 2. **核心任务**: - 初始化CPU核心时钟(PLL配置) - 配置最小可用内存(SRAM或片上RAM) - 加载SPL到SRAM(如TI SoC的MLO文件) 3. **典型代码位置**: ```assembly /* ARMv7复位向量示例 */ .globl _start _start: b reset ... reset: /* 关闭MMU和缓存 */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x00002000 @ 关闭MMU bic r0, r0, #0x00000005 @ 关闭D-cache和分支预测 mcr p15, 0, r0, c1, c0, 0 /* 设置临时堆栈指针 */ ldr sp, =CONFIG_SPL_STACK /* 跳转到C入口 */ bl spl_main ``` ### 二、SPL(Secondary Program Loader)阶段 1. **代码入口**: - `spl\arm\crt0.S`中的`_start`符号 - 主要文件:`common/spl/spl.c` 2. **关键流程**: ```c void spl_main(void) { arch_cpu_init(); // CPU架构初始化 board_init_f(0); // 早期板级初始化 spl_load_image(); // 加载U-Boot Proper jump_to_image_no_args(&spl_image); // 跳转 } ``` 3. **内存初始化细节**: - DDR控制器参数配置(时序、PHY校准) - 内存训练(High-Speed SerDes初始化) - 内存映射表建立(通过`dram_init_banksize()`) ### 三、U-Boot Proper阶段 1. **执行入口**: - `arch/arm/lib/crt0.S`中的`_main` - 调用链:`_main → board_init_f → relocate_code → board_init_r` 2. **重定位机制**: ```c // 重定位偏移量计算 gd->reloc_off = (ulong)dest_addr - (ulong)__image_copy_start; // 重定向全局数据结构 gd->relocaddr = dest_addr; gd->ram_size = CONFIG_SYS_SDRAM_SIZE; ``` 3. **设备树处理流程**: - 初始DTB位置:`CONFIG_SYS_FDT_BASE` - 重定位后通过`fdt_shrink_to_minimum()`压缩DTB - 通过`fdtdec_setup()`更新内存节点 ### 四、驱动初始化顺序 1. **关键初始化序列**: ```c board_init_r() { serial_initialize(); // 串口子系统 dm_scan_platdata(); // 设备树解析 mmc_initialize(); // 存储设备初始化 env_initialize(); // 环境变量加载 set_cpu_clk_info(); // 时钟树构建 initr_net(); // 网络子系统 } ``` 2. **环境变量处理**: - 存储介质优先级:`ENV_IMPORT_FDT` > `ENV_IS_IN_MMC` > `ENV_IS_IN_SPI_FLASH` - 变量覆盖机制:`env_import()` → `himport_r()` ### 五、自动引导流程 1. **bootcmd执行逻辑**: ```c void autoboot_command(const char *s) { char *autoboot = env_get("bootcmd"); if (autoboot) run_command_list(autoboot, -1, 0); } ``` 2. **典型内核加载步骤**: ```bash # 环境变量示例 bootcmd=mmc dev 0; fatload mmc 0:1 0x80008000 zImage; fatload mmc 0:1 0x83000000 dtb; bootz 0x80008000 - 0x83000000 ``` 3. **ATF(ARM Trusted Firmware)集成**: - BL2 → BL31 → U-Boot(BL33)启动- PSCI服务初始化(CPU热插拔、电源管理) ### 六、高级调试技巧 1. **异常追踪方法**: ```bash # 开启调试日志 setenv bootargs earlycon console=ttyS0,115200 debug # 查看重定位信息 md.l 0x1ffb7230 1 # gd->relocaddr地址 ``` 2. **JTAG调试配置**: ```gdb target remote :3333 add-symbol-file u-boot 0x8ff00000 b board_init_f ``` **性能优化关键点**: 1. 减少SPL大小:`CONFIG_SPL_FRAMEWORK`裁剪 2. 加速DDR初始化:预校准参数存储到OTP 3. 快速启动配置:`CONFIG_BOOTDELAY=0`跳过倒计时 **启动时间优化示例**: ```c // 在include/configs/myboard.h中配置 #define CONFIG_SKIP_LOWLEVEL_INIT // 跳过重复的lowlevel_init #define CONFIG_BOOTSTAGE_REPORT // 启动阶段耗时分析 #define CONFIG_HW_WATCHDOG // 硬件看门狗优化 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

tilblackout

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值