uboot

在支持Nand Flash操作之前，首先要对Nand Flash的读写方法有一定的了解，参考文章： S3C2440-裸机篇-10 | 使用S3C2440操作Nand Flash 1. 去除nand flash屏蔽 在之前初步移植uboot时，发现开启nand flash之后编译不通过，所以屏蔽了nand flash的使用，在单板配置文件 include/configs/smdk2440.h 中开启： 然后编译，改正编译错误。 2. 定位编译出错问题所在 首先来修复第一个问题： 查看s3c2410_nand.c文件的72行： 这个指针有问题的话，就是nand这个结构体变量的定义问题，找到nand变量的定义： struct s3c2410_nand * nand = s3c2410_get_base_nand ( ) ; 接下来问题就变为 struct s3c2410_nand 这个结构体定义有问题，继续寻找该定义，果然，在文件 arch/arm/include/asm/arch-s3c24x0/s3c24x0.h 中，我们定义的是CONFIG_S3C2440，所以有struct s3c2440_nand的定义，没有struct s3c2410_nand的定义： 3. 修复编译错误 — 添加s3c2440_nand.c文件 3.1. 添加文件到工程中 这里涉及到将所有定义全部改变

uboot的源文件众多，学习庞然大物首先找到脊椎--顶层的makfile，逐一破解。但是，uboot的makefile同样是一个庞然大物，所以也要找到它的主线。倘若过分专注部分细节，很难做到把握全局，实际上也不可能很好理解细节。 介于此，笔者已经写了一篇 uboot makefile整体解析 ，可以先从主体上把握makefile。然后，再读这篇makefile强大功能实现的细节，才能做到循序渐进。 说明：uboot顶层makefile的注释机会全部源码都搬上来了，而注释都是黑体加粗以与源码有强烈的区别。 VERSION = 1 //主版本号 PATCHLEVEL = 1 //次级版本号 SUBLEVEL = 6 EXTRAVERSION = //版本号扩展 U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) //这个Uboot的版本为1.1.6 VERSION_FILE = $(obj)include/version_autogenerated.h //生成uboot的版本信息 HOSTARCH := $(shell uname -m | \ sed -e s/i.86/i386/ \ -e s/sun4u/sparc64/ \ -e s/arm.*/arm/ \ -e s/sa110/arm/

