Retrieving usercode from binary configuration image

[Altera_Forum]

Hello, 

 there have been various discussions about the raw binary file format, solutions for the basically simple problem of retrieving the usercode have been already posted. http://www.alteraforum.com/forum/showthread.php?t=16118  If I remember right, the rbf header format has been previously described in the source of a NIOS programmer tool, at least for older FPGA types, e.g. Cyclone II.  Obviously the coding has changed between different devices, although the principle scheme (bit serial in bytes respectively dwords) is the same.  Now I want to add usercode decoding to a remote system update package, to allow rejection of invalid application images. Does anybody have information about rbf header coding of recent FPGAs, e.g. Cyclone V?   Best regards,  Frank

[Altera_Forum]

Hey Frank, 

   --- Quote Start ---   Now I want to add usercode decoding to a remote system update package   --- Quote End ---   I took a slightly different approach to validating images for the FPGAs on this board;  http://www.ovro.caltech.edu/~dwh/carma_board/  In this document  http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf  I describe how I use U-Boot's mkimage tool to add a header to the .RBF files. This allows me to use mkimage to get a summary of the image too.  My MAXII configuration controller also reads this header before allowing FPGA configuration, but that would be optional if you used a processor to validate the header, and then write the .RBF contents to flash.  This saves having to know anything about the .RBF format.  Cheers, Dave

[Altera_Forum]

Hello Dave, 

 that's a reasonable method if a configuration controller is involved, e.g. multiple FPGAs configured from a single flash memory. I'm targetting to "minimal" systems with programmable part comprised of one FPGA and a serial flash.  I have the RSU running now with a pof check demanding a specific usercode target field. It turned out that (at least for cyclone III) the RSU controller is reading in the rbf header part, 40 data bytes and a CRC16 or checksum. The usercode is placed in byte offset 8 to 39, bit 0.  The RSU controller checks the CRC, so you can enforce a pof error if you don't accept the usercode.  Best wishes, Frank

[Altera_Forum]

Hey Frank, 

 If your RSU controller is running on the FPGA and reading the .RBF header, then its not much different having it read the mkimage header. At least you get to control what the header includes then :)  I have not looked at the format of the .RBF with Cyclone V devices. I did play around with the JRunner and SRunner source. While playing with that code I realized that it should be possible to "port" the code to run with a fake FPGA, i.e., if you wrote some code for a fake FPGA that knew how to interpret the .RBF then, you could get JRunner and SRunner to configure and verify your fake FPGA. If I really needed to know what the .RBF header was, and these tools worked with Cyclone V, then using these tools and a debugger might be one way to investigate further.  Cheers, Dave

[Altera_Forum]

Hello Dave, 

 thanks again for your comment.   I can't change the rbf header format at will because it must be understood by the hardware FPGA configuration controller. RSU controller "pof checking" is an optional consistency check step before rebooting the new application image. Originally it checks only for a header with valid CRC. Configuration with a corrupted image or an image for a different FPGA type is rejected by the hardware configuration controller anyway. But an image for a different instrument using the same FPGA type could be loaded accidentally. The additional usercode validation reduces the risk to boot a wrong image.  Alternatively, additional information can be put in an unused configuration image part. But it would require additional manipulation of image files.   Regards,  Frank

[Altera_Forum]

