[azonenberg]

As far as using QSPI memory, one thing I have planned (and will be thoroughly testing) is using an external SPI flash as configuration data storage. Right now if I want to store any nonvolatile settings with power loss protection I need to burn two 128 kB erase blocks (one primary and one secondary, so I can ping-pong data between them and not lose anything if I have a power loss during a write cycle or similar) of the on-chip flash, space that I'd much rather use for firmware.

MicroKVS expects to be able to memory map data fetches (uncached), but is fine with using indirect access for writes.

[azonenberg]

But if I can memory map the FPGA via the FMC, I can simply put an APB memory mapped QSPI controller on the FPGA and store my config there, using the same flash for the FPGA bitstream as well.

This saves a chip on the board, reduces the amount of PCB routing required, and eliminates use of the sketchy OCTOSPI peripheral entirely. Testing that out is on my list of things to do on this board eventually.

[15155]

I almost always include I2C EEPROM - just too cheap and pretty easy to route.

[azonenberg]

That can't be memory mapped, so I'd need to rewrite my KVS code which currently expects to be able to return a pointer to the raw on-flash image of the config data. Doable but a pain.