UBOOT源码分析

合集下载

Uboot中start.S源码的指令级的详尽解析+v1.6

3. start.S 的总结 ....................................................................................................................... 63 3.1. start.S 各个部分的总结.............................................................................................63 3.2. Uboot 中的内存的 Layout.......................................................................................64
Uboot中start.S源码的指令级的详尽解析
Version: 1.6 Author: green-waste (at)
目录
1. 正文乊前 .................................................................................................................................. 4 1.1. 本文内容........................................................................................................................4 1.2. 本文目标........................................................................................................................4 1.3. 代码来源..........................................4 1.4. 关亍本文内容的组织形式............................................................................................4 1.5. 阅读此文所要具有的前提知识....................................................................................5 1.6. 声明................................................................................................................................5

uboot之relocate代码的深入理解

uboot之relocate代码的深入理解在读网络原理时，发现Dave Clark说的一句话“我们拒绝国王，总统和选举。

我们信奉的是是大体的一致意见和正在执行的代码”在读linux0.11内核时，发现linus说的一句话，“要了解系统真正的运行机制，一切尽在源代码中”。

在读众多的关于uboot移植的文档如，大家却在说“第一阶段~~~~第二阶段~~~~~”，“ 这一段完成~~~~”却很少见到讲解过start_armboot()函数是怎么实现的，只是笼统的说完成神马神马的初始化~~在今天之前看了那么多文档，发现自己对uboot说的是头头是道，“第一阶段~~第二阶段~~”，然后移植到自己板子上，则是两眼一摸黑，神马都不知道~~~然而就是今天，就在写这篇文档之前。

我才发现了uboot真正的执行与实现原理。

而达到这一步的最初动力就是：要看看uboot到底是怎么执行的，而不光是知道它“应该”是怎么执行的和它的流程。

在不懂得代码操作过程而只知道执行流程的时候，知道的执行流程只能是浮云~~~而要根根据自己的板子实际的改动uboot中的代码那就更别谈了。

于是，深入到uboot 的代码中去，尽管有些代码很难懂，尽管有些函数，宏定义根本不知道放在哪，但总是能找到的，总是能看懂的~只要方向正确，哪怕多走点路，也总能是到达目的地的~~至此，才真正算是明白学习之道：多看，多想，多写~~~还是那句话：除了代码，神马都是浮云！这两天天气突然转冷，就刚才由大雪籽转而飘起了大雪，手也开始不听使唤的抖动起来了。

自己的对uboot的理解也逐渐深入了，下面就一段段的写下，加深印象吧这两天天气突然转冷，就刚才由大雪籽转而飘起了大雪，手也开始不听使唤的抖动起来了。

uboot移植与源码分析总结（6）-Nand驱动

uboot移植与源码分析总结（6）-Nand驱动uboot移植与源码分析总结(6)-Nand驱动2013-06-29 11:32:17分享：有关nand flash的特性描述，可以见我之前写的这篇文章《NandFlash结构与分析》。

从功能上来说，nand flash与norflash 并无太大差异，主要区别在于操作接口和方式。

Nand基于非sram总线接口，使用nand接口，所以一般需要mcu具有nand控制器才可与其连接。

在读取时，以页为单位；擦除和写入时，以块为单位。

将nand视作一个MTD设备uboot将nand视作一个mtd设备，所以使用mtd机制对nand 设备进行管理。

单个nand设备用nand_info_t来描述。

而nand_info_t实际上就是mtd结构。

最多支持的nand设备数CONFIG_SYS_MAX_NAND_DEVICE可由开发者自行配置。

不过一般目标板上只有一块Nand设备，所以取值通常为1。

但是仅使用mtd结构来描述不够，因为MTD只是一个通用的存储描述结构，而Nand设备特定的某些属性，如ECC布局等不能简单的添加到mtd结构中。

所以，uboot定义了nand_chip结构。

