7.5. ROMFS

ROMFS is a read-only filesystem built into the cam at compile time and mounted at /rom/. The file blocks live in flash and are mapped into the address space, so opening a file there exposes its bytes directly from flash with no RAM copy. Models, label files, and Haar cascades are the typical contents.

7.5.1. Why models live here

Two reasons. The first is the RAM trade-off already noted: a model on /rom/ reads in place from flash and costs no RAM beyond its tensor arena, where a model on /sdcard/ is copied into RAM at load time and costs the file size on top of the arena. On the smaller cams that difference is often the difference between fitting and not fitting.

The second is the NPU. The N6’s NPU and the Ethos-U on the AE3 expect their weights in a memory-addressable region with the right alignment, and the build tooling that compiles a model for those accelerators (STEdgeAI for the N6’s NPU, Vela for the AE3’s Ethos-U) places the result in ROMFS with that layout. A model loaded from /sdcard/ lands in heap RAM, which is fine for the CPU paths the H7 and RT1062 use, but gives up the direct-from-flash NPU path the faster cams were designed around.

7.5.2. A normal MicroPython filesystem

At runtime ROMFS behaves like any other mounted MicroPython filesystem: os.listdir() enumerates /rom/, builtins.open() opens files in it, and a path under it passes to any API that accepts a path. The only restriction is that scripts cannot write to it – the partition is read-only at run time.

The IDE can edit ROMFS. It exposes the partition’s contents in its file browser and supports adding, removing, and replacing files there the same way it does for the SD card. The intended use is to add custom models, label files, helper scripts, or any other resource the application needs to ship with the cam. Anything dropped into /rom/ through the IDE gets the same direct-from-flash, NPU-accessible storage the preloaded models have.