Glossary

BBM = bad block management
BBT = bad block table
CFI = common flash interface
FTL = flash translation layer
LLD = low level driver, below the FTL where talking to the chip happens

NOR flash is used for random byte access, so can be used for executing code in place. NAND flash cannot, but is used for bulk storage in thumb drives and SD cards. NAND must be R/W on a page basis, and erased on block (multiple pages) basis. NAND chips arrive from factory with a few bad blocks, but this allows for cheaper storage. A block is considered bad if there are so many errors per some number of bytes, i.e. if a limit is exceeded. Loading images into memory from SPI NOR is slower than using parallel NOR or NAND. Great comparison: https://user.eng.umd.edu/~blj/CS-590.26/micron-tn2919.pdf
Journalling means the FFS records what it's doing to preserve the process in the event of power failure interruption. Changes are tracked before being committed.

Where to add driver support for a new flash type in Uboot

Look for the .../drivers/mtd/<if_type>/<vendor>.c file. There should be a parameter struct that looks like this, to which a new device entry can be added:

static const struct <vendor>_<if_type>_flash_params <vendor>_<if_type>_flash_table[] = {
	{
		.idcode1 = STM_ID_M25P16, (an ST Micro example)
		.page_size = 256,
		.pages_per_sector = 256,
		.nr_sectors = 32,
		.name = "M25P16",
	},
}

Changing Uboot default EVs

Go to the .../include/configs/ folder and find the <proj_name>.h that is referenced by make. This is the master config file and allows changes to things like ENV_OFFSET, flash specs, etc as well.

Finding more config files

Try the .../board/<vendor>/<product>/ directory.

Loading

You must erase flash in blocks, and erase first before writing. With U-boot sf command, use a "whole" or proper boundary block size (i.e. 0xc0000 instead of 0xbffff).

To put the Buildroot output file system onto your root flash device, use

$ sudo dd if=buildroot/output/images/rootfs.ext4 of=/dev/sdc2

Devices

Memory Technology Device (MTD) is a Linux device for flash memory - an abstraction layer created because of the bad fit of block and character devices for raw flash. USB sticks, SD cards, CF cards, etc, have a block device interface implementation via FTL. JFFS2 and YAFFS are examples of MTD aware file systems. MTD is a separate kind of device from block, character, or network devices.

In practice, flash file systems are used only for Memory Technology Devices (MTDs), which are embedded flash memories that do not have a controller. Removable flash memory cards and USB flash drives have built-in controllers to manage MTD with dedicated algorithms,[2][3] like wear leveling, bad block recovery, power loss recovery, garbage collection and error correction, so use of a flash file system has limited benefit.

MultiMedia Card (MMC) is a flash memory card standard.

SSD, MMC, eMMC, RS-MMC, SD, mini-SD, micro-SD, USB flash drive, CompactFlash, MemoryStick, MemoryStick Micro, and other FTL devices are block devices, not raw flash devices. Of course, hard drives are also block devices. MMC utilities will show you partitions.

SD card markings: http://gopro.com/support/articles/how-to-identify-your-microsd-card-class-rating

NAND flash is being replaced by eMMC in many recent embedded boards. eMMC is NAND flash with an MMC interface, but as opposed to MMC, is soldered on the board, to be immune from reliability issues caused by vibrations. Keep in mind that eMMC is distinct from MTD. The mtdinfo utility won't show eMMC devices, and they have different listings in the system block devices:

# ls /sys/block
loop0      loop4      mmcblk1    ram0       ram12      ram2       ram6
loop1      loop5      mtdblock0  ram1       ram13      ram3       ram7
loop2      loop6      mtdblock1  ram10      ram14      ram4       ram8
loop3      loop7      mtdblock2  ram11      ram15      ram5       ram9

Both will show here

# cat /proc/partitions
major minor  #blocks  name
  31        0        768 mtdblock0
  31        1          8 mtdblock1
  31        2       1272 mtdblock2
 179        0    7782400 mmcblk1
 179        1    1040384 mmcblk1p1

There is an extremely simple FTL layer in Linux MTD subsystem - mtdblock. It emulates block devices over MTD devices. There is also an mtdblock_ro module which emulates read-only block devices. When you load this module, it creates a block device for each MTD device in the system. The block devices are then accessible via /dev/mtdblockX device nodes.

For flash devices, either NAND or NOR, there is no partition table on the device itself. That is, you can't read the device in a flash reader and find some table that indicates how many partitions are on the device and where each partition begins and ends. There is only an undifferentiated sequence of blocks. This is a fundamental difference between MTD flash devices and devices such as disks or FTL devices such as MMC.

