Adding a QSPI memory chip on a STM32G4 does not work due to some small
issues, which are fixed in this commit:
- Rename QUADSPI1_xxx alt-func names to QUADSPI_xxx, to match the static
names used in `qspi.c`.
- Enable `mpu.h` macros on G4.
- Don't include I- and D-cache invalidation on G4.
Signed-off-by: Damien George <damien@micropython.org>
Allows `MICROPY_HW_QSPIFLASH_SIZE_BITS_LOG2` and
`MICROPY_HW_QSPI_MPU_REGION_SIZE` to be arbitrary expressions, eg function
calls.
The `storage.h` header needs to be included in case access to `spi_bdev_t`
is needed by the macros.
Signed-off-by: Damien George <damien@micropython.org>
stm32's QSPI driver supports memory-mapped mode. The memory-mapped flash
can also be erased/written to. To support both these modes, it switches in
and out of memory-mapped mode during an erase/write.
If the flash is erased/written and then switched back to memory mapped
mode, the cache related to the memory-mapped region that changed must be
invalidated. Otherwise subsequent code may end up reading old data.
That cache invalidation is currently not being done, and this commit fixes
that.
This bug has been around ever since QSPI memory-mapped mode existed, but
it's never really been observed because it's not common to use flash in
memory-mapped mode and also erase/write it. Eg PYBD_SF2 uses the
memory-mapped flash in read-only mode to store additional firmware.
But since the introduction of ROMFS, things changed. The `vfs.rom_ioctl()`
command can erase/write memory-mapped flash.
Signed-off-by: Damien George <damien@micropython.org>
This commit implements `vfs.rom_ioctl()` to query, erase and write both
internal and external flash, depending on how the board configures its
flash memory.
A board can configure ROM as follows.
To use internal flash memory:
#define MICROPY_HW_ROMFS_ENABLE_INTERNAL_FLASH (1)
To use external flash memory (QSPI memory mapped):
#define MICROPY_HW_ROMFS_ENABLE_EXTERNAL_QSPI (1)
#define MICROPY_HW_ROMFS_QSPI_SPIFLASH_OBJ (&spi_obj)
Then the partition must be defined as symbols in the linker script:
_micropy_hw_romfs_part1_start
_micropy_hw_romfs_part1_size
And finally the partition needs to be enabled:
#define MICROPY_HW_ROMFS_ENABLE_PART1 (1)
There's support for a second, optional partition via:
_micropy_hw_romfs_part2_start
_micropy_hw_romfs_part2_size
#define MICROPY_HW_ROMFS_ENABLE_PART1 (1)
Signed-off-by: Damien George <damien@micropython.org>
The existing MPU_CONFIG_DISABLE macro enables the MPU region but disables
all access to it.
The rename is necessary to support an MPU_CONFIG_DISABLE macro that
actually disables the MPU region entirely.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The STATIC macro was introduced a very long time ago in commit
d5df6cd44a. The original reason for this was
to have the option to define it to nothing so that all static functions
become global functions and therefore visible to certain debug tools, so
one could do function size comparison and other things.
This STATIC feature is rarely (if ever) used. And with the use of LTO and
heavy inline optimisation, analysing the size of individual functions when
they are not static is not a good representation of the size of code when
fully optimised.
So the macro does not have much use and it's simpler to just remove it.
Then you know exactly what it's doing. For example, newcomers don't have
to learn what the STATIC macro is and why it exists. Reading the code is
also less "loud" with a lowercase static.
One other minor point in favour of removing it, is that it stops bugs with
`STATIC inline`, which should always be `static inline`.
Methodology for this commit was:
1) git ls-files | egrep '\.[ch]$' | \
xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/"
2) Do some manual cleanup in the diff by searching for the word STATIC in
comments and changing those back.
3) "git-grep STATIC docs/", manually fixed those cases.
4) "rg -t python STATIC", manually fixed codegen lines that used STATIC.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The existing qspi for stm32 implementation can only send a spi command with
exactly 0 or 2 data bytes. Certain spiflash chips (e.g. AT25SF321B) have
commands that only take a single data byte, and will ignore the command if
more than that is sent. This commit allows sending a command with a single
data byte.
Signed-off-by: Victor Rajewski <victor@allumeenergy.com.au>
This changes the signatures of QSPI write_cmd_data, write_cmd_addr_data and
read_cmd_qaddr_qdata so they return an error code. The softqspi and stm32
hardware qspi driver are updated to follow this new signature. Also the
spiflash driver is updated to use these new return values.
Signed-off-by: Damien George <damien@micropython.org>
With a SPI flash that has more than 16MB, 32-bit addressing is required
rather than the standard 24-bit. This commit adds support for 32-bit
addressing so that the SPI flash commands (read/write/erase) are selected
automatically depending on the size of the address being used at each
operation.
When going out of memory-mapped mode to do a control transfer to the QSPI
flash, the MPU settings must be changed to forbid access to the memory
mapped region. And any ongoing transfer (eg memory mapped continuous read)
must be aborted.
The Cortex-M7 CPU will do speculative loads from any memory location that
is not explicitly forbidden. This includes the QSPI memory-mapped region
starting at 0x90000000 and with size 256MiB. Speculative loads to this
QSPI region may 1) interfere with the QSPI peripheral registers (eg the
address register) if the QSPI is not in memory-mapped mode; 2) attempt to
access data outside the configured size of the QSPI flash when it is in
memory-mapped mode. Both of these scenarios will lead to issues with the
QSPI peripheral (eg Cortex bus lock up in scenario 2).
To prevent such speculative loads from interfering with the peripheral the
MPU is configured in this commit to restrict access to the QSPI mapped
region: when not memory mapped the entire region is forbidden; when memory
mapped only accesses to the valid flash size are permitted.
Prior to this patch the QSPI driver assumed that the length of all data
reads and writes was a multiple of 4. This patch allows any length. Reads
are optimised for speed by using 32-bit transfers when possible, but writes
always use a byte transfer because they only use a single data IO line and
are relatively slow.
Taking the address assumes that the pin is an object (eg a struct), but it
could be a literal (eg an int). Not taking the address makes this driver
more general for other uses.
genhdr/pins.h is an internal header file that defines all of the pin
objects and it's cleaner to have pin.h include it (where the struct's for
these objects are defined) rather than an explicit include by every user.