int (*verify_buf)(struct mtd_info *mtd, const uint8_t *buf, int len);void (*select_chip)(struct mtd_info *mtd, int chip);int (*block_bad)(struct mtd_info *mtd, loff_t ofs, int getchip);int (*block_markbad)(struct mtd_info *mtd, loff_t ofs);void (*cmd_ctrl)(struct mtd_info *mtd, int dat, unsigned int ctrl);int (*init_size)(struct mtd_info *mtd, struct nand_chip *this, u8 *id_data);int (*dev_ready)(struct mtd_info *mtd);void (*cmdfunc)(struct mtd_info *mtd, unsigned command, int column,int page_addr);int(*waitfunc)(struct mtd_info *mtd, struct nand_chip *this);void (*erase_cmd)(struct mtd_info *mtd, int page);int (*scan_bbt)(struct mtd_info *mtd);int (*errstat)(struct mtd_info *mtd, struct nand_chip *this, int state,int status, int page);int (*write_page)(struct mtd_info *mtd, struct nand_chip *chip,const uint8_t *buf, int page, int cached, int raw);int chip_delay;unsigned int options;int page_shift;int phys_erase_shift;int bbt_erase_shift;int chip_shift;int numchips;uint64_t chipsize;然后，分配了CONFIG_SYS_MAX_NAND_DEVICE个nand_chip 结构。

uboot代码详细分析

uboot代码详细分析目录u-boot-1.1.6之cpu/arm920t/start.s分析 (2)u-boot中.lds连接脚本文件的分析 (12)分享一篇我总结的uboot学习笔记（转） (15)U-BOOT内存布局及启动过程浅析 (22)u-boot中的命令实现 (25)U-BOOT环境变量实现 (28)1.相关文件 (28)2.数据结构 (28)3.ENV的初始化 (30)3.1env_init (30)3.2env_relocate (30)3.3env_relocate_spec (31)4.ENV的保存 (31)U-Boot环境变量 (32)u-boot代码链接的问题 (35)ldr和adr在使用标号表达式作为操作数的区别 (40)start_armboot浅析 (42)1.全局数据结构的初始化 (42)2.调用通用初始化函数 (43)3.初始化具体设备 (44)4.初始化环境变量 (44)5.进入主循环 (44)u-boot编译过程 (44)mkconfig文件的分析 (47)从NAND闪存中启动U-BOOT的设计 (50)引言 (50)NAND闪存工作原理 (51)从NAND闪存启动U-BOOT的设计思路 (51)具体设计 (51)支持NAND闪存的启动程序设计 (51)结语 (53)参考文献 (53)U-boot给kernel传参数和kernel读取参数—structtag(以及补充) (53)1、u-boot给kernel传RAM参数 (54)2、Kernel读取U-boot传递的相关参数 (56)3、关于U-boot中的bd和gd (59)U-BOOT源码分析及移植 (60)一、u-boot工程的总体结构： (61)1、源代码组织 (61)2.makefile简要分析 (61)3、u-boot的通用目录是怎么做到与平台无关的？ (63)4、smkd2410其余重要的文件： (63)二、u-boot的流程、主要的数据结构、内存分配 (64)1、u-boot的启动流程： (64)2、u-boot主要的数据结构 (66)3、u-boot重定位后的内存分布： (68)三、u-boot的重要细节。

U-Boot启动过程--详细版的完全分析

(一)U-Boot启动过程--详细版的完全分析我们知道，bootloader是系统上电后最初加载运行的代码。

它提供了处理器上电复位后最开始需要执行的初始化代码。

在PC机上引导程序一般由BIOS开始执行，然后读取硬盘中位于MBR(Main Boot Record，主引导记录)中的Bootloader(例如LILO或GRUB),并进一步引导操作系统的启动。

然而在嵌入式系统中通常没有像BIOS那样的固件程序，因此整个系统的加载启动就完全由bootloader来完成。

它主要的功能是加载与引导内核映像一个嵌入式的存储设备通过通常包括四个分区：第一分区：存放的当然是u-boot第二个分区：存放着u-boot要传给系统内核的参数第三个分区：是系统内核（kernel）第四个分区：则是根文件系统如下图所示：u-boot是一种普遍用于嵌入式系统中的Bootloader。

Bootloader介绍Bootloader是进行嵌入式开发必然会接触的一个概念，它是嵌入式学院<嵌入式工程师职业培训班>二期课程中嵌入式linux系统开发方面的重要内容。

