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的工作態度要好多了。