uboot启动流程分析

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

总体分析：你的目的是什么？ 你的计划是什么？ 你会碰到什么问题？ 你怎么解决的问题？ 你今天做了该做的事情了吗？ 你今天能把该做的事情做完吗？ 修改注意事项有什么？ 注意：Toodir 中的Makefile 中的路径nand_spl/board/samsung/smdk6410 未作更改 出现nand BUG 测检查nand_spl/board/samsung/oko6410 下面的config.mk 你对S3C6410 的了解到了什么程度？ 给数据手册制作书签，方便查询……一个一个找太累了！！！ 调试技巧：将修改的部分做Mark by xcc 方便调试。 启动成功，flash 初始化问题。 增加一个任务：移植一个Linux ，内核版本暂定为3.1 吧。 第一步：建立开放环境 碰到的问题：交叉编译环境在AMD平台的虚拟机上面出现硬件编译环境不支持的问题。Arm-linux-gcc:souch file cannot found 解决办法：自建交叉编译环境 第二步：分析 实现目标： 本次移植的功能特点包括： 支持Nand Flash读写 支持从Nor/Nand Flash启动 支持CS8900或者DM9000网卡 支持Yaffs文件系统 支持USB下载(还未实现) 1， 了解u-boot主要目录结构和启动流程，阅读代码 2， 生成了基本的uboot.bin，烧写到开发板上

1、前言 在前面的文章Uboot启动流程分析(一)中，链接如下： https://www.cnblogs.com/Cqlismy/p/12000889.html 已经简单地分析了low_level_init函数，其调用流程如下： save_boot_params_ret | cpu_init_crit | 　　| | 　　lowlevel_init | 　　| | 　　s_init | _main 接下来，则继续往下分析_main函数。 2、_main函数 在save_boot_params_ret的最后，会运行bl _main这句代码，Uboot则将会跳转到_main函数中去运行，该函数的定义在arch/arm/lib/crt0.S文件中，_main函数的功能已经在文件中注释得很清楚了，先来看看_main函数实现的功能是什么，注释如下： /* * This file handles the target-independent stages of the U-Boot * start-up where a C runtime environment is needed. Its entry point * is _main and is branched into from the target's start.S file. * * _main execution

1、前言 在前面的文章 https://www.cnblogs.com/Cqlismy/p/12000889.html 中，已经简单分析了low_level_init函数，其调用流程如下： save_boot_params_ret | cpu_init_crit | 　　| | 　　lowlevel_init | 　　| | 　　s_init | _main 接下来，则继续往下分析_main函数。 2、_main函数 来源： https://www.cnblogs.com/Cqlismy/p/12002764.html

uboot的relocation原理详细分析 转自：http://blog.csdn.net/skyflying2012/article/details/37660265 最近在一直在做uboot的移植工作，uboot中有很多值得学习的东西，之前总结过uboot的启动流程，但uboot一个非常核心的功能没有仔细研究，就是uboot的relocation功能。 这几天研究下uboot的relocation功能，记录在此，跟大家共享。 自己辛苦编辑，转载请注明出处，谢谢！ 所谓的relocation，就是重定位，uboot运行后会将自身代码拷贝到sdram的另一个位置继续运行 ，这个在uboot启动流程分析中说过。 但基于以前的理解，一个完整可运行的bin文件，link时指定的链接地址，load时的加载地址，运行时的运行地址，这3个地址应该是一致的 relocation后运行地址不同于加载地址 特别是链接地址，ARM的寻址会不会出现问题？ 新版uboot跟老版uboot不太一样的地方在于新版uboot不管uboot的load addr（entry pointer）在哪里，启动后会计算出一个靠近sdram顶端的地址，将自身代码拷贝到该地址，继续运行。 个人感觉uboot这样改进用意有二，一是为kernel腾出低端空间，防止kernel解压覆盖uboot，二是对于由静态存储器

（1）IIC EEPROM IIC EEPROM，采用的是IIC通信协议。 IIC通信协议具有的特点： 【1】简单的两条总线线路，一条串行数据线(SDA)，一条串行时钟线(SCL)； 【2】串行半双工通信模式的8位双向数据传输，位速率标准模式下可达100Kbit/s； 【3】一种电可擦除可编程只读存储器，掉电后数据不丢失，由于芯片能够支持单字节擦写，且支持擦除的次数非常之多，一个地址位可重复擦写的理论值为100万次，常用芯片型号有 AT24C02、FM24C02、CAT24C02等，其常见的封装多为DIP8，SOP8，TSSOP8等； （2）SPI NorFlash SPINorFlash，采用的是SPI 通信协议。 【1】有4线(时钟，两个数据线，片选线)或者3线(时钟，两个数据线)通信接口，由于它有两个数据线能实现全双工通信，因此比IIC通信协议的 IIC EEPROM的读写速度上要快很多。 【2】SPI NorFlash具有NOR技术Flash Memory的特点，即程序和数据可存放在同一芯片上，拥有独立的数据总线和地址总线，能快速随机读取，允许系统直接从Flash中读取代码执行；可以单字节或单字编程，但不能单字节擦除，必须以Sector为单位或对整片执行擦除操作，在对存储器进行重新编程之前需要对Sector或整片进行预编程和擦除操作。 【3

转自：https://www.cnblogs.com/biaohc/p/6403863.html 1：什么是UBOOT，为什么要有UBOOT？ 　　UBOOT的主要作用是用来启动linux内核，因为CPU不能直接从块设备中执行代码，需要把块设备中的程序复制到内存中，而复制之前还需要进行很多初始化工作，如时钟、串口、dram等； 　　如要想让CPU启动linux内核，只能通过另外的程序，进行必要的初始化工作，在把linux内核中代码复制到内存中，并执行这块内存中的代码，即可启动linux内核；一般情况下，我们把linux 　　镜像储存在块设备中如SD卡、iNand、Nandflash等块设备中，首先执行UBOOT带码，在UBOOT中把块设备中的内核代码复制到内存地址0x30008000地址处，然后在执行bootm 0x30008000 　　命令来执行内核代码； 整个过程大致如上述所讲，下面我们详细分析一下UBOOT启动内核的代码： 2：在启动UBOOT时候会出现看机倒计时，如果没有按键按下，会自动启动内核，我们来看一下这个是如何实现的： 下面这段代码是在main_loop函数中：作用是执行完倒数计时函数以后启动linux内核，启动方式是 s = getenv ("bootcmd");我们假定不使用HUAH_PARSER的情况下 run_command (s, 0);