Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

RBF format internals

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!

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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!