Forum Discussion

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

How do I determine FPGA image size within a POF

Hello all. I have searched around and can't find quite the answer I'm looking for so I'm hoping that I can get some help here.

First a little background. I am attempting to create an application which will run on an SBC controller, read in a POF file and write the FPGA contained in the file across a cPCI interface to flash on a selected PIO board. These peripheral boards are using Cyclone IV. The POF files are generated by a vendor who also builds the enclosure housing the boards. The enclosure is sealed, so I have no access to the JTAG ports on the cards. The POF files at the moment are generated using either QuartusII 12.1 or QuartusII 13.1.0 (some with each). All this is to say that I don't have access to the JTAG interface, I don't have access to the "source" project which generates the FPGAs, and I don't have the ability to receive the files from the vendor in another format. Due to configuration management requirements I need to be using these files unmodified.

So far I have managed to create a program which does this, however identifying the location of the FPGA image within the POF file has been problematic. By dumping the contents of the POF file I have basically discovered that there is a brief header containing version information on the QuartusII software used to generate the POF, then a block containing what should be the entire contents of flash, then a footer with some other information including the Page_0 offset and a mysterious hex value which does not appear to be the size of the FPGA. I have noticed that the FPGA images always seem to start with 0xF76A, so I have been able to make my program scan for that pattern, the problem is that I don't know how to determine where the end of the actual FPGA is located (right now it is a hard-coded size, which concerns me because I don't want the loader to have to be checked every time a new FPGA is received from the vendor). I don't want to write to the entire flash space, just the minimum needed to get the FPGA image into flash. I could scan from the 0xF76A until I reach a large block of 0xFFFF's, then back up, but I am hoping that there is a more elegant way to do this. While using the USB Blaster on a test board in a development box which isn't sealed, it looks like the Quartus software stops writing right at the end of the FPGA image, so there must be some way to tell how large it is. Does anyone know how to determine this from within the POF file data? Thanks in advance!

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Pof file format:
    bytes 0 to 3:  "POF\0"
    bytes 4 to 7:  unknown
    bytes 8 to 11: number of 'packets'.
Each 'packet' starts with a header:
    bytes 0 and 1:   packet type
    bytes 2 to 5:    packet length
    bytes 6 onwards: data

    Packet type 0x11 has a 12 byte header and then the raw data for the entire EPCQ.

    Packet type 0x1a contains the string "mPage_0 00000000 0226A5F8;" the last number seems to be the data size in bits.

    Don't know what packet 0x23 contains.

    The last packet is a always type 8 and contains a crc of the file upto, but excluding, the crc data.

    The crc is CRC-CCITT - and can be calculated by: 

    static uint32_t
pof_calc_crc(const uint8_t *dp, const uint8_t *end)
{
    uint32_t crc;
    uint32_t t;
    crc = 0xffff;
    while (dp < end) {
        crc ^= *dp++;
        t = (crc ^ crc << 4) & 0xff;
        crc = crc >> 8 ^ t << 8 ^ t << 3 ^ t >> 4;
    }
    return crc ^ 0xffff;
}

    Remember to bit-reverse the data as you write it to the epcq.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    ted, I had indeed found that pdf file last week during my searching. It has been quite insightful. The only real confusion coming out of that document is the bytes 4-7 (as indicated in the preceding post) and the packet type 0x11 doesn't appear to be described.

    dsl,

    Thanks for the info. That pretty much lines up with what I was assuming (so I appreciate the confirmation).

    Here is what is still confusing me. The footer has the mPage_0 with the offset into the packet 0x11 flash space which tells me where the FPGA image actually starts, but the second hex number doesn't appear to be the size of the image. In my case if I start at the offset provided (0x00020000 which ends up being 0x20094 in my file due to header) and search forward until I start getting all 0xfff, I get to address 0x0387f60. This gives me a size of 0x0367ecc. However the second hex number in my footer is 0x01b3f830. Any ideas on why these numbers don't match, or what the 1b3f830 is really telling me?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    As I said, the size in bits:

    $ printf '%x\n' $((0x1b3f830/8))

    367f06

    Non-encrypted images seem to end with a few 0xff bytes.

    Encrypted ones 'just stop' - makes it difficult to detect truncated .rbf files.

    Quite why .rbf files contain slightly different data to .pof is another matter entirely.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hi,

    Near the end of .pof file, you can see, as Dsl said, "mPage_0 00000000 0226A5F8;" the last number seems to be the data size in bits.

    does it mean that i can write user data, to epcs, from offset (0x0226a5f8 / 8) ? (through ASMI_parallel component)

    note : you can know the size of programming data with :

    sof2flash --input=your_sof_file.sof --ouput=dummy.flash --offset=0x00

    nios2-elf-size dummy.flash

    this size, in bytes, may be different from (supposed) data size in bits found at the end of .pof file because of compression (see quartus>asignments>devices...)