what is the mapping of the RDP file?

[Scotty2]

Hello, 

I would like to unpack the .rdp file and modify some bytes to include a date and a version, and if there is a crc or checksum, I'd like to re-compute it and append it back to the rdp file. This rpd file would then be written to the flash using the "rsu_client" provided by Intel.

What I would like to know is the exact mapping (layout) and the content of the .rpd file?

I have the mapping file that goes along with the corresponding JIC file, but not the mapping of the rdp file itself. For example, in the configuration below, what is the exact layout of the address range of P1?

MAPPING of the JIC FILE:
BLOCK                         START ADDRESS   END ADDRESS
BOOT_INFO                     0x00000000      0x0010FFFF
FACTORY_IMAGE                 0x00110000      0x0090FFFF (0x00180FFF)
SPT0                          0x00910000      0x00917FFF
SPT1                          0x00918000      0x0091FFFF
CPB0                          0x00920000      0x00927FFF
CPB1                          0x00928000      0x0092FFFF
P1                            0x01000000      0x01FFFFFF (0x01070FFF)
P2                            0x02000000      0x02FFFFFF
P3                            0x03000000      0x03FFFFFF

Thanks

[lixy]

Hi beam_me_up_scotty,

RPD map is not provided for the security of user design.

If you want to include some version information to the RPD, there's an idea that maybe you can try to add a HEX page when you try to create an POF file in "convert programming file" window.

Since you mentioned that you may use RSU feature, also pay attention to avoid this HEX data from overwriting the RSU pointers.

https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm#program/pgm/pgm_db_hex_file_prop.htm

Thanks & Regards,

Xiaoyan

[Scotty2]

Hi Xiaoyan,

Thank you for the response, I will investigate adding the HEX file with the Programming File Generator. I do have a few follows ups!

Firstly, would it be possible to explain how the "NameHash" at the end of the RPD file is generated by Quartus? 

00070020  53 69 67 6e 2d 32 31 2e  32 6e 64 2d 32 32 2e 34  |Sign-21.2nd-22.4|
00070030  61 63 73 2d 31 00 00 00  0f 00 00 00 54 00 00 00  |acs-1.......T...|
00070040  4e 61 6d 65 48 61 73 68  3a 34 31 31 39 39 46 44  |NameHash:41199FD|
00070050  37 30 32 38 45 46 43 35  32 44 46 34 36 37 46 44  |7028EFC52DF467FD|
00070060  45 34 35 32 33 45 38 38  37 39 34 36 42 39 31 42  |E4523E887946B91B|
00070070  41 30 39 36 42 39 33 38  33 30 31 37 39 34 37 45  |A096B9383017947E|
00070080  30 37 37 39 39 44 43 41  45 00 00 00 25 00 00 00  |07799DCAE...%...|

Secondly, how come the RPD file generated by Quartus is slightly different than the one read back from the flash using the rsu_client?

$$ cmp -l s0_dumped.rpd s0_quartus.rpd
  7946   0 260
  7947   0   3
  7954   0 160
  7955   0   5
  8189 343 121
  8190  64 276
  8191  64 350
  8192  53 113

Lastly, would it be possible to know how the contents of the JIC file is translated and converted by the JTAG programmer to the QSPI flash?

Thank you very much for your support.

[lixy]

Hi Scotty2,

1, Would it be possible to explain how the "NameHash" at the end of the RPD file is generated by Quartus?

When I generate an RPD file, I did not see this info as you showed in your code. There's also no related info in our documentations. Is it possibly something created by yourself?

2, How come the RPD file generated by Quartus is slightly different than the one read back from the flash using the rsu_client?

I will confirm this question with our RSU experts.

3, Would it be possible to know how the contents of the JIC file is translated and converted by the JTAG programmer to the QSPI flash?

As you can see in "Programming File Generator", when you generate the JIC file, the "FLASH loader" must be selected. Therefore, there's actually a "FLASH loader" in JIC file.

When you start programming with JIC file, the "FLASH loader" will firstly be configured to FPGA, so that the FPGA will act as a bridge between Programmer and the FLASH. After the bridge is built, the raw configuration data will be programmed into FLASH through FLASH loader.

Not sure if this explanation answers your question?

Definition of JIC file: https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm#reference/glossary/def_jic.htm

Thanks & Regards,

Xiaoyan

[Scotty2]

Hi Xiaoyan,

1. I have rechecked my Bitstream and RPD file generation process, while I do run Quartus post flow and post module scripts, they do not try to embed any hash into the binaries. The "nameHash" also does not match the one generated by Quartus at the end of the generation with the name "Design Hash".

2. Any update on this?

3. Yes, thank you.

Regards

[lixy]

Hi Scotty2,

1, About the first question, thanks for your clarification. I have asked more engineers about it and we all did not see this NameHash before. I will try to find more information related.

2, About the data difference read back from RSU_client, it could be some header/footer. As mentioned before, RPD file content and map is confidential for security consideration. However, could you explain why ask this question. Does anything wrong happen to RSU process?

Thanks & Regards,

Xiaoyan

[lixy]

Hi Scotty2,

The probable reason why there's "NashHash" in RPD and there's difference between read-back RPD and original RPD could be related to some command / Tcl you ran. You may check them.

If you do not have further questions, I will mark this issue as resolved.

Thanks & Regards,

Xiaoyan