> NAND flash -> MTD subsystem -> JFFS2
> All of this is provided by the MTD subsystem.
Again, thank you Hunyue. I understand now that there's a layer
between jffs2 and the NAND. This helps to explain some things.
> This tends to be the reason why the mkfs.jffs2 tool works on images and is
why it appears to be a little different from the other filesystems.
I understand that mkfs.jffs2 tool is typically used on a host system
to create a filesystem image for the target. I've noticed that there
are command line options for mkfs.jffs2 where you specify things like
the NAND page size, the erase block size and the cleanmarker size. I'm
assuming that you need to specify these things because the resultant
image is typically loaded onto the NAND through JTAG or a uboot
utilility so there's no mtd subsystem present to handle this for you,
It needs to be specified because on a NAND device, you can only erase in
discrete sizes. This means all files must start on a erase size block boundry
or you will have issues later on when the file is modified. This isn't seen
much on disk-centric file systems as they tend to have a common sector size;
whereas, on flash this can vary from part to part.
If I want to write a directory tree to NAND from the kernel through a
jffs2 mountpiont, I should be able to just extract a regular tarball
of the tree to the NAND, right?
> What rev of the board and is there any messages on the serial console when
the lockup happens?