multiboot 的golden image 和update image的 mcs文件的生成及调试

multiboot的功能对于不同的FPGA应该是相同的,但是具体的配置可能不一样。基本流程如下:

上图来源是xapp1246,  明显分为5个步骤,在FPGA启动时是有flash的0地址开始,但是因为golden image加了一些配置,在FPGA接收到这些配置是会转到其他的地址,继续读update image的内容。这些配置需要在生成golden bit的时候加约束命令如下: 

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]                 //可选的压缩项
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]      //使能回读功能
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 32'h00800000 [current_design]  //update image 的起始地址

 如果在加载update image 出错时,又要能够返回到golden image区,这需要在生成update image时添加如下约束:

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]

 意义如同golden image。生成这两个bit 后使用如下命令生成mcs文件。

write_cfgmem -force -format mcs -interface bpix16 -size 128 -loadbit "up 0x0 led_icape_golden.bit up 0x00800000 led_light_update_error.bit" -file icape_golden_light_update_error.mcs

 这些参数和具体的flash 和bit文件的大小有关。比如 bpix16表示16位的bpi flash,  up 0x0 led_icape_golden.bit表示 这个bit 的开始地址是0x0, 最后是生成的mcs文件。前提是当前的工作目录存在这两个bit。 pwd命令查看当前的工作目录,cd命令可以切换当前工作目录。

为了验证,update 配置错时可以返回到golden 配置,可以将bit更改其中的数据,再生成mcs文件,烧录到flash中,即可完成验证。

 但是,在本实验中发现了一个有趣的问题:

测试1:led1工程,做为golden image 并加了golden的约束。 led2工程, 做为update image 并加了update的约束。 最后将两个bit 合并为一个mcs。结果是没问题,而且也能在update image有错的情况下,返回到golden区。

测试2:flash系统的升级工程,做为golden image 添加和测试1一样的golden 约束。led2工程和测试1一致。生成mcs的命令也是一样只是bit不同。结果是不能启动update image,而只是返回到golden image。

可能产生的原因:golden image没有尝试跳转。golden image 跳转地址有误。update image bit写入flash中有误。

同事直接看生成的mcs文件,发现跳转的地址是00。但是我已添加了约束命令,为什么没有效果?惊人的结果截图看效果:

在Linux系统下多了一些符号,这些符号导致了跳转的地址没有写入到bit文件中。入下图:是bit的开头。为啥能在这看出重启地址没有写入,我不说,有兴趣可以查查。当然我也不是特别清楚,我也需要在查查。

为什么会牵涉到linux我也先不说。。。哈哈。

原文地址:https://www.cnblogs.com/cornhill/p/5625009.html