一段复制官方的解释
http://www.wiki.xilinx.com/Prepare+boot+image
Example: FSBL pre-loads Linux images
This example contains - next to the obligatory boot loaders - images to boot Linux. In this case the FSBL loads those iamges to the address given by the load attribute in the .bif file. That way U-Boot would not have to load any images and would simply boot by directly issuing a matching bootm command.
image : {
[bootloader]fsbl.elf
u-boot.elf
[load=0x2a00000]devicetree.dtb
[load=0x2000000]uramdisk.image.gz
[load=0x3000000]uImage.bin // currently bootgen requires a file extension. this is just a renamed uImage
}
Example: U-Boot loads Linux images
This example contains the same images as the one above, but this time instead of the load, the offset attribute is used. In this case the FSBL does not touch those images, but they are located at a known offset in the boot image. By matching these offsets with U-Boot, U-Boot can read the images from flash prior to booting them.
image : {
[bootloader]fsbl.elf
u-boot.elf
[offset=<dt-offset>]devicetree.dtb
[offset=<ramdisk_offset>]uramdisk.image.gz
[offset=<uimage_offset>]uImage.bin // currently bootgen requires a file extension. this is just a renamed uImage
}
生成镜像就是两种动作,load是fsbl运行阶段会被拷贝到指定的内存,后续就只直接对这个load地址直接运行bootm启动内核,而offset的动作就是fsbl不动qspi里面的镜像,在运行uboot的时候通过SF: 11010048 bytes @ 0x520000 Read: OK把uimage文件拷贝到一个地址,然后对11010048地址运行bootm,问题出现在这个官方uboot的默认环境变量是以0xffset的形式去启动内核,结果petalinux-package确实以load的形式生成镜像。之间的差别还在于,petalinux-package生成的BOOT.BIN比BOOT.bin文件要小一点。load的形式复制过程在fsbl是怎么拷贝的就不得而知,因为为什么要以load=0x520000为地址,而不是0x11010048为加载地址呢,如果所有的参数都没有错,那可能就是fsbl就没有执行复制或者类似于自解压image.ub从uboot.elf文件后到0x520000这个动作,这个是我自己猜想,反正也没人商量。