PREV_LEC | NEXT_LEC

What You Will Learn

Prerequisites

Why the Bootloader Needs Its Own Drivers

Before Linux runs, nothing runs — no MTD subsystem, no mmcblk driver, no filesystem layer. The bootloader is the very first piece of software to touch the board’s flash, and its job is to find a kernel image, load it into RAM, and jump to it. That means the bootloader needs its own minimal, self-contained drivers for whatever flash device the board actually has: NOR, NAND, or an MMC/SD/eMMC controller. We’ll use U-Boot as our example, since it’s the dominant bootloader across embedded Linux, but the same division of responsibility — read, erase, write, at a very low level — applies to any bootloader.

U-Boot and NOR Flash

U-Boot’s NOR support lives in its CFI (Common Flash Interface) driver family, and because NOR flash can be read directly like RAM, U-Boot offers simple byte-level commands: erase to unlock and blank a range, and cp.b to copy data byte-by-byte into flash. Suppose a board maps 64 MiB of NOR flash starting at 0x60000000, with an 8 MiB kernel partition beginning at 0x60200000. Downloading and flashing a new kernel image looks like this:

=> tftpboot 0x82000000 zImage
=> erase 0x60200000 0x609fffff
=> cp.b 0x82000000 0x60200000 ${filesize}

The ${filesize} variable is set automatically by tftpboot to the exact size of the file that was just downloaded, so you never have to hand-calculate how many bytes to copy.

U-Boot and NAND Flash

NAND can’t be addressed byte-by-byte, so U-Boot manages it through a dedicated nand command with page-and-block-aware sub-commands: erase, write, and read. This example loads a kernel into RAM over the network and then programs it into NAND at a 2 MiB offset:

=> tftpboot 0x82000000 zImage
=> nand erase 0x200000 0x600000
=> nand write 0x82000000 0x200000 ${filesize}

U-Boot can also mount and read files directly out of JFFS2, YAFFS2 or UBIFS filesystems living on NAND, which is handy for loading a device tree blob or an initramfs without hardcoding raw offsets.

U-Boot and MMC, SD, eMMC

For managed flash, U-Boot talks to the on-board MMC/SD/eMMC controller through drivers under drivers/mmc, exposing sector-level mmc read and mmc write commands, plus the ability to mount FAT32 or ext4 filesystems directly:

=> mmc dev 0
=> fatload mmc 0:1 0x82000000 zImage
=> ext4load mmc 0:2 0x83000000 rootfs.cpio.gz

Notice how much higher-level this is compared to raw NOR/NAND commands — because the card’s own controller already handles wear leveling and bad blocks, U-Boot is free to work in terms of filesystem files rather than raw byte offsets.

Accessing Flash From Linux: The MTD Subsystem

Once Linux is running, raw NOR and NAND flash are handled by the Memory Technology Device (MTD) subsystem, which provides a uniform read/erase/write interface regardless of the underlying chip technology. For NAND specifically, MTD also exposes functions for out-of-band (OOB) metadata and bad block identification — the same concerns the bootloader’s NAND driver had to handle, now managed by a full kernel subsystem instead of a minimal boot-time driver.

Managed flash — MMC/SD/eMMC — instead uses the mmcblk driver, since wear leveling and bad-block handling already happen inside the card. CompactFlash and hard disks go through the SCSI Disk driver, sd, because CF exposes itself as a standard disk over its ATA-style interface. USB flash drives layer the usb_storage driver underneath that same sd driver, since the USB mass storage class is itself built on the SCSI command set.

Hands-On: Inspecting Flash Devices From Linux

Let’s write a small original script, ep_storage_map.sh, that reports every flash-backed block device on a running board and which driver family owns it — a fast way to sanity-check a new board bring-up before writing a single line of application code.

#!/bin/sh
# ep_storage_map.sh - map flash block devices to their driver family
# Original demo script for the EmbeddedPathashala free linux device drivers course

echo "--- MTD (raw NOR/NAND) devices ---"
if [ -e /proc/mtd ]; then
    cat /proc/mtd
else
    echo "no MTD devices present"
fi

echo ""
echo "--- Managed flash (mmcblk) devices ---"
for dev in /sys/block/mmcblk*; do
    [ -e "$dev" ] || continue
    name=$(basename "$dev")
    size=$(cat "$dev/size" 2>/dev/null)
    echo "$name : $size sectors"
done

echo ""
echo "--- SCSI-backed (sd, CF/USB) devices ---"
for dev in /sys/block/sd*; do
    [ -e "$dev" ] || continue
    name=$(basename "$dev")
    model=$(cat "$dev/device/model" 2>/dev/null)
    echo "$name : $model"
done

Expected output on a board with onboard NAND, an eMMC rootfs, and a USB stick plugged in:

$ ./ep_storage_map.sh
--- MTD (raw NOR/NAND) devices ---
dev:    size   erasesize  name
mtd0: 00400000 00020000 "u-boot"
mtd1: 07c00000 00020000 "kernel"

--- Managed flash (mmcblk) devices ---
mmcblk0 : 15558144 sectors

--- SCSI-backed (sd, CF/USB) devices ---
sda : Cruzer_Blade

Common Mistakes and Troubleshooting

Best Practices

• Keep a known-good recovery path (SD boot, JTAG) before flashing NOR/NAND
• Always match filesystem choice to the underlying flash type (UBIFS/JFFS2 for MTD, ext4 for managed flash)
• Script flashing steps instead of typing U-Boot commands by hand in production
• Verify device identity with sysfs before any write/erase operation

Performance Considerations

Raw NAND through MTD can outperform managed flash for large sequential writes because there’s no hidden controller translation layer in the way, but it requires the host to do all wear-leveling work itself via UBI/UBIFS. Managed flash trades a small amount of raw throughput for a much simpler host-side software stack — for most embedded products, that tradeoff favors managed flash unless you have a specific reason not to.

Summary and Key Takeaways

Conclusion

Storage strategy in embedded Linux is really two decisions in one: which flash hardware to put on the board, and which software path — MTD or block-device — you’ll use to talk to it at every stage of the boot chain. Get comfortable identifying devices in sysfs and matching them to the right driver family, and board bring-up debugging gets dramatically faster.

FAQ: Bootloader and Linux Flash Access

PREV_LEC | NEXT_LEC