The partitioning of the flash device is therefore in the eyes of the beholder, that is, either U-Boot or the kernel, and the partitions are "created" when beholder runs. That's why you see the message Creating 3 MTD partitions. It reflects the fact that the flash partitions really only exist in the MTD system of the running kernel, not on the flash device itself.

This leads to a situation in which U-Boot and the kernel can have different definitions of the flash partitions, which is apparently what has happened in the case of the OP.

https://stackoverflow.com/questions/8585864/nand-partitioning-in-u-boot

File Systems

To format to UDF on Windows 7, use the command line format E: /FS:UDF

Great little blurb on file system options for embedded NAND flash: http://electronics.stackexchange.com/questions/60156/best-linux-filesystem-to-use-on-mmc-memory-chip

If your filesystem is read-only, use ext2. That is proven stable for several decades, is fast, efficient, supports ownership, supports permission bits and has a huge user base as every Linux box supports it. In other words it supports everything a decent Linux system requires. If read-only is not an option, your next best bet is ext3. Apart from all the properties that ext2 comes with, ext3 brings journaling. This means that every change on disk is only committed once it has actually been written to disk. Very stable, proven technology. A problem with ext3 is wear leveling. Ext4 improves on performance in several use cases, but comes with more CPU overhead. Most distributions today default to ext4. Apparently it reduces unnecessary writes, which is good for an SSD. Ext4 has a TRIM extension. Next in line it BTRFS. Don't go there. Although several distributions offer BTRFS or even default to it, it wasn't stable last time I tested it (H2 2012). You don't want to use a filesystem that hasn't proven itself under stress. Too many bugs are being fixed. Linux offers a wealth of filesystems, but the ones I mentioned above are the most common ones. Of course there is FAT32 (vfat), don't go there. It is old, it suffers from fragmentation and doesn't allow for ownership and file permissions. NTFS is closed source, don't even think about it. Yes it kinda works on Linux but the implementation is fully based on reverse engineering (because Microsoft doesn't release any technical details) and the Linux implementation is just not reliable. A JFFS2 needs to be entirely scanned on a mount, so mount time increases linearly with device size. This is caused by the fact that there is not some sort of tree structure to store files.

Flash file systems are different from regular disk file systems because they add wear levelling. JFFS2 is a common flash file system, but it is limited to 512MB drives so it's usually only used for small onboard flash chips rather than USB sticks or SD cards.

Handy tool for mounting a JFFS2 file system: http://wiki.emacinc.com/wiki/Mounting_JFFS2_Images_on_a_Linux_PC You can set up some RAM as a faux MTD device and simulate NAND flash: https://michlstechblog.info/blog/linux-create-multiple-partitions-in-an-virtual-mtd-device-created-by-nandsim/

UBIFS

UBIFS is an attempt to improve upon the shortcomings of JFFS2.
http://www.linux-mtd.infradead.org/doc/ubifs.html
http://www.sed.inf.u-szeged.hu/project/ubifs
One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash. Please, make sure you understand the differences between raw flash and, say, MMC flash before dealing with UBIFS.

UBIFS runs on top of UBI (Unsorted Block Images), which is an abstraction layer for MTD devices, i.e. it works on top of an MTD device. UBI is not a Flash Translation Layer (FTL), and it has nothing to do with FTL; UBI works with bare flashes, and it does not work with consumer flashes like MMC, RS-MMC, eMMC, SD, mini-SD, micro-SD, CompactFlash, MemoryStick, USB flash drive, etc; instead, UBI works with raw flash devices, which are mostly found in embedded devices like mobile phones, etc.

UBI also provides a block device that allows regular, block-oriented file systems to be mounted on top of an UBI volume. This is possible because UBI handles bad-blocks transparently.

mtd-utils is required for Linux UBI.

Flash Driver Write Example

Using the Cypress FTL and LLD as an example, the data length and ECC parity bit length are predetermined and hardcoded. The write function receives a chunk of data and first writes the data to the flash unit normally via the LLD. Then the data is sent to an ECC calculation function and the parity bits are determined. Then those are written with the RANDOM DATA INPUT Operation so you can access the specific location of the field. Likely you'll have padding bytes to make sure the combination of data and ECC length is extended out to a word boundary. Then final flash program confirmation is made.

Per Micron "Each NAND Flash page can accommodate four PC-sized, 512-byte sectors. The spare area of each page provides additional storage for ECC and other software information."

Further ECC Information

BCH is a common encoding used for flash ECC, and more efficient apparently than Hamming. Here is a discussion about handling erased (all ones) flash pages: http://lists.infradead.org/pipermail/linux-mtd/2013-October/049333.html