本篇文章主要讲解Bootloader 的基本概念以及内部原理，这部分内容的掌握将对嵌入式linux系统开发的学习非常有帮助！Bootloader的定义：Bootloader是在操作系统运行之前执行的一小段程序，通过这一小段程序，我们可以初始化硬件设备、建立内存空间的映射表，从而建立适当的系统软硬件环境，为最终调用操作系统内核做好准备。

意思就是说如果我们要想让一个操作系统在我们的板子上运转起来，我们就必须首先对我们的板子进行一些基本配置和初始化，然后才可以将操作系统引导进来运行。

具体在Bootloader中完成了哪些操作我们会在后面分析到，这里我们先来回忆一下PC的体系结构：PC机中的引导加载程序是由BIOS和位于硬盘MBR中的OS Boot Loader（比如LILO和GRUB等）一起组成的，BIOS在完成硬件检测和资源分配后，将硬盘MBR中的Boot Loader读到系统的RAM中，然后将控制权交给OS Boot Loader。

分析uboot生成bin文件完整过程

2. Create a new directory to hold your board specific code. Add any
files you need. In your board directory, you will need at least
/*
#date:2012-11-13
#从 make XXX_config --> make -->生成 u-boot.bin文件
#逐步展开分析
#我们以smdk2410为例展开分析.
#~^~要真正掌握u-boot的移植,我们有2件事需要去做.
#(1)分析makefile、链接脚本等相关的文件,以达到了解u-boot的架构,掌握u-boot的实现过程
"Makefile" and to the "MAKEALL" script, using the existing
entries as examples. Note that here and at many other places
For the Cogent platform, you need to specify the cpu type as well;
e.g. "make cogent_mpc8xx_config". And also configure the cogent
directory according to the instructions in cogent/README.
config.mk lib_i386 nios2_config.mk
COPYING lib_m68k nios_config.mk
cpu lib_microblaze post

uboot源码分析（2）uboot环境变量实现简析

uboot源码分析（2）uboot环境变量实现简析uboot 环境变量实现简析----------基于u-boot-2010.03u-boot的环境变量是使⽤u-boot的关键，它可以由你⾃⼰定义的，但是其中有⼀些也是⼤家经常使⽤，约定熟成的，有⼀些是u-boot⾃⼰定义的，更改这些名字会出现错误，下⾯的表中我们列出了⼀些常⽤的环境变量：bootdelay 执⾏⾃动启动的等候秒数baudrate 串⼝控制台的波特率netmask 以太⽹接⼝的掩码ethaddr 以太⽹卡的⽹卡物理地址bootfile 缺省的下载⽂件bootargs 传递给内核的启动参数bootcmd ⾃动启动时执⾏的命令serverip 服务器端的ip地址ipaddr 本地ip 地址stdin 标准输⼊设备stdout 标准输出设备stderr 标准出错设备上⾯只是⼀些最基本的环境变量，请注意，板⼦⾥原本是没有环境变量的，u-boot的缺省情况下会有⼀些基本的环境变量，在你执⾏了saveenv之后，环境变量会第⼀次保存到flash或者eeprom中，之后你对环境变量的修改,保存都是基于保存在flash中的环境变量的操作。

环境变量可以通过printenv命令查看环境变量的设置描述，通过setenv 命令进⾏重新设置，设置完成后可以通过saveenv将新的设置保存在⾮易失的存储设备中（nor flash 、nand flash 、eeprom）。

例如：setenv bootcmd "nand read 0x30008000 0x80000 0x500000;bootm 0x30008000"saveenv通过这两条命令就完成了环境变量bootcmd的重新设置，并讲其保存在固态存储器中。

下⾯简单分析下uboot中环境变量的实现流程。

uboot启动后，执⾏玩start.S中的汇编程序，将跳⼊board.c 中定义的start_arm_boot()函数中，在该函数中，uboot讲完成板⼦外设和相关系统环境的初始化，然后进⼊main_loop循环中进⾏系统启动或者等待与⽤户交互，这其中就包括环境变量的初始化和重定位。

BOOT详解

1 U-Boot简介U-Boot，全称Universal BootLoader，是遵循GPL条款的开放源码项目。

从FADSROM、8xxROM、PPCBOOT逐步发展演化而来。

其源码目录、编译形式与Linux内核很相似，事实上，不少U-Boot源码就是相应的Linux内核源程序的简化，尤其是一些设备的驱动程序，这从U-Boot源码的注释中能体现这一点。

但是U-Boot不仅仅支持嵌入式Linux系统的引导，当前，它还支持NetBSD,VxWorks, QNX, RTEMS, ARTOS,LynxOS嵌入式操作系统。

其目前要支持的目标操作系统是OpenBSD, NetBSD,FreeBSD,4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR,VxWorks, LynxOS, pSOS, QNX, RTEMS,ARTOS。

这是U-Boot中Universal的一层含义，另外一层含义则是U-Boot除了支持PowerPC系列的处理器外，还能支持MIPS、x86、ARM、NIOS、XScale等诸多常用系列的处理器。

这两个特点正是U-Boot 项目的开发目标，即支持尽可能多的嵌入式处理器和嵌入式操作系统。

就目前来看，U-Boot 对PowerPC系列处理器支持最为丰富，对Linux的支持最完善。

其它系列的处理器和操作系统基本是在2002年11月PPCBOOT改名为U-Boot后逐步扩充的。

从PPCBOOT向U-Boot 的顺利过渡，很大程度上归功于U-Boot的维护人德国DENX软件工程中心WolfgangDenk[以下简称W.D]本人精湛专业水平和持着不懈的努力。

当前，U-Boot项目正在他的领军之下，众多有志于开放源码BOOTLOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入，以支持更多的嵌入式操作系统的装载与引导。

am335xu-boot启动过程分析

am335xu-boot启动过程分析 u-boot属于两阶段的bootloader，第⼀阶段的⽂件为 arch/arm/cpu/armv7/start.S 和 arch/arm/cpu/armv7/lowlevel_init.S，前者是平台相关的，后者是开发板相关的。

1. u-boot第⼀阶段代码分析（1）硬件设备初始化将CPU的⼯作模式设为管理模式（SVC）；关闭中断；禁⽤MMU,TLB ; 板级初始化；（2）为加载Bootloader的第⼆阶段代码准备RAM空间加载u-boot.img，跳转到u-boot.img；上述⼯作，也就是uboot-spl代码流程的核⼼。

代码如下：arch/arm/cpu/armv7/start.S1/*2 * the actual reset code3*/4reset:5 bl save_boot_params6/*7 * disable interrupts (FIQ and IRQ), also set the cpu to SVC32 mode,8 * except if in HYP mode already9*/10 mrs r0, cpsr11 and r1, r0, #0x1f @ mask mode bits12 teq r1, #0x1a @ test for HYP mode13 bicne r0, r0, #0x1f @ clear all mode bits14 orrne r0, r0, #0x13 @ set SVC mode15 orr r0, r0, #0xc0 @ disable FIQ and IRQ16 msr cpsr,r017@@ 以上通过设置CPSR寄存器⾥设置CPU为SVC模式，禁⽌中断18@@ 具体操作可以参考《[kernel 启动流程] （第⼆章）第⼀阶段之——设置SVC、关闭中断》的分析1920/* the mask ROM code should have PLL and others stable */21#ifndef CONFIG_SKIP_LOWLEVEL_INIT22 bl cpu_init_cp1523@@ 调⽤cpu_init_cp15，初始化协处理器CP15,从⽽禁⽤MMU和TLB。