make mini2440_config 分析： Uboot第一步--make xxx_config。 mini2440_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t mini2440 tekkamanninja s3c24x0 unconfig的定义-- unconfig: @rm -f $(obj)include/config.h $(obj)include/config.mk \ $(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \ $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep 好了，清楚一点了。清楚了，但我又迷茫了，为什么我一运行 make mini2440_config就会跑到mini2440_config : unconfig 这个地方运行啊？如果非要解释那么好吧：mini2440_config是一个伪目标，因为mini2440_config的：后面只跟着一个 unconfig，而unconfig也是一个伪目标。为什么unconfig是一个伪目标呢？因为unconfig的：后面什么都没有。如果他是个变量 的话 后面一定会加点什么东西，他就像make clean的clean一样，是个伪的。

make xxx_config实质上就是调用了 首先看MKCONFIG： 【注意】SRCTREE=源文件下的目录 之后的语句： @$(MKCONFIG) $(@:_config=) arm arm920t EmbedSky NULL s3c2440就相当于执行 #mkconfig xxx arm arm920t EmbedSky NULL s3c2440 #$0 $1 $2 $3 $4 $5 $6 于是乎就开始执行mkconfig； [ "${BOARD_NAME}" ] 就是指明xxxx，上面的实例为100ask24x0 这里就会执行echo “Configuring for 100ask24x0 board...” （1）建立软链接 之后就会执行： ln -s asm-arm asm 【注意】 建立一个链接文件，为什么这么做呢？ 在源文件中调用： #include <asm/type.h> 　　　　//就相当于 include <asm-arm/type.h> ------------------------------------------------------------------------- 继续往下看： 同样生成asm-arm/proc文件。 （2）生成config.mk文件 生成config.mk文件： echo "ARCH = $2" > config.mk

BootLoader：嵌入式系统从开始上电到系统启动需要一个引导过程，这个引导程序就叫作启动加载程序，即BootLoader。它在操作系统运行之前运行，它负责初始化硬件设备，建立内存空间的映射表，从而建立适当的系统软硬件环境，为最终调用操作系统内核做好准备。最常用的一种就是uboot。 uboot的配置编译：uboot的编译是基于GNU Makefile组织编译的，顶层的Makefile完成对开发板整体配置，然后递归调用各级子目录下的Makefile，最后把所有编译过的程序链接成u-boot映像。 具体的配置流程： 解压uboot源码："$ tar -xvf u-boot-2013.01.tar.bz2" 修改顶层的Makefile（改为自己交叉编译工具链）：ifeq (arm, $(ARCH)) CROSS_COMPILE ?= /opt/arm-linux-gcc-4.8.3/bin/arm-none-linux-gnueabi- 进入源码目录，并配置："$make exynos4412_config" 编译：make 编译好的uboot就可以烧写到开发板中。 串口调试命令：uboot烧写好后，还需要串口调试设置相关环境变量，主要有： 设置内核启动参数：setenv bootargs root=/dev/nfs nfsroot=192.168.9.120:/source

　　1.裸机运行程序时一般情况下程序代码小于16KB将其下载地址设置到BL1的起始地址。BL0会自动加载并执行BL1。 当程序大于16kB时无法直接运行。 　　例如UBOOT就大于16KB，执行的原理为。将程序分为BL1、BL2两部分。 其中BL1初始化DDR并且指定BL2的起始地址。BL2为真正需要的程序。 BL1部分 start.S #define WTCON 0xE2700000 #define SVC_STACK 0xd0037d80 .global _start // 把_start链接属性改为外部，这样其他文件就可以看见_start了 _start: // 第1步：关看门狗（向WTCON的bit5写入0即可） ldr r0, =WTCON ldr r1, =0x0 str r1, [r0] // 第2步：设置SVC栈 ldr sp, =SVC_STACK // 第3步：开/关icache mrc p15,0,r0,c1,c0,0; // 读出cp15的c1到r0中 //bic r0, r0, #(1<<12) // bit12 置0 关icache orr r0, r0, #(1<<12) // bit12 置1 开icache mcr p15,0,r0,c1,c0,0; // 第4步：初始化ddr bl sdram_asm_init // 第5步：重定位

为什么要有uboot 1.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

命令格式：./maketek [option] [project] [action] [modules] Option : -t ,-tee :输出log信息到当前终端 -o , -opt=…… : 编译附加条件，一般使用-opt=TARGET_BUILD_VARIANT=user来编译用户板软件 -h ,help : 打印帮助信息并退出 Project ： 工程名，例如：basicom72_wet_jb3 Action ： n , new : 重新编译整个工程 c , clean：清理编译时copy的文件及log信息 r , remake：整个工程检查修改部分并编译 listp , listproject: 查看目前所有的project codegen : 生成database nandgen : 生成nand_device_list.h (仅限使用nand flash 时使用) check-env : 检查编译环境是否OK check-dep ：检查功能依赖性 check-modem ：检查modem update-modem ：更新最新的modem.img 到system.img mm : 用来编译APK模块，如：./mk mm package/apps/deskclok emigen : 生成flash相关文件（custom_emi.c/.h） modules : 编译模块

uboot启动的第一阶段分析 1.start.S引入，start.S在目录cpu/s5pc11x/下。 (1)如何确认uboot的程序入口，那就是去分析u-boot.lds，从u-boot.lds找到uboot的程序入口为ENTRY(_start)，因此_start符号所在的文件就是整个程序的起始文件，_start所在处的代码就是整个程序的起始代码。 (2)在C语言中整个项目的入口就是main函数（这是C语言规定的），所以譬如说一个有10000个.c文件的项目，第一个要分析的文件就是包含了main函数的那个文件。 (3)在uboot中因为有汇编阶段参与，因此不能直接找main函数。整个程序的入口取决于链接脚本中ENTRY声明的地方。ENTRY(_start)因此_start符号所在的文件就是整个程序的起始文件，_start所在处的代码就是整个程序的起始代码。 (4)我们搜索，定位到_start就在uboot/cpu/s5pc11x/start.S中 2.start.S分析之头文件包含 (1)#include <config.h>， 实际是包含的Include/config.h, 而config.h中包含的是#include <configs/x210_sd.h>， 所以这里实际上包含的就是 include/configs/x210_sd.h, 这样就把start.S和x210_sd

1、不简单的头文件包含 #include <config.h>：这个文件的内容其实是包含了一个头文件：#include <configs/x210_sd.h>". #include/version.h中包含了include/version_autogenerated.h，这个头文件就是配置过程中自动生成的。里面就一行内容：#define U_BOOT_VERSION "U-Boot 1.3.4" 2、启动代码的16字节头部 3、异常向量表的构建 4、用0xdeadbeef对齐填充 5、分配空间放TEXT_BASE c3e00000 6、分配空间放uboot在DDR中的物理地址 33e00000 7、设置CPU为SVC模式 8、设置 L2、 L1cache和 MMU 9、识别并暂存启动介质，因此执行完这一段代码后r3中存储了0x03，以后备用。 10、设置栈， 并调用 lowlevel_init ；目的：栈是在 SRAM中设置的，因为当前整个代码还在 SRAM中运行，此时 DDR还未被初始化还不能用 10.1lowlevel_init详解 （1）先将LR入栈 （2）检查复位状态，防止DDR再次初始化； 冷上电时 DDR是需要初始化才能用的；而热启动或者低功耗状态下的复位则不需要再次初始化 DDR。 （3） IO状态恢复 （4）关看门狗 （5） SRAM SROM相关 GPIO设置