本文是基于arm平台。例子都是以tiny210(s5pv210 armv7)为基础的。
[kernel 启动流程]系列:
- [kernel 启动流程] 前篇——vmlinux.lds分析
- [kernel 启动流程] (第一章)概述
- [kernel 启动流程] (第二章)第一阶段之——设置SVC、关闭中断
- [kernel 启动流程] (第三章)第一阶段之——proc info的获取
- [kernel 启动流程] (第四章)第一阶段之——dtb的验证
- [kernel 启动流程] (第五章)第一阶段之——临时内核页表的创建
- [kernel 启动流程] (第六章)第一阶段之——打开MMU
- [kernel 启动流程] (第七章)第一阶段之——跳转到start_kernel
建议参考文档:
================================================
零、说明
本文是《[kernel 启动流程] (第一章)概述》的延伸,
阅读本文前建议先阅读《[kernel 启动流程] (第一章)概述》
1、kernel启动流程第一阶段简单说明
arch/arm/kernel/head.S
- kernel入口地址对应stext
- 1
-
第一阶段要做的事情,也就是stext的实现内容
- 设置为SVC模式,关闭所有中断
- 获取CPU ID,提取相应的proc info
- 验证tags或者dtb
- 创建页表项
- 配置r13寄存器,也就是设置打开MMU之后要跳转到的函数。
- 使能MMU
- 跳转到start_kernel,也就是跳转到第二阶段
本文要介绍的是“验证tags或者dtb的合法性”的部分。因为现在基本上很少使用atags,所以这里我们只说dtb的部分。
2、疑问
主要带着以下几个问题去理解
- dtb是什么?为什么要验证dtb的合法性?
- 如何验证dtb的合法性?
3、对应代码实现
- 1
- 2
- 3
- 4
- 5
- 6
- 7
一、DTB说明
这部分建议直接参考wowo的dtb的文章
Device Tree(一):背景介绍
Device Tree(二):基本概念
Device Tree(三):代码分析
简单说明,dtb里面存放了各种硬件信息,如果dtb有问题,会导致后续开机过程中读取的设备信息有问题而导致无法开机。
二、如何验证了一个dtb是否合法
1、原理说明
在生成dtb的时候会在头部上添加一个幻数magic,而验证dtb是否合法主要也就是看这个dtb的magic是否和预期的值一致。
2、dtb结构如下
结构体如下 |
---|
DTB header |
alignment gap |
memory reserve map |
alignment gap |
device-tree structure |
alignment gap |
device-tree string |
3、dtb header结构如下:
结构体如下 |
---|
magic |
totalsize |
off_dt_struct |
off_dt_strings |
off_mem_rsvmap |
version |
…… |
其中,magic是一个固定的值,0xd00dfeed(大端)或者0xedfe0dd0(小端)。
以s5pv210-tiny210.dtb为例:
执行”hexdump -C s5pv210-tiny210.dtb | more”命令
- 1
- 2
- 3
可以看到dtb的前面4个字节就是0xd00dfeed,也就是magic。
综上,我们只要提取待验证dtb的地址上的数据的前四个字节,与0xd00dfeed(大端)或者0xedfe0dd0(小端)进行比较,如果匹配的话,就说明对应待验证dtb就是一个合法的dtb。
三、代码分析
具体就是分析__vet_atags的实现。
通过《[kernel 启动流程] (第一章)概述》,我们已经知道r2上存放的是dtb的地址指针,而代码中所要做的,就是要通过这个地址指针,获取前四个字节,去和dtb应有的幻数,也就是0xd00dfeed(大端)或者0xedfe0dd0(小端)进行比较。匹配的话,则说明这是一个合法的dtb。
代码如下(省略了验证atags的部分):
arch/arm/kernel/head-common.S
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
DTB的幻数,也就是OF_DT_MAGIC定义如下:
arch/arm/kernel/head-common.S
- 1
- 2
- 3
- 4
- 5
综上,验证dtb的工作完成。