MTK SPI驅動的問題

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