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

2024-01-31 08:04
文章标签 分析 源码 启动 学习 boot 内核 bootz zimage

本文主要是介绍U-Boot学习(7)：内核启动之bootz启动zImage源码分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

文章目录

  • 1 bootz的执行时机
    • 1.1 do_bootz函数
  • 2 bootz_start函数
    • 2.1 bootm_headers_t结构体
    • 2.2 do_bootm_states:BOOTM_STATE_START
      • 2.2.1 bootm_start
    • 2.3 bootz_setup
    • 2.4 bootm_find_images
  • 3 do_bootm_states：启动内核
    • 3.1 bootm_os_get_boot_func
    • 3.2 boot_prep_linux
    • 3.3 boot_selected_os
      • 3.3.1 boot_jump_linux
        • 3.3.1.1 announce_and_cleanup
        • 3.3.1.2 kernel_entry

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_PREP、BOOTM_STATE_OS_FAKE_GO和BOOTM_STATE_OS_GO。

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

所以接下来我们就来分析一下bootz_start和do_bootm_states函数。

2 bootz_start函数

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

2.1 bootm_headers_t结构体

在分析这个函数之前，我们发现有一个bootm_headers_t的images变量在这里经常用到，使用到的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_HOSTCCimage_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;
#endifint		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_os、fit_hdr_rd、fit_hdr_fdt、fit_hdr_setup：指向FIT格式中OS、initramdisk、FDTblob和x86setup镜像头部的指针。
    • fit_uname_os、fit_uname_rd、fit_uname_fdt、fit_uname_setup：分别是FIT格式中OS、initramdisk、FDTblob和x86setup镜像节点的名称。
    • fit_noffset_os、fit_noffset_rd、fit_noffset_fdt、fit_noffset_setup：分别是FIT格式中OS、initramdisk、FDTblob和x86setup镜像节点的偏移。
  3. Image Information and Execution Pointers
    • os：存储OS镜像信息的结构体。
    • ep：存储OS的入口点。
    • rd_start、rd_end：RAMdisk的起始和结束地址。
    • ft_addr、ft_len：FlatDeviceTree（平面设备树）的地址和长度。
    • initrd_start、initrd_end：initramdisk的起始和结束地址。
    • cmdline_start、cmdline_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_statesret = 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所在内存的头尾赋值start和end变量。

我们可以看一下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.os为IH_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_LIBFDTdebug("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_LIBFDT或BOOTM_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中执行代码了。至于这边传了三个参数，分别作为r0，r1和r2寄存器的值，传递给Linux内核使用。

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

这篇关于U-Boot学习(7)：内核启动之bootz启动zImage源码分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

原文地址:
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.chinasem.cn/article/663066。

相关文章

Java程序进程起来了但是不打印日志的原因分析

Java程序进程起来了但是不打印日志的原因分析

《Java程序进程起来了但是不打印日志的原因分析》：本文主要介绍Java程序进程起来了但是不打印日志的原因分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Java程序进程起来了但是不打印日志的原因1、日志配置问题2、日志文件权限问题3、日志文件路径问题4、程序
阅读更多...
Spring Boot 集成 Quartz并使用Cron 表达式实现定时任务

Spring Boot 集成 Quartz并使用Cron 表达式实现定时任务

《SpringBoot集成Quartz并使用Cron表达式实现定时任务》本篇文章介绍了如何在SpringBoot中集成Quartz进行定时任务调度,并通过Cron表达式控制任务... 目录前言1. 添加 Quartz 依赖2. 创建 Quartz 任务3. 配置 Quartz 任务调度4. 启动 Sprin
阅读更多...
Java 正则表达式URL 匹配与源码全解析

Java 正则表达式URL 匹配与源码全解析

《Java正则表达式URL匹配与源码全解析》在Web应用开发中,我们经常需要对URL进行格式验证,今天我们结合Java的Pattern和Matcher类,深入理解正则表达式在实际应用中... 目录1.正则表达式分解：2. 添加域名匹配 (2)3. 添加路径和查询参数匹配 (3) 4. 最终优化版本5.设计思
阅读更多...
Java字符串操作技巧之语法、示例与应用场景分析

Java字符串操作技巧之语法、示例与应用场景分析

《Java字符串操作技巧之语法、示例与应用场景分析》在Java算法题和日常开发中,字符串处理是必备的核心技能,本文全面梳理Java中字符串的常用操作语法,结合代码示例、应用场景和避坑指南,可快速掌握字... 目录引言1. 基础操作1.1 创建字符串1.2 获取长度1.3 访问字符2. 字符串处理2.1 子字
阅读更多...
Linux内核参数配置与验证详细指南

Linux内核参数配置与验证详细指南

《Linux内核参数配置与验证详细指南》在Linux系统运维和性能优化中,内核参数（sysctl）的配置至关重要,本文主要来聊聊如何配置与验证这些Linux内核参数,希望对大家有一定的帮助... 目录1. 引言2. 内核参数的作用3. 如何设置内核参数3.1 临时设置（重启失效）3.2 永久设置（重启仍生效
阅读更多...
Spring Boot循环依赖原理、解决方案与最佳实践(全解析)

Spring Boot循环依赖原理、解决方案与最佳实践(全解析)

《SpringBoot循环依赖原理、解决方案与最佳实践(全解析)》循环依赖指两个或多个Bean相互直接或间接引用,形成闭环依赖关系,：本文主要介绍SpringBoot循环依赖原理、解决方案与最... 目录一、循环依赖的本质与危害1.1 什么是循环依赖？1.2 核心危害二、Spring的三级缓存机制2.1 三
阅读更多...
在Spring Boot中浅尝内存泄漏的实战记录

在Spring Boot中浅尝内存泄漏的实战记录

《在SpringBoot中浅尝内存泄漏的实战记录》本文给大家分享在SpringBoot中浅尝内存泄漏的实战记录,结合实例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧... 目录使用静态集合持有对象引用，阻止GC回收关键点：可执行代码：验证：1，运行程序（启动时添加JVM参数限制堆大小）：2，访问 htt
阅读更多...
如何配置Spring Boot中的Jackson序列化

如何配置Spring Boot中的Jackson序列化

《如何配置SpringBoot中的Jackson序列化》在开发基于SpringBoot的应用程序时,Jackson是默认的JSON序列化和反序列化工具,本文将详细介绍如何在SpringBoot中配置... 目录配置Spring Boot中的Jackson序列化1. 为什么需要自定义Jackson配置？2.
阅读更多...
Python 迭代器和生成器概念及场景分析

Python 迭代器和生成器概念及场景分析

《Python迭代器和生成器概念及场景分析》yield是Python中实现惰性计算和协程的核心工具,结合send()、throw()、close()等方法,能够构建高效、灵活的数据流和控制流模型,这... 目录迭代器的介绍自定义迭代器省略的迭代器生产器的介绍yield的普通用法yield的高级用法yidle
阅读更多...
Redis在windows环境下如何启动

Redis在windows环境下如何启动

《Redis在windows环境下如何启动》：本文主要介绍Redis在windows环境下如何启动的实现方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Redis在Windows环境下启动1.在redis的安装目录下2.输入·redis-server.exe
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2