Agilex 7 non-RSU boot: how to configure SDM to use 4x redundant HPS SPL images starting QSPI addr 0?

[Jaden0]

To boot an Agilex 7 (HPS boot first), the SDM QSPI is flashed with 4 redundant images that are 512KB (max) each. As I understand, the SDM copies the SPL into the HPS on-chip RAM, then releases the HPS reset. This works fine. On the HPS console, I can see the U-Boot SPL prints.

However, if I corrupt the first image by erasing the first 512KB of QSPI, the device does not boot.

How can I get the SDM to try the second image if the first image is bad, and so on?

[JingyangTeh]

Hi Jaden0

I am Jingyang and will be looking at this case.

By default the SDM will try out the next copy of the decision firmware once it finds that the first is corrupted.

Could you please share the steps and command that you used to erase the QSPI flash?

So that I could try to reproduce it on the board I have here.

Regards

Jingyang, Teh

[Jaden0]

Hi JingyangTeh, Thank-you for looking at this case.

>> By default the SDM will try out the next copy of the decision firmware once it finds that the first is corrupted.

Can you please confirm SDM will try the next copy when using a non-RSU layout, like the one shown here (so, there is just "Firmware", not "decision firmware"):
https://www.intel.com/content/www/us/en/docs/programmable/683673/23-3/standard-non-rsu-image-layout-in-flash.html

>> Could you please share the steps and command that you used to erase the QSPI flash?

1. Power cycle the device and verify boot succeeds.
    As I understand, this indicates: SDM successfully loaded the FSBL into HPS RAM and released the HPS reset.
    HPS ran the first stage bootloader, then the second stage bootloader.

2. When "Hit any key to stop autoboot: " is printed, press a key to stop the boot process in the U-Boot SSBL.

3. Verify the 4 images stored in SDM QSPI are all the same:
  SOCFPGA_AGILEX # sf probe
  SOCFPGA_AGILEX # sf read 0x02000000 0x0000000 0x00200000
  SOCFPGA_AGILEX # cmp 0x02000000 0x02080000 20000
  Total of 131072 word(s) were the same
  SOCFPGA_AGILEX # cmp 0x02000000 0x02100000 20000
  Total of 131072 word(s) were the same
  SOCFPGA_AGILEX # cmp 0x02000000 0x02180000 20000
  Total of 131072 word(s) were the same

4. Erase only the image at QSPI offset 0:
  SOCFPGA_AGILEX # sf erase 0x00000000 0x80000

5. Power cycle the device.

    result: The device does not boot -- No prints are seen on the HPS UART.

[aikeu]

Hi Jaden0,

If I am correct, I think from what you have erased in size, probably only DCMF0 and DCMF1 will be considered removed.....

Anyway try to perform the steps from "Corrupted Decision Firmware" example from the below by using the same address and erase size:

https://www.rocketboards.org/foswiki/Projects/AgilexHPSRemoteSystemUpdate#Corrupted_Decision_Firmware_AN1

This is to check if there is any difference in the outcome of corrupting the DCMF.

Thanks.

Regards,

Aik Eu

[Jaden0]

Hi @aikeu, Thank-you for helping with this issue.

>> If I am correct, I think from what you have erased in size, probably only DCMF0 and DCMF1 will be considered removed.....

The docs for a different device (Stratix 10) shows 256KB slots 5.4.2.1. RSU Image Sub-Partitions Layout (intel.com)

But for Agilex 7, 5.4.2.1. RSU Image Sub-Partitions Layout (intel.com) shows 512KB slots:

In my case, the device is Agilex 7, and the layout is non-RSU (so the RSU commands are turned off).

The initial 4 steps in my boot flow resemble the following:
https://www.rocketboards.org/foswiki/Documentation/AgilexSoCGSRD#Writing_JIC_Image_to_QSPI_Flash

I am seeing an issue in the SDM -> U-Boot SPL step where it appears SDM is not looking at the additional good images if the first image is bad.

A couple questions:

- Does SDM support non-RSU redundancy by default? Or is there a way to customize it so that it supports non-RSU 4x redundancy? If I understand correctly, SDM is part of the Quartus Prime release (eg., intelFPGA_pro/21.3/qprogrammer/quartus/common/devinfo/programmer/firmware/agilex.zip) and the source cannot be directly modified, correct? Are there configuration settings that will pull in support for non-RSU image redundancy?
- Does SDM, by default, support different image formats based on the SPL header? May I please know the tools and steps for generating and validating the header expected by SDM? For Agilex7, is mkpimage required, or only quartus_pgm?

[aikeu]

Hi Jaden0,

Regarding the size of the image, I think you maybe right when looking at the comparison between agilex7 and Stratix10 which tells why you have erase with 0x80000. However I think both RSU or non-RSU from having the same flash layout whereby the BOOT_INFO contains the same 4 decision firmwares where it is stored/located starting from address 0x00000000 of the QSPI flash.

For RSU, it considers a factory(bitstream1) and an additional application image( bitstream 2 can be ignored/removed).

Factory image is actually the same as application image((u-boot-spl-dtb.hex + ghrd_agfb014r24b2e2v.sof).). The difference is the specific location of address which used for factory recovery purpose.

Just consider the factory image alone is the same as the one used for non-RSU as I understand which includes 4 of the decision firmwares, refer to how the quartus programming file generator add the factory bitstream :

https://www.rocketboards.org/foswiki/Projects/AgilexHPSRemoteSystemUpdate#Creating_the_Initial_Flash_Image

The SDM firmware is fixed with the quartus tools version being used and is unable to be modified by user.

By right the SDM firmware will keep looking for a working decision firmwares from BOOT_INFO.

I am thinking if you try to generate the jic with quartus programming file generator will have any difference in the outcome.

Or can check if you just perform erase 4kb as below will have any issue to boot normally insted of erase with 0x80000:

sf erase 0 0x1000

Thanks.

Regards,

Aik Eu

[aikeu]

Hi Jaden0,

Any follow up from the previous comment?

Thanks.

Regards,

Aik Eu

[aikeu]

Hi Jaden0,

I will close the thread if no further question.

Thanks.

Regards,

Aik Eu

[Jaden0]

Hi @aikeu, Thanks for answering questions related to this issue. Please go ahead and close it. I will open a new ticket if I have further questions. Thank-you.

[aikeu]

Hi Jaden0,

I am closing the thread for now. I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

Thanks.

Regards,

Aik Eu