--- Quote Start ---   I can't change the rbf header format at will because it must be understood by the hardware FPGA configuration controller. RSU controller "pof checking" is an optional consistency check step before rebooting the new application image.   --- Quote End ---   I must be misunderstanding.  Your request above for details on the Cyclone V .RBF header implied to me that your RSU controller was something you had control of, eg., either NIOS II code or a hardware implementation, otherwise how would you be able to modify the code to handle Cyclone V .RFB files?    --- Quote Start ---   But an image for a different instrument using the same FPGA type could be loaded accidentally. The additional usercode validation reduces the risk to boot a wrong image.   --- Quote End ---   Right, but if you do control the RSU code, and you use mkimage to append another header to the .RBF file, then that new header can contain additional consistency checks. The RSU controller then strips/ignores the 64-byte mkimage header, and sends the .RBF file as normal.  I was paranoid about misloading images on the four FPGAs on the CARMA board I linked to above. Each of the FPGAs has a virtually identical pin out, however, if the .RBFs for the FPGAs were loaded out of sequence (eg., due to a file naming error), then I wanted to make sure no damage could occur. What I did was to add resistor shorts under the FPGA BGA so that each FPGA had a unique ID code. Each FPGA design then contains an ID register indicating the intended device. The FPGA control logic (which controls the output tri-state logic) checks that the FPGA ID register (intended FPGA ID) matches the pin strapping on the device (actual ID), and if they do not match, the outputs do not become active, so there is no chance of driver conflict. The CPU interface is identical between all devices, so that logic is not disabled if the device is misloaded, and this allows the PowerPC to confirm that IDs match and that the FPGAs can be enabled.    --- Quote Start ---   Alternatively, additional information can be put in an unused configuration image part. But it would require additional manipulation of image files.    --- Quote End ---   Or perhaps at the end of an image? But even in that case, you would need to make sure that the RSU controller ignored bytes at the end of the file. If you can modify the RSU controller to do that, then you can also support a header appended to the beginning of the .rbf.  Cheers, Dave

[Altera_Forum]

Hello Dave, 

   --- Quote Start ---  I must be misunderstanding.  --- Quote End ---   Only a detail. There are two instances reading the image from the serial (or parallel) flash.  1. The RSU (remote sytem update) controller with enabled "pof checking" feature, optional Altera IP that provides a user interface to the hardware remote update block 2. The hardware configuration controller that reads the configuration image  The latter is always present, the former must be instantiated if you select "remote" configuration mode under configuration options.  The hardware ID check in application is another good way to avoid loading of a wrong FPGA image. Asking for failure safety in this point isn't paranoia, I think. It's even more demanding if the FPGA e.g. controls power electronic components.   Presently I'm exploring the available options in combination with the Altera remote system update concept. First results are promising.  Best regards Frank

[Altera_Forum]

Hey Frank, 

 Thanks for the additional details. I'd like to read a little more about these components, in case I want to use them. What is the best place to look? Is there an app note or user guide you recommend?  I do recall reading at some point that the RSU controller can be provided an image start address. If that is correct, then that could be utilized to add an additional layer of protection, i.e., you can add a header to your .RBF image that software can use for interrogation, and by setting the RSU image start address below that header, it will be ignored. Here's how it would be used;  1. Quartus creates .RBF 2. Add a custom header that identifies; project name, version, unique version control ID (for tracking the original source code used to create the image), target hardware, etc. 3. Use a flash programmer that compares the image header to the target hardware characteristics, eg., reads a board information register or EEPROM. 4. Use the flash programmer to program the entire image to flash, including the header details. 5. At some later point in time, the flash programmer can be used to verify or extract the flash image, and via the header, you can match the binary image to your version controlled code.  If my recollection is correct, then the hardware controller will skip all this information.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 it should work to have the custom header below the regular rbf and sending the rbf address as update start address. The loaded application can retrieve the last loaded flash address from the remote update controller and retrieve the custom information below it.  Suggested reading about remote system update:  Remote Update IP Core User Guide http://www.altera.com/literature/ug/ug_altremote.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=ug_altremote   Altera ASMI Parallel Megafunction User Guide http://www.altera.com/literature/ug/ug_altasmi_parallel.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=ug_altasmi_parallel  AN 603: Active Serial Remote System Upgrade Reference Design http://www.altera.com/literature/an/an603.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=an603 with design files (unfortunately schematic design)  AN 521: Cyclone III Active Parallel Remote System Upgrade Reference Design http://www.altera.com/literature/an/an521.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=an521 also with desugn files  RSU chapter of the respective FPGA handbook. There are some detail differences in RSU controller commands, port widths etc. between devices. You can easily miss things like a required right shift of the address port. The handbook is the ultimate reference in this regard.  Best regards, Frank