1 引言
在做家联网项目中，对MTK的低端芯片方案进行过选型，主要分析了MTK7620/7628 2.4G SOC方案，虽然最终选择了更廉价的其它方案，但在本选型中发现网上甚少涉及的的，且平常不太受重视的FLASH读写问题，其具体处理与部分解决方法如本文所述。
2 内容
本次涉及到的FLASH读写问题主要如下：
1）不擦除问题
2）读死循环问题。
2.1 FLASH不擦
具体表现为：在uboot下，升级固件时，串口上显示擦除操作超级快，6M多几乎是秒清，然后写得也较快。
开始还挺乐呵地认为MTK好牛，比QCA的要快多了。但每次写完后，直接提示检测错误后，就非常郁闷了。利用mn检查0x90050000位置的信息，才发现其上的内容根本没有变化，既没有擦除，也没有写入，板子还是由原来的固件驱动着；偶尔地，有擦有写，但不完整，导致板子无法正常启动。
这个问题的处理主要涉及到uboot中spi_flash.c的改写，发现将raspi_write_enable指令仅可能靠近有写/擦调用的raspi_cmd指令，会极大地降低出现的概率；另外，测试中发现，如果利用杜邦线将FLASH引出时，出现的概率会大大增加。在QCA方案中，我们只发现在QCA9557硬件平台上短暂出现过这个无法擦除的问题，但通过在擦除操作前usleep
15后，问题不再重现。
附带地，这个问题肯定是个共性问题，试过好多厂家的板子，在uboot下只要多升级几次（最多不超过5次），就有可能碰到不擦除，或部分擦除，部分不擦除的问题。可能还是时序有问题吧，我在扇区擦，写前usleep了还是不能彻底解决此问题。从FLASH驱动的稳定性上讲，QCA的确实要稳定多了，虽然会慢一点。
2.2 读死循环问题
具体表现为，利用raspi_cmd函数执行winbond的“Instruction Set Table 1”中“Read Security Registers”指令时，会直接将板子挂住（不是挂死）。表现为串口不再更新打印，没有panic，也不会重启。
通过跟踪打印，是挂在raspi_cmd函数的下边循环中。
do {
reg = (u32) (ra_inl(RT2880_SPIFIFOSTAT_REG) & 0xff);
} while (reg == 0 );
可能基于代码的原始意图，以及正常预期，这里应该能读到值，且能正确退出吧。但这个陷入死循环的条件却偏偏被我一下子就触发了。
其实这里只要加上一个计数，在计数器超过预期后异常后退出，同时在计数器异常时，立即让读缓存区全为FF或全00并直接退出，这样更友好。
另外，通过对照7620与7628的SPI FLASH驱动，发现7628的驱动比7620的驱动要好用些，可以直接一致地调用Winbond的“Instruction Set Table 1” —“Instruction Set Table 4”中大部分指令（4B指令没有用），不会出现挂死现象。真的要感谢那个写ralink_bbu_spi的程序员，应该做了好多调试。比那个写uci2dat的工作态度要好多了。
