Force A10 FPGA to reload after WARM reset with u-Boot 2021.4

[MWill5]

Hello,

For our Arria 10 product line. we are migrating our u-Boot software from 2014 to the newly recommended 2021.4.  We have it working and booting to linux using the split RBF flow (SPL programs peripheral image, TPL u-Boot programs core image).  However, if we issue a reboot in linux, the SPL skips reconfiguring the FPGA and our u-Boot script still attempts to program the core RBF.  This causes u-Boot to hang and reset via the watchdog timer, indefinitely.  This means a WARM reset is no longer useful.  This should be reproduceable on the SoC development kit.

In addition, our normal flow for firmware upgrade is to put the new RBF (or in this case .itb) file on the FAT directory and issue a WARM reset.  This is broken.

Is there any way to force the SPL to always reload the FPGA?

-Mike

[EBERLAZARE_I_Intel]

Hi,

First of all, you need to refer here for the full flow of what is needed and how the Early IO Release flow:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an-a10-soc-fpga-early-io-release.pdf

https://rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10#Appendix_45_Reducing_Arria_10_Fabric_Configuration_Time

Could you try the standard flow which is not using split .rbf and see if the issue is the same?

[mawillia · Accepted solution]

Hi.

Thanks for the response.  I am reasonably familiar with the A10 early IO release flow.  We've been supporting our A10 based SOMs since 2018.  We are simply upgrading from Intel's reference uBoot 2014 to 2021.

Having the SPL program the entire bitstream (non-split RBF) will not work either because it will skip programming the FPGA if it is already in user mode (see line 126 of spl_a10.c ).  This can be easily tested and confirmed on the Arria10 SocKit board.  Besides, the SPL programming the entire core is prohibitively slow with larger FPGA sizes (10-30 seconds instead of < 1, depending on density for us) as it has to bounce small reads in and out of SRAM instead of DMA'ing the full image to DDR.  I am surprised that SPL booting a non-split image is now the "standard flow", it never was before due to the load times.

We ended up using this patch as a work-around, which forces the SPL to always reconfigure the peripheral bitstream and re-init/cal the HPS EMIF DDR.  It only supports split RBF loading; you have to load the core rbf in the u-Boot.img TPL.  This works for us.  We are still testing it, but so far it has allowed us to issue a reboot from linux multiple times without issue as well as support uploading new FPGA bitstreams in the ITB file for a remote firmware upgrade.

With regards,

Mike

[mawillia]

I should clarify, we have a requirement to be able to remotely upgrade the RBFs.  So using a non-split RBF would not support that without physically powering off the device.  A reboot would not cause the current Intel based SPL to reload an updated set of RBFs in an ITB file on the FAT partition.  The only way the current SPL supports updating the FPGA seems to be a power cycle, which may not be possible in some situations.

-Mike