前段时间使用TI的am4378芯片,发现系统在SD卡启动的时候,启动文件使用的是MLO和uboot.img:而Norflash和eMMC启动的时候使用的是 uboot-spl.bin和uboot.bin,有如下疑问: 1. MLO和Uboot-spl.bin有什么区别?uboot.img和uboot.bin有什么区别? 2. 为什么后者需要Norflash再配合eMMC,而不是直接eMMC? ----------------------------------------------------

本次移植跟以往的不同之处是采用了spl来引导u-boot,参考了博客http://blog.csdn.net/fulinus/article/details/42738641 下载链接:http://pan.baidu.com/s/1bnlRKgn 使用方法: 1. 编译 make tq2440_defconfig make 2. 然后会在u-boot根目录下生成u-boot.bin,在spl目录下会生成u-boot-spl.bin,目前的分区是: u-boot-spl.bin (1M) u-b

使用CCS调试基于AM335X的SPL.Uboot 一.开发环境 1.硬件平台:创龙AM3359核心板 2.SDK版本:ti-processor-sdk-linux-am335x-evm-03.00.00.04-Linux-x86-Install 3.Uboot版本:u-boot-2016.05-g1051776-v1.4.tar 4.CCS版本:CCS6.2.0.00050_linux-x64.tar 二.开发准备 1.使用虚拟机安装64位 Ubuntu16.04系统. 2.SDK的安装按照创

什么是SPL? SPL(secondary program loader)是一个十分小的bin文件,它是用来引导主u-boot文件.对于一些SRAM很小的SOC,无法一次性加载ROM中的bootloader到SRAM中,因为一般SRAM远远小于bootloader的大小.这时候SPL应运而生了. 加载过程 嵌入式系统的SOC内部会有比较小的SRAM,而外部的一般会有DDR或者SDRAM,后面的RAM就是外部RAM:SPL会先被加载到SRAM中,然后初始化DDR或者SDRAM,总之会初始化外部的R

uboot分为uboot-spl和uboot两个组成部分.SPL是Secondary Program Loader的简称,第二阶段程序加载器,这里所谓的第二阶段是相对于SOC中的BROM来说的,之前的文章已经有所介绍,SOC启动最先执行的是BROM中的固化程序. BROM会通过检测启动方式来加载第二阶段bootloader.uboot已经是一个bootloader了,那么为什么还多一个uboot spl呢? 这个主要原因是对于一些SOC来说,它的内部SRAM可能会比较小,小到无法装载下一个完整的

5.1 u-boot.lds  链接脚本分析 uboot 编译出来的第一个链接脚本就是执行 u-boot.lds 链接脚本,去掉里面无用的和没有定义的,进行分析. /* 配置头文件,自动生成的,包含芯片SOC 相关的头文件 */ #include <config.h> /* 主要是做一些 32位 和64 位的适配定义 */ #include <asm/psci.h> /* 输出格式为 elf32-littlearm, */ OUTPUT_FORMAT("elf32-lit

上篇博客:http://www.cnblogs.com/yeqluofwupheng/p/7347925.html 讲到uboot-spl的工作流程,接下来简述一下uboot.bin的工作流程,这对应BL2的流程. BL2的主要文件和任务流程如下: arch/arm/cpu/armv7/start.S           1. 设置CPU为SVC模式           2. 关闭MMU           3. 关闭Cache           4. 跳转到lowlevel_init.S l

在mini2440的教程中,在构建nandflash系统的时候是首先通过supervivi借助dnw烧写uboot.bin到nand flash 第零块, 由于我使用的是64位操作系统,usb驱动没安装成功,就尝试了其他方法烧写uboot.bin到nandflash,尝试了N多种方法都失败了, 静下心来一想,既然NORFLASh中的uboot可以启动,为什么不直接通过uboot烧写呢,于是就试了一下,UBOOT下用tftp下载到内存,然后用nand write 指令烧写,成功了

一.uboot启动分为了三个阶段BL0.BL1.BL2:BL0表示上电后运行ROM中固化的一段程序,其中ROM中的程序是厂家写进去的,所以具体功能可能根据厂家芯片而有所不同.功能如下: 初始化系统时钟.特殊设备的控制器.启动设备.看门狗.堆栈.SRAM等硬件: 验证B1镜像,并且加载BL1镜像到SRAM中,然后跳转到BL1镜像的地址上. BL0需要将BL1加载到对应的RAM上,这就涉及到它的启动模式,详细如下:1.OneNand Boot模式 要了解OneNAND先得了解NOR Flash和NA

