Using Linux UBI and UBIFS in QSPI Flash and HyperFlash on i.MX RT
1. Overview
This article describes support for the UBI Flash management framework and the UBIFS Flash file system in the Emcraft Linux i.MX RT BSP.
The UBIFS solution provides a production-grade Flash file system for the i.MX RT microcontrollers, bringing capabilities typically found in application processors to the MCU world. Ability to efficiently manage Flash, with wear levelling, power-loss safety and long Flash life, is critical for virtually any i.MX RT application.
2. Reference Platforms
The UBI and UBIFS capabilities are available on the following hardware reference platforms, supported with the Emcraft Linux BSP:
NXP IMXRT1170-EVK / IMXRT1170-EVKB — QSPI NOR Flash (16 MB / 64 MB)
Avnet MaaXBoard-RT — HyperFlash (32 MB).
3. Why UBIFS on an MCU?
Embedded systems based on i.MX RT microcontrollers typically run RTOS environments (Zephyr, FreeRTOS, etc) with simple Flash storage solutions — raw Flash read/write, LittleFS, or FAT over Flash translation layers. These approaches work for basic key-value storage or logging, but have significant limitations when the application requires a full-featured file system on Flash.
The following table describes the key advantages of using UBIFS over the simple Flash file systems implemented by RTOS’s:
Feature | RTOS (LittleFS, FAT) | Linux + JFFS2 | Linux + UBIFS |
|---|---|---|---|
Wear leveling | Basic (LittleFS) or none (FAT) | Per-file, within JFFS2 | Full Flash, managed by UBI layer |
Mount time | Fast | Slow — scans entire Flash (O(n)) | Fast — on-flash index, O(1) |
Write performance | Synchronous | Synchronous | Write-back caching |
Compression | None | zlib, LZO | LZO |
Power-loss safety | Varies | Yes (log-structured) | Yes (journaling) |
Scalability | Limited to small partitions | Degrades on large partitions | Scales well to larger partitions |
POSIX compliance | Partial or none | Full | Full |
Volume management | None | None | UBI: multiple volumes, |
3.1. Key Advantages of UBIFS
Wear leveling across the entire Flash. UBI (Unsorted Block Images) manages wear leveling at the block level across the entire Flash partition, not just within individual files. This dramatically extends Flash lifetime in applications with uneven write patterns — for example, when a few configuration files are updated frequently while the rest of the file system is mostly read-only.
Fast, predictable mount time. JFFS2 must scan every node on the Flash at mount time, which takes seconds on multi-megabyte partitions. UBIFS uses an on-flash index (a "wandering tree" structure), so mount time is constant regardless of Flash size or how many files are stored. This is critical for systems that need fast boot or fast recovery after a power cycle.
Transparent compression. UBIFS compresses data transparently using LZO, effectively increasing the usable storage capacity. On a typical embedded root file system with binaries, libraries, and configuration files, data is commonly compressed to 40–60% of its original size. This means a 7.5 MB Flash partition can hold significantly more uncompressed data.
Write-back caching. Unlike JFFS2's synchronous writes, UBIFS supports write-back mode where writes are cached in RAM and flushed to Flash asynchronously. This improves write throughput for applications that perform many small writes (logging, database updates, configuration changes). Data consistency is maintained on power loss through journaling, though uncommitted writes in the cache may be lost. Applications requiring guaranteed persistence should call sync or fsync.
Multiple volumes. UBI supports multiple logical volumes on a single Flash partition. For example, a production system could use separate volumes for the root file system (read-mostly), application data (read-write), and logs (write-heavy), each with different mount options, without needing separate MTD partitions.
4. Practical Examples
4.1. Persistent Configuration Storage
A networked sensor device stores its configuration on the Flash file system. With UBIFS, these files are compressed, wear-leveled, and power-loss safe. The following example creates a configuration directory and writes application settings:
/ # mkdir -p /etc/config
/ # echo '{"temp_max": 85, "interval": 10}' > /etc/config/settings.json
/ # echo "192.168.1.100 gateway" >> /etc/config/network.conf
/ # sync
/ # cat /etc/config/settings.json
{"temp_max": 85, "interval": 10}After a power cycle, the data is intact:
/ # cat /etc/config/settings.json
{"temp_max": 85, "interval": 10}
/ # cat /etc/config/network.conf
192.168.1.100 gateway4.2. Storage Efficiency with Compression
UBIFS compresses data on the Flash transparently. The compression benefit is visible when comparing the logical size of the root file system content with the actual Flash space consumed. The df output reflects the compressed on-flash usage:
/ # du -sh /bin /lib /etc /usr
384.0K /bin
452.0K /lib
92.0K /etc
1.4M /usr
/ # df -h /
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 4.0M 1.5M 2.4M 38% /The du output shows approximately 2.3 MB of uncompressed file system content (binaries, libraries, configuration files), while df reports only 1.5 MB used on the Flash — a ~35% space savings from transparent LZO compression. This effectively increases the usable storage capacity without any application changes, and the benefit grows with larger rootfs content.
4.3. Application Logging
UBIFS write-back mode batches frequent small writes, reducing the number of Flash erase cycles and extending Flash lifetime. The following example simulates a sensor logging application writing a record every 2 seconds:
/ # while true; do echo "$(date +%H:%M:%S) temp=23.$((RANDOM%10)) hum=$((40+RANDOM%20))"; sleep 2; done >> /var/log/sensor.log &
/ #After letting it run for several minutes:
/ # wc -l /var/log/sensor.log
150 /var/log/sensor.log
/ # tail -3 /var/log/sensor.log
00:05:26 temp=23.7 hum=48
00:05:28 temp=23.3 hum=52
00:05:30 temp=23.5 hum=45
/ # df -h /
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 4.0M 1.5M 2.4M 38% /The log writes are absorbed by the write-back cache and flushed to Flash in batches, minimizing the impact on Flash wear. The df output confirms that the log data has negligible impact on Flash usage thanks to the LZO compression.
Stop the background logger when done:
/ # kill %14.4. Monitoring Flash Health
UBI tracks the erase count for every physical erase block on the Flash and exposes the maximum value through the sysfs interface:
/ # cat /sys/class/ubi/ubi0/max_ec
2The max_ec value shows the highest erase count across all physical erase blocks. UBI wear leveling ensures this counter stays close to the average by redistributing writes across the Flash. NOR Flash devices typically support 100,000 or more erase cycles per block, so this counter allows the application to estimate remaining Flash endurance in the field.
5. Verification
After booting with UBIFS, the root file system is mounted automatically:
/ # mount | grep "on / "
ubi0:rootfs on / type ubifs (rw,relatime,assert=read-only,ubi=0,vol=0)Data written to the file system persists across power cycles:
/ # echo "persistence test" > /test_file
/ # rebootAfter reboot:
/ # cat /test_file
persistence test
/ # rm /test_file6. Further Reading
For build instructions, Flash partition layout, installation procedures, and detailed test plans, refer to:
Support Booting from FlexSPI Flash (QSPI Flash and HyperFlash) in Linux BSP for the i.MX RT Targets
Detailed documentation of the Emcraft Linux i.MX RT BSPs is available from the web site: