Forum Discussion
New ContributorForce A10 FPGA to reload after WARM reset with u-Boot 2021.4
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
Regular ContributorHi,
First of all, you need to refer here for the full flow of what is needed and how the Early IO Release flow:
Could you try the standard flow which is not using split .rbf and see if the issue is the same?
New ContributorHi.
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