uboot和内核到底是什么?uboot实质就是一个复杂的裸机程序:uboot可以被配置也可以做移植: 操作系统内核本身就是一个裸机程序,和我们学的uboot和其他裸机程序没有本质的区别:区别就是我们操作系统运行起来后可以分为应用层和内核层,分层后,两层的权限不同,内存访问和设备操作的管理上更加精细(内核可以随便方位各种硬件,而应用程序只能被限制的访问硬件和内存地址) 直观来看:uboot的镜像是u-boot.bin,Linux系统的镜像是zImage,这两个东西其实都是两个裸机程序镜像.从系统启

一.编译u-boot命令 1.配置开发板 #make TQ2440_config 2.编译 #make all 3.交叉编译器是crosstools_3.4.5_softfloat” 使用4.3.3版本的会出现问题. 编译linux内核用的是4.3.3版本的,否则也会出问题. 二.u-boot常用命令 1.help 命令 2.下载命令 (1)tftpboot [loadaddr] [bootfilename] 从tftp服务器上下载文件 (2)usbslave 1 [loadaddr]  借助D

说明:文件位置:在uboot的目录下,文件名为:config.mk.是一个makefile文件,以后会被主Makefile调用. 它的主要作用的是: (1)具体的设置交叉编译工具链接(主Makefile中也有设置交叉编译工具链) (2)加载include/autoconfig.mk文件(这个文件是在主Makefile中生成的) (3)指定-Ttext链接地址 (4)makefile的推导规则   下面来具体的分析代码: 1.设置交叉编译工具链

说明:文件位置:在uboot的目录下,文件名为:mkconfig.本身是一个脚本文件. 它的主要作用的是: (1)创建一个重要的符号链接 (2)创建一个config.mk文件(在include目录下) (3)创建一个config.h文件(在include目录下)   下面会截距一部分重要的代码来分析   1.首先要明白一个参数($1.$2.$3.$4.$5),这是传参 (1)@$(MKCONFIG) $(@:_config=) arm s5pc11x x210 samsung s5pc110 这

说明:文件位置:在uboot的目录下,文件名为:Makefile 从文件的头部开始分析 1.24-29行,配置uboot的版本信息. VERSION = PATCHLEVEL = SUBLEVEL = EXTRAVERSION = U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) VERSION_FILE = $(obj)include/version_autogenerated.h 2.主机的环境信息(比如

在U-boot目录下,有个比较重要的目录就是SPL的,SPL到底是什么呢?为什么要用它呢? SPL(Secondary programloader)是uboot第一阶段执行的代码.主要负责搬移uboot第二阶段的代码到 系统内存(System Ram,也叫片外内存)中运行.SPL是由固化在芯片内部的ROM引导的.我们知道很多芯 片厂商固化的ROM支持从nandflash.SDCARD等外部介质启动.所谓启动,就是从这些外部介质中搬移一段 固定大小(4K/8K/16K等)的代码到内部RAM中运行.

u-boot这个东西从自我N年前使用到现在,变化好多,今天开始重新研究下,本系列的研究都是基于BeagleBoneBlack(bbb)开发板和 u-boot v201801版本的. SPL介绍 在源代码中 doc/README.SPL 中说得比较明白,我这里再归纳下. 现在很多处理器都内置一个BOOT ROM,执行部分初始化,并可从各种外设和存储器中加载程序并执行,BOOT ROM中固化的程序被称为一级程序加载器,被它加载的程序就称为二级程序加载器(secondary program loade

关键词:bootrom.spl.uboot.linux.mksheader.sb_header.mkimage.image_header_t等等. 首先看一个典型的bootrom->spl->uboot->linux流程log,主要分为4个部分,中间有3个衔接点. # Hello DeepEye -- Boot from SD card -- sdio initialize done. sd card read done. --------------------------------

ELF格式“u-boot”文件的生成规则如下,下面对应Makefile的执行过程分别分析各个依赖. $(obj)u-boot: depend version $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT) UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) |sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\ cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF

uboot启动流程分析,针对S5PV210 BL1阶段,SPL,u-boot-spl.bin 1.首先运行arch/arm/cpu/armv7/start.S 里面的_start函数,进行异常向量表设置,然后跳转到reset复位处理函数,设置处理器SVC模式,关闭IRQ和FIQ中断.设置cp15协处理器 的SCTRL寄存器V(bit13)为0,设置异常向量表在0x00000000-0x0000001C,设置异常向量表地址为_start.跳转到cpu_init_cp15初始化协处理器,清除TLB,

这东西已经写,我们没有时间发布,如今,终于有时间稍微长送记录汇总uboot学习过程.具体了.以后忘了也能够再温习回来嘛有些特殊字符显示得乱掉了 Makefile追踪技巧: 技巧1:能够先从编译目标開始顺藤摸瓜地分析,先不要关注详细细节,着重关注基本的代码结构和编译过程 技巧2:追踪分析时要通过文本或者其它途径临时记录重要的线索 技巧3:将基本的Makefile文件里export出来的变量以及include的文件提取出来,看看include的文件大致是些什么文件,当看到一些来历不明的变量或者操作时