本文最初发表在CSDN我的博客上，但是最近csdn博客管理不知道为何一直打不开，写不了新文章，干脆把博客搬到这边来。
这是玩米尔
开发板遇到第一个问题，在此记录分享下。
2019-10-27 使用jtag下载自己生产的boot_myir.bin成功，串口能够打印。怀疑可能用SD卡的那种方式传递boot不可靠，具体原因不详。下次的实验可以将uboot的IP地址更换，看看是否生效。Uboot更换ip生效。
2019-11-14 烧写内核后产生错误如下：
SF: 4718592 bytes @ 0x500000 Read: OK
SF: 65536 bytes @ 0x800000 Read: OK
Copying ramdisk...
SF: 6291456 bytes @ 0x820000 Read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
不管使用项目的内核还是米尔的内核都是这个问题；有几个方向进行检查，首先看uboot中加载地址是否修改正确。其次修改设备树中烧写的地址。
发现一个重要问题，用TFTP的方式无法成功烧写bin文件。同理如果这个问题不能解决，也说明可能用TFTP烧写的dtb，内核文件也是不成功的。重点解决。找到问题所在可能是TFTP传递地址过高导致，使用0x200 0000 和0x100 0000都不能正确烧写，传递到DDR3的0x8000地址即可正确烧写。具体原因待分析(可以通过查看硬件DDR3实际连接图对比看看)。不过也可以解释为何内核文件不正确。
## Boo
ting kernel from Legacy Image at 02080000 ...
Image Name: Linux-3.15.0-xilinx
Image Type:
ARM Linux Kernel Image (uncompressed)
Data Size: 3886088 Bytes = 3.7 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
然后再使用0x8000地址烧写后，内核应该是可以起来部分，应该是长度小了导致加载不完全使得CRC校验错误。将uboot的image的size改成0x400000然后将设备树和文件系统的起始地址后移到0x900000.然后不再报内核错误。只要这四个文件正确的写到相应的地址，且文件大小在uboot中设置正确，就不会再有内核或者文件系统不正常加载的问题。
总结：
1、在uboot的源码中设置好针对qspi启动的地址。
2、要确认TFTP是否成功，尤其缓存地址如果太大，会出现烧写不成功的现象。这个在JTAG烧写就可以对比出来。
疑问待解决：
1、为何之前项目使用缓存地址0x200 0000可以正常TFTP烧写，而现在只能使用0x8000的缓存地址；
2、看项目的uimag也差不多4M字节大小，而项目的uboot的地址分配给uimage只有0x300000的大小，却也可以正常启动。
————————————————
版权声明：本文为CSDN博主「buck_wan」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/buck_wan/article/details/103087603
