Uboot 大全 | uboot 启动流程（二）
- 设备树
- 驱动模型DM
- 驱动模型的结构
- 驱动模型的初始化
- 环境变量
- board_init_f流程
- board_init_r流程
U-boot支持的主要特性
uboot在初始化完成后会为用户提供一个命令行交互接口，用户可通过该接口执行uboot定义的命令，以用于查看系统状态，设置环境变量和系统参数等。为了方便对硬件和驱动的管理，uboot还引入了类似linux内核的设备树和驱动模型特性。当然，为了增加系统的可配置性、可调试性以及可跟踪性等，它还支持环境变量、log管理、bootstage统计以及简单的ftrace等功能。下面将对这些特性做一简单的介绍。
设备树
设备树是一种通过dts文件来描述SOC属性，通过将设备的具体配置信息与驱动分离，以达到利用一份代码适配多款设备的机制。dts文件包含了一系列层次化结构的节点和属性，它可以通过dtc编译器编译成适合设备解析的二进制dtb文件。uboot设备树的使用包含以下流程：为目标板添加dts文件、选择一个运行时使用的dtb文件、使能设备树。以下为详细介绍：
- 如何为目标板添加一个dts文件 在arch//dts目录下，添加一个xxx.dts文件，该文件可以从内核拷贝，或者在uboot dts目录下选择一个其它目标板的dts为基础，再根据实际需求进行修改。修改完成后，在arch/arm/dts/Makefile中为其添加编译选项：
dtb-$(CONFIG_yyy) +=xxx.dtb
其中yyy为使用该dts的目标板
- 如何为目标板选择dts文件
uboot的设备树文件位于arch//dts目录下，可通过以下选项为目标板选择一个默认的dts文件：
CONFIG_DEFAULT_DEVICE_TREE="xxx”
这是因为与内核不一样，uboot最终的镜像会和dtb打包在一个镜像文件中，因此在编译流程中就需要知道最终被使用的dtb。关于uboot镜像与dtb之间的关系后续在分析，先梳理流程。
- 通过编译命令指定dts
有时在编译时希望使用一个不是默认指定的dts，则可以通过在编译命令中添加DEVICE_TREE=zzz方式指定新的dts文件，其示例如下：
make DEVICE_TREE=zzz
- 如何使能设备树
通过配置CONFIG_OF_CONTROL选项即可使能设备树的支持。
uboot与dtb可以有以下几种打包组合方式：
- 若定义了CONFIG_OF_EMBED选项，则在链接时会为dtb指定一个以__dtb_dt_begin开头的单独的段，dtb的内容将被直接链接到uboot.bin镜像中。官方建议这种方式只在开发和调试阶段使用，而不要用于生产阶段
- 若定义了CONFIG_OF_SEPARATE选项，dtb将会被编译为u-boot.dtb文件，而uboot原始镜像被编译为u-boot-nodtb.bin文件，并通过以下命令将它们连接为最终的uboot.bin文件：
cat u-boot-nodtb.bin u-boot.dtb >uboot.bin
驱动模型DM
U-boot驱动模型与linux的设备模型比较类似，利用它可以将设备与驱动分离。对上可以为同一类设备提供统一的操作接口，对下可以为驱动提供标准的注册接口，从而提高代码的可重用性和可移植性。同时，驱动模型通过树形结构组织uboot中的所有设备，为系统对设备的统一管理提供了方便。
驱动模型的结构
驱动模型主要用于管理系统中的驱动和设备，uboot为它们提供了以下描述结构体：
- driver结构体
driver结构体用于表示一个驱动，其定义如下:
struct driver {
char *name;
enum uclass_id id;
const struct udevice_id *of_match;
int (*bind)(struct udevice *dev);
int (*probe)(struct udevice *dev);
int (*remove)(struct udevice *dev);
int (*unbind)(struct udevice *dev);
int (*of_to_plat)(struct udevice *dev);
int (*child_post_bind)(struct udevice *dev);
int (*child_pre_probe)(struct udevice *dev);
int (*child_post_remove)(struct udevice *dev);
int priv_auto;
int plat_auto;
int per_child_auto;
int per_child_plat_auto;
const void *ops; /* driver-specific operations */
uint32_t flags;
#if CONFIG_IS_ENABLED(ACPIGEN)
struct acpi_ops *acpi_ops;
#endif
}
驱动可以通过以下接口注册到系统中：
#define U_BOOT_DRIVER(__name) \
ll_entry_declare(struct driver, __name, driver)
其中ll_entry_declare的定义如下：
#define ll_entry_declare(_type, _name, _list) \
_type _u_boot_list_2_##_list##_2_##_name __aligned(4) \
__attribute__((unused)) \
__section(".u_boot_list_2_"#_list"_2_"#_name)
即其会定义一个struct driver 类型的_u_boot_list_2_driver_2_#name变量，该变量在链接时需要被放在.u_boot_list_2_driver_2#_name段中。我们再看下这些section在链接脚本中是如何存放的，以下为armv8架构链接脚本arch/arm/cpu/armv8/u-boot.lds中的定义。
.u_boot_list : {
KEEP(*(SORT(.u_boot_list*)));
}
从定义可看到这些以.u_boot_list 开头的section都会被保存在一起，且它们会按照section的名字排序后再保存。这主要是为了便于遍历这些结构体，如我们需要遍历所有已经注册的driver，则可通过以下代码获取driver结构体的起始地址和总的driver数量。
struct driver *drv =
ll_entry_start(struct driver, driver); //获取已注册driver的起始地址
int n_ents = ll_entry_count(struct driver, driver); //获取已注册driver的数量
其中ll_entry_start和ll_entry_coun的定义如下：
#define ll_entry_start(_type, _list) \
({ \
static char start[0] __aligned(CONFIG_LINKER_LIST_ALIGN) \
__attribute__((unused)) \
__section(".u_boot_list_2_"#_list"_1"); \ //定义一个.u_boot_list_2_"#_list"_1的段，若需要遍历driver，则该段的名字为.u_boot_list_2_driver_1，即它位于所有实际driver section之前的位置
(_type *)&start; \
})
#define ll_entry_end(_type, _list) \
({ \
static char end[0] __aligned(4) __attribute__((unused)) \
__section(".u_boot_list_2_"#_list"_3"); \ //定义一个.u_boot_list_2_"#_list"_3的段，若需要遍历driver，则该段的名字为.u_boot_list_2_driver_3，即它位于所有实际driver section之后的位置
(_type *)&end; \
})
#define ll_entry_count(_type, _list) \
({ \
_type *start = ll_entry_start(_type, _list); \
_type *end = ll_entry_end(_type, _list); \
unsigned int _ll_result = end - start; \ //通过以上两个标号就可以很方便地获取驱动的起止地址和计算已注册驱动的总数
_ll_result; \
})
最后我们给出.u_boot_list_2类型section在内存中的布局图：
- uclass_driver结构体 uclass_driver结构体用于表示一个uclass驱动，其定义如下：
struct uclass_driver {
const char *name;
enum uclass_id id;
int (*post_bind)(struct udevice *dev);
int (*pre_unbind)(struct udevice *dev);
int (*pre_probe)(struct udevice *dev);
int (*post_probe)(struct udevice *dev);
int (*pre_remove)(struct udevice *dev);
int (*child_post_bind)(struct udevice *dev);
int (*child_pre_probe)(struct udevice *dev);
int (*child_post_probe)(struct udevice *dev);
int (*init)(struct uclass *class);
int (*destroy)(struct uclass *class);
int priv_auto;
int per_device_auto;
int per_device_plat_auto;
int per_child_auto;
int per_child_plat_auto;
uint32_t flags;
};
其注册和遍历方式与driver完全相同，只是结构体类型和section名有所不同，以下为其定义：
#define UCLASS_DRIVER(__name) \
ll_entry_declare(struct uclass_driver, __name, uclass_driver)
- udevice结构体
udevice在驱动模型中用于表示一个与驱动绑定的设备，其定义如下：
struct udevice {
const struct driver *driver;
const char *name;
void *plat_;
void *parent_plat_;
void *uclass_plat_;
ulong driver_data;
struct udevice *parent;
void *priv_;
struct uclass *uclass;
void *uclass_priv_;
void *parent_priv_;
struct list_head uclass_node;
struct list_head child_head;
struct list_head sibling_node;
#if !CONFIG_IS_ENABLED(OF_PLATDATA_RT)
u32 flags_;
#endif
int seq_;
#if !CONFIG_IS_ENABLED(OF_PLATDATA)
ofnode node_;
#endif
#ifdef CONFIG_DEVRES
struct list_head devres_head;
#endif
#if CONFIG_IS_ENABLED(DM_DMA)
ulong dma_offset;
#endif
}
系统中所有的udevice结构体可以通过parent、child_head和sibling_node连接在一起，并且最终挂到gd的dm_root节点上，这样我们就可以通过gd->dm_root遍历所有的udevice设备。下图是udevice的连接关系，其中每个节点的parent指向其父节点，sibling指向其兄弟节点，而child指向子节点。
由于每个udevice都属于一个uclass，因此除了被连接到gd->dm_root链表之外，udevice还会被挂到uclass的链表中。它们之间的连接关系将在下面介绍uclass时给出。
udevice是在驱动模型初始化流程中根据扫描到的设备动态创建的，在uboot中实际的设备可以通过以下两种方式定义：
- devicetree方式：这种方式通过devicetree维护设备信息，uboot在驱动模型初始化时，通过解析设备树获取设备信息，并完成其与驱动等的绑定
- 硬编码方式：这种方式可通过下面的宏定义一个设备：
#define U_BOOT_DRVINFO(__name) \
ll_entry_declare(struct driver_info, __name, driver_info)
- uclass结构体
uclass用于表示一类具有相同功能的设备，从而可以为其抽象出统一的设备访问接口，方便其它模块对它的调用。以下为uclass的定义：
struct uclass {
void *priv_;
struct uclass_driver *uc_drv;
struct list_head dev_head;
struct list_head sibling_node;
}
uclass将所有属于该类的设备挂到其dev_head链表上，同时系统中所有的uclass又会被挂到一张全局链表gd->uclass_root上。其结构如下图：
驱动模型的初始化
驱动模型初始化主要完成udevice、driver以及ucalss等之间的绑定关系，其主要包含以下部分：
- udevice与driver的绑定
- udevice与uclass的绑定
- uclass与uclass_driver的绑定
该流程通过dm_init_and_scan函数实现，它会分别扫描由U_BOOT_DRVINFO以及devicetree定义的设备，为它们分配udevice结构体，并完成其与driver和uclass之间的绑定关系等操作。需要注意的是该函数在board_init_f和board_init_r中都会被调用，其中board_init_f主要是为了解析重定位前需要使用的设备节点，这种类型节点在devicetree中会增加u-boot,dm-pre-reloc属性。这块代码流程比较清晰，有兴趣的同学可以自己分析一下。
环境变量
环境变量可以为uboot提供在运行时动态配置参数的能力，如在命令行通过修改环境变量bootargs可以改变内核的启动参数。它以env=value格式存储，其中每条环境变量之间以’\0’结尾。根据系统的配置参数，uboot在include/env_default.h中为系统定义了一份默认的环境变量：
#ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
env_t embedded_environment __UBOOT_ENV_SECTION__(environment) = {
#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
1,
#endif
{
#elif defined(DEFAULT_ENV_INSTANCE_STATIC)
static char default_environment[] = {
#elif defined(DEFAULT_ENV_IS_RW)
uchar default_environment[] = {
#else
const uchar default_environment[] = {
#endif
#ifndef CONFIG_USE_DEFAULT_ENV_FILE
#ifdef CONFIG_ENV_CALLBACK_LIST_DEFAULT
ENV_CALLBACK_VAR "=" CONFIG_ENV_CALLBACK_LIST_DEFAULT "\0"
#endif
#ifdef CONFIG_ENV_FLAGS_LIST_DEFAULT
ENV_FLAGS_VAR "=" CONFIG_ENV_FLAGS_LIST_DEFAULT "\0"
#endif
#ifdef CONFIG_USE_BOOTARGS
"bootargs=" CONFIG_BOOTARGS "\0"
#endif
#ifdef CONFIG_BOOTCOMMAND
"bootcmd=" CONFIG_BOOTCOMMAND "\0"
#endif
…
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
"\0"
#else
#include "generated/defaultenv_autogenerated.h"
#endif
#ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
}
#endif
};
在该环境变量中，board可通过重新定义CONFIG_EXTRA_ENV_SETTINGS的值设置其自身的默认环境变量，如对于qemu平台，其定义位于include/configs/qemu-arm.h：
#define CONFIG_EXTRA_ENV_SETTINGS \
"fdt_high=0xffffffff\0" \
"initrd_high=0xffffffff\0" \
"fdt_addr=0x40000000\0" \
"scriptaddr=0x40200000\0" \
"pxefile_addr_r=0x40300000\0" \
"kernel_addr_r=0x40400000\0" \
"ramdisk_addr_r=0x44000000\0" \
BOOTENV
环境变量被修改后可以保存到固定的存储介质上（如flash、mmc等），以便下一次启动后加载最新的值。Uboot通过U_BOOT_ENV_LOCATION宏定义环境变量的存储位置，例如对于mmc其定义如下（env/mmc.c）：
U_BOOT_ENV_LOCATION(mmc) = {
.location = ENVL_MMC,
ENV_NAME("MMC")
.load = env_mmc_load,
#ifndef CONFIG_SPL_BUILD
.save = env_save_ptr(env_mmc_save),
.erase = ENV_ERASE_PTR(env_mmc_erase)
#endif
}
环境变量在mmc中的具体存储位置可通过配置选项或devicetree设置，如对于mmc：
- devicetree方式可在/config节点中设置以下属性
u-boot,mmc-env-partition：指定环境变量存储的分区，环境变量会被存储在在该分区的结尾处
u-boot,mmc-env-offset：若未定义u-boot,mmc-env-partition属性，则该参数用于指定环境变量在mmc裸设备上的偏移
u-boot,mmc-env-offset-redundant：指定备份环境变量在mmc设备上的偏移
- 通过配置参数设置
CONFIG_ENV_OFFSET：与u-boot,mmc-env-offset含义相同
CONFIG_ENV_OFFSET_REDUND：与u-boot,mmc-env-offset-redundant含义相同
下面的选项用于配置环境变量的长度及其保存的设备：
（1）CONFIG_ENV_SIZE：环境变量的最大长度
（2）CONFIG_ENV_IS_IN_XXX（如CONFIG_ENV_IS_IN_MMC）：环境变量保存的设备类型
（3）CONFIG_SYS_MMC_ENV_DEV：环境变量保存的设备编号
uboot对保存在固定介质中的环境变量会使用crc32校验数据的完整性，若数据被破坏了则会使用默认环境变量重新初始化环境变量的值。
Board_init_f和board_init_r函数流程
board_init_f和board_init_r的函数逻辑都比较清晰，下面我们只给出其调用流程图，而不再深入其细节了。
board_init_f流程
board_init_f是uboot重定位前的流程，它包括一些基础模块的初始化和重定位相关的准备工作。以下为该函数在armv8架构下可能的执行流程，图中虚线框表示该流程是可配置的，实线框表示是必选的。
board_init_r流程
board_init_r是uboot重定位后需要执行的流程，它包含基础模块、硬件驱动以及板级特性等的初始化，并最终通过run_main_loop启动os会进入命令行窗口。
后记
board_init_f与board_init_r的分界点是重定位。
- 以下是run_main_loop的后续流程，粗粗整理一下。还有待于完善
- do_bootcmd
- 加载linux内核
相关文章
- docker高级篇第三章-dockerfile案例之制作自己的centos镜像
- Lightroom Classic 2022 for Mac(Lrc2022) 11.5中文版
- java基于ssh的旅游系统
- java论坛贴子网站ssm论坛项目发帖子网站论坛系统论坛源码
- java美食论坛系统发帖子系统美食论坛网站美食分享论坛源码
- ACDSee 2023软件下载和安装教程
- ACDSee 2022软件下载和安装教程
- LPCG：用激光点云指导单目的3D物体检测
- ACDSee 2021软件下载和安装教程
- ACDSee 2020软件下载和安装教程
- ACDSee 2019软件下载和安装教程
- 深度学习算法原理——RCNN
- 2023年机器学习趋势分析
- 实时语义SLAM：激光+IMU+GPS/MAV
- VP-SLAM：具有点、线和灭点的单目实时VSLAM
- Adobe Acrobat 9 Pro软件安装教程（一款强大的PDF编辑软件）
- PDF编辑器Acrobat DC（PDF） 功能简介+安装破解
- PDF编辑软件：Adobe Acrobat DC
- Acrobat DC 2019 For Mac软件安装教程
- Acrobat Pro DC2021软件安装教程