Flash in Small Devices: Routers, Cameras and Watches

The GL.iNet GL-MT300N V2 router has 128MB of RAM and 16MB of flash, according to OpenWrt’s device page. A Linksys E8450 has 512MB of RAM and a 128MiB SPI NAND chip. Neither chip has a controller of its own, so the processor reads its bootloader, kernel and root file system straight off the chip. On NAND it also has to cope with bad blocks.

Parts 1 to 3 of this series cover managed flash, in UFS, eMMC and SD cards, where a controller hides that work, and Part 5, Flash in Phones and Tablets, covers how phone flash shares a package with RAM. Beyond NAND Part 1 covers how NOR cells work and how serial NOR runs from SPISPI is a simple serial bus of a clock, a chip select and data lines. Serial NOR and NAND flash chips use it, often in dual or quad data modes. to xSPI. This part covers what small devices do with the bare chips, which sizes they use, how the chip is carved into partitions, and who looks after wear.

A bare chip leaves the work to the host

Managed flash puts a controller beside the NAND, and a small board usually has none. NOR and SPI NAND are memory chips with a serial interface, and the host decides how to map, erase and protect them. This part follows four boards, from 4MB to 128MiB of flash. A PineTime smartwatch pairs 512KB inside its nRF52832 with an extra 4MB SPI NOR chip. OpenIPC’s test camera has 8MB of NOR, the GL-MT300N V2 has 16MB, and the E8450 has 128MiB of SPI NAND.

Figure 1 splits those boards by chip type. NOR serves as code storage up to 16MB here and SPI NAND takes over at 128MiB, and OpenIPC says most IP cameras carry 8MB or 16MB of NOR or NAND, so these sizes are typical of the class and not records.

NOR holds the code a processor runs

A microcontroller often has little or no program flash of its own. Raspberry Pi’s RP2040 has none and runs cached execute-in-place from external QSPI memory, up to 16MB. That is why the code sits in NOR, where the processor can fetch from it directly, as execute in place explains.

On an ESP32 the flash layout is a table. ESP-IDF keeps the partition table at offset 0x8000, allows up to 95 entries in it, and gives it a 4KB sector. Its bootloader runs the app labeled factory by default, and that app sits at 0x10000, 64KB into the chip.

Figure 2 draws the table ESP-IDF calls a factory app with two OTA definitions. Sectors for NVS, otadata and phy_init come first, then three 1MB apps follow at 0x10000, 0x110000 and 0x210000. Everything ends at 0x310000, inside a 4MB chip with room to spare. Two OTA slots keep an update from overwriting the running app, a pattern Beyond NAND Part 1 covers under the update needs two copies.

A router or camera slices one chip into partitions

Linux sees a bare flash chip as named partitions of fixed size. On the GL-MT300N V2 the NOR holds a 192KiB bootloader, a 64KiB bootloader environment and 64KiB of factory data, and the other 16,064KiB belongs to firmware. Inside that firmware space the kernel takes about 2MiB, and rootfs_data takes the largest share at around 10MiB.

OpenIPC’s boot log for a Chacon camera shows a similar split on a 16MB XM25QH128A with 64KiB blocks. Its partitions are boot, env, kernel, rootfs and rootfs_data, and every boundary falls on a 64KiB multiple.

Figure 3 draws the two 16MB chips at one scale, and both give most of the chip to the writable partition, about 10MiB on the router and about 8.7MiB on the camera. This guide reads that partition as the one that wears, since the others change only when firmware is updated.

SPI NAND adds capacity and bad blocks to manage

Winbond’s W25N01GV is a 1Gb serial SLC NAND with 65,536 pages of 2,048 bytes and 1,024 erasable blocks of 128KB. Its SPI clock runs up to 104MHz, equal to 416MHz on four data lines, with a 50MB/s continuous transfer rate. It comes in an 8-pad WSON or a 16-pin SOIC, so it fits where a NOR chip fits.

NAND also ships with bad blocks. Per the datasheet, up to 2% of blocks can be marked bad at shipment, a maximum of 20 on this part, and a user should scan the whole array for the factory markers. A bad block management command links a bad logical block to a spare physical one in a look-up table of up to 20 links, and the manufacturer may already have used some of those entries. A 1-bit ECC is on board.

Figure 4 draws each of the 1,024 blocks as a square and marks 20 of them bad. The look-up table has as many links as the worst case needs, so a chip that arrives with the maximum may have few links to spare. Winbond advises keeping a table of the factory bad blocks before the first erase or program.

Endurance is rated at more than 100,000 erase/program cycles on the strength of the on-chip ECC, with more than 10 years of retention. Beyond NAND Part 1 lists the NOR W25Q128JV at 100K cycles per sector and more than 20 years of retention. On paper the cycle ratings match, and the NAND figure assumes ECC is on. Retention is the larger gap, at more than 10 years against more than 20.

Raw NAND leans on UBI, and the E8450 shows why

Take the E8450. According to its OpenWrt page, the vendor layout puts a JFFS2 rootfs_data partition straight on the raw NAND, while OpenWrt’s UBIUBI is a wear-leveling and volume management layer that runs on top of an MTD device. It hides wear and bad blocks from the file system above it. layout puts one UBI partition across the chip behind a 512KiB bl2 partition. The page says the vendor layout can no longer be kept since August 27, 2021, because it carries ECC errors from the factory that the new SPI NAND driver rejects.

UBI does that work. In the Linux MTDMTD is the Linux subsystem that gives flash chips one uniform interface. An MTD device, such as /dev/mtd0, represents raw flash. documentation, UBI is a wear-leveling and volume management layer that runs on top of an MTD device and hides wear and bad blocks from the file system above it. It stores an erase counter in a header in every physical eraseblock, which is why a flashing tool that is not UBI-aware can lose the counts. UBIFS is the file system on top, and its authors report it survived more than 100,000 power cuts in stress tests on OneNAND flash.

Figure 5 stacks the layers. A SquashFS root is mounted at /rom and a UBIFS overlay at /overlay, and both sit in the UBI partition that fills the chip behind a 512KiB bl2 boot partition.

Wear and power loss on a microcontroller

UBI assumes Linux. littlefs targets microcontrollers instead. Its README lists copy-on-write operations that fall back to the last good state after a power cut, dynamic wear leveling with bad block detection, and RAM use that stays bounded as the file system grows. Metadata lives in small logs called metadata pairs, file data lives in copy-on-write structures, and the allocator spreads wear by limiting the erases allowed on a block per allocation.

Figure 6 shows why a power cut leaves the old file intact. An update goes to a new copy first and is committed only when sync or close is called, so a cut lands either before the commit, with the old copy still current, or after it. Remove and rename are atomic even on power loss.

Industrial managed flash guards against the same threat in hardware, which Part 4 covers.

Reading a chip marking

OpenIPC’s installation guide gives a rule for reading a flash chip. Digits in a model number are megabits, so 64 in EN25QH64 means 64Mb, or 8MB, and 128 means 16MB. A bootloader log does the lookup too. On one OpenIPC camera it printed a 16MB XM25QH128A with 64KiB blocks.

The last figure turns two markings into sizes. Size is the first question and chip type is the second. NOR means code can run in place and partitions follow the erase sector. NAND means bad blocks, ECC and a layer such as UBI, and a rating such as 100,000 cycles should be checked for whether it assumes ECC.

That closes the series, and the hub page, Flash in Devices, lists all six parts.