ECP5 has no means to reset itself

[oskirby]

It seems that there are three ways in which the ECP5 can reset itself in order to handle multi-boot images:

• VCC, VCCAUX and VCCIO8 rise above their POR thresholds.
• Rising edge on PROGRAMN pin
• Issuing a REFRESH command over SPI slave or JTAG ports.

I was hoping that one of the config ports would have been accessible internally from the FPGA fabric to issue the REFRESH command, but this doesn't appear to be the case so instead we'll need to bodge the board so that the FPGA can pull the PROGRAMN pin.

On the prototypes, we will work around the issue by removing IC12 and bridging ETH_RESET to SYS_RESET. This will allow the ETH_RESET pin to reboot the FPGA, but we loose the ability to reset the ethernet PHY independently of the rest of the system.

A better solution would be to pull SYS_RESET low via one of the unused pins in the DDR3 bank.

[oskirby]

For the DFU bootloader, it has been requested to add some non-volatile state that can allow the user image to boot into the DFU image without needing to physically press the boot pin. Without such a state, the DFU bootloader has no way to distinguish between a normal power-on and when rebooting back into the DFU bootloader.

[oskirby]

I think my favourite solution so far to the non-volatile "goto DFU" problem is to use a small IO expander such as the PCA9570 to control the pull-up on the boot button. At a true power-on reset, the PCA9570 would initialize to a pull-up state but when pulled low before a soft reset, the bootloader would detect this as a "goto DFU" reboot.

[bmentink]

Any solution to this?

[oskirby]

@bmentink for the ECP5 in general, the common solution is to connect the PROGRAMn pin to any GPIO of the FPGA, which gives the logic fabric the ability to pull PROGRAMn and trigger a reset of the FPGA. This works just fine, but it makes the boot process somewhat inflexible when there are multiple bitstreams to navigate.

For the Logicibone, my prototype board have been modified to reuse the reset line on the ethernet controller to achieve this behavior (this is noted on page 4 of the schematic). A permanent fix will require another board revision to provide a dedicated reset line. I don't have any plans to produce another board revision for the foreseeable future due to the chip shortage and a general lack of time to work on this project.

[bmentink]

@oskirby
Many thanks for the reply. I was asking as I am trying to port your bootloader to the Colorlight i5 board as per:
here
With the resetn GPIO line connected to PROGRAMN, how do you select which image to boot to ... (bootloader or user)?

Cheers,