uboot移植之修改支持NorFlash识别篇5
uboot移植之前期准备篇1
uboot移植之Makefile分析概述篇2
uboot移植之init_sequence_f函数数组分析(番外篇)
uboot移植之源码流程分析篇3(超详细！)
uboot移植之修改支持SDRAM篇4
uboot移植之修改支持NandFlash识别篇6（超详细）
前情回顾：成功修改了SDRAM之后，启动uboot，发现其输出打印信息中识别出来"Flash: 0 Bytes"，明显不符合我们硬件信息状态。所以，有必要修改以支持NorFlash。
在工程文件中搜索关键字“Flash: ”，根据输出信息，最终定位到drivers\mtd\cfi_flash.c的 flash_init 调用函数：
flash_info结构体中包含了该flash空间大小，芯片id，扇区数量等等的芯片特定数据信息成员，类似于篇6中nand flash的mtd_info结构体。由于BANKS宏为1，for循环仅仅执行一次。第2358~2359行代码并没有做什么实质性操作，不予理会。
((unsigned long []){ 0x12345678 }) [i]。就是将大括号里的地址强制转换成unsigned long数组类型，然后根据索引 i 取对应数值，确定flash的块基址。看测试：（大括号不能省略）
关键在于调用if语句，去检测Nor Flash，如果检测到的id并不存在，就打印一条unknown语句，但是根据我们uboot的启动输出信息可以知道，并没有输出该语句，可见id是匹配的。为了加快找到具体问题所在，可以在该文件开头定义调试信息打印宏开关，重新编译烧写，启动时观察更加详细的输出信息，找到问题。
重启：
查看Nor Flash的型号芯片手册，可以知道厂家ID，设备id为正好为C2，2249，并没有错误。
Nor Flash连接CPU时，根据不同的数据宽度，比如16位的NOR FLASH，处理器的地址线要向左移偏1位。而32位就需要向左偏移2位。
因为芯片手册中指定发出的地址是针对作用于Nor Flash，而不是代表CPU本身发出的地址，所以，还要根据具体情况决定是否要移位以保证Nor Flash接收到的地址值是正确的。
所以，(555<<1)=aaaa，(2AA<<1)=5554，刚好对应了uboot启动信息中的addr，也即是cpu发出的地址。
调用语句打印“FEDEC PROBE:”信息的函数正好是 flash_detect_legacy ，即是说：在flash_detect_legacy函数中可以正确识别出芯片id，但是在通过芯片id调用jedec_flash_match匹对的时候失败了，没有找到对应型号的Nor Flash。
此时，我们的位置在
重点分析jedec_flash_match函数，其实就是循环调用jedec_table数组中的内容，并且以识别出来的ID号为依据，不断匹配校验，如果找到了，就提取对应芯片的信息。但是，根据实际，程序并没有找到。所以，在该数组中，缺少了该芯片ID的原材料信息。
接下来，仿照其他特点相近的芯片数组项，添加一个自己芯片型号的数组项。
如果一个Nor Flash中块大小的划分类型都是16k。那么，其擦除区域数NumEraseRegions为1。
如果一个Nor Flash中块大小的划分类型有16k，8k。那么，其擦除区域数NumEraseRegions为2。
如果一个Nor Flash中块大小的划分类型有16k，8k，32k，64k。那么，其擦除区域数NumEraseRegions为4。
ERASEINFO参数格式：(参数1：块大小，参数2：块数量)。至于各个区域的地址范围，以及各种块数量可以查看芯片手册得知：
我们用的Nor型号中16k，8k，32k，64k对应的块数量分别有1，2，1，31个。全部块加起来刚好1M。将修改过的文件上传，重新编译，烧写，启动uboot：
可以识别出Flash正确大小了，调试宏可以关闭。“ERROR: too many flash sectors”也不难去掉，只要将相应的扇区宏上限调高些就可以避免打印了。
参考资料：
《ARM9嵌入式系统设计与应用开发》 熊茂华 杨震伦 主编
《嵌入式Linux应用开发完全手册》 韦东山著
《S3C2440A_UserManual_Rev13》
《MX29LV160DBTI-70G(NOR FLASH)》