This commit adds preliminary support for ST's new STM32N6xx MCUs.
Supported features of this MCU so far are:
- basic clock tree initialisation, running at 800MHz
- fully working USB
- XSPI in memory-mapped mode
- machine.Pin
- machine.UART
- RTC and deepsleep support
- SD card
- filesystem
- ROMFS
- WiFi and BLE via cyw43-driver (SDIO backend)
Note that the N6 does not have internal flash, and has some tricky boot
sequence, so using a custom bootloader (mboot) is almost a necessity.
Signed-off-by: Damien George <damien@micropython.org>
On stm32, the startup code attempts to mount the configured filesystem. If
there is an existing littlefs filesystem that's suitable corrupted it's
possible for the reported blocksize to be incorrect here:
uint32_t block_size = lfs2_fromle32(superblock->block_size);
This `block_size` (which is read from the filesystem iteself) is used to
create the len argument passed to `pyb_flash_make_new()`. In that function
the len arg is validated to be a mutliple of the underlying hardware block
size, as well as not bigger than the physical flash. Any failure is raised
as a ValueError. This exception is not caught currently in main, it flows
up to the high level assert / startup failure.
As this occurs before `boot.py` is run, the users (potentially frozen)
application code doesn't have any opportunity to detect and handle the
issue.
This commit adds a helper function which attempts to create a block device,
and on error returns `None` instead of raising an exception. Using this in
main means that a potentially corrupt filesystem will simply remain
unmounted, and the application can handle the issue safely.
The fix here also handles the case where the littlefs filesystem is valid
but the autodetection code (which detects the filesystem size) does not
work correctly. In that case it will retry mounting the filesystem using
the whole size of the block device.
Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
A board can now define the following to fully customise the extended block
device interface provided by the storage sub-system:
- MICROPY_HW_BDEV_BLOCKSIZE_EXT
- MICROPY_HW_BDEV_READBLOCKS_EXT
- MICROPY_HW_BDEV_WRITEBLOCKS_EXT
- MICROPY_HW_BDEV_ERASEBLOCKS_EXT
Signed-off-by: Damien George <damien@micropython.org>
When littlefs is enabled extended reading must be supported, and using this
function to read the first block for auto-detection is more efficient (a
smaller read) and does not require a cached SPI-flash read.
Signed-off-by: Damien George <damien@micropython.org>
And return -MP_EIO if calling storage_read_block/storage_write_block fails.
This lines up with the return type and value (negative for error) of the
calls to MICROPY_HW_BDEV_READBLOCKS (and WRITEBLOCKS, and BDEV2 versions).
The pyb.Flash() class can now be used to construct objects which reference
sections of the flash storage, starting at a certain offset and going for a
certain length. Such objects also support the extended block protocol.
The signature for the constructor is: pyb.Flash(start=-1, len=-1).
This commit refactors and generalises the boot-mount routine on stm32 so
that it can mount filesystems of arbitrary type. That is, it no longer
assumes that the filesystem is FAT. It does this by using mp_vfs_mount()
which does auto-detection of the filesystem type.
Instead of checking each callback (currently storage and dma) explicitly
for each SysTick IRQ, use a simple circular function table indexed by the
lower bits of the millisecond tick counter. This allows callbacks to be
easily enabled/disabled at runtime, and scales well to a large number of
callbacks.
It makes it cleaner, and simpler to support multiple different block
devices. It also allows to easily extend a given block device with new
ioctl operations.
Prior to this patch, storage.c was a combination of code that handled
either internal flash or external SPI flash and exposed one of them as a
block device for the local storage. It was also exposed to the USB MSC.
This patch splits out the flash and SPI code to separate files, which each
provide a general block-device interface (at the C level). Then storage.c
just picks one of them to use as the local storage medium. The aim of this
factoring is to allow to add new block devices in the future and allow for
easier configurability.
This is to keep the top-level directory clean, to make it clear what is
core and what is a port, and to allow the repository to grow with new ports
in a sustainable way.
