07.26.2011, 嵌入式, by qwl.
自己從第一次接觸nandflash到現在也有將近兩年的時間了，從剛開始的無從下手到現在的略知一二。
回過頭來看自己的學習歷程，積累了很多無論你如何google和泡罈子都學習不到的經驗。現在拿出來分享給大夥，算是對集體智慧型的一種回饋吧。
首先說一下nandflash本身的一些缺陷和優勢：
優勢：1，速度快。這個貌似沒啥可說的，對於現在動輒上g的晶元容量，速度是必要的基礎。
2，便宜。雖然趕不上硬碟，但是在嵌入式裝置裡面絕對是價效比槓槓的。
3，沒了。除了傻快傻便宜，真沒嘛優勢。
劣勢：1，可靠性不高。這裡所說的可靠性分為兩個方面，第一是晶元出廠的時候就伴隨著一定概率的缺陷。你們懂得，我說的是壞塊。這個缺陷會令很多初入此行的孩紙們丟掉工作，後面會詳細說。第二個是晶元使用過程中的不穩定，當然還是在說會產生壞塊的問題。。。
2，不能片上執行程式。由於無法直接定址，所以就不可能做到片上執行程式。這是很多網路上文章經常提到的一點，實際上對生活影響不大。因為現在記憶體便宜的很，一般的家用嵌入式裝置對記憶體沒有這麼苛刻的要求。
3，晶元操作複雜。不同於norflash，nandflash沒有這麼容易操作。我說的操作主要是指不通過驅動程式直接靠程式設計完成對於flash的訪問。但是我還是要說上面的話：實際上對於生活影響不大。因為目前大部分的民用嵌入式裝置都有作業系統，一般為linux。linux為flash裝置提供了mtd驅動層，我們對於flash的操作都被抽象成了統一的介面甚至是裝置符號，無需關心底層實現。
下面來說說實際使用時候的一些心得體會：
一，什麼樣nandflash分割槽大小是合理的？
考慮到業務的需要，一般我們不會將整個晶元完全當作乙個整體來使用。就如同你使用電腦的時候不會只給硬碟分乙個區一樣。主要是為了防止對分割槽進行改動或者重新燒錄的時候會丟失全部的資料。
而如何分割槽才是合理的呢？我歸納主要有以下幾點需要注意：
1，任意乙個分割槽的大小不要超過作業系統所能操作記憶體的2/3。比如你有128m記憶體，linux可以支配其中的96m，那請不要將nandflash的分割槽設計為大於64m。
這樣的考慮主要是因為，如果未來你需要公升級這個分割槽，尤其是通過網路公升級這個分割槽。如果你的公升級方式不是增量式的，那麼你必須有一段與flash分割槽大小一致記憶體空間用來存放映象。這個時候假設你的flash分割槽為96m，那麼你將不可能完成更新。因為你沒有足夠的記憶體空間。除非實時解壓縮實時燒錄，風險很高。
2，分割槽一定要給壞塊留出足夠的空間。我最早接觸到nandflash的時候就犯了這個錯誤，uboot大小200k，我給它劃分的空間為256k，結果遭遇壞塊，上下移動都沒有空間，非常杯具。
拿目前嵌入式系統比較常用的128m nandflash，他沒產生乙個壞塊，空間損失128k。也就是說，如果你設計分割槽大小為512k，遭遇兩個壞塊，實際空間只有256k了。
通過大量裝置生產後所統計出來的結果，一般nandflash出廠的壞塊基本不會超過4塊。位置不固定。所以我的推薦是，如果你的某些分割槽容量較小，比如設計使用容量為512k，請劃分該分割槽為1m以避免壞塊。如果分割槽容量較大，比如60m，請劃分64m。這樣比較合理。
3，如果被劃分的分割槽將會使用檔案系統，比如yaffs之類，請不要劃分的過小。比如你有乙個分割槽用來儲存配置檔案，你認為只需要3m就可以解決問題。但實際上你會發現，這個分割槽只要一mount上，就已經被占用了2m，因為檔案系統自己會規劃出來一部分區域。你自己能操作的空間只剩下1m了，與設計目標產生巨大的衝突。請適當調整大小，並同時參考2號建議。
二，如何對nandflash分割槽進行合理的規劃？
這裡所說的規劃指flash要如何進行邏輯上的區分，比如要分幾個區等。
這個問題說起來比較複雜，因為不同的應用有不同的設計目標。有些提供可能簡單的分兩個區甚至不分割槽就能解決問題，而有些可能會很複雜。
這裡我拿我所經手的專案舉例子：
專案為iptv機頂盒，使用linux作業系統，使用uboot作為引導程式。
我的分割槽如下：
1m,uboot
1m,uboot-config
3m,kernel
32m,rootfs
16m,backup-rootfs
5m,config
uboot如果公升級失敗，將會帶來災難性的後果。但是有些uboot啟動的引數需要被動態的更改，所以必須要把uboot儲存引數的部分與uboot分離。所以uboot被分為兩個區分別儲存。
kernel無需多說，由於附帶的驅動較多3m是乙個合理的數值。
rootfs指linux所依賴的根檔案系統。包括busybox以及實現最小系統所必須的檔案。
rootfs-backup為備份根檔案系統，裡面存放最小系統所必須的檔案以及系統恢復用的程式。
config分割槽儲存應用程式所依賴的一些配置檔案。單獨乙個分割槽存放是為了避免使用者程式分割槽被公升級時，每乙個使用者自己的設定以及資訊不會丟失。
我這裡要特別說一下uboot部分。
uboot是整個nandflash的靈魂，沒有他系統就無法正常啟動，甚至無法正常初始化記憶體。當然uboot只是一種程式，他開源，易於使用，大夥都愛用它。親，支援哦～
在我們的專案中，uboot一直沒給我們找什麼麻煩。但是到了工廠生產的時候，卻吃了大虧。100片nandflash燒錄完有超過10片無法正常啟動。為什麼呢？原因如下：
nandflash在出廠的時候一定會保證第乙個塊不是壞塊，在我們所使用的晶元裡，就是前128k絕對可以使用。但是後面的塊就無法保證了。我們為uboot劃分了512k空間，本來覺得就算是有壞塊也會跳過去，沒有所謂。
但是我們忽略的乙個雷人的問題……那就是uboot被燒錄器燒錄完以後，已經因為壞塊導致自己被燒錄的支離破碎。當cpu將第一塊資料讀取到記憶體中並執行的時候，這部分**不具備跳壞塊讀取的能力，自然而然的uboot其餘的部分就無法正常讀取，自然系統將會無法啟動……
如何解決呢？
方法說簡單也簡單，說複雜也複雜。我們需要首先編譯乙個小於128k什麼功能都不帶但是完整的uboot。通過這個uboot引導起來以後再從flash裡面讀取另外乙個完整功能的uboot到記憶體，然後引導這個uboot然後再引導linux。這就是傳說中的二段跳。
所以在我們的系統分割槽中，uboot的那1m分割槽，實際上包含了兩個uboot。
前128k乙個，後面也許緊貼著也許隔若干個壞塊又是乙個uboot。這樣就避免在工廠生產出來的uboot無法啟動問題。同學們一定要切記！
基本上就是這些，下一次有時間會說說如何通過uboot實現公升級失敗後的啟動分割槽切換，來完成災難拯救的任務。
**：
關於cachedrowset在實際專案中的應用
由於專案需求原因，需要實現乙個功能就是，抽取大量的資料庫資料然後寫入文字並打包上傳。看似乙個很簡單的東西，在大資料量的環境下就顯得不是那麼簡單了。首先有60張左右的表需要進行資料的處理。各個公司情況不同，表的總資料量可能是幾千萬到幾十億不等。所以，耗時非常嚴重。由於只是單純的進行資料的提取加工寫入文...
關於NandFlash 啟動問題
最初學習嵌入式linux驅動時，按照韋東山老師的移植教程糊里糊塗的完成了2440的norflash和nandflash的啟動，但並不明白所以然，所以就花時間研究一下，解除心中的疑惑。並附上韋東山的講解 如下圖2440的記憶體對映所示 norflash啟動 根據手冊可知，當晶元配置為norflash啟...
JMeter BeanShell在實際測試中的應用
beanshell最常用的場景 beanshell除了可以import外部jar包外，還有乙個十分好用的特性，就是可以可以引用外部beanshell指令碼。aa bb cc scripta.bsh void printinfo scriptb.bsh source aa bb cc scripta....