01-04-2013 07:37 AM
Are there any code examples for the a SPI flash bootloader which copies the C-code from SPI flash to DDR memory and then jumps to DDR for thje LX16 ?
Solved! Go to Solution.
01-04-2013 07:58 AM
The factory image that is shipped on the LX16 board is an example of a SPI flash bootloader. It copies the C code from SPI fash (in SREC format) into DDR memory and then jumps Microblaze execution to DDR.
You can obtain the source code for the factory image from the DRC:
Take a look inside the S6EV-LX16_Factory_Test_Source_v11_3\serial_flash_bootloader folder for the bootloader source.
Building everything up into a single PROM image can be a bit tricky but there is an example of how to do this if you look into the create_factory_test_prom_image.bat file in the project root. Basically, you use the Xilinx MCS utility to piece everything together into the locations that the Bootloader is expecting.
There is also a make_bin.sh script which uses the mb-objcopy tool to seperate the Microblaze interrupt vectors from the rest of your application code.
If you need to shift things around location-wise in the SPI flash that should be okay too, just be sure to update the bootloader with the new locations as well.
06-01-2013 07:13 PM
Is there a reason Avnet didn't use the xilisf library for the SPI flash bootloader for the LX16 board?
I'm asking because I can't get XIsf_Initialize to work with this board. I'm attempting to use the same approach to developing a bootloader as with the LX-9 microboard and I'm getting the idea a different approach may have been used for a reason.
Is that the case, or should this approach work? Other than loading the SREC file at 0x80000 rather than 0x60000 should any other changes be needed to get this to work?
06-02-2013 09:02 PM
06-03-2013 06:07 AM
Kevin, thanks for the reply. I have some follow-ups.
Thanks again for the help,
06-04-2013 10:43 AM
I will let other communtiy members comment on the first part of your follow-up, but let me focus on your second part.
I tried to locate a concise guide to point you to, but I was not able to locate one. IIRC, some of this booting strategy was adopted from MicroBlaze applications that were developed back from the Spartan3A generation of reference designs. I did find something for the KC705 that you could follow from a high level point of view to see what steps are needed to generate a PROM image using a tools only flow:
That being said, I think there are answers to your other questions that should get you underway if you want to keep using the simplified example flow that we used on the LX16 OOB design.
Another script which needs to be run is the make_bin.sh script which runs Xilinx mb-objcopy utility to extract the interrupt vector and application binary code from your main application into the vectors.b and app.b files respectively. You used to have to run this script from the cygwin environment but I think you can now run these commands from the Xilinx Command Prompt in 14.5 tools or even from the Windows Command Prompt once you have set your environment with the settings32.bat or settings64.bat scripts.
You are correct that the bootloader gets stuffed into the download.bit file so that the bootloader application is the first executable to run out of BRAM once your MicroBlaze has been configured within the fabric.
This thread shows where you can obtain Version 1.24 of the xmcstuil.exe application:
If you are not using a web server then the memory file system is probably not needed and you can remove the webserver memory file system handler from the bootloader code, your application code, and remove the related memory offsets from the batch file. The offsets were determined by looking at the size of the differnt pieces and arranging them so that they do not overlap the same PROM memory space.
That is a good point about the SREC format, it was my mistake to mention that. The stock bootloader example from Xilinx uses SREC format, but if you follow the method provided with the LX16 factory test example in the serial_flash_bootloader folder, it looks like we are just copying raw binary data from the SPI flash so you do not have the overhead of the SREC to deal with.
06-04-2013 06:08 PM - edited 06-04-2013 06:16 PM
Kevin, thanks for taking the time to explain this in detail. This seems pretty straightforward so I think I ought to be able to get it to work. It'll be another week or so before I can get back to this project but I did want to say thanks now.
Meantime however, my application will need to save data in flash so I'd still like any tips on how to use the xilisf library with this board if that's possible.
07-02-2014 04:41 AM
The flash used is a 2.7-3.3V device while the IO-standard for the flash interface pins in the FPGA are set as LVCMOS2.5 (in the ucf). My question: is it alright to interface these two different levels? For a 2.5V pin, as per the datasheet, max Vin_H = VCCO + 0.3V which in this case would be 2.8V while the flash is operating at 3V.
I am a bit curious because the flash is required only during the start-up phase and putting in a level translator to bridge the devices might require valuable board space.
Thank you for your response in advance,