uboot启动代码详细讲解

·1 引言在专用的嵌入式板子运行 GNU/Linux 系统已经变得越来越流行。

一个嵌入式 Linux 系统从软件的角度看通常可以分为四个层次：1. 引导加载程序。

固化在固件(firmware)中的 boot 代码，也就是 Boot Loader，它的启动通常分为两个阶段。

2. Linux 核。

特定于嵌入式板子的定制核以及核的启动参数。

3. 文件系统。

包括根文件系统和建立于 Flash 存设备之上文件系统，root fs。

4. 用户应用程序。

特定于用户的应用程序。

有时在用户应用程序和核层之间可能还会包括一个嵌入式图形用户界面。

常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 等。

引导加载程序是系统加电后运行的第一段软件代码。

回忆一下 PC 的体系结构我们可以知道，PC 机中的引导加载程序由 BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的 OS Boot Loader（比如，LILO 和 GRUB 等）一起组成。

BIOS 在完成硬件检测和资源分配后，将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中，然后将控制权交给 OS Boot Loader。

Boot Loader 的主要运行任务就是将核映象从硬盘上读到 RAM 中，然后跳转到核的入口点去运行，也即开始启动操作系统。

而在嵌入式系统中，通常并没有像 BIOS 那样的固件程序（注，有的嵌入式 CPU 也会嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由 Boot Loader 来完成。

