在搞定了nandflash bin文件的基礎上，
可以做些簡單的應用測試程序了，現在又幾個方式燒寫nandflash
1. 通過MDK自帶的燒寫方式
2. 通過把程序加載到SDRAM中運行，把指定的bin文件燒寫進nandflash中。
3. 通過工具DNW，USB燒寫
對於方式1，我加上led顯示發現 Init（）函數被flashOS調用了2次
，這很奇怪。打算放棄方式1，採取方式2來進行。
按照正常流程，Init()在整個操作流程中應該只調用一次就可以，現在竟然調用了兩次，這難道是因爲程序運行復位了？？？確實是程序跑飛了，但怎麼還能自己復位呢？
方式2需要實現fopen等文件操作接口。
網上下載了一個2410完全開發pdf教程，說的非常好，看了後有了很多啓發，也讓我有了更大的信心
繼續回到方式1，因爲在nand編程算法中沒有涉及到MPLLCON的設置，根據手冊，設置MPLLCON之前（即沒有使用PLL），CPU的時鐘是來自於外部晶振12MHZ，所以我想在nand編程算法中嵌入
串口打印輸出的代碼baud = 115200bps，出現flash time out！！！這是一個問題
或者我嘗試這樣做:在flash編程算法中我田間MPLL的設置操作，之後看UART輸出情況。
（插曲，我在SDRAM把對nand進行編程時發現nand前面很多塊都是壞塊，那壞塊以後就不會用了嗎？這不是浪費嗎）
test：
還有一個問題很奇怪，我用不帶校verify的nand編程算法把2410_Run_nand
的bin文件（大小爲17K放到）燒寫到nand中，之後竟然可以運行起來，串口中看到了打印的數據，但是要等很長時間才能打印出來，這非常奇怪，使用的
bootload中也加入了代碼的搬運工作。。。原因待查
現在往其中燒錄bin文件（27KB）之後，無法運行。我無意中注意到bootload中的nand_read_ll()函數只是根據地址和尺寸從nand中讀取數據，並沒有檢查壞塊的操作，這就有可能搬運到了無效的數據到SDRAM中
運行，當然程序也就無法工作了。如果程序size是低於1個blocksize的（16KB）燒錄後運行是OK的，但是如果超過16KB則會出現異常問題。
解決思路：增加壞塊檢查。
應該這樣：把nandboot單獨做個project編譯生成bin（務必保證小於4KB）文件，燒錄到nand 0x0開始的區域，該nboot中做代碼搬運，nandcopy的源地址爲應用程序的load位置，目標地址爲SDRAM的位置。
運行異常還有可能有個原因：可能我的主程序中有中斷設置，在運行中產生了一次中斷，則PC指向了默認的異常向量表（0x0/4/8/C等開始的地方）這導致程序流程就亂了。嘿嘿。所以首先要確定一下
在程序中如果發生中斷的話。PC如何處理。
測試思路：在SDRAM中調試運行一個帶中斷的程序，觸發中斷後看PC的指向。就這麼辦！！！
（這個任務一定要在明天，及2010.01.16做一下，務必要看2410中中斷一章節手冊）
新任務1，在MDK下建立好VIVI針對2410的編譯project。通讀VIVI，下週三前完成。
新任務2，2010.01.17號開始仔細研究MMU機制，打算花一天時間，並寫好記錄文檔。
繼續跟蹤2410init.s上在nand中運行情況，使用串口打印字符，可以知道程序流程，目前已經發現uart初始化OK, 在進入nandcopy函數中程序沒有返回，所以問題可以定位在這個地方，
NND先檢查它的nand配置也沒有錯誤。bl nand_read_ll進入該函數前沒有問題，但是沒有它沒有返回。我現在懷疑這個nand_read_ll函數根本就進不去，因爲在link的時候，這個函數不知道被link在哪裏了，
或者說被link到前4K SRAM區域之外的地方，所以用bl指令跳轉到那根本不行。但即使跳轉的不對，爲什麼會出現8次重新的開始的情況呢？繼續查？
哈哈，經過查看編譯後的map文件。發現nand_read_ll函數果然被定位到SRAM之外區域呢？這肯定是跳轉不到的呀。。
map如下：
wait_idle 0x00001204 ARM Code 44 nandread.o(.text)
nand_read_ll 0x00001230 ARM Code 216 nandread.o(.text)
知道事發原因了，那現在開始改 link佈局。
我看了一下發現在4KB以內的代碼主要有（毫無疑問2410Init.o代碼肯定是在裏面的，因爲我在sct文件中指定了它的佈局）2410lib.o, led.o, nanddriver.o,這就必須要面對一下分散加載
機制的使用了。OK, let‘s go，勝利就在不遠的前方。
暫且有兩個思路：
思路 1，精簡代碼，只針對bootload工程，
這個bootload起名 dreamload（自己給自己搞笑了）
---UART
---USB(暫不加)
---NAND READ
確保其編譯生成的bin文件一定要在4KB以內。
思路 2，利用好分散加載文件，程序大些，bin甚至超過blocksize也無所謂，只要main程序在bin中的load addr讓dreamload中nandcopy函數知道，保證複製到SDRAM中沒有問題
先按照第一種方式做：
在這之前，在鞏固一下分散加載的機制，|Image$$EREGION_name$$Base|指的是某個region的執行地址；|load$$EREGION_name$$Base|指的是某個region的加載地址；
這個我理解爲編譯器在link過程時，把|load$$EREGION_name$$Base|和bin文件中的EREGION位置關聯起來。
NND回過來看這個在網上下載的2410init.s真是垃圾，錯誤百出，作者也太無良了，是不是故意寫錯的啊？
不過也好，我可以更深入的瞭解事情的真相哦。繼續改自己的bootload!!!
做了幾個3個實驗，發現問題
實驗一：保證整個bin文件小於4KB,下載後運行沒有問題
實驗二：在上述基礎上，不做nandcopy過程，在SRAM中運行也沒有問題
實驗三：把user_main()函數定位到超過4KB的區域外，在下載到nand中運行，發現無法運行
看來可以知道是由於block壞塊引起的，因爲我知道我板子上的nand從第二個塊開始就好多壞塊，在用MDK工具下載bin是是關注了是或否有壞塊的，如果有壞塊會一次找下一個塊，直到找到好塊爲止。
所以有可能user_main函數已經被定位到nandflash很後面的區域了。
而在現在的nandboot裏面讀取數據時沒有關注是否壞塊，所以拷貝到SDRAM中的內容可能是完全錯亂的，所以打算明天回來在異常向量裏面加上打印語句。現在的現象是異常復位。
那我就不明白了，所謂的vivi難道在copy數據前都沒有對nand的壞塊進行檢查嗎？
這是爲什麼呢？
我靠在網上一搜這個問題，是很大的難題啊？涉及到壞塊管理。
何時才能移植我的UC/OS + GUI啊，還有 wince 和 linux 的移植!!! 真是萬事開頭難
~。。~
