下载文档原格式
U-boot分析与移植<1）----bootloader分析一、Boot Loader 概念就是在操作系统内核运行之前运行的一段小程序。
通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境，他就是所谓的引导加载程序<Boot Loader）。
嵌入式软件在Flash存储器中的分布图二、为什么需要BootLoader？BootLoader的终极任务是引导操作系统，所谓引导操作系统，就是启动内核，在启动内核之前所需要的环境<如初始化sdram，设置cpu模式等，下面会介绍）都是由BootLoader 来完成的。
试想一下，如果你要启动内核，让内核在内存上跑，但连sdram都没有初始化，这显然不行。
在s3c2440中，系统在上电或复位时通常都从地址 0x00000000 处开始执行，而在这个地址处安排的通常就是系统的Boot Loader 程序。
在x86的PC机上，Boot Loader = BIOS + GRUB/LILO。
三、BootLoader的选择有些人误认为BootLoader=U-Boot，其实BootLoader只是所有引导加载程序中的一个总称。
四、启动过程S3C2440 支持两种方式的启动：Nor Flash 启动和Nand Flash 启动。
Nor Flash 和Nand Flash 都是非易失性存储器，Nor Flash 的特点是芯片内执行和不能直接写操作，程序可以直接在其中运行，而不必将程序读取到RAM 中运行。
Nor Flash 虽然具有这个优点，但是它的性价比远低于Nand Flash，因而很多系统采用Nand Flash 启动。
Nand Flash 的特点是采用非线性存储模式，程序无法在其中运行，它只能作为程序或数据的存储载体，存储在其中的程序只能先拷贝到RAM 中才能运行。
刷入uboot和大分区的方法一、概念解释1.1 uboot是什么U-boot是一种开源的引导加载程序，它通常用于嵌入式系统的启动过程中，负责引导操作系统的启动和初始化硬件设备。
在嵌入式系统中，uboot扮演着非常重要的角色，它的稳定性和可靠性直接影响整个系统的稳定性。
1.2 分区的作用分区是将存储设备按照一定的规则划分成多个逻辑部分的过程。
对于嵌入式系统而言，合理的分区管理可以提高存储设备的利用率，同时也方便系统的管理和维护。
二、刷入uboot的步骤2.1 确定目标设备我们需要明确要刷入uboot的目标设备是什么，是一个嵌入式开发板还是其他类型的设备。
不同的设备可能需要不同的uboot版本和刷入方法。
2.2 获取uboot源码接下来，我们需要从冠方或者其他可靠渠道获取uboot的源码。
一般来说，冠方的源码是最稳定和可靠的选择，我们可以从冠方的仓库或者全球信息站上下载源码。
2.3 编译uboot获取源码之后，我们需要根据目标设备的硬件配置，对源码进行编译。
在编译之前，我们需要配置好交叉编译工具链和相关的环境变量，确保编译过程顺利进行。
2.4 刷入uboot当uboot源码编译完成之后，我们需要将编译生成的二进制文件刷入目标设备的存储设备中。
这个过程可能涉及到串口或者其他调试工具的使用，需要特别注意刷入过程中的各项参数和配置。
2.5 测试uboot刷入完成后，我们需要对uboot进行测试，确保它能够正常启动，并且能够正确识别硬件设备。
三、创建大分区的步骤3.1 确定分区方案在创建大分区之前，我们需要确定硬盘或者TF卡的分区方案，包括分区的数量、大小和格式等。
3.2 使用分区工具常用的分区工具有fdisk、parted等，我们可以使用这些工具来创建和调整分区。
在使用分区工具时，需要特别注意当前存储设备上是否有重要的数据，避免误操作导致数据丢失。
3.3 格式化分区创建完分区之后，我们需要对分区进行格式化，以便后续的数据存储和管理。
uboot命令U-boot基础现在为Linux开放源代码Bootloader有很多，blob、redboot 及U-BOOT等，其中U-BOOT是目前用来开发嵌入式系统引导代码使用最为广泛的Bootloader。
它支持POWERPC、ARM、MIPS和 X86等处理器，支持嵌入式操作系统有Linux、Vxworks及NetBSD等。
2.1 U-boot源代码目录结构|-- board 平台依赖，存放电路板相关的目录文件|-- common 通用多功能函数的实现|-- cpu 平台依赖，存放cpu相关的目录文件|-- disk 通用。
硬盘接口程序|-- doc 文档|-- drivers 通用的设备驱动程序，如以太网接口驱动|-- dtt|-- examples 应用例子|-- fs 通用存放文件系统的程序|-- include 头文件和开发板配置文件，所有开发板配置文件放在其configs 里|-- lib_arm 平台依赖，存放arm架构通用文件|-- lib_generic 通用的库函数|-- lib_i386 平台依赖，存放x86架构通用文件|-- lib_m68k 平台依赖|-- lib_microblaze 平台依赖|-- lib_mips 平台依赖|-- lib_nios 平台依赖|-- lib_ppc平台依赖，存放ppc架构通用文件|-- net 存放网络的程序|-- post 存放上电自检程序|-- rtc rtc的驱动程序`-- tools 工具详细实例：board：开发板相关的源码，不同的板子对应一个子目录，内部放着主板相关代码。
Board/at91rm9200dk/at91rm9200.c, config.mk, Makefile, flash.c ,u-boot.lds等都和具体开发板的硬件和地址分配有关。
common：与体系结构无关的代码文件，实现了u-boot所有命令，其中内置了一个shell脚本解释器(hush.c, a prototype Bourne shell grammar parser), busybox中也使用了它。
深度解析：嵌入式之uboot1.为什么要有uboot1.1、计算机系统的主要部件(1)计算机系统就是以CPU为核心来运行的系统。
典型的计算机系统有：PC机（台式机+笔记本）、嵌入式设备（手机、平板电脑、游戏机）、单片机（家用电器像电饭锅、空调）(2)计算机系统的组成部件非常多，不同的计算机系统组成部件也不同。
但是所有的计算机系统运行时需要的主要核心部件都是3个东西：CPU + 外部存储器（Flash/硬盘） + 内部存储器（DDR SDRAM/SDRAM/SRAM）1.2、PC机的启动过程(1)部署：典型的PC机的BIOS程序部署在PC机主板上（随主板出厂时已经预制了），操作系统部署在硬盘上，内存在掉电时无作用，CPU在掉电时不工作。
(2)启动过程：PC上电后先执行BIOS程序（实际上PC的BIOS就是NorFlash），BIOS程序负责初始化DDR内存，负责初始化硬盘，然后从硬盘上将OS镜像读取到DDR中，然后跳转到DDR中去执行OS直到启动（OS启动后BIOS 就无用了） 1.3、典型嵌入式linux系统启动过程(1)典型嵌入式系统的部署：uboot程序部署在Flash（能作为启动设备的Flash）上、OS部署在FLash（嵌入式系统中用Flash代替了硬盘）上、内存在掉电时无作用，CPU在掉电时不工作。
(2)启动过程：嵌入式系统上电后先执行uboot、然后uboot负责初始化DDR，初始化Flash，然后将OS从Flash中读取到DDR中，然后启动OS（OS启动后uboot就无用了）总结：嵌入式系统和PC机的启动过程几乎没有两样，只是BIOS 成了uboot，硬盘成了Flash。
1.4、android系统启动过程(1)Android系统的启动和Linux系统（前面讲的典型的嵌入式系统启动）几乎一样。
几乎一样意思就是前面完全一样，只是在内核启动后加载根文件系统后不同了。
(2)可以认为启动分为2个阶段：第一个阶段是uboot到OS启动；第二个阶段是OS启动后到rootfs加载到命令行执行；现在我们主要研究第一个阶段，android的启动和linux的差别在第二阶段。
1嵌入式Linux软件结构与分布一般情况下嵌入式Linux系统中的软件主要分为以下几部分：1)引导加载程序：其中包括内部ROM中的固化启动代码和BootLoader两部分。
内部固化ROM是厂家在芯片生产时候固化的，作用基本上是引导BootLoader。
有的芯片比较复杂，比如Omap3在flash中没有代码的时候有许多启动方式：USB、UART或以太网等等。
而S3C24x0则很简单，只有Norboot和Nandboot。
drive e rs。
2)Linux kernel和driv3)文件系统。
包括根文件系统和建立于Flash内存设备之上的文件系统（EXT4、UBI、CRAMFS等等）。
它是提供管理系统的各种配置文件以及系统执行用户应用程序的良好运行环境及载体。
4)应用程序。
用户自定义的应用程序，存放于文件系统之中。
在Flash存储器中，他们的分布一般如下：BootLoader(被挂载到根文件系统或者作为2在嵌入式Linux中BootBootL L o a d er的必要性Linux内核的启动除了内核映像必须在主存的适当位置，CPU还必须具备一定的条件：1．CPU寄存器的设置：R0＝0；R1＝Machine ID(即Machine Type Number，定义在linux/arch/arm/tools/mach-types)；R2＝内核启动参数在RAM中起始基地址；2．CPU模式：必须禁止中断（IRQs和FIQs）；CPU必须SVC模式；3．Cache和MMU的设置：MMU必须关闭；指令Cache可以打开也可以关闭；数据Cache必须关闭；但是在CPU刚上电启动的时候，一般连内存控制器都没有初始化过，根本无法在主存中运行程序，更不可能处在Linux内核启动环境中。
为了初始化CPU及其他外设，使得Linux内核可以在系统主存中运行，并让系统符合Linux内核启动的必备条件，必须要有一个先于内核运行的程序，他就是所谓的引导加载程序（Boot Loader）。
uboot命令解释与运行分析题记: 省略200字这一回来分析一下uboot中命令行的解释, 所以我们直接从main_loop开始分析.1. 从汇编阶段进入c阶段的第一个函数是start_xxx, 如/lib_unicore/board.c中的start_unicoreboot. 前半部分调用了若干初始化函数来进行部分硬件的初始化, 并设置一下环境. 这里不是我们本回要讨论的所以一一跳过. 在start_xxx的最后调用了main_loop(), 而且还是被一个死循环死死圈住了;2. 现在我们已经进入了这个圈套那么只能往里钻了. common/main.c文件中的main_loop().上面代码主要是对自启动部分的描述, 其中命令执行部分是在run_command中进行的, 这个等在后文分析. 如果我们没有bootcmd 或者在延时中被打断, 那么代码会继续向下执行3.read_line()读取到命令行后会调用common/main.c文件中的run_command().现在是分析run_command()的时候了,不管是从环境变量还是终端获得命令,都是由run_command()来处理的.中场休息,下面要进入处理cmdbuf的循环中了, 长征马上开始以;分割. 忽略'\;'for(inquotes = 0, sep = str;*sep; sep++){if((*sep=='\'')&&(*(sep-1)!='\\'))inquotes=!inquotes;if(!inquotes &&(*sep ==';')&&( sep != str)&&(*(sep-1)!='\\'))break;}//如果上面for循环找到一条以';'结束的命令, 那么sep指向命令末尾token = str;if(*sep){str = sep + 1;*sep ='\0';}elsestr = sep;process_macros (token, finaltoken);if((argc = parse_line (finaltoken, argv))== 0){rc =-1;4.就此打断一下, 我们要分析一下find_cmd了, 不能再跳过了. find_cmd()在.u_boot_cmd段中寻找该命令的cmd_tbl_t结构, 找到后返回该结构. 该命令的结构是通过定义在include/command.h中的宏定义U_BOOT_CMD登记进.u_boot_cmd段中的.5. 刚才我们在长征的半路翻越了一座雪山, 现在继续回到while循环中if(cmdtp->cmd == do_bootd){if(flag & CMD_FLAG_BOOTD){puts("'bootd' recursion detected\n");rc =-1;continue;}else{flag |= CMD_FLAG_BOOTD;}}#endif//长征马上结束, 胜利就在眼前! 调用结构体中注册的cmd函数, 何时注册的呢? 上面不远处介绍的U_BOOT_CMD!if((cmdtp->cmd)(cmdtp, flag, argc, argv)!= 0){ rc =-1;}repeatable &= cmdtp->repeatable;if(had_ctrlc ())return-1;}。
uboot源码分析2-启动第⼆阶段⼀、背景知识1、uboot第⼆阶段应该做什么？概括来讲uboot第⼀阶段主要就是初始化了SoC内部的⼀些部件（譬如看门狗、时钟），然后初始化DDR并且完成重定位。
由宏观分析来讲，uboot的第⼆阶段就是要初始化剩下的还没被初始化的硬件。
主要是SoC外部硬件（譬如iNand、⽹卡芯⽚····）、uboot本⾝的⼀些东西（uboot的命令、环境变量等····）。
然后最终初始化完必要的东西后进⼊uboot的命令⾏准备接受命令。
2、uboot中经常出现⼀种情况就是根据⼀个宏是否定义了来条件编译决定是否调⽤⼀个函数内部的代码。
uboot 中有2种解决⽅案来处理这种情况：⽅案⼀：在调⽤函数处使⽤条件编译，然后函数体实际完全提供代码。
⽅案⼆：在调⽤函数处直接调⽤，然后在函数体处提供2个函数体，⼀个是有实体的⼀个是空壳⼦，⽤宏定义条件编译来决定实际编译时编译哪个函数进去。
⼆、函数执⾏流程1、定义变量，gd，然后实例化2、给gd->bd赋值，内存间隔为了防⽌⾼版本的gcc的优化造成错误3、执⾏init_sequence函数，都是board级别的各种硬件初始化cpu_init（）：cpu内部的初始化，但在start.S初始化过，所以这⾥是空的。
board_init（）：⽹卡的GPIO和端⼝的配置、定义开发板的机器码、定义uboot给linux kernel启动时的传参的内存地址gd->bd->bi_boot_params=0x30000100注意：board_init中除了⽹卡的初始化之外，剩下的2⾏⽤来初始化DDR。
这⾥的初始化DDR和汇编阶段lowlevel_init中初始化DDR是不同的。
当时是硬件的初始化，⽬的是让DDR可以开始⼯作。
现在是软件结构中⼀些DDR相关的属性配置、地址设置的初始化，是纯软件层⾯的。
