u_boot移植(五)之分析uboot源码中nand flash操作
一、OneNand 和Nand Flash
我们已经能从Nand Flash启动了，启动之后，大家会看到如下效果:
可以看出,我们的uboot默认使用的是OneNand。需要注意的是我们的FSC100上面是没有OneNand的，有的是K9F2G08U0B
型号的NAND FLASH。
前面我们了解过Nor Flash 和Nand Flash，那OneNand Flash又是什么呢?
二、uboot 源码中Nand Flash部分代码分析
我们从Nand Flash初始化看起，打开lib_arm/board.c文件,为了紧抓主
线，以下代码只列举出了主线代码。
可以看出，我们可以通过CONFIG_CMD_NAND和
CONFIG_CMD_ONENAND两个宏来选择NAND FLASH初始化还是 ONENAND FLASH初始化。
uboot 中默认定义了宏CONFIG_CMD_ONENAND,所以选择的是ONENAND FLASH初始化。我们的FSC100上面使用的是
NAND FLASH，所以我们要定义CONFIG_CMD_NAND宏，取消CONFIG_CMD_ONENAND宏的定义。
嗯！先做个记录:
修改include/configs/fsc100.h,定义宏CONFIG_CMD_NAND,取消宏CONFIG_CMD_ONENAND。
好了，接下我们看看nand_init()函数时如何实现的。
看以看出，这段代码调用根据CONFIG_SYS_MAX_NAND_DEVICE宏[默认没有定义]的值来决定系统中Nand Flash设备的个数。接着调
用nand_init_chip()函数完成Nand Flash初始化，然后计算出每块Nand Flash的大小。最终会输出Nand Flash总的容量。
嗯!做个记录:
修改include/configs/fsc100.h,定义
宏CONFIG_SYS_MAX_NAND_DEVICE,值为1
没有看明白的地方是给nand_init_chip()函数传递的参数，接下来我们来看看他们是如何定义的。
哈哈，终于到了让人头疼的地方了。先来看看struct nand_chip和struct mtd_info两个结构体,这两个结构体的成员有很多很多，很多初学者一看到就晕头转向了，为了让大家不被吓到，我对这两个结构体的成员做了精简，只保留我们关心的成员，其它的都去掉了。
(1)struct nand_chip
每个成员的注释如下:
其中[BOARDSPECIFIC]标识的是需要我们自己填充的，它们跟我们开发板相关。其中select_chip会被uboot源码默认赋值
，但默认值一般都不能达到我们要求，所以需要我们自己填充。总结如下:
@IO_ADDR_R/W 用来记录SOC上面读取/写入数据的NFDATA寄存器地址
@select_chip 用来记录决定是否选中Nand Flash芯片的函数
@cmd_ctrl 用来记录发向Nand Flash发送命令或地址的函数 @dev_ready 用来记录探测Nand Flash是否就绪的函数
@options 用来记录Nand Flash的位宽
(2)struct mtd_info
每个成员解释如下:
@type 类型 : NOR Flash 、Nand Flash等
@size 存储设备大小
@name 设备名
@erase 对设备进行擦除操作
@read 对设备进行读操作
@write 对设备进行写操作
@priv 私有指针
哥们，这两个结构体到底是用来干嘛的呀? 要想回到这个问题，还得从Linux 内核的MTD框架说起。
MTD，Memory Technology Device即内存技术设备，在Linux内核中，引入MTD层为NOR FLASH和NAND FLASH设备提供统一接口。uboot中的MTD架构就是拷贝了内核的代码。
在MTD的架构中，在MTD层用一个数组 struct mtd_info
*mtd_table[MAX_MTD_DEVICES]保存系统中所有的MTD设备。每个MTD 设备利用 struct mtd_info 这个结构来描述，该结构中描述了存储设备的基本信息和具体操作所需要的内核函数。用数据结构struct nand_chip来表示一个NAND FLASH芯片, 该结构体包含了关于Nand Flash的地址信息,读写方法,ECC模式,硬件控制等一系列底层机制。
总的来说，在MTD架构中，用struct mtd_info 描述一个Flash 型设备，这个结构体中提供了通用的操作Flash 型设备的函数接口。例如:读、写、擦除等。用struct nand_chip描述一个NAND FLASH芯片，这个结构体中提供具体对NAND FLASH设备的操作函数。
这样做的一个好处就是，就是规范了函数调用接口。上层工程师调用通用的函数接口来操作Flash型设备，底层工程师提供具体函数接口来操作Flash型设备。关于上、下两层如何关联，就由MTD层来做。
这种分层的思想，在Linux 内核中体现了淋漓尽致，大家一定要掌握这种思想。
好了，不管有没有理解，都不影响我们移植uboot，我们只需要关系我们需要修改的部分，其他的部分MTD框架都给我们做好了。接着看代码吧!
这段代码主要干了三件事情:
(1)调用board_nand_ini()函数完成SOC的NAND Flash 控制器初始化，并且填充struct nand_chip结构体相应字段。也可以理解
为完成实际的开发板上的NAND Flash设备初始化。
(2)调用nand_scan()函数，扫描NAND Flash设备，并且填充struct
mtd_info结构体。也可以理解为完成MTD设备初始化。
(3)调用add_mtd_device()函数，向系统添加mtd设备。
接下来，我们先来看看第一件事,初始化开发板上的NAND Flash设备。显然，这个board_nand_ini()函数会随着开发板的不同实现就不同。在uboot的源码中，并没有S5CPC100对应的NAND Flash设备初始化函数，但是有s3c2410芯片对应的NAND Flash设备初始化函数。这两块SOC都是三星的产品，大同小异，我们先来分析一下s3c2410芯片对应的board_nand_init()函数的实现，然后编写S5PC100的board_nand_init()函数。
嗯!记录一下:
需要在drivers/mtd/nand目录下添加s5pc100_nand.c文件，完成FSC100的NAND Flash设备初始化。
s3c2410_nand.c
看以看到board_nand_init()函数，主要完成了一下几件事情:
(1)初始化Nand Flash控制器，让其发出Nand Flash要求的时序。
(2)填充了struct nand_chip结构体的select_chip 成员值为NULL 、cmd_ctrl成员值为s3c2410_hwcontrol、dev_ready成员值为
s3c2410_dev_ready。还记得这些成员值都是用来干嘛的吗?回顾一下....
(3)根据CONFIG_S3C2410_NAND_HWECC宏，决定Nand Flash设备使用硬件 ECC还是软件ECC。
关于s3c2410_hwcontrol、s3c2410_dev_ready函数时如何实现的，先不
急，后面用到的时候再看。接着来看看nand_scan函数时如何实现的。
这段代码很短，上面的注释是理解nand_scan函数主要功能最好资料，大家一定要读懂。
先来看看nand_scan_ident()函数，字面意思就是扫描Nand Flash设备的ID。
这段代码主要完成了,一下几件事情:
(1)调用nand_set_defaults()函数，初始化了struct nand_chip 没有在board_nand_init()函数中初始化的成员
例如:
(2)调用nand_get_flash_type()函数，读取了当前开发板中NAND FLASH 设备ID。我们来看看是如何实现的。
嗯，这段代码我精简了一下，如果全部贴出来，肯定会有很多人会说，"哥，我不干了，太吓人了"。废话少说，还是看看这段代码主要干了什么。从上面代码可以看出，这段代码中主要干了一下几件事情:
<1>发送读取ID命令给当前开发板上的Nand Flash设备，然后读取设备ID
<2>根据读取的NAND Flash设备ID ,在nand_flash_id数组中查询是否支持当前NAND FLASH
nand_flash_id 在driver/mtd/nand/nand_ids.c文件中有定义，以下这个
文件中的部分内容。
需要注意的是，如果这个数组中没有当前开发板NAND Flash的型号，大家只需要按照格式添加自己开发上的Nand Flash 设备到这个数组即可。
不知道到这个地方大家有没有晕掉，其实我一直跟学员将，有人带着分析代码是幸福的。
好了，接下来我们需要思考一下。我们知道要想对Nand Flash操作，必须先向Nand Flash 发送命令、发送地址操作。很明显这些操作是和具体SOC相关的。在前面的代码中分析中，我们看到在向Nand Flash发送命令是通过chip->cmdfunc()进行的。
接下来，我们就由chip->cmdfunc()为出发点，看看在uboot中如何向Nand Flash设备发送命令、发送地址的。
三、分析如何Nand Flash设备发送命令、地址
先来回顾一下chip->cmdfunc()函数，是什么时候赋值的。
可以看到，chip->cmdfunc赋值为nand_command函数。我们来看看这个函数是如何实现的。
可以看出，最终是调用chip->cmd_ctrl实现的。回顾一下chip-
>cmd_ctrl是什么时候赋值的。
嗯，在board_nand_init函数中，nand->cmd_ctrl =
s3c2410_hwcontrol。我们来看看s3c240_hwcontrol是如何实现的。
可以看出，如果s3c2410_hwcontrol 参数ctrl 中包含NAND_CLE则是向NFCMD寄存器中写入命令，如果ctrl中包含NAND_ALE则是向NFADDR 寄存器中写入地址。
嗯，做个记录:
需要在drivers/mtd/nand目录下的5pc100_nand.c文件中实现
s5pc100_hwcontrol函数中实现根据ctrl值是否含有
NAND_CLE、NAND_ALE来决定是向NFCMD寄存器写值还是想NFADDR寄存器写值。
呵呵，分析就到这里了，下一节，我们把我们需要修改的地方修改一下，完成对Nand Flash操作的支持。
背景： Board →ar7240(ap93) Cpu →mips 1、首先弄清楚什么是u-boot Uboot是德国DENX小组的开发，它用于多种嵌入式CPU的bootloader程序, uboot不仅支持嵌入式linux系统的引导，当前，它还支持其他的很多嵌入式操作系统。 除了PowerPC系列，还支持MIPS，x86，ARM，NIOS，XScale。 2、下载完uboot后解压，在根目录下，有如下重要的信息（目录或者文件）： 以下为为每个目录的说明： Board：和一些已有开发板有关的文件。每一个开发板都以一个子目录出现在当前目录中，子目录存放和开发板相关的配置文件。它的每个子文件夹里都有如下文件(以ar7240/ap93为例)： Makefile Config.mk Ap93.c 和板子相关的代码 Flash.c Flash操作代码 u-boot.lds 对应的链接文件 common：实现uboot命令行下支持的命令，每一条命令都对应一个文件。例如bootm命令对应就是cmd_bootm.c cpu：与特定CPU架构相关目录，每一款Uboot下支持的CPU在该目录下对应一个子目录，比如有子目录mips等。它的每个子文件夹里都有入下文件： Makefile Config.mk Cpu.c 和处理器相关的代码s Interrupts.c 中断处理代码 Serial.c 串口初始化代码 Start.s 全局开始启动代码 Disk：对磁盘的支持
Doc：文档目录。Uboot有非常完善的文档。 Drivers：Uboot支持的设备驱动程序都放在该目录，比如网卡，支持CFI的Flash，串口和USB等。 Fs：支持的文件系统，Uboot现在支持cramfs、fat、fdos、jffs2和registerfs。 Include：Uboot使用的头文件，还有对各种硬件平台支持的汇编文件，系统的配置文件和对文件系统支持的文件。该目下configs目录有与开发板相关的配置文件，如 ar7240_soc.h。该目录下的asm目录有与CPU体系结构相关的头文件，比如说mips 对应的有asm-mips。 Lib_xxx：与体系结构相关的库文件。如与ARM相关的库放在lib_arm中。 Net：与网络协议栈相关的代码，BOOTP协议、TFTP协议、RARP协议和NFS文件系统的实现。 Tools：生成Uboot的工具，如：mkimage等等。 3、mips架构u-boot启动流程 u-boot的启动过程大致做如下工作： 1、cpu初始化 2、时钟、串口、内存(ddr ram)初始化 3、内存划分、分配栈、数据、配置参数、以及u-boot代码在内存中的位置。 4、对u-boot代码作relocate 5、初始化malloc、flash、pci以及外设(比如，网口) 6、进入命令行或者直接启动Linux kernel 刚一开始由于参考网上代码，我一个劲的对基于smdk2410的板子，arm926ejs的cpu看了N 久，启动过程和这个大致相同。 整个启动中要涉及到四个文件： Start.S →cpu/mips/start.S Cache.S →cpu/mips/cache.S Lowlevel_init.S →board/ar7240/common/lowlevel_init.S Board.c →lib_mips/board.c 整个启动过程分为两个阶段来看： Stage1：系统上电后通过汇编执行代码 Stage2：通过一些列设置搭建了C环境，通过汇编指令跳转到C语言执行. Stage1： 程序从Start.S的_start开始执行.(至于为什么，参考u-boot.lds分析.doc) 先查看start.S文件吧!~ 从_start标记开始会看到一长串莫名奇妙的代码：
u－boot 移植步骤详解 1 U-Boot简介 U-Boot，全称Universal Boot Loader，是遵循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软件工程中心Wolfgang Denk[以下简称W.D]本人精湛专业水平和持着不懈的努力。当前，U-Boot项目正在他的领军之下，众多有志于开放源码BOOT LOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入，以支持更多的嵌入式操作系统的装载与引导。 选择U-Boot的理由： ①开放源码； ②支持多种嵌入式操作系统内核，如Linux、NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS； ③支持多个处理器系列，如PowerPC、ARM、x86、MIPS、XScale； ④较高的可靠性和稳定性； ④较高的可靠性和稳定性； ⑤高度灵活的功能设置，适合U-Boot调试、操作系统不同引导要求、产品发布等； ⑥丰富的设备驱动源码，如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等； ⑦较为丰富的开发调试文档与强大的网络技术支持； 2 U-Boot主要目录结构 - board 目标板相关文件，主要包含SDRAM、FLASH驱动； - common 独立于处理器体系结构的通用代码，如内存大小探测与故障检测；
NAND Flash 存储器 和 使用ELNEC编程器烧录NAND Flash 技术应用文档 Summer 翻译整理 深圳市浦洛电子科技有限公司 August 2006
目录 一． 简介 ----------------------------------------------------------------------------------- 1 二． NAND Flash与NOR Flash的区别 -------------------------------------------- 1 三． NAND Flash存储器结构描叙 --------------------------------------------------- 4 四． 备用单元结构描叙 ---------------------------------------------------------------- 6 五． Skip Block method（跳过坏块方式） ------------------------------------------ 8 六． Reserved Block Area method（保留块区域方式）----------------------------- 9 七． Error Checking and Correction（错误检测和纠正）-------------------------- 10 八． 文件系统 ------------------------------------------------------------------------------10 九． 使用ELNEC系列编程器烧录NAND Flash -------------------------------- 10 十． Invalid Block Management drop-down menu -------------------------------- 12 十一． User Area Settings3 -------------------------------------------------------- 13 十二． Solid Area Settings --------------------------------------------------------- 15 十三． Quick Program Check-box ---------------------------------------------- 16 十四． Reserved Block Area Options --------------------------------------------17 十五． Spare Area Usage drop-down menu ------------------------------------18
AM335x uboot spl分析 芯片到uboot启动流程 ROM → SPL→ uboot.img 简介 在335x 中ROM code是第一级的bootlader。mpu上电后将会自动执行这里的代码，完成部分初始化和引导第二级的bootlader，第二级的bootlader引导第三级bootader，在 ti官方上对于第二级和第三级的bootlader由uboot提供。 SPL To unify all existing implementations for a secondary program loader (SPL) and to allow simply adding of new implementations this generic SPL framework has been created. With this framework almost all source files for a board can be reused. No code duplication or symlinking is necessary anymore. 1> Basic ARM initialization 2> UART console initialization 3> Clocks and DPLL locking (minimal) 4> SDRAM initialization 5> Mux (minimal) 6> BootDevice initialization(based on where we are booting from.MMC1/MMC2/Nand/Onenand) 7> Bootloading real u-boot from the BootDevice and passing control to it. uboot spl源代码分析 一、makefile分析 打开spl文件夹只有一个makefile 可见spl都是复用uboot原先的代码。 主要涉及的代码文件为u-boot-2011.09-psp04.06.00.03/arch/arm/cpu/armv7 u-boot-2011.09-psp04.06.00.03/arch/arm/lib u-boot-2011.09-psp04.06.00.03/drivers LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-spl.lds 这个为链接脚本 __image_copy_end _end 三、代码解析 __start 为程序开始（arch/arm/cpu/armv7/start.S） .globl _start 这是在定义u-boot的启动定义入口点，汇编程序的缺省入口是 start 标号，用户也可以在连接脚本文件中用ENTRY标志指明其它入口点。
?UBoot源码解析（一）
主要内容 ?分析UBoot是如何引导Linux内核 ?UBoot源码的一阶段解析
BootLoader概念?Boot Loader 就是在操作系统内核运行之前运行 的一段小程序。通过这段小程序，我们可以初始 化硬件设备、建立内存空间的映射图，从而将系 统的软硬件环境带到一个合适的状态，以便为最 终调用操作系统内核准备好正确的环境 ?通常，Boot Loader 是严重地依赖于硬件而实现 的，特别是在嵌入式世界。因此，在嵌入式世界 里建立一个通用的Boot Loader 几乎是不可能的。 尽管如此，我们仍然可以对Boot Loader 归纳出 一些通用的概念来，以指导用户特定的Boot Loader 设计与实现。
UBoot来源?U-Boot 是 Das U-Boot 的简称，其含义是 Universal Boot Loader，是遵循 GPL 条款的开放源码项目。最早德国 DENX 软件工程中心的 Wolfgang Denk 基于 8xxROM 和 FADSROM 的源码创建了 PPCBoot 工程项目，此后不断 添加处理器的支持。而后，Sysgo Gmbh 把 PPCBoot 移 植到 ARM 平台上，创建了 ARMBoot 工程项目。最终， 以 PPCBoot 工程和 ARMBoot 工程为基础，创建了 U- Boot 工程。 ?而今，U-Boot 作为一个主流、通用的 BootLoader，成功地被移植到包括 PowerPC、ARM、X86 、MIPS、NIOS、XScale 等主流体系结构上的百种开发板，成为功能最多、 灵活性最强，并且开发最积极的开源 BootLoader。目前。 U-Boot 仍然由 DENX 的 Wolfgang Denk 维护
uboot版本文件结构的更新改变 分类：ARM2011-09-22 12:57 339人阅读评论(0) 收藏举报本来是开始分析uboot代码的，但是无论是教材还是网上资料都对于我最新下的uboot原码结构不同，对于还是小白的我不容易找到相应的文件，下面是uboot版本中文件组织结构的改变，，，，， u-boot版本情况 网站：http://ftp.denx.de/pub/u-boot/ 1、版本号变化： 2008年8月及以前 按版本号命名：u-boot-1.3.4.tar.bz2(2008年8月更新) 2008年8月以后均按日期命名。 目前最新版本：u-boot-2011.06.tar.bz2（2011年6月更新） 2、目录结构变化： u-boot目录结构主要经历过2次变化，u-boot版本第一次从u-boot-1.3.2开始发生变化，主要增加了api的内容；变化最大的是第二次，从2010.6版本开始。 u-boot-2010.03及以前版本 ├── api存放uboot提供的接口函数 ├── board根据不同开发板定制的代码，代码也不少 ├── common通用的代码，涵盖各个方面，已命令行处理为主 ├── cpu与体系结构相关的代码，uboot的重头戏 ├── disk磁盘分区相关代码 ├── doc文档，一堆README开头的文件 ├── drivers驱动，很丰富，每种类型的设备驱动占用一个子目录 ├── examples示例程序 ├── fs文件系统，支持嵌入式开发板常见的文件系统 ├── include头文件，已通用的头文件为主 ├── lib_【arch】与体系结构相关的通用库文件 ├── nand_spl NAND存储器相关代码 ├── net网络相关代码，小型的协议栈 ├── onenand_ipl
2 uboo t 源码分析 2.5.1.star t.S 2.5.1.star t.S 引入引入 2.5.1.1、u-boot.lds中找到start.S入口 (1)在C语言中整个项目的入口就是 main函数（这是 个.c文件的项目，第一个要分析的文件就是包含了C语言规定的），所以譬如说一 个有 main函数的那个文件。 10000 ( 2 方。ENTRY(_start)因此 _start 符号所在的文件就是整个程序的起始文 件， _sta rt 所在处的 代码就是整个程序的起始代码。 2.5.1.2、SourceInsight中如何找到 文件 (1)当前状况：我们知道在uboot中的1000多个文件中有一个符号 叫 _start，但是我们不知道 这个符号在哪个文件中。这种情况下要查找一个符号在所有项目中文件中的引用，要使用SourceInsight的搜索功能。 (2)start.s 在cpu/arm_cortexa9/start.s (3)然后进入start.S文件中，发现 个uboot的入口代码，就是第57 57行中就 是行。_sta rt 标号的定义处，于是乎我们就找到了整 2.5.1.3、SI中找文件技巧 (1)以上，找到了start.S文件，下面我们就从start.S文件开始分析uboot第一阶段。 (2)在SI中，如果我们知道我们要找的文件的名字，但是我们又不知道他在哪个目录下，我 们要怎样找到并打开这个文件？方法是在 SI中先打开右边的工程项目管理栏目，然后点击 最左边那个（这个是以文件为单位来浏览的），然后在上面输入栏中输入要找的文件的名 字。我们在输入的时候，SI在不断帮我们进行匹配，即使你不记得文件的全名只是大概记 得名字，也能帮助你找到你要找的文件。 2.5.2.start.S解析1 2.5.2.1、不简单的头文件包含
NOR-FLASH驱动文档(SST39VF1601)2012-03-30 00:57:33 NOR-FLASH是最早出现的Flash Memory，目前仍是多数供应商支持的技术架 构.NOR-FLASH在擦除和编程操作较少而直接执行代码的场合，尤其是纯代码存储的应用中广泛使用,但是由于NOR-FLASH只支持块擦除,其擦除和编程速度较慢，而块尺寸又较大，导致擦除和编程操作所花费的时间很长,所以在纯数据存储和文件存储的应用中显得力不从心. NOR-FLASH的特点是: 1. 程序和数据可存放在同一芯片上，FLASH芯片拥有独立的数据总线和地址总线，能快速随 机读取，并且允许系统直接从Flash中读取代码执行，而无需先将代码下载至RAM中再执行； 2. 可以单字节或单字读取，但不能单字节擦除，必须以部分或块为单位或对整片执行擦除操 作，在执行写操作之前,必需先根据需要对部分,块或整片进行擦除,然后才能写入数据。 以SST系列NOR-FLASH芯片为例介绍FLASH的使用方法及驱动. 首先,在驱动的头文件中,要根据芯片的具体情况和项目的要求作如下定义: 1. 定义操作的单位,如 typedef unsigned char BYTE; // BYTE is 8-bit in length typedef unsigned short int WORD; // WORD is 16-bit in length typedef unsigned long int Uint32; // Uint32 is 32-bit in length 在这里地址多是32位的,芯片写操作的最小数据单位为WORD,定义为16位,芯片读操作的最小数据单位是BYTE,定义为8位. 2. 因为芯片分为16位和32位的,所以对芯片的命令操作也分为16位操作和32位操作(命令 操作在介绍具体的读写过程中将详细介绍). #ifdef GE01 /*宏NorFlash_32Bit，若定义了为32位NorFlash，否则为16位NorFlash*/ #define NorFlash_32Bit #endif 3. 根据芯片的情况,定义部分(段)和块的大小. #define SECTOR_SIZE 2048 // Must be 2048 words for 39VF160X #define BLOCK_SIZE 32768 // Must be 32K words for 39VF160X
Common目录下面与环境变量有关的文件有以下几个：env_common.c，env_dataflash.c，env_eeprom.c，env_flash.c，env_nand.c，env_nowhere.c，env_nvram.c，environment.c。 env_common.c中包含的是default_environment[]的定义； env_dataflash.c，env_eeprom.c，env_flash.c，env_nand.c， env_nvram.c 中包含的是相应存储器与环境变量有关的函数：env_init(void)，saveenv(void)，env_relocate_spec (void)，env_relocate_spec (void)，use_default()。至于env_nowhere.c，因为我们没有定义CFG_ENV_IS_NOWHERE，所以这个文件实际上没有用。 environment.c这个文件时是我真正理解环境变量的一个关键。在这个文件里定义了一个完整的环境变量的结构体，即包含了这两个ENV_CRC（用于CRC校验），Flags（标志有没有环境变量的备份，根据CFG_REDUNDAND_ENVIRONMENT这个宏定义判断）。定义这个环境变量结构体的时候还有一个非常重要的关键字： __PPCENV__，而__PPCENV__在该.c文件中好像说是gnu c编译器的属性,如下： # define __PPCENV__ __attribute__ ((section(".text"))) 意思是把这个环境变量表作为代码段，所以在编译完UBOOT后，UBOOT的代码段就会有环境变量表。当然，这要在我们定义了ENV_IS_EMBEDDED之后才行，具体而言，环境变量表会在以下几个地方出现（以nand flash为例）： 1、UBOOT中的代码段（定义了ENV_IS_EMBEDDED）， 2、UBOOT中的默认环 境变量， 3、紧接UBOOT（0x0 ~ 0x1ffff）后面：0x20000 ~ 0x3ffff 之间，包括备份的环境变量，我们读取，保存也是对这个区域（即参数区）进行的。3、SDRAM中的UBOOT中，包括代码段部分和默认部分，4、SDRAM中的melloc分配的内存空间中。 Environment.c代码如下： env_t environment __PPCENV__ = { ENV_CRC, /* CRC Sum */ #ifdef CFG_REDUNDAND_ENVIRONMENT 1, /* Flags: valid */ #endif { #if defined(CONFIG_BOOTARGS) "bootargs=" CONFIG_BOOTARGS "\0" #endif #if defined(CONFIG_BOOTCOMMAND) "bootcmd=" CONFIG_BOOTCOMMAND "\0" #endif #if defined(CONFIG_RAMBOOTCOMMAND) "ramboot=" CONFIG_RAMBOOTCOMMAND "\0"
嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解（一） 嵌入式Linux之我行，主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验，二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处，谢请指正。 ?共享资源，欢迎转载：https://www.doczj.com/doc/4012060386.html, 一、移植环境 ?主机：VMWare--Fedora 9 ?开发板：Mini2440--64MB Nand,Kernel:2.6.30.4 ?编译器：arm-linux-gcc-4.3.2.tgz ?u-boot：u-boot-2009.08.tar.bz2 二、移植步骤 本次移植的功能特点包括： ?支持Nand Flash读写 ?支持从Nor/Nand Flash启动 ?支持CS8900或者DM9000网卡 ?支持Yaffs文件系统 ?支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程，如下图。
u-boot的stage1代码通常放在cpu/xxxx/start.S文件中，他用汇编语言写成；u-boot的stage2代码通常放在lib_xxxx/board.c文件中，他用C语言写成。各个部分的流程图如下：
2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持，可以查看board目录的一些子目录，如：board/samsung/目录下就是对三星一些ARM 处理器的支持，有smdk2400、smdk2410和smdk6400，但没有2440，所以我们就在这里建立自己的开发板项目。 1）因2440和2410的资源差不多，主频和外设有点差别，所以我们就在board/samsung/下建立自己开发板的项目，取名叫my2440 2）因2440和2410的资源差不多，所以就以2410项目的代码作为模板，以后再修改
浅谈NorFlash的原理及其应用 NOR Flash NOR Flash是现在市场上两种主要的非易失闪存技术之一。Intel 于1988年首先开发出NOR Flash 技术，彻底改变了原先由EPROM（Erasable Programmable Read-Only-Memory电可编程序只读存储器）和EEPROM（电可擦只读存储器Electrically Erasable Programmable Read - Only Memory）一统天下的局面。紧接着，1989年，东芝公司发表了NAND Flash 结构，强调降低每比特的成本，有更高的性能，并且像磁盘一样可以通过接口轻松升级。NOR Flash 的特点是芯片内执行（XIP ，eXecute In Place），这样应用程序可以直接在Flash闪存内运行，不必再把代码读到系统RAM中。NOR 的传输效率很高，在1~4MB的小容量时具有很高的成本效益，但是很低的写入和擦除速度大大影响到它的性能。NAND的结构能提供极高的单元密度，可以达到高存储密度，并且写入和擦除的速度也很快。应用NAND的困难在于Flash的管理需要特殊的系统接口。性能比较 flash闪存是非易失存储器，可以对称为块的存储器单元块进行擦写和再编程。任何flash 器件的写入操作只能在空或已擦除的单元内进行，所以大多数情况下，在进行写入操作之前必须先执行擦除。NAND器件执行擦除操作是十分简单的，而NOR则要求在进行擦除前先要将目标块内所有的位都写为0。由于擦除NOR器件时是以64～128KB的块进行的，执行一个写入/擦除操作的时间为5s，与此相反，擦除NAND器件是以8～32KB的块进行的，执行相同的操作最多只需要4ms。执行擦除时块尺寸的不同进一步拉大了NOR和NAND之间的性能差距，统计表明，对于给定的一套写入操作（尤其是更新小文件时），更多的擦除操作必须在基于NOR的单元中进行。这样，当选择存储解决方案时，设计师必须权衡以下的各项因素。 l 、NOR的读速度比NAND稍快一些。 2、NAND的写入速度比NOR快很多。 3 、NAND的4ms擦除速度远比NOR的5s快。 4 、大多数写入操作需要先进行擦除操作。 5 、NAND的擦除单元更小，相应的擦除电路更少。此外，NAND 的实际应用方式要比NOR复杂的多。NOR可以直接使用，并可在上面直接运行代码；而NAND需要I/O接口，因此使用时需要驱动程序。不过当今流行的操作系统对NAND结构的Flash都有支持。此外，Linux内核也提供了对NAND结构的Flash的支持。详解 NOR
Uboot启动分析笔记-----Stage1(start.S与lowlevel_init.S详解) Uboot启动分析笔记-----Stage1(start.S与lowlevel_init.S详解) 1 u-boot.lds 首先了解uboot的链接脚本board/my2410/u-boot.lds,它定义了目标程序各部分的链接顺序。OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") /*指定输出可执行文件为ELF格式，32为，ARM小端*/ OUTPUT_ARCH(arm) /*指定输出可执行文件为ARM平台*/ ENTRY(_start) /*起始代码段为_start*/ SECTIONS { /* 指定可执行image文件的全局入口点，通常这个地址都放在ROM(flash)0x0位置*、. = 0x00000000;从0x0位置开始 . = ALIGN(4); 4字节对齐 .text : {
cpu/arm920t/start.o (.text) board/my2440/lowlevel_init.o (.text) *(.text) } . = ALIGN(4); .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } . = ALIGN(4); .data : { *(.data) } /* 只读数据段，所有的只读数据段都放在这个位置*/ . = ALIGN(4); .got : { *(.got) } /*指定got段, got段式是uboot自定义的一个段, 非标准段*/ . = .; __u_boot_cmd_start = .; /*把__u_boot_cmd_start赋值为当前位置, 即起始位置*/ .u_boot_cmd : { *(.u_boot_cmd) } /* u_boot_cmd段，所有的u-boot命令相关的定义都放在这个位置，因为每个命令定义等长，所以只要以__u_boot_cmd_start为起始地址进行查找就可以很快查找到某一个命令的定义，并依据定义的命令指针调用相应的函数进行处理用户的任务*/ __u_boot_cmd_end = .; /* u_boot_cmd段结束位置，由此可以看出，这段空间的长度并没有严格限制，用户可以添加一些u-boot的命令，最终都会在连接是存放在这个位置。*/
NAND FLASH相对于NOR FLASH而言，其容量大，价格低廉，读写速度都比较快，因而得到广泛应用。NOR FLASH的特点是XIP，可直接执行应用程序， 1～4MB时应用具有很高的成本效益。但是其写入和擦除的速度很低直接影响了其性能。 NAND FLASH不能直接执行程序，用于存储数据。在嵌入式ARM应用中，存储在其中的数据通常是读取到SDROM中执行。因为NAND FLASH主要接口包括 几个I/O口，对其中的数据都是串行访问，无法实现随机访问，故而没有执行程序。 NAND FLASH接口电路是通过NAND FLAH控制器与ARM处理器相接的，许多ARM处理器都提供NAND FLASH控制器，为使用NAND FLASH带来巨大方便。 K9F2G08U0B是三星公司的一款NAND FLASH产品。 K9F2G08U0B包含8个I/O，Vss、Vcc、以及控制端口（CLE、ALE、CE、RE、WE、WP、R/B）。其存储结构分块。 共2K 块 每块大小16 页 每页大小2K + 64BYTE 即容量=块数×页数×每页大小=2K×16×（2K + 64BYTE）=256M BYTE + 8M BYTE NAND FLASH控制器提供了OM[1:0]、NCON、GPG13、GPG14、GPG15共5个信号来选择NAND FLASH启动。 OM[1:0]=0b00时，选择从NAND FLASH启动。 NCON：NAND FLASH类型选择信号。 GPG13：NAND FLASH页容量选择信号。 GPG14：NAND FLASH地址周期选择信号。 GPG15:NAND FLASH接口线宽选择。0：8bit总线宽度；1：16bit总线宽度。 访问NAND FLASH 1）发生命令：读、写、还是擦除 2）发生地址：选择哪一页进行上述操作 3）发生数据：需要检测NAND FLASH内部忙状态 NAND FLASH支持的命令： #define CMD_READ1 0x00 //页读命令周期1 #define CMD_READ2 0x30 //页读命令周期2 #define CMD_READID 0x90 //读ID 命令 #define CMD_WRITE1 0x80 //页写命令周期1 #define CMD_WRITE2 0x10 //页写命令周期2 #define CMD_ERASE1 0x60 //块擦除命令周期1 #define CMD_ERASE2 0xd0 //块擦除命令周期2 #define CMD_STATUS 0x70 //读状态命令 #define CMD_RESET 0xff //复位 #define CMD_RANDOMREAD1 0x05 //随意读命令周期1
关于uboot移植 CAMDIVN与时钟 2010-03-09 19:57 在该文件的122行附近有这样一个结构体 typedef struct { S3C24X0_REG32 LOCKTIME; S3C24X0_REG32 MPLLCON; S3C24X0_REG32 UPLLCON; S3C24X0_REG32 CLKCON; S3C24X0_REG32 CLKSLOW; S3C24X0_REG32 CLKDIVN; } /*__attribute__((__packed__))*/ S3C24X0_CLOCK_POWER; 是用来封装时钟寄存器的，我们要在其中增加一项S3C24X0_REG32 CAMDIVN，为什么加这么一个呢？因为这个寄存器是2410所没有的，而2440在配置时钟的时候又必须用到，看名字我们就知道是用来配置CAMERA时钟的，也就是配置摄像头的时钟的。 貌似和配置uboot启动的时钟没有关系？其实不然，我们在修改下一个文件的时候就可以看到其用途了， 此结构体修改后的结果为 typedef struct { S3C24X0_REG32 LOCKTIME; S3C24X0_REG32 MPLLCON; S3C24X0_REG32 UPLLCON; S3C24X0_REG32 CLKCON; S3C24X0_REG32 CLKSLOW; S3C24X0_REG32 CLKDIVN; S3C24X0_REG32 CAMDIVN; } /*__attribute__((__packed__))*/ S3C24X0_CLOCK_POWER; 第二个文件..\cpu\arm920t\s3c24x0\speed.c 在这个文件中需要修改两个函数 第一个函数在54行附近：static ulong get_PLLCLK(int pllreg) 由于S3C2410和S3C2440的MPLL、UPLL计算公式不一样，所以get_PLLCLK 函数也需要修改：
本文原创于观海听涛,原作者版权所有,转载请注明出处。 近几天开发项目需要用到STM32驱动NAND FLASH,但由于开发板例程以及固件库是用于小页(512B,我要用到的FLASH为1G bit的大页(2K,多走了两天弯路。以下笔记将说明如何将默认固件库修改为大页模式以驱动大容量NAND,并作驱动。 本文硬件:控制器:STM32F103ZET6,存储器:HY27UF081G2A 首先说一下NOR与NAND存储器的区别,此类区别网上有很多,在此仅大致说明: 1、Nor读取速度比NAND稍快 2、Nand写入速度比Nor快很多 3、NAND擦除速度(4ms远快于Nor(5s 4、Nor 带有SRAM接口,有足够的地址引脚来寻址,可以很轻松的挂接到CPU 地址和数据总线上,对CPU要求低 5、NAND用八个(或十六个引脚串行读取数据,数据总线地址总线复用,通常需要CPU支持驱动,且较为复杂 6、Nor主要占据1-16M容量市场,并且可以片内执行,适合代码存储 7、NAND占据8-128M及以上市场,通常用来作数据存储 8、NAND便宜一些 9、NAND寿命比Nor长 10、NAND会产生坏块,需要做坏块处理和ECC 更详细区别请继续百度,以上内容部分摘自神舟三号开发板手册
下面是NAND的存储结构: 由此图可看出NAND存储结构为立体式 正如硬盘的盘片被分为磁道,每个磁道又分为若干扇区,一块nand flash也分为若干block,每个block分为如干page。一般而言,block、page之间的关系随着芯片的不同而不同。 需要注意的是,对于flash的读写都是以一个page开始的,但是在读写之前必须进行flash 的擦写,而擦写则是以一个block为单位的。 我们这次使用的HY27UF081G2A其PDF介绍: Memory Cell Array = (2K+64 Bytes x 64 Pages x 1,024 Blocks 由此可见,该NAND每页2K,共64页,1024块。其中:每页中的2K为主容量Data Field, 64bit为额外容量Spare Field。Spare Field用于存贮检验码和其他信息用的,并不能存放实际的数据。由此可算出系统总容量为2K*64*1024=134217728个byte,即1Gbit。NAND闪存颗粒硬件接口: 由此图可见,此颗粒为八位总线,地址数据复用,芯片为SOP48封装。 软件驱动:(此部分写的是伪码,仅用于解释含义,可用代码参见附件 主程序: 1. #define BUFFER_SIZE 0x2000 //此部分定义缓冲区大小,即一次写入的数据 2. #define NAND_HY_MakerID 0xAD //NAND厂商号 3. #define NAND_HY_DeviceID 0xF1 //NAND器件号 4. /*配置与SRAM连接的FSMC BANK2 NAND*/
bootm命令中地址参数，内核加载地址以及内核入口地址 分类：u-boot2010-11-04 10:472962人阅读评论(0)收藏举报downloadlinuxbytecmdheaderimage bootm命令只能用来引导经过mkimage构建了镜像头的内核镜像文件以及根文件镜像，对于没有用mkimage对内核进行处理的话，那直接把内核下载到连接脚本中指定的加载地址0x30008000再运行就行，内核会自解压运行（不过内核运行需要一个tag来传递参数，而这个tag是由bootloader提供的，在u-boot下默认是由bootm命令建立的）。 通过mkimage可以给内核镜像或根文件系统镜像加入一个用来记录镜像的各种信息的头。同样通过mkimage也可以将内核镜像进行一次压缩(指定-C none/gzip/bzip2),所以这里也就引申出了两个阶段的解压缩过程：第一个阶段是u-boot里面的解压缩，也就是将由mkimage压缩的镜像解压缩得到原始的没加镜像头的内核镜像。第二个阶段是内核镜像的自解压，u-boot 里面的解压实际上是bootm 实现的，把mkimage -C bzip2或者gzip 生成的uImage进行解压；而kernel的自解压是对zImage进行解压，发生在bootm解压之后。 下面通过cmd_bootm.c文件中对bootm命令进行解析以及执行的过程来分析，这三种不同地址的区别： ulong load_addr = CFG_LOAD_ADDR; /* Default Load Address */ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { ...... if (argc < 2) { addr = load_addr;//当bootm命令后面不带地址参数时，将默认的加载地址赋值给addr } else { addr = simple_strtoul(argv[1], NULL, 16); //如果bootm命令后面带了加载地址，则将该地址赋值给addr,所以最终有用的地址还是bootm命令后附带的地址 } ...... //
NAND FLASH在储存测试系统中的应用(3) 2009-11-09 22:35:43 来源:王文杰马游春李锦明 关键字：NAND FLASH 储存测试K9K8G08UOM 2 NAND FLASkI Memory的硬件部分 本设计当中，FLASH的数据输入输出口、控制端口通过调理电路与FPGA的端口相连，图4所示是其硬件连接电路。 从图4中可知，FLASH的数据输入输出端口I／00～7、控制端口／CE、是通过芯片SN54LV245与FPGA相连；FLASH的控制端口cLE、ALE、／WE、／RE通过芯片SN54LV245和芯片74HCl4与ITGA相连。其中F-CLE、F-ALE、F—WE、F-RE、F—CE、F- R／Bur是FPGA的I／O口，是FPGA逻辑的输入输出口。CLE、ALE信号是FLASH存储器命令、地址锁存使能信号,／WE是保证命令、地址、数据能否及时正确的写入FLASH 的信号，／RE信号控制着数据的读取，这些信号的精确度关系着FLASH存储、读数功能的实现。所以，这些信号的好坏直接关系着FLASH的正常工作。经实践的电路调试，这些信号在传输过程中受到了其它因素的干扰，信号明显失真，在电路中加入74HCl4(非门)以后，信号会变得光滑，准确。 芯片SN54LV245是八进制三态总线收发器，DIR=1时，总线传输方向从A→B；DIR=0时，总线传输方向从B→A。／OE是片选信号。／0E，DIR信号是由FPGA内部编程逻辑控制的。 FL,ASH接口中，为了保证／wE、／RE、／CE、R／B控制信号初始状态无效，由硬件电路实现端口值拉高。本设计中不使用写保护功能，所以／WP端口也接上了上拉电阻。 3 结束语 基于闪存技术的固态存储器存储密度大，功耗小，可靠性高，体积小重量轻且成本也在不断降f氐，在航空应用中有良好的应用前景。在设计储存测试系统时选用大容量的NAIXD FLASH存储器大大提高了储存、读取速度，并且设计电路结构简单，易于修改。 (本文转自电子工程世界：http://www.eewo