7628 uboot启动流程

SNOWPIAOP

已于 2023-01-22 20:11:10 修改

阅读量1.7k

点赞数

分类专栏： uboot 文章标签： UBOOT

于 2023-01-19 10:53:25 首次发布

本文链接：https://blog.csdn.net/snowpiaop/article/details/128733347

版权

uboot 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

7628 uboot启动流程图

uboot启动过程如图：

7628的uboot加载内核实例

首先拿7628来举例说明上述流程。作为对比，后面还会拿7621来举例。两者的差别是7628是linux 2.6时代的，很老的实现，采用的是遗留类型的内核。而7621已经是linux 4时代，uboot已经不仅支持遗留类型的，还支持所谓fit类型的内核，而且7621是用nand flash。

op1-3: 2次搬头部代码到内存地址1

这里要详细讨论的细节是：
谁去搬？
为什么要搬到内存去，不能直接用？
具体是从flash哪个位置去搬？这个位置怎么来的？
那里有什么？
怎么搬法？
第一次搬了些什么？为什么只搬这些？
搬到哪内存位置？这个位置又是哪来的？

第一个问题：谁去搬？
显然，这时，控制权还在uboot，则完成了ddr的初始化之后，要启动内核了，所以uboot要负责将flash的内核代码搬到内存中运行。
为什么要搬到内存中运行呢？主要还是内核的代码太大了啊，flash放不下。flash只保存了经过压缩的内核代码。
具体从哪位置去搬呢？这个和板子以及flash布局是密切相关的。
我手上这块7628的板子，8m的flash大小，其布局是先放uboot，再放一些uboot的环境配置，然后，再放内核和文件系统。是可以算出来这个内核所在的flash偏移位置的。再根据flash在系统中的基存内存地址，就可以计算出来uboot要访问的地址值了。
那这个flash地址里放的是什么呢？具体组成是怎么样的呢？
这主要是内核相关信息，具体组成由2部分：
第一部分，160字节的厂商自定义内核信息头
第二部分，是uimage镜像再经过某种加工之后的内容，大小在第一部分指定

起始地址	结束地址	存放内容	大小(字节)
0x0000000	0x0000009f	厂商自定义头	160
0x00000a0	由头指定大小	uImage再加工内容	由头指定大小

头部160又切成两部分
64+96
64字节主要存放了厂商的标志，用来web升级时校验固件是否为本厂商的固件用。还存放了镜像的大小。
96字节则更细致地描述了固件的方方面面细节，包括版本字符串信息、固件大小。
可以理解为，这160字节，可以详尽地了解内核文件的总体概况。但还不包括内核实际压缩算法这类信息。这类信息需要在uImage头里解读。
可以简单描述为打包工具在uimage再加工内容之外再套了一层头部信息，供升级时校验使用。当然，也就影响了uboot加载内核相关的代码。移植之后的uboot也要相应支持对这个头的处理。

了解了这个组成之后，就可以回答，第一次要搬的内容了。
第一次搬的就是这个厂商头。
如果厂商头都不对，也就不需要再往下走了。
搬这个很少字节的厂商头，就可以知道实际的镜像大小，以便第二次搬完整内核代码。
最后一个问题：搬到哪去？
这个目的地址是uboot里随便指定就可以。和内核没有什么相关性。
根据7628的内存布局。
ddr内存条映射到系统地址空间是从0x80000000位置开始。
所以uboot把它搬到了0x80050000这里，也就是给前面预留了320k空间，以便于在前面插入一些其他数据.
这个地址的选择并没有什么特别的意义。只要是合法内存范围，又不要太靠内存起始位置就行。

这个操作，如果用tftp指令来手工替代的话，可以执行

tftp 0x80050000 SDXV100R001.bin

op4:跳到内存地址1+头大小偏移量位置，执行机器码

按照上述分析，这个位置的机器码是uImage再加工的内容，还不是uimage的头，因此，不能直接就可以转换成uImage旧版标准头，即op5的工作还不能在内存地址1+160这里直接做，所以有了这一步go内存的处理。
这一步的处理，实际是完成uimage再加工动作逆向加工，例如原先UIMAGE是经过压缩的，则这一步就是解压缩。以便将uimage数据还原出来。
这个操作，也可以手工完成：

go 0x800500a0

这一步成功的基础是，SDXV100R001.bin的偏移160字节处，有一段在UBOOT下可执行的代码。
具体可参见另文章《uboot环境中运行HELLOWORLD》的原理分析。
这处代码是某个.C经LD转成ELF之后，再经过OBJCOPY处理之后得到可在UBOOT执行的BIN，然后打包时，放到这个位置。

op5:内存地址2转换成uImage旧版标准头

OP4经过反加工操作之后，uImage的内容才真正露出来到内存地址2。
内存2在7628中指向0x80c00000.
从OP5开始，实际上就是bootm 操作。用命令行可以取代：

bootm 0x80c00000

OP6-OP9都是bootm的执行过程。

那么，这是目前的方案而已，针对打包方式相应的解包方法一一呼应。
换一种方案，如果flash中保存的内容变成uImage内容，即变成如下图，那么就会有另一种解包方案，让uboot直接拿内存地址1+160偏移位置的数据转成uimage旧版标准头，即省去步骤4的go：

起始地址	结束地址	存放内容	大小(字节)
0x0000000	0x0000009f	厂商自定义头	160
0x00000a0	由头指定大小	uImage内容	由头指定大小

这个方法，也可以把SDXXXX.bin中uImage内核运行起来。

tftp 0x80bfff60 SDXV100R001.bin
File: cmd_net.c, Func: do_tftpb, Line: 56
load addr= 0x80bfff60
boot file= SDXV100R001.bin
TFTP from server 192.168.100.191; our IP address is 192.168.100.2
Filename 'A200V100R006.bin'.
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #######################################################Bytes transferred = 3940352 (3c2000 hex)
<RGS>bootm 0x80c00000
## Booting image at 80c00000 ...
   Image Name:   Linux Kernel Image
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    1724414 Bytes =  1.6 MB
   Load Address: 80001000
   Entry Point:  8000d1d0
   Verifying Checksum ... OK
OK
No initrd
## Transferring control to Linux (at address 8000d1d0) ...
## Giving linux memsize in MB, 64

Starting kernel ...