Allow SPI flash to be configurable per board
I'm using a SPI flash chip* on a custom board that turns out to have a slightly different process to enable Quad-SPI mode than drivers/memory/spiflash.c - in my case, the two bytes of the status register need to be written as two separate operations, rather than a single operation with two bytes. More generally, other SPI flash chips may have different opcodes again. So it would be useful to have the chip initialisation either configurable in mpconfigboard.h, or alternatively, having different spiflash driver files for different chips, and be able to specify which driver in the board config. Any thoughts about the best approach here?
* The AT25SF321, which, on the surface seems much the same as the AT25SF641 on the PYBD (including the SR write operation), and the datasheets says this as well, but turns out the AT25SF321B (note the B on the end) has the split SR write operation.
stm32: add support to PYBD_SF6 for boards with larger flash
Summary
There are some newer PYBD_SF6 being produced (finally!) which have a larger flash, namely two of 8MiB (instead of the older ones with two of 2MiB).
This PR adds support for these boards. The idea is to have the same PYBD_SF6 firmware run on both old and new boards. That m(eans autodetecting the flash at start-up and configuring all the relevant SPI/QSPI parameters, including for ROMFS and mboot.
I tried many ways of doing this, some more general and others more board-specific. The more general approaches touched a lot more files than this PR which is less general and has a lot of the auto-detection logic in the PYBD_SF6 board directory.
Eventually the logic here could be generalised so it can work with other stm32 boards and even ports, but for now it's mostly contained to PYBD_SF6.
Testing
Tested both mboot and the main firmware on original PYBD_SF6 hardware, and newer hardware with the larger flash.
I added some info to machine.info() to print out the detected flash size, which helps with debugging.
Trade-offs and Alternatives
As discussed above, there are many ways to achieve this goal, some more/less general than others. I think this PR strikes a good balance there and doesn't impact existing boards that don't need this auto-detection feature (such as the stm32 Arduino boards which do use the QSPI interface; a more general solution would need to modify those boards quite a bit).