由于项目设计需要，需要频繁的更换比特流文件，之前使用petalinux生成的boot.bin每次都需要合并比特流，比较麻烦，遂换了一个uboot版本（米联客默认的u-boot），将bitstream放到了独立于boot.bin的文件中，如图所示。
但是在配置好对应的文件之后，启动系统却发现比特流文件无法被正常的加载，部分日志如下：
reading uEnv.txt
17 bytes read in 11 ms (1000 Bytes/s)
Loaded environment from uEnv.txt
Importing environment from mmc 0...
[INFO] Trying to boot from mmc 0
reading uImage
4176536 bytes read in 274 ms (14.5 MiB/s)
reading devicetree.dtb
14739 bytes read in 16 ms (899.4 KiB/s)
reading system.bit.bin
13321514 bytes read in 825 ms (15.4 MiB/s)
zynq_validate_bitstream: Bitstream is not validated yet (diff 6e)
fpga - loadable FPGA image support
其中**zynq_validate_bitstream: Bitstream is not validated yet (diff 6e)**则代表了bit文件验证失败的情况。然而这个比特流文件之前的启动方式都用的好好的，为什么呢？
进一步追寻源头，在设备启动的时候不停的按住回车，停留在uboot的手动启动环节，通过printenv查找对应的启动指令，发现出现验证信息的指令是uboot指令集中的fpga指令，其用法如下：
Usage:
fpga [operation type] [device number] [image address] [image size]
fpga operations:
dump [dev] [address] [size] Load device to memory buffer
info [dev] list known device information
load [dev] [address] [size] Load device from memory buffer
loadp [dev] [address] [size] Load device from memory buffer with partial bitstream
loadb [dev] [address] [size] Load device from bitstream buffer (Xilinx only)
loadbp [dev] [address] [size] Load device from bitstream buffer with partial bitstream(Xilinx only)
Load device from filesystem (FAT by default) (Xilinx only)
loadfs [dev] [address] [image size] [blocksize] <interface>
[<dev[:part]>] <filename>
loadmk [dev] [address] Load device generated with mkimage
For loadmk operating on FIT format uImage address must include
subimage unit name in the form of addr:<subimg_uname>
可以看到，fpga指令中提供了多种加载方式，如load loadp loadb loadbp等。
而我当前的uboot则使用的是load方式。注意到loadb是有一个提示（xilinx only）的，而我恰好就是使用xilinx生成的bitstream文件，所以在这里试图将load指令改为对应的loadb指令。使用setenv来修改环境变量，使用saveenv保存环境变量。
保存，重新启动。最后bitstream可以正常的被加载！
解决了问题，有空还是得想想为什么。
经过资料的查找，可以发现，bitstream存在两种封装格式，一种是直接描述硬件的纯二进制文件，一种是除了纯硬件描述码外，文件头部还封装了比特流信息的，就如上图正常加载比特流文件之后，我们还可以看到芯片型号，生成日期，版本号，名字等信息，这些就是xilinx的特有的比特流文件头部。如果以正常的load方式加载，这些不属于硬件描述的文件头部被当成了硬件描述加载，当然会加载的一塌糊涂。而loadb则会正确的读取出文件头信息，把剩下的硬件描述正确的加载，所以可以正常的被启动起来。