casaroli opened a new pull request, #19531:
URL: https://github.com/apache/nuttx/pull/19531
## Summary
The rp2350 executes in place from its external QSPI flash, and a NuttX image
normally leaves most of that flash unused. This adds a driver that exposes
the
unused region as an MTD device, so it can carry a filesystem. The rp2040 port
already has the equivalent (`rp2040_flash_mtd.c`); the rp23xx port had
nothing.
- The region is described by `RP23XX_FLASH_MTD_OFFSET` (byte offset from
`0x10000000`) and `RP23XX_FLASH_MTD_SIZE`, both multiples of the 4096 byte
erase sector. If the region would overlap the running image the driver
refuses to initialize (checked against `__flash_binary_end`) rather than
corrupting the firmware.
- Erase and program go through the bootrom flash routines. Those stall
instruction fetch from the same flash, so the driver runs them from SRAM
with
interrupts disabled and, on SMP builds, the other core parked. Interrupt
latency is affected for the duration of a write; this is inherent to
writing
the flash you are executing from.
- Afterwards the QSPI interface is returned to execute-in-place mode. By
default the driver restores the fast read mode the bootrom configured at
boot; `RP23XX_FLASH_MTD_SAFE_XIP` instead always uses the bootrom
`flash_enter_cmd_xip` routine, which is slower to execute from but depends
only on the documented bootrom entry point -- the safe choice when bringing
up a new board.
- The driver answers the `BIOC_XIPBASE` ioctl with the memory-mapped address
of
the region, so a filesystem that supports execute in place can hand out
real
flash pointers instead of copying into RAM.
- The common board bringup registers the device as `/dev/rpflash`.
## Impact
- New feature, opt-in via `CONFIG_RP23XX_FLASH_MTD` (default n, `depends on
MTD`). No change to existing behavior when disabled.
- Arch: `arm` (rp23xx / RP2350). Boards: rp23xx common bringup registers
`/dev/rpflash` when the option is enabled.
- No new external dependencies. No ABI/API changes beyond the new Kconfig
symbols and the new device node.
- Documentation: a Flash MTD section and a peripheral-table row were added to
`Documentation/platforms/arm/rp23xx/index.rst`.
## Testing
**Hardware:** RP2350 board (Pimoroni Pico Plus 2), `raspberrypi-pico-2:nsh`
plus `MTD`, `MTD_BYTE_WRITE`, `RP23XX_FLASH_MTD`, `FS_SPIFFS`. Programmed
over
SWD with a Raspberry Pi Debug Probe (probe-rs); console on UART0. Defaults
were
used for the region: offset `0x100000`, size `0x100000`.
SPIFFS was chosen for the test because it binds directly to an MTD device
node,
so the exact code this PR adds is what gets exercised -- no extra board glue.
1. **Device registers:** `ls -l /dev` shows `rpflash` with size **1048576**,
exactly the configured region size.
2. **Format (erase + program of the whole 1 MiB region):** `mount -t spiffs
/dev/rpflash /mnt` formats and mounts successfully; `mount` then lists
`/mnt type spiffs`.
3. **Write and read back:** `echo hello-rp2350-mtd > /mnt/test.txt` then
`cat /mnt/test.txt` returns `hello-rp2350-mtd`.
4. **Multi-sector write:** `dd if=/dev/zero of=/mnt/big.bin bs=512 count=64`
writes 32768 bytes at ~71 KB/s; both files list correctly.
5. **Remount:** `umount /mnt` followed by a fresh mount re-reads everything
from
flash -- both files are present and `test.txt` still reads back correctly.
6. **Persistence across reset** (the real proof the data reached flash):
after a
full reset and re-mount, `ls -l /mnt` still shows `test.txt` (17 bytes)
and
`big.bin` (32768 bytes), and `cat /mnt/test.txt` still returns
`hello-rp2350-mtd`.
7. **XIP correctly restored:** the firmware continues to run from flash after
all of the erase/program activity -- `uname -a` and `free` work normally
after the writes, which is the property that breaks first if the QSPI
interface is not put back into execute-in-place mode.
`tools/checkpatch.sh -f` (nxstyle) and `-g` (patch + commit message) both
pass.
### Note on provenance
This driver was developed and used for some time on a downstream branch
carrying an XIP filesystem; this PR extracts just the MTD driver, with no
dependency on that work. The `BIOC_XIPBASE` support is what that filesystem
used, and it is useful to any execute-in-place filesystem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
