15.1.12. Editing the ROM file system¶
Boards with ROMFS support carry a read-only file system
in flash, mounted on the camera at /rom. It ships
with the board’s default machine-learning models, and
it is where a product’s models and assets belong: files
in ROMFS are memory-mapped straight out of flash, so a
large model loads without consuming RAM for a copy. The
IDE’s Tools → ROM File System submenu is the editor for
it.
15.1.12.1. The editor¶
Edit ROMFS on OpenMV Cam reads the connected camera’s
ROMFS and opens it in the editor: a file tree plus
buttons to add files, create folders, delete and
extract entries, and pull a model straight in from the
model zoo. A usage readout tracks
how much of the board’s ROMFS partition the contents
occupy. Nothing touches the camera until Commit,
which asks whether to write the result back to the
camera or save it to a .img file on disk.
Two conversions happen automatically as files are
added. A .py script is cross-compiled to .mpy
bytecode for the target board, and a model file is
converted for the board’s NPU accelerator when it has
one and the model needs it. What lands in ROMFS is
always the form the camera executes directly.
Screenshot needed
figures/romfs-editor.png – the Edit ROMFS
dialog showing a file tree with a model file and a
folder in it, the Model Zoo / Add File / New Folder
/ Delete / Extract File / Commit buttons, and the
size-usage readout. Capture the whole dialog.
Open ROMFS File runs the same editor against a
.img image file on disk instead of a connected
camera, and New ROMFS File starts it empty – either
way, the path to preparing a ROMFS image offline, for
flashing in production or shipping alongside a custom
firmware build. Reset ROMFS on
OpenMV Cam restores the connected camera’s ROMFS to the
board’s defaults, undoing all edits.
See also
Building a ROMFS image for ROMFS’s role in shipping an application – what to put there, and how the camera reads it at runtime.