appro dm368ipnc nandwriter的ubl和u-boot烧写问题以及diagnostic for dm368的诊断程序
新板调试总是挫折不断，问题解决一个就又出来一个，连绵不绝。。。
这次是使用ccs3.3通过nandwriter烧写ubl和u-boot的问题，按照appro的UsersGuide烧写步骤，一直比较顺利，直到提示烧写diagnostic dm368 file，资料里找来找去就是没有这个东西，然后我就选择了skip，调过了此步，ccs提示nand 烧写成功。
但是板子重启后，ubl起来但是u-boot没有起来，提示这样的错误：
所以这个问题，不是u-boot没烧进去 就是u-boot烧错位置了，经过查找资料，ubl和u-boot正确的烧写位置应该是：
Uboot starts after block 25, abd UBL is between 1 and 24.
RBL looks for a header of UBL in the block 1 to 24, and UBL (once loaded) looks for a header of UBOOT from the block 25 to block 50.
但是从ccs的log文件看上去，u-boot写入的地址却是：block 0x8 through 0xC.
后来有个好心网友给我传了一个diagnostic_ipnc_dm368_1.0.0.bin，在烧写的最后一步写进去后，重启新板，ubl起来，然后启动了diagnostic也就是诊断程序，而且我发现diagnostic_ipnc_dm368_1.0.0.bin写到的地址是block 0x1B through 0x1F. 而这个地址应该是u-boot该待的地方，后来我重新烧写，烧写到diagnostic dm368 file的时候我没有选择diagnostic_ipnc_dm368_1.0.0.bin，而再烧u-boot-1.3.4-dm368_ipnc_1.0.1.bin，这样，重启后 u-boot终于起来了！！！
diagnostic_ipnc_dm368_1.0.0.bin是一个诊断程序，在裸机状态下测试板子上的资源是否可用，这在生产调试阶段是非常有用的，而开始我却认为他是必要的烧写步骤呢，文盲害死人啊。
在ti的e2e上有一个帖子：
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/62651/749602.aspx#749602
描述的就是这个问题。
结论是，不要太信任appro给你提供的文件，任何事情都有错误的可能，所以解决办法就是自己重新编译nandwriter程序，源码在...\Utils\src下的flash_utils_dm36x_1.1.0.zip ，用ccs3.3编译可能会出现一个错误，这个需要安装ccs的更新来解决，下载地址：
https://www-a.ti.com/downloads/sds_support/CodeGenerationTools.htm#TMS470
找到TMS470 for ccs3.3的当前版本，然后安装到 C\CCStudio3.3\tms470\cgtools下就好了
虽然u-boot是成功启动了，但新问题又来了，网络不通。。。希望明天能够把网络搞通。
新板调试时的心情，可以用忐忑不安来形容