ARM uboot源码分析1-启动第一阶段

最新推荐文章于 2024-01-01 15:11:41 发布

滨边美波她男友

最新推荐文章于 2024-01-01 15:11:41 发布

阅读量484

点赞数

分类专栏： ARM S5PV210 朱有鹏文章标签： ARM 嵌入式 linux arm开发 s5pv210

本文链接：https://blog.csdn.net/weixin_42109053/article/details/128853916

版权

ARM S5PV210 朱有鹏专栏收录该内容

95 篇文章 36 订阅

订阅专栏

文章详细介绍了u-boot的入口点start.S的引入和解析，包括入口点的确定、头文件的包含、启动代码的16字节头部、异常向量表的构建、栈的设置以及lowlevel_init函数的初步执行。内容涉及汇编语言、链接脚本、系统初始化等多个方面。

摘要由CSDN通过智能技术生成

一、start.S 引入

1、u-boot.lds 中找到 start.S 入口

(1) 在 C 语言中整个项目的入口就是 main 函数（这是 C 语言规定的），所以譬如说一个有 10000 个.c 文件的项目，第一个要分析的文件就是包含了 main 函数的那个文件。

(2) 在 uboot 中因为有汇编阶段参与，因此不能直接找 main.c。整个程序的入口取决于链接脚本中 ENTRY 声明的地方
ENTRY(_start) 。因此 _start 符号所在的文件就是整个程序的起始文件，_start 所在处的代码就是整个程序的起始代码。

在这里插入图片描述

二、start.S 解析1

在这里插入图片描述

1、不简单的头文件包含

(1) #include <config.h>。config.h 是在 include 目录下的，这个文件不是源码中本身存在的文件，而是配置过程中自动生成的文件。（详见 mkconfig 脚本）。这个文件的内容其实是包含了一个头文件：#include <configs/x210_sd.h>".
在这里插入图片描述

(2) 经过分析后，发现 start.S 中包含的第一个头文件就是：include/configs/x210_sd.h，这个文件是整个 uboot 移植时的配置文件。这里面是好多宏。因此这个头文件包含将 include/configs/x210_sd.h 文件和 start.S 文件关联了起来。因此之后在分析start.S 文件时，主要要考虑的就是 x210_sd.h 文件。

在这里插入图片描述

(3) #include <version.h>。include/version.h 中包含了 include/version_autogenerated.h ，这个头文件就是配置过程中自动生成的。里面就一行内容：#define U_BOOT_VERSION "U-Boot 1.3.4"。这里面定义的宏 U_BOOT_VERSION 的值是一个字符串，字符串中的版本号信息来自于 Makefile 中的配置值。这个宏在程序中会被调用，在 uboot 启动过程中会串口打印出 uboot 的版本号，那个版本号信息就是从这来的。

在这里插入图片描述

(4) #include <asm/proc/domain.h>。asm 目录不是 uboot 中的原生目录，uboot 中本来是没有这个目录的。asm 目录是配置时创建的一个符号链接，实际指向的就是 asm-arm（详解上一章节分析 mkconfig 脚本时）.

在这里插入图片描述

(5) 经过分析后发现，实际文件是：include/asm-arm/proc-armv/domain.h

(6) 从这里可以看出之前配置时创建的符号链接的作用，如果没有这些符号链接则编译时根本通不过，因为找不到头文件。（所以 uboot 不能在 windows 的共享文件夹下配置编译，因为 windows 中没有符号链接）

思考：为什么 start.S 不直接包含 asm-arm/proc-armv/domain.h，而要用 asm/proc/domain.h。这样的设计主要是为了可移植性。因为如果直接包含，则 start.S 文件和 CPU 架构（和硬件）有关了，可移植性就差了。譬如我要把 uboot 移植到 mips 架构下，则 start.S 源代码中所有的头文件包含全部要修改。我们用了符号链接之后，则 start.S 中源代码不用改，只需要在具体的硬件移植时配置不同，创建的符号链接指向的不同，则可以具有可移植性。

三、start.S 解析2

1、启动代码的 16 字节头部

在这里插入图片描述

(1) 裸机中讲过，在 SD 卡启动/ Nand 启动等，整个镜像开头需要 16 字节的校验头。（mkv210image.c 中就是为了计算这个校验头）。我们以前做裸机程序时根本没考虑这 16 字节校验头，因为：

如果我们是 usb 启动直接下载的方式启动的，则不需要 16 字节校验头（irom application note）；
如果是 SD 卡启动，mkv210image.c 中会给原镜像前加 16 字节的校验头。

在这里插入图片描述

(2) uboot 这里 start.S 中在开头位置放了 16 字节的填充占位，这个占位的 16 字节只是保证正式的 image 的头部确实有 16 字节，但是这 16 字节的内容是不对的，还是需要后面去计算校验和然后重新填充的。

2、异常向量表的构建

在这里插入图片描述

(1) 异常向量表是硬件决定的，软件只是参照硬件的设计来实现它。

(2) 异常向量表中每种异常都应该被处理，否则真遇到了这种异常就跑飞了。但是我们在 uboot 中并未非常细致的处理各种异常。

(3) 复位异常处的代码是：b reset，因此在 CPU 复位后真正去执行的有效代码是 reset 处的代码，因此 reset 符号处才是真正的有意义的代码开始的地方。

3、有点意思的 deadbeef

在这里插入图片描述

(1) .balignl 16,0xdeadbeef. 这一句指令是让当前地址对齐排布；如果当前地址不对齐，则自动向后走地址直到对齐，并且向后走的那些内存要用 0xdeadbeef 来填充。

(2) 0xdeadbeef 这是一个十六进制的数字，这个数字很有意思，组成这个数字的十六进制数全是 abcdef 之中的字母，而且这 8 个字母刚好组成了英文的 dead beef 这两个单词，字面意思是坏牛肉。

(3) 为什么要对齐访问？有时候是效率的要求，有时候是硬件的特殊要求。

4、TEXT_BASE 等

在这里插入图片描述

(1) 第 100 行这个 TEXT_BASE 就是上个课程中分析 Makefile 时讲到的那个配置阶段的 TEXT_BASE，其实就是我们链接时指定的 uboot 的链接地址。（值就是 c3e00000）

(2) 源代码中和配置 Makefile 中很多变量是可以互相运送的。简单来说有些符号的值可以从 Makefile 中传递到源代码中。

在这里插入图片描述

四、start.S 解析3

在这里插入图片描述

(1) CFG_PHY_UBOOT_BASE 33e00000 uboot 在 DDR 中的物理地址

1、设置 CPU 为 SVC 模式

在这里插入图片描述

(1) msr cpsr_c, #0xd3 将 CPU 设置为禁止 FIQ 、IRQ，ARM 状态，SVC 模式。

(2) 其实 ARM CPU 在复位时默认就会进入 SVC 模式，但是这里还是使用软件将其置为 SVC 模式。整个 uboot 工作时 CPU 一直处于 SVC 模式。

2、设置 L2、L1cache 和 MMU

在这里插入图片描述

(1) bl disable_l2cache // 禁止L2 cache
(2) bl set_l2cache_auxctrl_cycle // l2 cache 相关初始化
(3) bl enable_l2cache // 使能 l2 cache
(4) 刷新 L1 cache 的 icache 和 dcache。
(5) 关闭 MMU.
总结：上面这 5 步都是和 CPU 的 cache 和 mmu 有关的，不用去细看，大概知道即可。