I have a design that relies on RSU for remote updates. I currently encrypt the .pof file for JTAG programming. When generating that encrypted .pof file, I also choose to generate the .rpd files that go into CFM1. When downloading the .rpd files with the encrypted .pof and .ekp programmed via JTAG, the RSU is unsuccessful. I see a revert to application image 0, which my design will only go to if there is a problem with application image 1. The encrypted .pof file does not seem to like downloading a n.rpd file.
Is there any way to get an .rpd file to download with an encrypted .pof
"For security application when you need to generate a signed or encrypted .rbf file, you need to first generate .rbf file from a .sof file, and only then generate the initial RSU image from the .rbf file."
Is it possible to follow above instruction for security application?
That document refers to a Stratix10, I am using a Max10. I can try the equivalent on Max10.
The process for generating the encrypted files is as follows:
1. Compile design, .sof is created
2. Take .sof into Convert Programming Files
3. Using .key file, generate encrypted .pof and encrypted .rpd and .ekp file from the base .sof
4. JTAG program the encrypted .pof with the .ekp
What you're telling me to do is add a step in step 3 where I would generate a .rbf file from the .sof, then encrypt that .rbf to make an .rpd file that is encrypted that can be downloaded into flash?
Thank you for the document. Currently I am able to successfully perform an RSU with an .rpd file without encryption.
As soon as I choose to use an encrypted .pof, the .rpd file generated in the same step (from checking the generate .rpd box) does not work. I do a readback of the boot source register in the dual boot IP and the device is booting from the fallback image. This only happens when using the encrypted option.
I'm not sure you have taken a look the following steps on generating .ekp File and Encrypt Configuration File in the User Guide on page 41 as I'm assuming there could be some problems on the file generation.
Hello, this is the .cof file I am using to generate the encrypted .pof and .rpd. I have a script that replaces the generic values with the inputs to the script that are the respective .sof, . ekp and .key file. The generated .pof is labeled as "encrypted" and the CFM 1 .rpd file is used and the other 2 are removed because I do not use those. This .cof is identical to how the unencrypted one works except for the .key/.ekp fields which are excluded. The same process is used to give me the final .rpd and .pof but the unencrypted version works perfectly and the encrypted one does not.
Sorry for the delay in response. From your flow, nothing sounds out of the ordinary to me.
- May I know if this is a singular case or are you seeing the same issue in other new devices?
- Can you consistently replicate this issue?
- Can you try to perform a full chip erase and see if the issue still persists?
Please let me know if this works for you. Thank you.
1. This issue follows other boards, although they are all the same board design.
2. Yes this issue will always happen. Downloading the .rpd will work and boot into the application image every time without encryption but will not work when trying with encryption.
3. Full chip erase does not help the issue
Just want to check whether you have tried the 184.108.40.206. Integrate the .ekp into .pof Programming (Page 55) when programming the FPGA with Initial Image using JTAG using the Programmer window?
Also, please check the Configuration Image Outcome Based on Encryption Settings (Page 56) from the same document as the Encryption Settings may affect the result for this process.
I am using Quartus 21.1 but I can try the latest version.
Yes, I have been using 220.127.116.11 o on the document you linked to do all the programming so far. I tried 18.104.22.168 but my device would not boot.
I select the encrypted .pof image, right click and add the .ekp file generated in the same step, and also select an .ips file. I am not sure if the .ips file affects this but the .pof programming will fail without using an .ips file. This is done with an EtherBlaster. I can try a USB blaster but that should not make a difference.
If I am reading that table right, both images are encrypted with key x, and key x is loaded while programming. Config_sel pin is set to 1 so the device should boot into image 1, which it does without encryption