比如在一个基于 ARM7TDMI core 的嵌入式系统中，系统在上电或复位时通常都从地址0x00000000 处开始执行，而在这个地址处安排的通常就是系统的 Boot Loader 程序。

·2 bootloader简介简单地说，Boot Loader （引导加载程序）就是在操作系统核运行之前运行的一段小程序，它的作用就是加载操作系统，它是系统加电后运行的第一段软件代码。

iTop4412的uboot第一阶段

2 uboot源码分析2.5.1.start。

S引入2。

5.1.start。

S引入2.5。

1.1、u-boot。

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

ENTRY(_start)因此_start符号所在的文件就是整个程序的起始文件，_start所在处的代码就是整个程序的起始代码。

2。

5.1.2、SourceInsight中如何找到文件(1)当前状况：我们知道在uboot中的1000多个文件中有一个符号叫_start，但是我们不知道这个符号在哪个文件中。

这种情况下要查找一个符号在所有项目中文件中的引用，要使用SourceInsight的搜索功能。

(2）start。

s 在cpu/arm_cortexa9/start.s(3)然后进入start。

S文件中，发现57行中就是_start标号的定义处，于是乎我们就找到了整个uboot的入口代码，就是第57行。

2.5。

1.3、SI中找文件技巧（1）以上,找到了start.S文件，下面我们就从start。

S文件开始分析uboot第一阶段。

（2)在SI中，如果我们知道我们要找的文件的名字，但是我们又不知道他在哪个目录下，我们要怎样找到并打开这个文件？方法是在SI中先打开右边的工程项目管理栏目，然后点击最左边那个（这个是以文件为单位来浏览的），然后在上面输入栏中输入要找的文件的名字。

我们在输入的时候，SI在不断帮我们进行匹配,即使你不记得文件的全名只是大概记得名字,也能帮助你找到你要找的文件。

2。

5。

2。

start.S解析12。

5。

2。

1、不简单的头文件包含(1)#include 〈config.h>.config.h是在include目录下的，这个文件不是源码中本身存在的文件,而是配置过程中自动生成的文件。

uboot分析之bootm

uboot分析之bootmbootm命令执⾏过程中调⽤了bootm_start函数，这个函数⽐较重要，所以先分析它。

