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 @@ -46,7 +46,7 @@
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.
+Samsung's 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 @@ -59,19 +59,33 @@ 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, the latest nand driver code protects bad block information. It's safe to erase a +NAND flash with flash_erase or flash_eraseall.
++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 without needing any further formatting. This formatting +is also necessary before you copy a filesystem 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 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.
+The following is an example procedure for creating a jffs2 image, erasing flash, and writing flash:
+
+$ mkfs.jffs2 \
+ --eraseblock=128KiB \
+ --pad \
+ --output=image.jffs2 \
+ --compression-mode=priority \
+ --no-cleanmarkers \
+ --root=$ROOT_DIR
+
+$ flash_eraseall -j /dev/mtdX
+
+$ nandwrite /dev/mtdX image.jffs2
+
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. +
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 + 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 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 + +
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
+Yes, you can. The requirements are the same as for bootloaders.
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 +
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