First off, an mtd is a "memory technology device", so it's just "mtd. An "mtd device" is a pleonasm.
Unix traditionally only knew block devices and character devices. Character devices were things like keyboards or mice, that you could read current data from, but couldn't be seeked and didn't have a size. Block devices had a fixed size and could be seeked. They also happened to be organized in blocks of multiple bytes, usually 512.
Flash doesn't match the description of either block or character devices. They behave similar to block device, but have differences. For example, block devices don't destinguish between write and erase operations. Therefore, a special device type to match flash characteristics was created: mtd.
So mtd is neither a block nor a char device. There are translations to use them, as if they were. But those translations are nowhere near the original, just like translated chinese poems.
Mainly for NOR flash. As long as the flash is only read, it behaves just like normal memory. The read() function for NOR chips is essentially a memcpy(). For some purposes the extra memcpy() is a waste of time, so things can be optimized.
So the point() function does just that, it returns a pointer to the raw flash, so callers can operate directly on the flash.
But of course, things are a little more complicated than that. NOR flash chips can be in several different modes and only when in read mode will the above work. Therefore point() also locks the flash chip in addition to returning a pointer. And while locked, writes to the same flash chips have to wait. So callers have to call unpoint() soon after to release the chip again.
Not from a bare NAND chip. You need a glue logic around, which gives you memory access to the chip on bootup, like the DiskOnChip devices do. This will be a quite complex CPLD. An alternative is to use a small e.g. 1MB NOR Flash, which contains the boot code and maybe a compressed kernel image. Then you can use JFFS2 on NAND as your root filesystem
Some newer chips make the first page available for reading after power up. This could be helpful for starting a small 256/512/2048 byte bootcode. At the time of this writing there is no tested implementation of this.
Samsungs S3C2410 ARM based SOC-CPU provides a mechanism to boot from NAND flash.
No. The generic NAND driver supports 8/16 bit wide NAND Flash only. 32 bit NAND Flash can be built by using 2 or 4 chips and connect them to D0-7, D8-D15, D16-D23 and D24-D31 on the data bus. You can tie all corresponding control signals together. But you have to build a new nand16 or nand32 driver, which can be derived from the existing nand.c. Be aware, that the writebuffer size is 2 or 4 times as big as on 8 bit NAND. This mean's, if you flush the buffer to ensure, that your data are on disk, you may waste much more memory space than on 8 bit NAND. Another point is bad block handling. When a block on 1 chip is bad, the corresponding blocks on the other chips are lost too, as you present them as one big block to the filesystem driver. The JFFS2 code, which handles the writebuffer and the out of band (spare) area of NAND doesn't support 32 bit neither.
Yes, the latest nand driver code forces the protection of bad block information. It's safe to erase a NAND flash with erase(all) /dev/mtdX. It's recommended to use eraseall with -j or --jffs2 option set. This will write the cleanmarker to the out of band area. So you can mount the filesystem and no further formatting is needed. This formatting is also neccecary before you copy a fs-image to the chip.
Yes, as long as your chip does not contain bad blocks. Make sure, that the erasesize you set to mkfs.jffs2
is the same as the erasesize of your chip. Data will only be written with ECC, if your default settings for
oob-layout selection are set for JFFS2. For bad block aware copying, use nandwrite from mtd-utils.
nandwrite -j /dev/mtdX image
Yes, as long as your program is aware of bad blocks. Make sure to set the desired ECC layout by ioctl (MEMSETOOBSEL). A example for bad block handling and usage of ioctl (MEMOOBSEL) can be found in util/nandwrite.c
Recent changes to the NAND layer now make it possible to read/write across a block boundary.
Yes, if you use your bootloader to erase the FLASH chip and copy a filesystem image to it. For erase make sure, that you don't erase factory-marked bad blocks. They are marked in the 6th byte (offset 0x5) in the out of band area of the first page of a block. The block is bad, if any bit in this byte is zero. If you erase such a block, the bad block information is erased too and lost. Further use of this block will lead to erroneous results
For JFFS2 filesystems it's recommended to programm the JFFS2 erased marker into the out of band area of the first page in each erased block after erasing the block. Do not program it into the data area of the page !
For 256 byte pagesize devices program the following data into the out of band area:
| Offset | 0x06 | 0x07 |
| Data | 0x85 | 0x19 |
For 512 byte pagesize devices program the following data into the out of band area:
| Offset | 0x08 | 0x09 | 0x0a | 0x0b | 0x0c | 0x0d | 0x0e | 0x0f |
| Data | 0x85 | 0x19 | 0x03 | 0x20 | 0x08 | 0x00 | 0x00 | 0x00 |
If you copy a filesystem image to the chip, it's recommended to write it with ECC. You can use the ECC code in the nand driver to do this. If you have a bad block on your chip, just skip this block and copy the data to the next block. JFFS2 and other NAND flash aware filesystems handle this gap.
Yes, you can. The requirements are the same as for bootloaders
JFFS2 adopts the philosophy of keeping the user completely appraised of what is going on. This can catch out the unwary novice. The following messages can be moved to a higher log level once you are sure that they are benign.
Empty flash at 0xXXXXXXXX ends at 0xXXXXXXXX
This message is generated if a block of data is partially written. It is generally not a sign of any problem.
jffs2: Erase block size too small (XXKiB). Using virtual blocks size(XXKiB) instead
Output for larger NAND devices to reduce memory allocation.
jffs2: No clean, dirty _or_ erasable blocks to GC from! Where are they all?jffs2: Couldn't find erase block to garbage collect!
These two messages are generally output together. They are usually output on dismount and simply indicate that the garbage collector has nothing to do. This is more likely to be seen for filesystems which have few files or no activity.
JFFS2 images can not be loop mounted. The only way to manipulate them is by copying them into
a mtdram device and mounting the device with JFFS2
If you are desperate, then fix jffs2_dump to recreate the filesystem from the image. It's not hard. All the
basics are done already.
On NOR FLASH each write goes directly into the FLASH
On NAND FLASH and NOR ECC FLASH we have a writebuffer for writing only full pages to the chips.
There could be a loss of data, when the writebuffer is not flushed before power down. There are some
mechanisms to ensure, that the writebuffer is flushed. You can force the flush of the writebuffer by
using fsync() or sync() in your application.
JFFS2 has a timed flush of the write buffer, which forces the flush of the buffer to flash, if there are no
writes to the filesystem for more than about 5 seconds. The time depends on the cycletime of kupdated, which
can be adjusted via /proc/sys/vm/dirty_expire_centisecs.
When you unmount the filesystem the buffer is flushed too.
If the partition is being used as a root filesystem, which obviously cannot be dismounted, the filesystem should be remounted read only on shutdown. In the case of JFFS2 this will cause the garbage collector to flush its write buffers. Failure to do this may cause the filesystem to generate warnings regarding bad CRC. These are partially collected garbage blocks which will be rescheduled for garbage collection some time later. This kind of behaviour may also be observed after a system crash.
There are several possibilities to do so
For NOR FLASH there are no restrictions. For NAND FLASH please read the NAND FAQ section.
If an error occurs when writing to a page, JFFS2 will attempt recovery of the data. If the block contains nodes that have already been written to flash, the block is refiled onto the list of blocks that are bad but still in use (the bad_used_list). Then the write buffer itself is recovered. This takes into account any data that has been partially written to flash. Once the write buffer has been recovered, normal operation continues. Garbage collection is responsible for moving the valid nodes from the block that was refiled.
Once garbage collection has written all of the valid nodes to a different eraseblock, the block is moved to the erase pending list. From there JFFS2 will erase the eraseblock. If the erase failed, it is put on the erase pending list again for a retry. If the erase fails at the device level a total of three times, it is marked as bad in the OOB area and filed onto the bad_block_list. If the erase succeeds, a clean marker is written to the OOB area and the block is filed onto the free list. This is done because NAND flash can have non-permanent failures due to over-programing or write-disturb errors. A block erase clears these conditions.