mon/cmd_bootm.cCpp代码1. static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])2. {3. void *os_hdr;4. int ret;5. memset ((void *)&images, 0, sizeof (images));//images是⼀个bootm_headers_t类型的全局变量。

见下⾯的分析。

6. images.verify = getenv_yesno ("verify");//从环境变量中检查是否要对镜像的数据（不是镜像头）进⾏校验。

7. bootm_start_lmb();//不做任何有意义的⼯作，除了定义# define lmb_reserve(lmb, base, size)8. /* get kernel image header, start address and length */寻找可⽤的内核镜像，见下⾯的分析。

主要根据传⼊的参数检查镜像的合法性并获取信息。

9. os_hdr = boot_get_kernel (cmdtp, flag, argc, argv,10. &images, &images.os.image_start, &images.os.image_len);//返回指向内存中镜像头的指针11. if (images.os.image_len == 0) {12. puts ("ERROR: can't get kernel image!\n");13. return 1;14. }15. /* get image parameters */16. switch (genimg_get_format (os_hdr)) {//根据镜像魔数获取镜像类型17. case IMAGE_FORMAT_LEGACY:18. images.os.type = image_get_type (os_hdr);//镜像类型19. p = image_get_comp (os_hdr);//压缩类型20. images.os.os = image_get_os (os_hdr);//操作系统类型21. images.os.end = image_get_image_end (os_hdr);//当前镜像的尾地址22. images.os.load = image_get_load (os_hdr);//镜像数据的载⼊地址23. break;24. default:25. puts ("ERROR: unknown image format type!\n");26. return 1;27. }28. /* find kernel entry point */29. if (images.legacy_hdr_valid) {//如果镜像已经通过验证30. images.ep = image_get_ep (&images.legacy_hdr_os_copy);//获取⼊⼝地址，填充images.ep 。

uboot分析和笔记

uboot一、uboot是ppcboot和armboot合并而成，现在主流的bootloader为uboot和redboot二、bootm addr_kernel addr_initrd三、移植uboot时最好（一定）要找到一个自己板子的原形（即自己的板子是在这个板子上做一些修改而来的）的版本，这样就可以事半功倍。

这样要修改的地方就比较少，也比较容易了。

uboot支持很多平台，与一个具体平台相关的主要有三个地方：1、./include/configs/xxxxx.h, 主要定义了flash、sdram的起始地址等信息，一般要修改flash的起始地址、大小，有时候会有位宽等。

2、./board/xxxxx/*，这个目录下主要有两三个.c文件，主要为该平台的初始化和flash操作的函数。

有时候flash的操作需要修改，不过一般都是找一个现有的支持该flash的驱动，一般情况在uboot 别的./board/平台下就会有现成的，拷贝过了就可以了。

3、./cpu/xxxxxx/arch_xxx/xxxxxx/*, 一般是此cpu的初始等函数。

四、具体移植的时候最多涉及到的会是./include/configs/xxxx.h，如果有现成的平台（uboot现在支持绝大部分我们常用的平台），可能只需要对着原来的xxxx.h文件，修改几个我们在硬件上修改了的地方，一般会是flash的起始地址、大小；内存大小（内存的起始地址应该都是0）；uboot设置信息保存的地址和长度；console 口和它的波特率；默认的设置；uboot的入口地址等（具体情况可能会有一些变化），如果不是从相同的平台移植，可能会比较麻烦，因为这时候要修改一些和此cpu相关的一些寄存器、频率和内存等硬件方面的东西了（也在这个xxxx.h中），虽然这时改动的地方也不多，但是会很痛苦，因为经常不知道要改哪里或者改为多少。

所以可能需要参考cpu的datasheet和到网上找一些资料了并且慢慢试了。

uboot 代码运行流程

uboot 代码运行流程U-Boot代码运行流程U-Boot（Universal Bootloader）是一个开源的引导加载程序，广泛应用于嵌入式系统中。

它负责在系统上电后初始化硬件并加载操作系统内核，是系统启动的重要一环。

下面将从U-Boot代码的运行流程方面进行介绍。

1. 启动阶段当系统上电后，处理器会从预定义的存储器地址开始运行代码。

U-Boot的启动代码通常存放在ROM中，处理器会从ROM的起始地址开始执行。

启动代码负责初始化处理器和一些外设，然后跳转到U-Boot的入口点。

2. 入口点U-Boot的入口点是指U-Boot的main()函数。

在启动代码的最后，会调用main()函数，从而进入U-Boot的主循环。

U-Boot的主循环负责处理用户输入的命令，并根据命令执行相应的操作。

3. 硬件初始化在main()函数中，首先会进行硬件的初始化工作。

这包括初始化串口、初始化存储器控制器、初始化网络接口等。

硬件初始化的目的是为了确保系统能够正常运行，并为后续的操作做好准备。

4. 系统启动硬件初始化完成后，U-Boot会尝试从存储设备（如闪存、SD卡）中加载操作系统内核镜像。

U-Boot会根据预定义的启动命令（例如bootcmd）来确定从哪个设备加载内核镜像，并执行相应的加载操作。

加载完成后，U-Boot会将控制权交给操作系统内核，进入操作系统的启动阶段。

5. 用户交互一般情况下，U-Boot会在系统启动后进入命令行界面，等待用户输入命令。

用户可以通过串口、网络等方式与U-Boot进行交互，执行各种操作，例如烧写固件、修改配置等。

U-Boot提供了丰富的命令集，可以满足不同的需求。

6. 系统重启当用户输入重启命令或系统发生异常时，U-Boot会执行系统重启操作。

重启操作包括重新初始化硬件、重新加载内核镜像等步骤，以重新启动系统。

U-Boot会将控制权交给重新加载的内核，然后进入内核的启动流程。

总结：U-Boot代码的运行流程包括启动阶段、入口点、硬件初始化、系统启动、用户交互和系统重启等几个关键步骤。

瑞芯微rk3399-uboot简单分析

瑞芯微rk3399-uboot简单分析使⽤的配置⽂件是：configs/rk3399_box_defconfigCONFIG_RKCHIP_RK3399=yCONFIG_PRODUCT_BOX=yCONFIG_NORMAL_WORLD=yCONFIG_SECOND_LEVEL_BOOTLOADER=yCONFIG_BAUDRATE=1500000CONFIG_ARM=yCONFIG_ROCKCHIP_ARCH64=yCONFIG_PLAT_RK33XX=y下载uboot原⽣的代码和瑞芯微提供的源码进⾏对⽐，⾸先肯定对⽐⼀下Makefile发现差异如下：ifeq ($(ARCHV),aarch64)ifneq ($(wildcard ../toolchain/aarch64-linux-android-4.9),)CROSS_COMPILE ?= $(shell pwd)/../toolchain/aarch64-linux-android-4.9/bin/aarch64-linux-android-endififneq ($(wildcard ../prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin),)CROSS_COMPILE ?= $(shell pwd)/../prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-endifelseifneq ($(wildcard ../toolchain/arm-eabi-4.8),)CROSS_COMPILE ?= $(shell pwd)/../toolchain/arm-eabi-4.8/bin/arm-eabi-endififneq ($(wildcard ../toolchain/arm-eabi-4.7),)CROSS_COMPILE ?= $(shell pwd)/../toolchain/arm-eabi-4.7/bin/arm-eabi-endififneq ($(wildcard ../toolchain/arm-eabi-4.6),)CROSS_COMPILE ?= $(shell pwd)/../toolchain/arm-eabi-4.6/bin/arm-eabi-endififneq ($(wildcard ../prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin),)CROSS_COMPILE ?= $(shell pwd)/../prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi-endififneq ($(wildcard ../prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin),)CROSS_COMPILE ?= $(shell pwd)/../prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-endififneq ($(wildcard ../prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin),)CROSS_COMPILE ?= $(shell pwd)/../prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-endifendif # ARCHV=aarch64这⼀段其实只是指定交叉编译⼯具链没什么好解释的。

U-boot中SPL功能和源码流程分析

U-boot中SPL功能和源码流程分析在U-boot⽬录下，有个⽐较重要的⽬录就是SPL的，SPL到底是什么呢？为什么要⽤它呢？ SPL（Secondary programloader）是uboot第⼀阶段执⾏的代码。

主要负责搬移uboot第⼆阶段的代码到系统内存（System Ram，也叫⽚外内存）中运⾏。

SPL是由固化在芯⽚内部的ROM引导的。

我们知道很多芯⽚⼚商固化的ROM⽀持从nandflash、SDCARD等外部介质启动。

所谓启动，就是从这些外部介质中搬移⼀段固定⼤⼩（4K/8K/16K等）的代码到内部RAM中运⾏。

这⾥搬移的就是SPL。

在最新版本的uboot中，可以看到SPL也⽀持nandflash，SDCARD等多种启动⽅式。

当SPL本⾝被搬移到内部RAM中运⾏时，它会从nandflash、SDCARD等外部介质中搬移uboot第⼆阶段的代码到系统内存中。

SPL复⽤的是uboot⾥⾯的代码. SPL的主要功能就是衔接系统的硬件SRAM和u-boot之间的纽带。

1.BasicArm Initialization2.UART console initialization3.Clocks and DPLL Locking(minimal)4.SDRAM initialization5.Mux(minimal)6.Boot Device Initialization, based on where we are booting from MMC1, or MMC2,or Nand, or Onenand7.Bootloading real u-boot from the Boot Device and passing control to it. 怎么编译SPL呢？上⽂中说道“SPL复⽤的是uboot⾥⾯的代码”，那要⽣成我们所需要的SPL⽬标⽂件，我们⼜该如何下⼿呢？很容易想到，通过编译选项便可以将SPL和uboot代码分离、复⽤。

4.3.1U-Boot代码结构分析

4.3.1U-Boot代码结构分析4.3 Bootloader之U-BootU-Boot是在PPC-Boot的基础上进化⽽来的⼀个开放源码的嵌⼊式BootROM程序，本⼩节将使⽤1.1.4版本的代码来分析U-Boot的代码结构，以及如何将它移植到基于S3C2410X的开发板上来。

4.3.1 U-Boot代码结构分析U-Boot4-9所⽰。

board：这个⽬录存放了所有U-Boot⽀持的⽬标板的⼦⽬录，如board/smdk2410/*就和我们的开发平台fs2410相类似。

要将U-Boot移植到⾃⼰的S3C2410X⽬标板上，必须参考这个⽬录下的内容，⽐如对Flash 以及Flash宽度和⼤⼩的定制等就要修改其中的flash.c。

cpu：这个⽬录存放了U-Boot⽀持的CPU类型，因为我们的开发平台是S3C2410X，所以只关⼼cpu/arm920t，CPU相关的⽂件主要是初始化⼀个执⾏环境，包括中断的初始化；start.S是整个u-boot.bin ⽬标可执⾏代码的第⼀段代码，它们是从Flash开始运⾏的，其主要⼯作就是对整个U-Boot⽬标代码的重定位，即将U-Boot转移到内存中去运⾏。

common：这个⽬录存放了U-Boot的⼀些公共命令的实现，像那些以cmd_*.c为名字的⽂件就是对应U-Boot的每个命令的实现代码，我们通常关⼼cmd_boot.c和cmd_bootm.c（它们和内核的引导相关）。

drivers：这个⽬录中存放了各种外设接⼝的驱动程序。

fs：这个⽬录中存放了U-Boot⽀持的⽂件系统。

lib_arm：这个⽬录存放了ARM平台公共的接⼝代码。

include：这个⽬录存放头⽂件的公共⽬录，其中的include/configs/smdk2410.h定义了所有和S3C2410X 相关的资源的配置参数，我们往往只需修改这个⽂件就可以配置⽬标板的参数，如波特率、引导参数、物理内存映射等。

8 u-boot程序分析

阶段二详细分析
board_init_f()
A.gd_t数据结构空间分配 B.回调一组初始化函数 C.对gd_t数据结构进行初始化 D.relocate_code(U-Boot重定义代码，即自搬移)
阶段二详细分析
阶段二详细分析
board_init_r()详细分析
简化board_init_r()函数后，如下：
u-boot是通过命令来操作的，等待用户输入命令，然后执行命令
cmd_tbl_t命令的执行分析类型的定义如下
run_command()函数是查找并执行用户输入的命令，分析器代码如下：
•解析用户输入的字符串； •经过解释后，用户输入的命令以及命令后面的参数分割成独立的字符串，并保存在argv数组中 •argc是命令+参数的个数以命令名字查找对应的cmd_tbl_t结构体； cmdtp指向命令对应的该结构体；通过指针cmdtp，执行命令对应的函数 cmdtp->cmd();
阶段一源码分析
load_uboot
根据不同启动设备，调用对应启动函数
阶段一源码分析
load_uboot
根据不同启动设备，调用对应启动函数
阶段一源码分析
把uboot代码从启动设备拷贝内存，跳转到 after_copy，在内存中执行
阶段一源码分析
after_copy
主要工作是点亮LED，保存启动信息，调board_init_f
教学要求
熟悉u-boot的代码理解u-boot源码的两个阶段主要完成的工作理解用户输入命令后u-boot执行的流程掌握向u-boot添加自定义命令的方法
u-boot的启动流程
分析u-boot的链接脚本（board/samsung/tiny4412/u-boot.lds）可以知道， u-boot的入口是start.S start.S（arch/arm/cpu/armv7/start.S）