RBF format internals

[Altera_Forum]

Hi, 

 Our company produces a telephony appliance that uses a Cyclone II FPGA. The FPGA image is stored in RBF format in a flash, and occasionally, we send out an updated image that the customer applies to their box.  The problem with using the rbf format is that we'd like to verify that the customer's updated image is valid before committing it to Flash. I suspect that within the RBF file there's an encoded CRC or checksum that the FPGA uses to guard against bit errors.  I would like to know how to decode/calculate it so I know it's a valid file. Also, the file always seems to have a binary header with FF's - it would be useful to verify that it's an rbf file by looking at this header.  Thanks!

[Altera_Forum]

A guess you have the Altera jrunner code. For some reason, it doesn't perform any rbf file format checking. So it seems like Altera doesn't feel a need to disclose format details apart from the obvious 44 bytes header length. 

 If you are really motivated, I think you would be able to identify check fields in rbf by trial and error.

[Altera_Forum]

You can determine what some of the fields are by looking at the NIOS bootloader source code. It accesses some of the data to determine the length of the FPGA image. 

 Jake

[Altera_Forum]

Don't worry about the internal format. Just calculate a crc on the file when you gnerate it and later before committing to flash. On linux you could use the cksum or sum commands. Don't know windows that well but at codeproject.com you can get source for CRC32.

[Altera_Forum]

Just tripped across this 

 http://www.altera.com/support/kdb/so...2004_4844.html   If I interpret it correctly the file just contains config data.

[Altera_Forum]

Thanks for your help - I was hoping to get away from adding an external checksum to the load, but that's probably the path of least resistance!