OMAP35x下OneNand的分析以及x-loader的介绍
1. OneNand
要分析OneNand,首先我们必须回顾一下NOR与NAND。
两者在读写速度、密度、成本、使用寿命等方面各有千秋。与NOR Flash相比,NAND Flash的读数据速度稍慢,但是擦写速度快得多,并且在容量、使用寿命、成本上也占有较大优势。NOR Flash的编程简单,而NAND Flash的编程较为复杂。NAND Flash一般用于存储数据,而NOR Flash一般用于存储启动代码。
NOR Flash带有SRAM接口,有足够的地址引脚来寻址,可以很容易地存取其内容的每一字节(有限的地址引脚是限制其容量的因素之一)。NAND Flash使用复杂的I/O口来串行地存取数据,各个产品或厂商的方法可能各不相同。
这点很重要,因为NOR的接口与SRAM兼容,那么就意味着,ARM处理器只需要一个LDR指令就直接会产生相应的总线时序。说白了,就是NOR不需要任何驱动,就可以对它进行读操作。(不能直接写,因为FLASH一般都有写保护,并且写之前必须先擦除相应的地址) 相应的,由于NAND的接口复杂,读写操作都必须通过驱动才能完成。
这里就涉及到一个最基本的问题,我们引导一个系统时候都需要一个Bootloader对系统初始化。那么这个Bootloder运行之前是不可能有任何驱动的,有鸡才有蛋嘛!所以通常情况下我们是不可能直接在NAND上存放Bootloader的,必须一个NOR存放Bootloader,NAND存放系统内核和文件系统。(三星的有些处理器除外,比如s3c2410,s3c2440.它有一个机制是自动把NAND的前4K映射到SDRAM中)
那么有没有FLASH能把NAND与NOR的优点集合在一起呢?我想很多朋友在刚开始学习NOR与NAND的时候就会提出这个疑问。三星帮我们实现了,不得不佩服三星。
为了弥补NAND Flash的不足,三星公司在NAND Flash芯片内集成了一个RAM接口,命名为OneNAND Flash,这类Flash拥有与NOR Flash相同的简单接口,而且不受地址引脚的限制,即容量与地址引脚无关。它的结构如下:
其中OTP是不可以擦除的,里面有出场信息以及坏块的索引。
我们可以看出OneNand其实就是结合了,NOR与NAND,接口采用了NOR的,架构采用了NAND的。事实上性能测验下来也确实是取二者之精华。BufferRam为5KB,1KB做bootram,4KB dataram。后面NAND架构还是block+page+sector的。
OneNand的驱动原理其实就是通过LDR直接配置OneNand内部寄存器,让其把自己NAND架构下的数据复制到BufferRam下供用户直接使用。
我们以LOAD(读)为例分析它的机制,流程图图下:
(1) 首先我们把要LOAD的Block地址给相应寄存器(偏移地址:F100h)
(2) 然后把要LOAD的Page+Sector地址给相应寄存器(偏移地址:F107h)
(3) 在选择要LOAD的目的为哪个DataRam(偏移地址:F200h)
(4) 并且设置相应的DataRam的起始地址(偏移地址:F101h)
(5) 清空中断状态寄存器(偏移地址:F241h)
(6) 发送LOAD命令给命令寄存器(偏移地址:F220h)
(7) 等待LOAD完成,查看中断寄存器是不是有相应标志位(偏移地址:F241h)
(8) 最后在相应dataram中获取数据。
2.x-loader
X-loader我也是在接触OMAP35x后才接触的,查看他的文件结构,发现与Uboot非常兼容,都是cpu下放有关arm的初始化,board下放板子的初始化,driver下放驱动等等。
X-loader在cpu下主要完成了常规的arm内核的初始化,这个代码与Uboot下的一致,在board下的omapebm下完成了对omap3530的总线,时钟的初始化。Uboot也有对应的代码,但是我发现有的函数根本没有完成相应的功能,而应该是在x-loder下实际完成的。
X-loader还完成了OneNand的相应初始化,并且把Uboot从NAND架构下,复制到BuffrtRam下,在复制到SDRAM中。
X-loader还支持从SD、MMC下引导Uboot,他在CPU下有对mmc的初始化程序,可以直接把uboot.bin从MMC下复制到SDRAM中。
至于为什么用x-loader,他只过不是Uboot的一个子集 原因是:U-BOOT 太大,塞不进 OMAP3的内部RAM。 所以 用x-load。 OMAP3 上电的时候,读取x-load 到 内部RAM,然后执行。 X-LOAD 初始化memory controller,把 u-boot 读进 外部 RAM,然后跳到 外部RAM 执行u-boot。