0
\$\begingroup\$

Coming from the world of MCUs, I create bootloaders so that customers can update the firmware. Specifically, i'm talking about a USB bootloader to narrow down the many different mediums.

How is this done with FPGAs and CPLD. I would prefer a solution that is secure. So the image sent is encrypted or obfuscated some how. But I would like to here solutions that are not as well.

For FPGA:

Since the firmware is stored in external flash memory, does the FPGA image just write to it's external flash and then restart? But what happens if the new file is corrupt or the connection is removed while updating? Is there a way to make a default backup? In MCUs, the bootloader is never overwritten so the application can mess up anytime and the bootloader will still work.

Is there a separate dedicated non-volatile memory portion that is not re-configured on power up that you can load a bootloader in?

For CPLD:

Since the image is stored internally, do they have a way to configure themselves? How would one make a bootloader for a CPLD?

Other thoughts:

Maybe you can put an FTDI chip of some sort with GPIO that you can control from a PC app via USB. This way you can bitbang an SPI to load in a new image on the external flash? Anybody do that? That way the FPGA image can be corrupt or missing and still will be able to load a new image.

Note that i'm assuming that the FPGA or CPLD is alone on a board. Meaning there is not an MCU on the board to do all this.

Any insight as to how the industry achieves this task would be great.

\$\endgroup\$

closed as too broad by Chris Stratton, Michel Keijzers, Dave Tweed Apr 29 '18 at 22:55

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ This is far too broad to fit the stack exchange mission. For FPGAs there are many solutions, either originating with vendors and detailed in the documentation or app notes or custom often using soft-core or external processors. CPLDs traditionally have not had enough capability to do this; those some today are arguably more low-end FPGAs wearing a CPLD label - so the question is really far, far too broad to fit here. If you have a single specific part and have not been able to figure it out after reading the documentation and searching app notes that might be a valid question. \$\endgroup\$ – Chris Stratton Apr 29 '18 at 17:38
1
\$\begingroup\$

There are a couple of options here. One is to use a part like an FT2232 where one port is set up as a serial port and the other one is set up as a JTAG interface, then use openocd to rewrite the FPGA config flash or CPLD internal configuration. I have done this before, and it works extremely well. You can also put the 'serial port' side in FIFO mode and get a much faster interface (many Mbps) that looks like a serial port from the software side. This might be the only way to do this for a CPLD as there probably isn't enough logic resources on the CPLD to implement something "in-band", presuming it even has self-programming capability.

As far as "in-band" updates on an FPGA, you basically have the right idea - rewrite the flash and reset. Manufacturers usually support some sort of 'golden bit file' fallback technique to enable fallback to a known good configuration if the update fails. It might be possible to do this automatically, manually via some sort of recovery jumper or switch, or under software control from a GPIO pin on an FTDI chip or similar.

As far as encryption/obfuscation, unless the config flash is internal to the part or the image can be stored in an encrypted manner in an external flash, I'm not sure there is much point to obfuscation as an unencrypted external flash can be simply read out with an external EEPROM programmer or similar device. For devices that support loading encrypted configurations, there will be some way to load an encryption key via JTAG or similar which is then either stored permanently or in battery-backed SRAM inside the FPGA. Then the FPGA will decrypt the bitstream with AES or similar during startup. In this case, there should be no need to implement any obfuscation or encryption on top of this.

\$\endgroup\$
  • \$\begingroup\$ For the "configure as USB bootloader from flash – wait for USB connection, overwrite flash with data from USB or time out and fall through to loading main image from flash – reset to that new state": there's examples I'd like to point you to: github.com/tinyfpga/TinyFPGA-B-Series/tree/master/bootloader \$\endgroup\$ – Marcus Müller Apr 29 '18 at 15:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.