测试用的FPGA型号为：xc6slx75-3csg484
ISE版本为：ISE 14.5
Flash芯片为：MT25QL128ABA8ESF-OSIT
其原理如下：
按照上图需要在FPGA外置的Flash芯片中放置3个image，分别是Header、Golden和Multi，依据UG380文档（Spartan 6的data sheet）要求，Header必须放在0x00000000位置；
Header、Golden和Multi Image可以通过ISE软件来生成，方式如下：
通过上述方式的设置，生成两个bit文件，一个是Golden，另一个是Multi，而Header放在了Golden bit的开头，如下图所示：
上述方法将Golden Image放在了0x00000044位置，将Multi Image放在了0x00400000位置
然后将这那两个bit文件，生成bin文件，然后远程写入Flash相应的地址即可
生成bin文件的命令如下：
D:\Xilinx\14.5\ISE_DS\ISE\bin\nt64\promgen.exe -u 0 filename.bit -p bin -w -b
也可以通过impact制作mcs文件，烧录到Flash中，具体方式如下：
下面说一下Header里面内容的含义：
通过上图可以看出Golden bit与Multi bit的主要区别是多了一些字节，而这些字节就是Header，具体含义如下：
FFFFFFFF // dummy word, dummy word
AA995566 // sync word
31E1FFFF
32610000 // 3261=GENERAL1 0x0000是Multiboot image localtion地址的低16位，即[15:0]
32810340 // 3281=GENERAL2 0x03=SPI x1 read command 0x40是Multiboot image localtion地址的高8位，即[23:16]
32A10044 // 32A1=GENERAL3 0x0044是Golden image localtion地址的低16位，即[15:0]
32C10300 // 32C1=GENERAL4 0x03=SPI x1 read command 0x00是Golden image localtion地址的高8位，即[23:16]
32E10000
30A10000
33012100
3201005F
30A1000E // IPROG Command
20002000 // NOOP, NOOP
20002000 // NOOP, NOOP
不过这里面有个疑问，依据上面的解释Golden的地址是0x000044，但是golden bit的0x44位置还处于Header中，是不是这个地址有问题呢？其实不是，因为真正烧录到Flash中的是bin文件，再看一下Golden bin文件的结构：
可以看到Golden bin文件中Golden恰好处于0x44这个地址处。
【参考文献】
- ug380.pdf
- https://forums.xilinx.com/t5/FPGA-Configuration/spartan6-multibooting-problem-it-is-not-working/td-p/497092
- https://forums.xilinx.com/t5/Spartan-Family-FPGAs-Archived/Spartan-6-multiboot-Fallback-does-NOT-work/td-p/702085
【备注】
ug380.pdf中的内容如下：
/*************************
There are three images for MultiBoot configuration. The first image is the Header. This
small bitstream contains the sync word, sets the addresses for the next bitstream as well as
the fallback or golden bitstream, and ends with an IPROG command. To generate this
bitstream automatically, add the BitGen option -g next_config_addr when creating
the programming file for the golden bitstream.
The second image is the MultiBoot bitstream. This is the bitstream that the user plans to
configure first. The location of this bitstream is defined by the values of GENERAL1,2. The
upper eight bits of the GENERAL 2 register are reserved for the opcode for the non-volatile
device. See Chapter 5, Configuration Details, for more information.
The third image is the fallback or golden bitstream. This bitstream is known to be “safe”
should an error occur consistently during configuration. The location of this bitstream is
defined by the values of GENERAL3,4. As with GENERAL1,2, the upper eight bits of
GENERAL4 are reserved for the opcode of the non-volatile device.
If the configuration fallback occurs and the golden bitstream is reached, the only way to
boot back into the MultiBoot bitstream (located at GENERAL1,2) is to toggle the
PROGRAM_B pin, power cycle the device, or use IPROG reconfiguration (see IPROG
Reconfiguration, page 136)
For designs that use more than two bitstreams, the GENERAL1,2 values must be set to the
location of the next bitstream then an IPROG command needs to be issued. GENERAL3,4
values should be reserved for the fallback bitstream.
The header image must start at address 0. This image has three “strikes” allotted to it. If a
CRC error is detected, the strike count increments and configuration restarts if the register
setting RESET_ON_ERROR is 1 (located in the register COR2, and can be set from BitGen
setting -g Reset_on_err) and the strike count is less than 3. The same behavior occurs
if the watchdog timer times out, but it does not depend on RESET_ON_ERROR. The strike
counter is found in the BOOTSTS registers. If the count is 3, configuration halts with INIT
and DONE driven Low. To clear the strike count, perform a hard reboot (pulse the
PROGRAM_B pin) or cycle power.
The MultiBoot image can reside at any address specified in GENERAL1,2. This image has
three “strikes” allotted to it. If an error is detected, the strike count increments and
configuration will restart at the address specified in GENERAL1,2 if the count is less than
3 and RESET_ON_ERROR is 1. If the count hits 3, configuration moves to the fallback
bitstream located at GENERAL3,4. There are two ways to clear the strike count: power
cycle the FPGA or pulse the PROGRAM_B pin.
The fallback (or golden) image can reside at any address specified in GENERAL3,4. This
image has 3 strikes allotted to it. If an error is detected, the strike count increments and
configuration will restart at the address specified in GENERAL3,4 if the count is less than
6. The value is 6 because it shares the strike counter with the MultiBoot image. If the count
reaches 6, configuration boots back to zero, where the header image is located. When this
occurs, configuration will attempt both the MultiBoot image and the fallback image three
more times before halting configuration. This results in a strike count of 9.
*************************/
链接 https://forums.xilinx.com/t5/FPGA-Configuration/spartan6-multibooting-problem-it-is-not-working/td-p/497092 中的内容如下：
Hello,
I have a problem with programming multiboot designs to a configuration flash. The issue is, to generate a fallback design with a single multiboot design. I am using a XC6LX45T with an 128MBit SPI Flash and ISE 13.2 with Windows 7.
In the properties dialog of "Generate Programming File" in the fallback / golden design, I activate "Place MultiBoot Settings into Bitstream" an set "-g next_config_addr" to 0x200000. The "-g golden_config_addr" value is 0x0, i hope this is set automatically, because i don't know the length of the header. "-g next_config_new_mode" must be set, else ISE return an error while generating the bitfile. "-g next_config_boot_mode" is set to 001, i hope this is the setting for 1x SPI.
In the master / multiboot design i do not activate these options. Only "-g reset_on_error" is active.
With impact i generate a prom file with two revisions. The first was the golden bitfile and the second was the master bitfile with an offset 0x200000. Programming fails because DONE does not rise high.
My question is, is this the right design flow for multiboot designs? Is there anything else to know? Is there a mor detailed documentation than ug380?
with best regards, lodentoni
P.S. Configuring the fpga with singleboot designs out of the flash works without problems.
Solution
Hi Lodentoni,
It looks to me that you have the same problem I had. Bitgen seems to clear SPI read command, which should be placed in the highest byte of the next config address. To overcome this problem, please add the SPI read command to to bitgen script as follows
"-g next_config_addr" to 0x200000
"-g next_config_addr" to 0x03200000
"-g golden_config_addr" 0x0
"-g golden_config_addr" 0x03000044"
Rgds,
Janne
PS: I have reported this bug to Xilinx and it will be fixed to ISE 13.3（但是Xilinx没有修改，反正ISE 14.5中没有修改）
链接 https://forums.xilinx.com/t5/Spartan-Family-FPGAs-Archived/Spartan-6-multiboot-Fallback-does-NOT-work/td-p/702085 中的内容如下：
https://forums.xilinx.com/t5/Spartan-Family-FPGAs-Archived/Spartan-6-multiboot-Fallback-does-NOT-work/td-p/702085
I think my issue is related to the header file. I followed the instructions given by siktap in this thread: https://forums.xilinx.com/t5/Configuration/Spartan-6-Fallback-Multiboot-Configuration/m-p/438250/highlight/true#M225
I have a golden image where leds blink quickly.
I have a multiboot image where leds blink slowly.
Both images have been tested stand-alone and work as expected.
On power-up, the multiboot image loads properly. However when I corrupt the multiboot image in the flash memory, the golden image does NOT get loaded; nothing happens and the fpga does not boot up. It seems like I might be missing an important value in one of the registers?
Here is the content of my boot_header.hex:
FFFFFFFF // DUMMYWORD, DUMMYWORD
AA995566 // SYNCWORD
31E1FFFF
32610000 // 3261=GENERAL1 0x0000=address[15:0] MultiBoot image location
32810340 // 3281=GENERAL2 0x03=SPIx1 read command, 0x40=address[23:16] MultiBoot image address
32A10000 // 32A1=GENERAL3 0x0000=address[15:0] Golden image address location
32C10301 // 32C1=GENERAL4 0x03=SPIx1 read command, 0x01=address[23:16] of Golden image address
32E10000
30A10000
33012100 // IS THIS SET PROPERLY?
3201001F
30A1000E
20002000 // NOOP, NOOP
20002000 // NOOP, NOOP
Here is how I generate the .mcs for my header:
promgen -w -p mcs -r boot_header_only.hex -o boot_header_only.mcs
Here is how I generate the .mcs for the two images:
promgen -w -p mcs -spi -s 16384 -u 010000 goldenFastBlink.bit -u 400000 MultibootSlowBlink.bit -o image_no_header.mcs
And then I add the content of boot_header_only.mcs in the beginning of image_no_header.mcs. I know for a fact that this (at least) partially works because my image at 0x004000000 gets loaded properly. If I try to corrupt a sector in the multiboot image region (let's say 0x00410000), the fallback mechanism does NOT work and NOTHING happens.
Is this related to my header file? What am I doing wrong?
06-06-2016 01:51 PM - edited 06-06-2016 01:54 PM
16,966 Views
Registered: 04-06-2012
Hi, I figured out what was wrong with my design. I had the '-g reset_on_err:yes' option for both the golden and multiboot images since it was mentionned in the thread I linked, so this option wasn't the issue. However, one very important information was missing from that thread.
My problem is that the multiboot image was being compiled with next_config_register_write:enable parameter, which is set by default. In a workflow similar to the reference thread I linked, the manually compiled header contains the important addresses. These addresses are neither found in the golden nor the multiboot images. For this reason, next_config_register_write MUST be set to next_config_register_write:disable for the multiboot image, otherwise the system flow is as follows:
- The header commands are executed and the multiboot and golden start addresses are set in the proper registers
- The multiboot address is loaded. However since the program is compiled with next_config_register_write:enable, the values for the golden and multiboot addresses that were set at step number 1 get erased and replaced by what I assume are default values (0x000000 everywhere?!).
- Assuming the multiboot image gets corrupted on purpose, the system is unable to fallback to the golden image because the address registers have been modified when the corrupted multiboot image was read.
I'm not yet sure if next_config_register_write must be set to enable/disable or if it is irrelevant for my project. I believe it is irrelevant since the golden image only exists to run a minimalist server that will enable me to write a new multiboot image to the memory. After doing so, the system will be rebooted anyway and the header in the flash should be read again, which will load the multiboot image. I believe it would be important if I planned to use icap to handle the signals directly to load the multiboot image without rebooting.
