TI中文支持网通过UBOOT烧写内核
信息提示：
DDR Clock :- 270MHz
Ethernet PHY: GENERIC @ 0x00
Hit any key to stop autoboot: 0
Loading from NAND 128MiB 3,3V 8-bit, offset 0x500000
** Unknown image type
Wrong Image Format for bootm command
ERROR: can't get kernel image!
DM36x IPNC:>run update_system1
TFTP from server 192.168.26.211; our IP address is 192.168.26.110
Filename 'uImage'.
Load address: 0x82000000
Loading: #################################################################
################################################
done
Bytes transferred = 1644624 (191850 hex)
NAND erase: device 0 offset 0x500000, size 0x400000
软件擦写的时候在此 卡住了~ 这个各位有没有碰到过这种情况？
Eason Wang：
我忘了你写的那个82000000地址对不对，你检查一下，或者去81000000试试，同时再看看你擦写的地址和长度是否正确？
erase中断我还没有遇见过
你可以看看update_system1的指令下，是分拆成了哪几条指令来做的，分开执行是否可以？
对于nand的问题，通常试试看nand scrub指令是否可以有改善。
jinxiong jiang：
回复 Eason Wang:
经过试验验证可以确认是 Appro uboot的问题，测试情况如下，
1、采用 Appro uboot （直接使用5.0SDK 自带的UBOOT)，会出现个别某几个硬件（大部分是可以正常下载的），下载内核的时候卡住，即 nand erase 就卡住了， 但是很奇怪，单独使用擦除命令却不会卡住。 update_system1的指令下，是分拆成了哪几条指令来做的，分开执行是否可以。验证是，分开执行也不行，确认不是封装的命令问题，即部分硬件只要先通过TFTP下载，再擦除，100% 卡住。
2、对于采用 Appro uboot 出现 nand erase 卡住的硬件，如果采用 UBOOT 的git版本（UBOOT 2013.7)，经过测试，是完全正常的。但我们的硬件也不能直接采用UBOOT 2013.7 ，这个与内核2.6.18 不太匹配，启动的时候会出现 error -3 while decompressing!， 但采用Appro的 UBOOT 1.3.4版本却不会出现这个出错信息。
Eason Wang：
回复 jinxiong jiang:
1. erase卡住和tftp下载是否有直接的对应关系？
2. 我不清楚你git到的uboot是从哪里来的？？是否可以提供来源
3. 你的nand和appro有什么区别？
jinxiong jiang：
回复 Eason Wang:
1. erase卡住和tftp下载是否有直接的对应关系？
答：是的，单独执行erase 不会卡住，部分硬件先TFTP下载到某个地址，再erase，100%卡住；
我做了一个这样的对比实验，基于同样程序、同样操作。
A、主板1+nand flash1: 先执行TFTP下载，再erase，100%卡住；
主板2+nand flash2: 先执行TFTP下载，再erase，不会卡住
B、主板1+nand flash2: 先执行TFTP下载，再erase，100%卡住；
主板2+nand flash1: 先执行TFTP下载，再erase，不会卡住
说明，这个卡住跟nand flash没有啥关系。
2. 我不清楚你git到的uboot是从哪里来的？？是否可以提供来源
答：就是UBOOT官方 版本，git://git.denx.de/u-boot.git
3. 你的nand和appro有什么区别？
答：采用的是三星的128M，
