@kwagyeman FYI this might be useful to you.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.51%. Comparing base (d901e98) to head (720f797).

@@           Coverage Diff           @@
##           master   #19348   +/-   ##
=======================================
  Coverage   98.51%   98.51%           
=======================================
  Files         176      176           
  Lines       22903    22903           
=======================================
  Hits        22562    22562           
  Misses        341      341           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Code size report:

Reference:  unix/README: Update the supported targets list. [d901e98]
Comparison: tools/mpremote: Implement incremental preparation for romfs deploy. [merge of 720f797]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:   +28 +0.010% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

@dpgeorge Can you add the mimxrt too?

Can you add the mimxrt too?

The mimxrt port (and others like rp2, esp32) do not need this addition, because they return a block device from the vfs.rom_ioctl(2, 0) call. And that block device allows you to read/write/erase blocks in arbitrary order.

The changes in this PR are only needed for ports that do not expose a block device for the ROMFS.

Mmm, would be nice to have a unified api here.

would be nice to have a unified api here.

That's not easy to implement. Eg on STM32 parts with ROMFS in internal flash, the page erase size is sometimes very large (eg 256kb on F767) and it's not feasible to expose that as a block device object (because you can't write 256kb at once so it'd need to support partial writes and that makes it quite complicated). So the way it's designed is:

• in cases where the ROMFS partition is exactly within an existing block device (eg rp2, esp32 external memory-mapped flash used for code and data and filesystem) then vfs.rom_ioctl() can just return that existing block device object (instead of implemented a whole different API to access that flash)
• in cases where the ROMFS partition is not backed by a traditional block device (eg STM32F767 internal flash) then it implements vfs.rom_ioctl() ioctl codes to erase/write the data
• ROMFS is a feature that you probably still want on devices with limited resources, and in that case the port should be able to choose the most minimal way to implement ROMFS partition access (either a block device or rom_ioctl() codes)
• the complexity to use the API is then pushed up to the user of vfs.rom_ioctl(), eg mpremote has logic to handle all the different cases (and this PR introduces a new scenario that needs to be handled: when partial erase may or may not be supported by the target)

In the end it's not that hard to support the different ways that it works, especially writing it in Python is pretty straightforward. I can add some docs for that (see also #19127).

If we really need to have a unified API for this... then it requires a redesign of the whole interface to come up with something that will suit all the ports and all the different ways of having writable ROM.

(Note that the situation in master already has this non-unified API. This PR does not change that but rather extends the vfs.rom_ioctl() interface to support partial erase on those targets that don't use the block protocol.)

Well, I can just use exceptions on returned types and name errors to have one piece of code handle everything, so, I can do that to handle everything.

I did some more thinking about this, and maybe it does need a bit of an overhaul to unify it, and also provide information about non-memory-mappable flash partitions that are used for filesystem only.