cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
4,856 Views

convert a bootoadable SREC file to something that iMPACT can write to flash (mcs?)

I am building a project that boots off of the flash memory on an Avnet virtex 5 FXT evaluation board  ( http://www.xilinx.com/products/devkits/aes_v5fxt_evl30-avnet.htm )  I am successfully building the project in EDK (10.1), using the "program flash memory" utility to convert the ELF file to a bootloadable SREC file which is then automatically written to flash with the specified offset.  After that I use iMPACT (also 10.1) to convert the bootloader bitstream to an MCS file which I also write to flash.  All of this works successfully.

 

The difficulty I am having is that I need to put this same working project on another identical board which is in another location where only iMPACT is available.  Therefore I need to be able to push the bootloadable image made by the EDK onto a board using only iMPACT.  I have attempted add the ELF to the MCS file I build in iMPACT but this causes iMPACT to crash. I suspect that this wouldn't work anyway since I need to be working with the SREC file directly which would also prevent me from trying to modify the genmcs.pl script included in XAPP719 since it converts ELF files.

 

I have also tried to readback the entire contents of flash with iMPACT, but this takes 7 hours and the resulting image appears to contain only the bootloader and not the entire contents.

 

I've looked at this post: http://forums.xilinx.com/xlnx/board/message?board.id=OTHER&thread.id=871 which seems to be similar to my question but dclemmensen uses his own bootloader application rather than the EDK generated one and so even though srec_cat may work for me, I don't know how to work out the addressing to work with EDK's bootloader.

 

Can anyone give me a step by step procedure for getting my bootloadable image onto the flash using only iMPACT? or how to readback a working image of my flash that doesn't take 7 hours?

 

0 Kudos
1 Reply
dclemmensen
Adventurer
Adventurer
4,845 Views
Registered: ‎12-29-2007

The approach I described can be generalized. It permits you to append any srecord file or files  to the PF image. here is what you need to do:

 1) figure  out how big the PF bitfile is before you start to append. This is the size of the bitfile generated by bitgen for your FPGA. The next address in the prom image will be the first available address into which you can tell srec_cat to put stuff: Call this address "FPGA_LEN"

 2) analyze the bootloader that the EDK emits and figure out what it wants to see in the PROM. This will probably be some sort of sync sequence, followed by some control words (e.g., size, load address in RAM, start address.) NOTE my bootloader resets the PF and bypasses the precise numbr of bits used by the FPGA, so I can use the very first bits after the FPGA image and I do nto need to scan for a sync word. If the bootloader continues reading the PF after the FPGA load instead of starting again from the beginning, then you must add some extra junk words and a sync sequence.

3) create a "binary" file that contains this entire header, including junk words and sync word if needed. You can build this as an srec file using a plain old text editor, or you can create a tool, or you can adapt a tool. Note the exact size of your header. Arbitrarily use 0x000 as the starting address for your header file.Call the length of this file "HDR_LEN."

4) generate your application srec file (named "srec_file" ) to be loaded in the RAM at address APP_START.

5) Create an srec_cat command that appends your header file at the address FPGA_LEN (e.g., with offset FPGA_LEN) and that appends your application srec_file with the following offset: PF_LEN+HDR_LEN-APP_START.

6) run your srec_cat command to create the MCS file . Then run the little sed script to remove the "type 5" record from the MCS file.

 

What did this do?  Well, you created three"binary" files: the FPGA image, the header image, and and the application image, and then you told srec_cat exactly how to put those images, in that order, into the PROM image. The FPGA image was already at PROM address 0, and therefore needed no offset. You generated the header image at "address 0", so you need to tell srec_cat to place it just above the FPGA image at FPGA_LEN in the PROM. You created your app image with its eventual address in RAM (0, or 0x1000000, or whatever for your system) but you want to put it in the PROM image at the address just above the header image, namely at  FPGA_LEN+HDR_LEN, so you add this offset and subtract the first RAM address.

 

How is this different from my original solution? well, I'm lazy, so I cleverly caused the linker to prepend the appropriate header to the app rather than creating a separate file. Unfortunately, my cleverness obscured the underlying principle.

 

How can you decide what the header must look like? Well, I would analyze the bootloader (HDL and/or processor code.) but you can also  simply use the Xilinx tools (as you have already done) and then analyze the contents of the MCS file. it is a minor struggle to finde the correct spot in in the file, but after you find it, you can simply read the hex. The simplest way to find the end of the FPGA image is to first build an MCS with nothing appended. the end of this file is the end of the FPGA image.

 

Warnings: both bit order and byte order are important.

 

 

 

0 Kudos