Thank you very much Hunyue! With your explanation, I think I see
where I've been getting confused. It seems that the Linux community
uses the word "filesystem" in two ways. One for describing a protocol
for interfacing with a storage media (i.e. ext2 for talking with RAM,
jffs2 for talking with NOR or NAND flash, vfat for talking with
harddrives, etc). The other usage
of the word is for describing the directory tree for the operating
system. Tools like mkfs.jffs2 are used to make an image of a directory
tree that will later be extracted onto the media. They aren't used to
format or prepare the media, right?
There is only one meaning for filesystem. The differences is due to the nature
of the media. Onboard flash is non removeable and as such, it is useful to be
able to build filesystems (think of a software group working on a media
player) without having to do it on the hardware itself. 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.
On Linux, with JFFS2, things look like this:
NAND flash -> MTD subsystem -> JFFS2
Compare this with a hard drive or a flash that emulates a hard drive:
Drive -> Drive controller driver to present a block device -> ext2
In both cases, JFFS2 and ext2 are the filesystem; JFFS2 just happens to know a
bit more about the underlying media.
> The tools mkfs.jffs2, etc are for creating the filesystem image. To create
a
> blank filesystem on flash, (assuming all the support is in the kernel),
do:
> flash_unlock /dev/mtdN
> flash_eraseall /dev/mtdN
> mount -t FSTYPE /dev/mtdblockN /mnt
If I'm understanding correctly, the "-t jffs2" switch for mounting
tells the OS that when accessing this NAND media mountpoint, use the
jffs2 protocols for managing ECC, minimizing block erases, wear-
leveling the NAND blocks, marking and tracking bad blocks, etc.
Right?
No, it tells the OS to use the JFFS2 filesystem. JFFS2 is special in that it
assumes it'll be starting on a blank flash so there is no initial formating.
Check the man page for the meaning of the -t flag to mount for more details.
I'm still fuzzy on how the jffs2 protocol gets the necessary
information about the NAND from this simple mount statement. For
example, how does jffs2 know the size of the NAND page size, the
number of OOB bytes, the erase block size, etc? And why don't we have
to use fdisk on this NAND device to set it's type and to set up
partitions?
All of this is provided by the MTD subsystem.
The partitioning is handled by the MTD subsystem. It has default values
defined in the board file and if you enable the option, you can override the
sizes/layout with a kernel commandline.
JFFS2 determines all the details of the flash by querying the MTD subsystem,
the "flash driver".
I was able to compile the MTD-utils flash_unlock and flash_eraseall to
perform the steps listed and create a mountpoint to mtdblock4 of type
jffs2. I actually got a message the flash_unlock couldn't unlock the
block, but flash_eraseall seemed to work okay so I'm assuming that the
block was already unlocked by some previous process.
With the NAND mounted, I decided to copy over the various directories
from my rootfs (i.e. /bin, /etc, /lib, /include, and so forth) using
cp -R. I then rebooted into uboot and changed bootargs to
console=ttyS2,115200n8 root=/dev/mtdblock4 rw rootfstype=jffs2 and
bootcmd to 'mmcinit;fatload mmc 0 0x80300000 uImage;bootm 0x80300000'
and was able to boot up with the rootfs running from NAND. Very
exciting!
I'm finding however that after less than a half-hour, the system locks
up. Not sure why. I'm going to wipe everything clean and start over
to make sure I'm using xloader, uboot, kernel, and fs that are all
compatible. There's a chance I've mixed things here in my various
attempts with various builds.
What rev of the board and is there any messages on the serial console when the
lockup happens?
-- Hunyue
If someone sees something else that I've done wrong, please advise
me.
Thanks!
-Eric
>
>
>
>
>
>
>
> > Okay, I'm getting frustrated in my attempts to get a root filesystem
> > running on NAND. Maybe there are some experts who can point this
> > newbie in the right direction. I'm not talking about reading some
> > rootfs from NAND into RAM and then running an ext2-type fs on that
> > RAM...I'm talking about running a rootfs on the NAND.
>
> > Keep in mind that I'm really new to this Linux world, so I may have
> > some concepts really wrong, so let's make sure I've got the big
> > picture first...
>
> > As I understand it, NAND requires a special filesystem using either
> > jffs2, yaffs2, or ubifs, right? These filesystems handle the details
> > of optimizing/caching writes and erases so as to preserve and wear-
> > level the NAND because it has a finite number of erases before it
> > starts to die.
>
> Yes. It also handles bad block management on the NAND.
>
>
>
> > I'm assuming that to make a jffs2, yaffs2, or ubifs file systems that
> > you need a mkfs.jffs2, mkfs.yaffs2, or mkfs.ubifs utility, right? As
> > I understand it, these applications will format the NAND and prepare
> > it for use. You can then untar some rootfs directory tree on the
> > NAND, change the uboot bootargs to use the proper NAND partition as
> > the rootfs, and then boot the Beagleboard using this NAND partition as
> > your rootfs. Am I right so far?
>
> There are 2 basic ways of doing it. One way is to create a filesystem
image on
> the host and write it to the NAND with nandwrite. The other way is to
create
> a blank filesystem and add things to it like any other filesystem.
>
> The tools mkfs.jffs2, etc are for creating the filesystem image. To create
a
> blank filesystem on flash, (assuming all the support is in the kernel),
do:
> flash_unlock /dev/mtdN
> flash_eraseall /dev/mtdN
> mount -t FSTYPE /dev/mtdblockN /mnt
>
> where N is the partition number. Look at the boot log or /proc/mtd for a
list
> of partitions. Avoid 0 and 1 as those tend to be U-boot and X-Loader. The
> flash_unlock may be unnecessary as some U-boot/kernel combinations unlock
it
> on startup.
>
> FSTYPE is jffs2, yaffs, etc. JFFS2 requires the type to be specified at
each
> use. Yaffs seems to know how to autodetect it after the first time.
>
>
>
> > Has anyone got their Beagleboard running the rootfs from a NAND
> > partition? If so, can you share some details about how you did it?
>
> I had JFFS2 running start with a blank file system that slowly got
populated.
