General-Purpose Media Interface (GPMI) Wiki

GPMI (General-Purpose Media Interface) is a NAND-flash controller IP block found in several NXP/Freescale i.MX application processors (e.g., i.MX23/i.MX28/i.MX6 variants). It offloads low-level NAND signaling, integrates tightly with a hardware BCH error-correction engine, and streams data through a DMA engine to system memory. In practice, GPMI is the SoC’s “raw NAND port,” enabling boot, firmware storage, and high-throughput data access on cost-sensitive systems.

Design goals

Protocol offload. Generate CLE/ALE/WE/RE/CS cycles and respect NAND timing modes without bit-banging in software.
ECC at line rate. Pair with a BCH block to encode/decode pages and manage OOB (spare) bytes transparently.
DMA-first throughput. Move full pages via descriptor chains, minimizing CPU intervention.
Flexibility. Support multiple chip-selects (banks), various page sizes, and vendor-specific OOB layouts.

Where it fits in an i.MX SoC

GPMI: issues commands/addresses, captures data, enforces timing, multiplexes channels.
BCH: computes parity and corrects bit errors (strength is SoC/page-size dependent).
APBH-DMA: executes linked descriptors (read/write/erase/status), allowing long I/O bursts.

Electrical/Protocol characteristics

Bus: Typically 8-bit data (D0–D7) with CLE, ALE, CE#, RE#, WE#, R/B#, WP#.
Timing: Programmable setup/hold/pulse widths to meet common asynchronous (SDR) NAND timing modes (e.g., ONFI mode 0+).
Chip-selects: Several independent CS lines allow multiple dies or packages on one interface.
Page/OOB: Handles 2-KB, 4-KB, and larger pages with configurable OOB layouts for ECC, bad-block markers, and metadata.

ECC and data integrity

GPMI is commonly paired with a hardware BCH engine (e.g., 8-, 16-, or higher-bit correction per 512- or 1,024-byte chunk, depending on the SoC). Reads pass data through the BCH for syndrome calculation and correction; writes stream data plus generated parity into the OOB. The controller reports corrected/uncorrectable errors so upper layers (e.g., UBI) can retire weak blocks before data loss.

Software support (Linux)

Driver: gpmi-nand in the Linux MTD subsystem.
Bindings: Device-tree nodes declare GPMI, the BCH companion, clocks, DMA channels, chip-select geometry, ECC strength, and OOB layout.
Stacks: Works with UBI/UBIFS for wear-levelling and power-fail robustness; also usable with YAFFS/Raw MTD.
Boot: Many i.MX parts can boot from NAND via GPMI; ROM code expects specific ECC layouts and search patterns in initial pages.

Typical capabilities

DMA-driven I/O with long descriptor chains (read/program/erase/status).
Bad-block management hooks (detect factory BBMs, mark runtime bad blocks).
Scrub/rescan support to monitor increasing bit error rates over device life.
Partitioning for bootloader, kernel, rootfs, and data volumes.

Performance notes

Throughput is dominated by the NAND device’s timing mode and ECC strength. GPMI is designed to saturate legacy asynchronous SLC/MLC NAND rates of its era with minimal CPU cost. Stronger BCH settings and larger page sizes reduce CPU overhead per byte but increase latency per operation—tune for your reliability targets and workload.

Limitations and gotchas

Interface scope: A raw NAND controller—not for eMMC, UFS, or SPI-NAND (those use different IP). Some GPMI generations target asynchronous NAND and may not support newer DDR/Toggle features.
ECC coupling: Boot ROMs and vendor BSPs assume specific ECC/OOB layouts; mixing distributions without aligning layouts can break boot or recovery.
Data quality: MLC/TLC and high-temp environments increase bitflips; choose adequate BCH strength and run periodic scrubbing.
Power-fail safety: Always pair with UBI/UBIFS or a journaled FTL; raw JFFS2 on large pages is risky under sudden resets.

Configuration checklist (practical)

Choose ECC strength based on NAND geometry and endurance targets.
Map OOB layout (parity, BBM, metadata) and lock it before production.
Size DMA descriptors to full pages plus OOB; enable interrupt coalescing if available.
Set timings from the NAND datasheet; verify with margin testing.
Validate boot path (ROM expectations, bad-block tables, duplicate headers).
Adopt UBI/UBIFS; enable wear-levelling, scrubbing, and health telemetry.

Alternatives

Controller types: ONFI-centric NAND controllers with integrated ECC; SPI-NAND (simpler wiring, lower bandwidth); eMMC/UFS (managed flash with FTL).
Use-case trade-off: GPMI + raw NAND offers lowest media cost and full control at the expense of software complexity and stricter reliability engineering.

Summary

GPMI is a mature, DMA-centric raw NAND interface that, together with a BCH engine and Linux’s MTD/UBI stack, provides a robust and cost-efficient flash solution on i.MX platforms. Its strength is precise timing control, hardware ECC integration, and boot support; its demands are careful ECC/OOB design, rigorous validation, and disciplined lifecycle management.

Share this post via: