Remove MMC access to FPGA flash

This would remove that akward SPI channel access circuit, right? I support that. For reference, this is also cited in issue #35 (closed)

Exactly. Update via MMC does not seem a handy feature after all. I know @KMacias was doing an attempt to use it some time ago and it turned to be damn slow and pretty unreliable.

For OTA I'm currently working with one of the students on WUT to develop a "golden" gateware that would enable network updates in a fast and reliable way. It will act as a sort of "gateware bootloader" that would be loaded every time FPGA starts and if no external connection will be made in specified time (or server will not serve new gateware in a specified time) it will reboot FPGA from defined flash address under which an application gateware is stored.

Another option would be to keep two flash memories, one with this "loader" and other with actual production firmware and to select between them with the MMC. This could make the bootloader simpler and the flash memory more robust.

I see your point here, however, if we use single flash memory, bootloader solution is independent of MMC and flash circuitry is simple. If MMC was to select which flash to use, a communication channel between FPGA and MMC would have to be established or one would have to use IPMI command for that. Both of these do not seem very straightforward to me.

@gustavo.bruno Do you feel convinced on removing MMC access to FPGA flash?

I agree that your solution seems to be a more robust one.

However, to register an alternative in case we find it needed in the future: there would be no need for communication between MMC and FPGA in this case. The idea was to have SCK, SDA of the both flash connected just to the FPGA and the CS pin just to the MMC. This way, there would be no need for communication between FPGA and MMC - the MMC just would start the board at "boot mode", which selects the flash with the loading gateware. After FPGA boot (which may be just set by time), it could just reselect the usual flash and the FPGA would proceed to update. But your solution seems more robust.

From my notes, during a meeting, we've agreed that:

• we'll use single flash memory
• a golden image will be used, if multiboot is required
• one of the current lines from MMC will be kept to act as a "gw select" line for golden image

assigned to @tprzywoz

Same as #101 (closed) :

MMC has been disconnected from flash memory. I left only PROGRAM_B DONE and INIT_B signals connected to MMC. I also added two new signals (MMC_TO_FPGA) to allow MMC control of FPGA configuration (during double boot).

CFG_FPGA (old SPI_FPGA):

I'm thinking of removing FLASH_CLK connection between flash and FPGA. To be honest, I don't know what is this for as CCLK_0 can be accessed using STARTUPE2 primitive.

mentioned in commit c2b15c2f

Just checked, I agree! Great catch!

The only thing left here is removing FLASH_CLK_C for good.

mentioned in commit d2255c95

Solved in d2255c95

closed

mentioned in issue #101 (closed)