03-25-2016 12:25 PM
I have a Kintex 7 design built in Vivado 2015.1
The .bit file is 15.5 MBytes. I can convert it to an MCS and successfully program a N25Q256 flash memory and boot from it. This works with 24-bit and 32-bit SPI addressing.
I need to use the QuickBoot method to allow the flash to be updated in the field.
I use the the MakeSpiFlashProgrammer.pl script with the MCS file generated with the 32-bit (4-byte) SPI addressing option to make 'initial' and 'update' MCS files. When I program the 'initial' MCS (~88MB) into the Flash memory the Kintex 7 fails to boot.
When I read back the Flash memory contents they match the MCS file used to program it so the flash programming seems to be working. When I follow the same procedure with a simple design using a compressed bitfile that is only a few MB then the 'initial' MCS boots correctly and I can use the 'update' MCS written though the 'SpiFlashProgrammer.vhd' block to replace the original image and again boot the updated design correctly.
The main difference is that the larger design crosses the 128MB boundary which requires the FPGA to use 4-byte addressing mode.
I have looked at the boot header and the jump address to the upper copy of the MCS appears to be correct. It looks as it the FPGA configuration process is unable to handle data in the upper half of the Flash memory address space.
Has anyone else seen this problem?
More details :
:100FF000 FFFFFFFFFFFFFFFFFFFFFFFFAA995566FF ## line 257 Critical switch word in last location on the first page
:10100000 200000003002000100F4000030008001E8 ## Two lines of Quickboot header. 0x00F40000 is the address of the update region
:10102000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0 ## Padding infront of 'golden' bitfile
.. golden bitfile..
:02000004 00F4 06 ## line 999669 Extended Linear Addr record (Type 04) Address is bits 31:16 of address
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00 ## First page of update - padding, starting at 0x00F40000
:10012000000000BB11220044FFFFFFFFFFFFFFFFA5 ## line 999688 Start of second (update) bit file
03-26-2016 04:38 AM
@gjones_cc Did you try this design bitstream with compression?
11-30-2016 12:06 PM
I'm having similar issues. I started with XAPP1081 and migrated the project to vivado 2016.2. I have everything working if I limit my mcs imagesize to 64Mbit (128Mb minimum flash with 24 bit addressing). I am aware that there are known 32 bit addressing issues with this Application note and example design. My hope is that I can work through the issues anyway. The quickboot method seems like a much simpler implementation than multiboot.
My settings for MakeSpiFlashProgrammer.pl are:
xilPerl MakeSpiFlashProgrammerMcsFiles.pl -imagesize 100 mydesign.mcs
This requires a minimum flash size of 200Mb. The output of the perl script displays a start address of X"00BF0000" and an end address of X"01680000". This requires 32 bit addressing of the flash (MicronN25Q 256Mb for me). If you look at the generated initial.mcs file, the wbstar (next_config_addr) field address appears to be addressed as 24 bits (00BF0000). If I attempt to load this file into flash as is, it does program and verify correctly, but the done pin never goes high and the FPGA doesn't boot. If I manually change the wbstar field to 32 bit addressing (0000BF00) then the FPGA will boot from flash correctly.
I'm trying to iron out the rest of the details of XAPP1081 for 32 bit addressing now. The parameters from the perl script need to be entered in the SpiFlashProgrammer.vhd file. I'm trying to determine if the cAddrUpdateStart and cAddrUpdateEnd constants need to be 24 bit or 32 bit addresses. I have them set at 32 for now, but when I initialize the SpiFlashProgrammer, I successfully erase the switch word, but never see the regEraseOK status bit go high. The state machine in SpiFlashProgrammer sends different commands to the flash depending on whether cAddrWidth is set to 32 or 24. I'm wondering if there are issues with the state machine erase when cAddrWidth is set to 32. I will provide an update if I sort this out.
Any advice is appreciated. Has anyone ever successfully modified XAPP1081 example files to work with 32 bit addressing?
11-30-2016 12:13 PM
BTW, I am using bitstream compression. I could most likely fit my quickboot design for the XC7K325T into a 128Mb flash, but the possibility exists to outgrow the allotted space, even with compression. I am also working on a XC7K420 board. This design will absolutely require 32 bit addressing.
09-14-2017 02:51 AM
Since i have an Artix7 xc7a200t the max bitstream size is 9730652 bytes if i'm not wrong. So could i use this design without worrying about the 32bit address limitation right?
I use the n25q256 flash
09-15-2017 08:51 AM
I tried the design and i have a different issue. I generated the bitstream with Vivado and with 32 bit addressing disabled, then i used prom gen to get the .mcs and finally the perl script. The FPGA boots.
Then i tried to import the original bitstream in SDK and add a bootloader to the internal ram and i created a download.bit file.
Same conversion as above, this time the FPGA won't boot! The size of the bistream is increased by few KB (the bootloader is 32kB) from 2.4 MB to 2.6 MB so i shouldn't hit the 32 bit limitation.
09-15-2017 08:59 AM
09-15-2017 09:06 AM
Hi Rob thanks for the update!
I tried today the design for the first time and found a strange different problem. If i program the bit file produced from Vivado is ok.
If i export the bit file to SDK and add a elf file to it (so .bit + elf = download.bit) it doesn't work (the FPGA won't boot) The bootloader is inside FPGA memory (almost 32KB)
It's not much bigger (the bit size pass from 2.5MB to 2.7MB) so is far beyond from the 32bit limitation.
My goal is to not use the SPIFlashProgrammer.vhd , i would like to use the AXI Quad spi core and program bitstream using it (loading bitstream by serial port). It means i don't even need mcs file, i could upload a raw bin file and add the required header (in theory, i haven't worked this out)
09-27-2017 08:09 AM
Thanks to Rob's new file i implemented the quickboot design successfully.
I simplified the script to have only the bitstream+biststream size + crc (not producing an mcs file). Then i upload this modified file through serial port to DDR.
I then implemented the algorithm described in the XAPP with a Microblaze C program and use the AXI quad spi core to update the SPI Flash.
Now i would like not to use perl to generate the image since is not present in Vivado, maybe i should convert to tcl.
04-19-2018 09:38 PM
i'm doing xapp1081 as well. Did anyone has any progress? it seems i can't feed the programmer with the right update data contents. For me i converted *_update.mcs to .bin and tried to feed to inData32. is it ok?
looking forward to your reply,
07-29-2020 07:33 PM - edited 07-29-2020 07:35 PM
I have some problems in my application.
1 The "spiFlashProgrammer.vhd " module works normally at " A7-100t + N25Q256A13 ".
The size of update_image.bin is 4MB, and the module works correctly, FPGA will work correctly after reboot.
constant cAddrWidth : integer := 24;
cAddrUpdateStart : std_logic_vector(31 downto 0) := X"00400000";
cAddrUpdateEnd : std_logic_vector(31 downto 0) := X"00800000";
cIdcode24N25Q : std_logic_vector(23 downto 0) := X"20BA19";
2 The "spiFlashProgrammer.vhd " module dose not work at " K7-325T + N25Q512A13 . ".
The size of update_image.bin is 8MB, set as below :
constant cAddrWidth : integer := 24; or constant cAddrWidth : integer := 32;
cAddrUpdateStart : std_logic_vector(31 downto 0) := X"00800000";
cAddrUpdateEnd : std_logic_vector(31 downto 0) := X"01000000";
cIdcode24N25Q : std_logic_vector(23 downto 0) := X"20BA20";
when I send erase command to the module, I find the FSM works differently to" A7-100t + N25Q256A13 " ,as show below:
As to 256Mb , the chipscope got FF from inSSDData8Receive .
As to 512Mb , the chipscope got 00 from inSSDData8Receive , so the next state is not right.
1 Is this module support 512Mb flash ? how to fix this problem?
2 Should I adjust cSizeSector to fix this issue?
07-31-2020 06:39 PM