Arria10 u-Boot 2021.04 support reboot from linux

We are trying to support the following 2 use cases using the latest 2021.04 version of u-Boot from altera with the A10. Both of these cases used to work with 2014 u-Boot. Basically, is there a way to get the SPL to force reconfigure an FPGA peripheral image?

Case 1. Reboot

  1. Cold reset (power on)
  2. SPL loads peripheral rbf
  3. TPL u-Boot loads core rbf
  4. TPL boots to linux
  5. linux issues reboot command
  6. SPL skips peripheral load
  7. TPL u-Boot attempts to load core rbf
  8. TPL hangs and watchdog reboots (repeat from step 6).

Use case 2: firmware upload

  1. Cold reset (power on)
  2. SPL loads peripheral rbf
  3. TPL u-Boot loads core rbf
  4. TPL boots to linux
  5. linux transfers a new .itb file to FAT partition
  6. linux issues reboot command
  7. SPL skips peripheral load (BAD, we want the new peripiheral image!)
  8. TPL u-Boot attempts to load core rbf
  9. TPL hangs and watchdog reboots (repeat from step 6).

Any suggestions to address this? Is there anything documented about reboot support and firmware upgrade support on the wiki somewhere?

-Mike

I’m also interested to hear any insights on this topic.

There is a way for software to initiate a Cold Reset in the A10’s Reset Manager Control register, bit 0 ‘swcoldrstreq’ (Intel® Arria® 10 HPS Register Address Map and Definitions), but this doesn’t force a reconfiguration of the FPGA in the SPL. The SPL still sees that the FPGA is already programmed, so it skips reconfiguration.

Well. In the interest of pressing on, we created this patch for our company’s A10 SOM (link below). It provides an option to force the SPL to reload the FPGA if it is fully configured (e.g., from any reset condition after it was fully programmed) or if it is completely unprogrammed (no peripheral image loaded). This will only work for designs using split RBF programming where only the peripheral image is specified to be loaded by the SPL. Using a full RBF by the SPL (not desirable, takes too long anyway) will cause the system to loop indefinitely. It seems to work, but YMMV. A better approach would be to create a flag in the ITB block and handle that appropriately, but in the interest of time and our use case this is what we did.

-Mike

u-Boot v2014.04 patch

Thanks for sharing. I was also looking at doing something very similar.

As I have the FPGA’s split, I think ALWAYS forcing a reprogram is a reasonable solution. The SPL programs the peripheral and u-boot programs the core. As you said, much quicker than SPL programming both!

Thanks,
-RD

Hi Mike,

Just wondering if you made any progress on this topic?

I’ve been using the solution to have the SPL always re-program the FPGA, and this works fine when 'reboot’ing from Linux. But if I run ‘reset’ whilst in u-boot, it still sees that the peripheral is already programmed, so it skips reprogramming peripheral.

Is this something you even had to consider? I need to run reset u-boot in some corner cases of my flow in order to fully reprogram the FPGA (with a different FPGA image!)

Thanks,
-RD