Arria 10: Remote Update Factory Fallback won't work & Watchdog does not trigger

Note: The fallback to the factory image does not work under the following conditions: If the last 576 bytes of an unencrypted application image bitstream are corrupted. Intel recommends that you examine the last 576 bytes of the unencrypted application image before triggering the application image configuration.

But I have noticed that the binary images of the FPGA bitstream vary in size. So there is no way to check explicit memory locations for these 576 Bytes. Is there any way to identify this section?

My Questions:

1. Why is the factory configuration fallback mechanism not working in the above described scenario? The Factory load image is valid!
2. How can I examine/validate a FPGA bitstream in flash memory before executing it. 

Status: consulting engineering to check on factory fallback mechanism failure and how to confirm the memory location of this 576 bytes is corrupted or not. 

regards,
Farabi

Hello Fabian, 

I checked with internal team, the size of the bitstreams varies, and it does not have a fixed size. 

Notes: The configuration bitstream is always the last block interpreted by FPGA, regardless of total image size. 

So the it is important to understand that the last 576 bytes is relative to the end of the image, not an absolute flash address. 

This block is processed before the FPGA can even attempt a configuration. 

It consists of : 

1- Configuration end markers - signal end of bitstream

2- CRC/Checksum data - to verify data integrity

3- Device configuration info - to confirm compatibility

4- RSU-related metadata - Required before fallback

If corrupted: 

1- FPGA doesn't know this image is failed

2- FPGA only know this image is invalid

3- Impact to - No fallback path is taken

I am checking how to validate the bitstream before we can proceed with RSU. I will get back after getting the confirmed answer. 

regards,
Farabi

Hi Fabian, 

1- Please dont do the 2-byte offset to trigger the CRC. You should delete some chunk of bitstream data and re-run to trigger the CRC.

2- Can you compare the last 576-bytes of RPD file with your flash last 576-bytes? the contents MUST match if not this area might corrupt and possible the root cause of your fallback failure. 

regards,
Farabi

Hello Farabi,

1. I when data somewhere in between the bitstream the CRC Fallback mechanism works as expected. But that does not solve our problem when somethng goes wrong at the end of the bitstream.
2. I checked the last 576 Byte of the RPD file and the flash contents. They actual do match.
   • The last 2664 Bytes of the RPD are 0xFF
   • Same applies for the Flash memory
3. I also compared multiple RPD files (same FPGA Target 10AX027E3F29E2SG)
   • The end of the RPD always terminates with a sequence of 4 Byte 0x6A followed by multiple 0xFF Bytes.
   • The last 576 Bytes of the RPD always show 0xFF as content
   • The absolute number of 0xFF Bytes varies between 2664 and 1616 Bytes (could be other values as well, I only analyzed 8 different bitstreams.
   • ==> Giving that I have no glue how to validate the last 576 Bytes and do not know what it should be (except 0xFF)
4. I just checked the newest Datasheet of the Remote Update IP core in 1.3.1. Remote System Configuration Mode d(Version 2024.07.25) has a new NOTE compared to Version 2022.08.16

   • If the first 1024 bytes and the last 576 bytes of an encrypted application imagebitstream are corrupted. Intel recommends that you examine the first 1024 bytesand the last 576 bytes of the encrypted application image before triggering theapplication image configuration.

   • This section does not make sense, as it is already included in the previous claim, that Fallback won't work if the last 576 Bytes are corrupted. Unless it is intended to be an OR combination, i.e. the Fallback won't work if the first 1024 or the last 576 Bytes are corrupted.
   • Could you please clarify this!

For being able to validate the first 1024 & last 576 Byte of the Bitstream we have to know how the should look like.

Thanks for your assistance.

best regards

Fabian

Hello Farabi,

I understand that this is a limitation in the HW of the RSU.  However we still require a Workaround to at least be able to validate the vulnerable parts of the bitstream  before we trigger the reconfiguration from our factory load.

Currently we have the situation that a corrupted bitstream may brick our system, resulting in an unresponsive system which must  be sent back to service center for manual repair by flashing a new image via JTAG.

The reliable Fallback mechanism for In-System Update Capabilities was an essential point for the decision for Aria 10 devices.

Now we end up, realizing that the Fallback mechanism does not work reliable. Sorry but we require at least a possibility to check an image before executing a reconfiguration. Unless we get any information about the structure of the first 1024 & last 576 Byte of the bitstream this is not possible. Ending up with a completely unresponsive system ist not an option!

Thanks for any further advice. 

best regards

Fabian

Hello Farabi,

I'm sorry but I must insist, that we require the information about how to check the vulnerable parts of the Bitstream (first 1024 and last 576 Byte). Otherwise there is no way to deal with the risk of a bricked FPGA in case of update errors. 

Could you please provide Information about the structure of these parts of the bitstream. 

Thanks for your assistance.

Best regards

Fabian