Honored ContributorHi,
When we generate the RBF file from the .sof file with compression enabled using the convert programming files option in Quartus II , is the length of the RBF file embedded into the file ? If yes where is that info present in the file ? If no, what are the means to determine the length of the RBF file ? Any other info regarding the rbf file format would be helpful. Please reply asap...
Honored ContributorI am curious as to why you care. Using passive serial we just send data until we get conf_done (we are reading an image from flash and have not recorded the file size) or nSTATUS indicates an error. When we write the RBF file to flash, we just write the whole file.
By the way, when I tried converting an SOF to RBF, I did not get a compressed file.Honored ContributorHonored ContributorThe length of the file is found within the file but it's encoded. The best place I can point you too is the assembly source code for the NIOS II bootloader found in "c:\altera\90\nios2eds\components\altera_nios2\boot_loader_sources\boot_loader_epcs_bits_sii_siii_ciii.S":
//
// If we arrive at this point we have verified that there is valid-looking
// configuration data. Extract its length.
//
// Like searching for the Software-Device ID code, the configuration
// bitstream length is encoded in a particular bit of a run of bytes.
// Total length field is 32 bits, which goes from CB Option bits 86..55
// corresponding to bit of byte to byte (for the most
// significant 7 bits) followed by the range of bits
// made up of bit of bytes. The above note about EPCS
// bit reversal still applies (so we're really looking at bits and ,
// respectively.
//I used the decoding scheme given in the above quoted bootloader source to determine rbf respectively configuration bitstream length and found, that the length doesn't match exactly. Unlike the exact length information in Cyclone II rbf-header, I got a length with a few bits remainder and by zero to three bytes shorter than the actual rbf file. I wonder if the decoding scheme may be partially incorrect. Because it doesn't hurt to send a few extra bits, I adjusted the length empirically. Does anyone know more about this issue?
Honored ContributorInteresting. This obviously merits further investigation.
The only problem I could potentially see is with regards to the NIOS. When the FPGA uses AS programming and the NIOS II also boots out of the AS device, the NIOS II bootloader uses the length to determine where the end of the bitstream is so it can jump to the end and start grabbing the processor's code. I'd have to look more closely at the bootloader to see if it would tolerate that address being early by a few bytes. With regards to programming the FPGA, I suppose if someone's code were to absolutely depend on that length variable to determine when they've loaded enough data, then it could also pose a problem. JakeHonored ContributorYes, I see, that it can be a problem with NIOS. However, the FPGA image has always trailing 0xFF and the NIOS boot image, as I learned from the bootloader document, is starting != 0xFF. So there should be still a clear start marking.
My application is more basic, the rbf image is written by a standard bootloader to a predefined flash area without length information, but the embedded PS loader should be able to load the correct bit stream length.
