Back to the Roots: How the Memory Crisis Made Us Rethink Embedded Linux

A 512 MB SPI NAND chip sitting loosely on top of our i.MX93-based SocBloc 4, which currently uses an 8 GB eMMC. The next design iteration will replace the eMMC with this SPI NAND — requiring a completely rethought software architecture.

An 8GB eMMC used to cost $1.50. Today it's $20. Automotive-grade parts are pushing $30. Production capacity for 2026 is fully booked, with manufacturers fulfilling under 30% of orders.

At PolyVection, we design custom chip-down Linux systems on NXP application processors — i.MX 8M Mini, 8M Nano, i.MX 91, i.MX 93 — and own the full stack from silicon to software. When component prices move, we feel it directly. And right now, NAND flash is forcing us to fundamentally rethink how we build embedded Linux systems.

What We Had

For years, eMMC was our default. An 8GB part cost next to nothing, and our proven A/B update architecture fit comfortably: two ext4 root partitions (~1.5GB each), a data partition, and a bootloader toggling between them during OTA. Around 4GB total. Simple, reliable, battle-tested across dozens of customer projects.

Nobody asked us to optimize image size. There was no reason to.

What Changed

The 2025–2026 NAND shortage is structural, not cyclical. Manufacturers are reallocating up to 40% of wafer capacity toward AI memory. NAND prices have increased over 240% since early 2025. The remaining eMMC production is shifting toward 64GB+ capacities for smartphones — the 4–8GB parts embedded systems depend on are becoming scarce.

LPDDR4 has stabilized it seems. NAND has not, and the outlook isn't improving. We're currently redesigning our i.MX93-based SocBloc 4 development kit to replace the 8GB eMMC with a 512MB SPI NAND. An ECC-free 512MB SPI NAND currently sits at $5–7 — a fraction of the $20 eMMC, but with a fraction of the capacity too. That means our 4GB A/B scheme simply doesn't fit anymore.

SquashFS: A 2002 Solution to a 2026 Problem

SquashFS was written by Phillip Lougher in 2002 for a set-top box with 8MB of RAM. It became the backbone of embedded Linux — OpenWrt used it to fit a full router OS into 4MB of flash. Then eMMC got cheap, and a generation of developers stopped bothering with compression. Ourselves included.

The NAND shortage broke that mindset. We found ourselves reaching for the same tools Lougher built 24 years ago.

The New Architecture

Here's what the partition layout looked like before, and what replaces it:

The old system needed 4.5 GB just for the OS — leaving no room on anything smaller than an 8 GB eMMC. The new layout fits the entire system into ~160 MB. On a 512 MB SPI NAND, that leaves around 350 MB of headroom for application data, logs, and future growth.

RAM: SquashFS vs. Initramfs

A common concern with compressed root filesystems is RAM usage. With a pure initramfs approach, the entire image is unpacked into RAM at boot — fine for a rescue environment, but impractical for a full production OS. SquashFS works differently: the kernel demand-pages compressed blocks on access and caches them in the page cache. Only data that's actually touched occupies RAM, and it's reclaimable under memory pressure.

In practice, our SquashFS-based system running nginx and a few Python services idles at around 120 MB RAM usage. Depending on the level of optimization and customer application requirements, that means you may get away with 1 Gbit (128 MB) LPDDR4 DRAM on a tightly scoped product. For general-purpose use, 2 or 4 Gbit (256 or 512 MB) are more realistic choices in serial production. In these system architectures, RAM capacity often equals NAND capacity — sometimes doubles it.

Rescue-Based OTA

Without A/B, we needed a different safety model. The boot partition holds two independent environments: a normal boot chain (kernel + SquashFS) and a rescue system (self-contained BusyBox + SWUpdate running entirely in RAM). Here's how an update works:

1. The normal system periodically polls the OTA server for available updates.
2. If an update is found, the system stores the download URL and authentication tokens in the persistent data partition.
3. The system reboots into the rescue environment.
4. The rescue initramfs — running entirely from RAM — reads the stored credentials, downloads the update, and writes the new SquashFS image and kernel to SPI NAND.
5. The system reboots back into normal mode. Update installed.

Because the rescue environment runs from RAM and is never modified during updates, it remains a known-good fallback. If anything goes wrong — download failure, power loss, corrupted image — the device always boots back into rescue and can retry.

Step One of Two

This is the first step: shrinking our proven 4GB image down to roughly 160MB while switching from A/B to rescue-based OTA. Everything still runs on eMMC for now.

The second step is the hardware migration — replacing eMMC with SPI NAND and moving from the ext4 boot partition to UBI/UBIFS, which is designed for raw NAND with proper wear leveling and bad block management. The software architecture we've built is designed with that transition in mind.

Why It Matters

An 8GB eMMC at $20 across a 50,000-unit run is a million dollars on the BOM that wasn't there two years ago. The techniques to avoid it aren't new — SquashFS, demand paging, read-only root — a decade of cheap storage just made us forget they existed.

We're rolling this architecture into our standard BSP for all new NXP i.MX designs. The NAND shortage may ease eventually, but the structural shift toward AI memory won't reverse. And honestly, the resulting system is better regardless of pricing: smaller footprint, immutable deployments, always-recoverable devices.

Sometimes going back to the roots is the way forward.

← Back to Insights

Facing similar challenges with NAND costs or OTA architecture? Get in touch.