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镜像再经过某种加工之后的内容，大小在第一部分指定

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

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

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

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

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

第四步经过反加工操作之后，uImage的内容才真正露出来到内存地址2。
内存2在7628中指向0x80c00000.

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