【JokerのKintex7325】SDK程序从QSPI启动。

软件环境：vivado 2018.1        硬件平台：XC7K325 

---

大年初一，祝大家新年快乐。抗击病毒形势这么严峻，哪里都去不了，窝家里写写笔记吧。继续之前的博客内容，把在SDK下的程序通过QSPI启动这个话题再延伸延伸，说说在K7的软核microblaze下面怎么搞，跟Z7下面的方式还是有区别的。

虽说只摆个microblaze软核，建个最小工程就能验证QSPI的烧写，但这里还是使用的是带网络功能的block design，搞的其实复杂了，至于为什么这么搞，后面会说。       

QSPI设置如下，这里需要注意一点，如果QSPI-FLASH挂在FPGA的专用管脚，则就要使能STARTUPE2原语，使用普通IO则不用使能。

编译生成bit stream完毕后，导入SDK，先建立lwip echo应用。

 修改创建的应用程序运行空间，让其运行在DDR内。

 

 最好在烧写入QSPI之前实际debug一下应用程序，确保是能正常运行且与预期要求是一致的。

 接下来做fsbl，创建新应用，选择自带的SREC SPI Bootloader。

但直接生成的并不能拿来直接使用，有些BSP的参数要改，第一个地方，BSP设置里面，serial_flash_family，我用的micron的片子，所以改成5，这个根据实际使用的QSPI片子型号自己修改。

 第二个要改的地方，fsbl应用上右键---generate linker script。

 改程序运行空间到bram里面，至于为什么不跟之前的lwip一样，放在DDR里，要改的地方改完，后面会说。

 接下来，先program FPGA。

 将Vivado中生成的bit文件和fsbl编译过的fsbl.elf文件合一起，生成download.bit。

 Program以后，左侧system_wrapper_hw_platform_0中可以看到生成的download.bit

 右键，查看download.bit文件大小，可以看到生成的启动文件 5266445 = 0x505C0D byte

 知道启动bit的大小以后，在fsbl中将blconfig.h中，修改FLASH_IMAGE_BASEADDR参数，这个参数是烧写到QSPI-FLASH里的应用APP相对于基地址的偏移量，那基地址到FLASH_IMAGE_BASEADDR放什么，当然是刚才生成的fsbl和bit stream合成的download.bit，所以才会将download.bit大小转16进制计算，就是为了算这个偏移量，但是这里写的0x00800000是为了两程序段之间留一定余量。

 将所有程序全部编译一遍以后，烧写QSPI前的准备工作基本也就做完了，烧写前切记记得如果还有在debug的程序，断掉debug，并disconnect连接。烧FLASH点击Program FPGA旁边的Program Flash按钮即可。

 首先烧写lwip应用程序，注意应用的elf文件路径、偏移量、Flash型号选对，将第一个选框ELF转换为SREC文件选中，因为我们fsbl的应用程序本身能识别的启动文件类型，就是srec文件，所以第一个框务必勾选。

 看到console框里的flash operation successful，应用程序就烧写完毕了。

接下来就是烧写启动文件download.bit了，注意，偏移量写0x00烧写到0地址。

 经过了8分钟的漫长等待时间，终于烧写完毕了。

 启动看看。

 经过漫长的等待，和无数的打印，终于启动了，花了6分钟，终于启动了，你敢信？我他吗人傻了啊，大过年的。启动个lwip空壳应用程序就花了6分钟，再加点收发的数据处理，那还得了？吓的我看了一眼lwip应用程序的大小。

 261 k，还好呀，再看看烧写时候转换成的srec文件。

也没变大多少啊，按理说qspi速度应该很快的，200多k怎么算都不至于需要6分钟啊。不过庆幸的是，功能倒是正常的没问题。

---

最后，说点前面留下的问题：

1. 当前网络上大多数关于microblaze的例程，都是简单的搭个microblaze的最小系统，SDK这边烧个简单的hello world，这只能验证个最基本的操作方法，真到实际项目中microblaze软核稍微承担点任务量，需要烧QSPI-Flash上电自启动，然后光是启动，就要等上个大几分钟，这谁受得了？客户早就操了。所以这也是我为什么这里用的lwip的程序来验证QSPI烧写启动的原因，因为这样才能看出来问题。

2.为什么fsbl的程序放bram里，这里需要先说明一下，网上的大多数例程没有挂bram，直接将fsbl的程序放在片上的ocm里，我这样尝试没有成功，但是使用挂bram然后fsbl程序放bram里启动却尝试成功了，有可能是我哪些设置没设置对，也有可能是网上例程有问题，还有可能是当挂bram时候，bram中程序搬运的优先级高于片上ocm，这个我不清楚，也就不评价了，只是指出这里有差异而已。

3.理论上开机时候打印的那么多调试信息，也很浪费启动时间，这个可以通过屏蔽FSBL工程中bootloader.c文件中的

//#define VERBOSE

 来让调试信息不打印出来，但是尝试过了以后，启动时间几乎没有任何的缩短，所以也侧面说明了，影响启动时间过长的原因中，基本不包括启动时的调试信息打印。

4.我所理解的整个的一个启动方式，大概是系统上电以后，先从qspi的0地址找到download.bit用其中的bit stream例化FPGA，然后将fsbl搬到bram中运行，紧接着在fsbl程序头文件设定的偏移地址处找到srec格式的应用程序文件，将其搬到DDR中（一般应用程序大小大于bram的大小，所以只能放DDR中运行）直到搬完然后运行，fsbl任务完成，程序启动。