一、wince 啟動過程分析
>>二、分析uboot啟動wince的可能性我用的是utu2440的開發板，板子自帶的啟動檔案包括nboot1、nboot2、eboot、wince核心，各個檔案作用是：nboot1：s3c2440對於nand flash，最大載入4k的**執行，可以直接執行這個程式，nboot1啟動後會從flash中載入nboot2
nboot2：主要實現從flash中讀取wince核心、載入eboot、顯示啟動畫面
eboot：實現對flash進行分割槽、格式化和燒寫wince核心映象檔案，這裡要注意的是eboot在燒寫 wince核心映象的過程中會把nk.bin解壓為nb.nb0再寫入到flash中。
>三、測試可能性對於nboot1、nboot2的功能完全可以用uboot代替，本身uboot已經實現nand falsh 啟動，再就是wince核心檔案 nk.nb0 可以直接載入到記憶體的 0x30200000，然後使用 uboot的 go 指令直接執行wince核心檔案。
在去掉binfs支援後，uboot可以實現將nk.nb0燒寫到flash中，然後啟動時讀取到0x30200000位置，最後用go命令載入啟動 wince，這麼來看應該是很簡單的事了（後來證明此時的想法太。。。。。。）
使用uboot將nk.nb0載入到0x3020000中，然後go 0x30200000，等了一會果真看到了wince的介面，這一步成功了，下一步就可以直接燒寫了。但是很快發現，使用這種方法啟動一次wince後就 無法再啟動uboot，通過讀取flash的內容發現，wince把uboot的flash塊給格式化了。是什麼原因呢？四、flash 管理區域劃分原來是因為這個wince核心有自動分割槽格式化功能，上面已經說了uboot中不實現分割槽格式化的功能，所以在wince中就必須新增這個功能。但是這樣 一來wince就會格式化uboot，通過閱讀eboot發現，eboot在格式化的時候會把eboot區標記為壞塊，這樣wince就不會進行格式化 了，看來必須首先解決這個問題。
我的flash大小是64m，wince 核心檔案加上uboot不超過32m，這樣就定義flash的前32m由uboot進行管理，這32m對wince來說是不存在的，後32m歸於 wince進行儲存，在wince中進行管理。如果要阻止wicne格式化前32m，可以再uboot中對前32m全部標記為壞塊，但是這樣一來uboot本身對flash所有操作也會首先做壞塊檢 測。如果這麼做的話，每次uboot對flash讀寫時取消壞塊標記，操作完成後在標記為壞塊。思路應該是可行的，但是感覺這麼做太麻煩了。當然條條大路 通羅馬，我們可以逆向思維一下，為何不能修改wince核心來遮蔽前32m flash空間呢？
通過閱讀wince的bsp，發現有個很重要的巨集定義
loader.h中
// nand boot (loads into steppingstone) @ block 0#define nboot_block 0
#define nboot_block_size 1
#define nboot_sector block_to_sector(nboot_block)
// toc @ block 1
#define toc_block 1
#define toc_block_size 1
#define toc_sector block_to_sector(toc_block)
// eboot @ block 2
#define eboot_block 2
#define eboot_sector_size file_to_sector_size(eboot_ram_image_size)
#define eboot_block_size sector_to_block(eboot_sector_size)
#define eboot_sector block_to_sector(eboot_block)
//#define
reserved_boot_blocks (
nboot_block_size +
toc_block_size +
eboot_block_size
)/*這個引數是定義預覽 block 的數量，預設是nboot + toc + eboot，我為了遮蔽前面32m空間，需要修改此定義*/
#define
reserved_boot_blocks
sector_to_block(file_to_sector_size(0x2000000))
// images start after oem reserved blocks
#define image_start_block reserved_boot_blocks
#define image_start_sector block_to_sector(image_start_block)
修改reserved_boot_blocks
閱讀了一下wince的fmd驅動，這裡初始化flash，發現有一句很不可理解
// pflashinfo->dwnumblocks = num_blocks ;/*這是原來的定義，修改為下面的值*/
pflashinfo->dwnumblocks = num_blocks - image_start_block ;
按照道理來講，初始化flash block數量時至少應該遮蔽nbot eboot兩部分，但是這個bsp中未遮蔽，在網上查詢了一下，的確有的bsp是定義為
num_blocks - image_start_block，我覺得這樣定義更合理。也許是bsp從三星出來到我手上中間經過不少人修改，留下了這個bug吧。
重新編譯，載入，一切正常，wince可正常啟動。
最後把wince核心檔案燒寫到flash中，uboot啟動時自動載入，一切正常。
經過這樣修改以後，wince啟動時如果沒有檢測到有效的mbr，則會自動分割槽格式化，第二次再啟動時就不會再格式化了，剩餘的32m空間可以儲存使用者文 件。在wince的儲存管理中可以看到flash大小為32m，的確已經成功遮蔽了前面的32m空間。
至此，該工作告一段落，uboot可以正常燒寫、載入wince了。
ARM開發版uboot燒寫
製作uboot，啟動開發板 zshh zshh shaohua arm arm資料 cd exynos4412 lzy1 src uboot uboot 2012 12 1.切換目錄到exynos4412 lzy1 src uboot uboot 2012 12 zshh zshh shaohua ...
三 開發板UBOOT燒寫
該板子的uboot kernel rootfs 的映象最後都要燒在nandflash 下，因此先了解一下nandflash 的 分割槽情況以避免出現前後覆蓋的情況 分割槽名稱 位址範圍 分割槽描述 bootloader 0x00000000 0x0003ffff 燒寫uboot 的分割槽 kerne...
通過uboot燒寫yaffs檔案系統
之前在sep4020上做開發的時候一直用的都是nfs檔案系統 今天嘗試在板子上燒寫cramfs以及yaffs檔案系統，按照手冊燒寫cramfs檔案系統時一切順利，沒有遇到什麼問題。在燒yaffs的時候，起初使用的是在啟動cramfs之後，再把yaffs的分割槽掛在到cramfs中，並把相關的檔案拷貝...