Filesystem for NAND

Hi all,

As I have not been able to boot from mmc/sd since a little "accident", I am now going through the process of getting my beagleboard to boot linux from NAND flash.

These are the steps I have taken

1. Erase all flash !
2. Unbrick board using u-boot v2 to load u-boot v1 etc.
3. Try reading x-loader from mmc using fatload. Board hangs
4. Load x-loader via serial and write to nand.
5. Load u-boot v1 via serial and write to nand
6. Load uimage via serial and write to nand

So far, so good. But when it comes to getting a file system for NAND I confess to be stuck. I understand a jffs2 file system is required but I don't know how to go about building one of these for the beagleboard.

Any help would be much appreciated.

TIA

Bob

Robert Hibberdine wrote:

Hi all,

As I have not been able to boot from mmc/sd since a little "accident", I am now going through the process of getting my beagleboard to boot linux from NAND flash.

These are the steps I have taken

1. Erase all flash !
2. Unbrick board using u-boot v2 to load u-boot v1 etc.
3. Try reading x-loader from mmc using fatload. Board hangs
4. Load x-loader via serial and write to nand.
5. Load u-boot v1 via serial and write to nand
6. Load uimage via serial and write to nand

So far, so good. But when it comes to getting a file system for NAND I confess to be stuck. I understand a jffs2 file system is required but I don't know how to go about building one of these for the beagleboard.

What's the issue? Getting a root file system at all or jffs2 in particular?

To get a root fs, have a look to the file system images at [1] or koen's images [2].

To put root fs into NAND, the easiest way is to boot kernel, mount MMC card (with tar.gz image of root fs) and NAND root fs partition, erase NAND root fs partition from kernel using mtd utils and then just extract tar.gz root fs image from SD card to NAND fs partition. E.g. something like

flash_eraseall -j /dev/mtd4

mkdir -p /mnt/mmc
mkdir -p /mnt/nand

mount /dev/mmcblk0p1 /mnt/mmc/
mount -t jffs2 /dev/mtdblock4 /mnt/nand

cd /mnt/nand
tar xvfz /mnt/mmc/rootfs.tar.gz .

Does this work? If it works, would be nice if you could update [3]. Please note that writing jffs2 root fs with U-Boot like described in [4] often doesn't work because of some differences between U-Boot and kernel NAND/jffs2 handling.

Dirk

[1] http://code.google.com/p/beagleboard/wiki/BeagleSourceCode "8MB Ramdisk File System Image" or "File system Image with ALSA libraries"

[2] http://www.angstrom-distribution.org/demo/beagleboard/Angstrom-Beagleboard-demo-image-glibc-ipk-2008.1-test-20080911-beagleboard.rootfs.tar.bz2

[3] http://elinux.org/BeagleBoardNAND#Writing_file_system_with_kernel

[4] http://elinux.org/BeagleBoardNAND#Writing_file_system_with_U-Boot

Hi, Bob,

I am trying to figure that out too several days ago. I was trying to
write rootfs from google code project to NAND so I can have a known good
default configuration. That rootfs is ext2 instead of jffs2. It turns out
the type of file system might not be important.

Here is what I have done:

1. Calculate the rootfs nand write size: use rootfs size, rounded up to
128KB boundary.
2. Write the rootfs to NAND with commnad "nand write" to address 0x680000
3. change bootcmd environment variable to something like this:
bootcmd=nand read 0x80300000 0x280000 0x1e0000; nand read 0x81600000
0x680000 0x340000; bootm 0x80300000
4. change bootargs environment variable to something like this:
bootargs=console=ttyS2,115200n8 ramdisk_size=8192 root=/dev/ram0 rw
rootfstype=ext2 initrd=0x81600000,8M nohz=0ff

5. try boot, if working, saveenv, boot

regards,
Guo

It is, ext2 will destroy your flash in the blink of an eye

regards,

Koen

PS: a slow blink, though :slight_smile:

Thanks for your reply..

Dirk Behme wrote:

Robert Hibberdine wrote:
  

Hi all,

As I have not been able to boot from mmc/sd since a little "accident", I am now going through the process of getting my beagleboard to boot linux from NAND flash.

These are the steps I have taken

1. Erase all flash !
2. Unbrick board using u-boot v2 to load u-boot v1 etc.
3. Try reading x-loader from mmc using fatload. Board hangs
4. Load x-loader via serial and write to nand.
5. Load u-boot v1 via serial and write to nand
6. Load uimage via serial and write to nand

So far, so good. But when it comes to getting a file system for NAND I confess to be stuck. I understand a jffs2 file system is required but I don't know how to go about building one of these for the beagleboard.
    
What's the issue? Getting a root file system at all or jffs2 in particular?

Well, I just need a file system in NAND because at present my mmc doe not seem to work. And I was under the impression that for a NAND filesystem you needed jffs2...Can I use a ext3 filesystem in NAND?

To get a root fs, have a look to the file system images at [1] or koen's images [2].

To put root fs into NAND, the easiest way is to boot kernel, mount MMC card (with tar.gz image of root fs) and NAND root fs partition, erase NAND root fs partition from kernel using mtd utils and then just extract tar.gz root fs image from SD card to NAND fs partition. E.g. something like

Agreed that this would be the easiest way to do this BUT as I said I can't use my mmc/sd. So I need to loadb my filesystem and then write it to NAND. The question is how would I package up an such an ext3 filesystem so I could load it into the board and write it to nand... ahhhh wait a minute, a possible answer just came to me, I could package it as a RAM file system. Would this work??

Thanks again,
Bob

Ah. I should have read this reply first :-)..
So I _do_ need a jffs2 filesystem??

Bob

Koen Kooi wrote:

oops! That is so called "learn from mistakes" :slight_smile:

In my u-boot bootcmd, I load ext2 rootfs from NAND to memory, then in
bootargs, tell kernel to mount rootfs from memory instead of NAND. In this
use case, my NAND will be fine, right?

Another thing, I tried to use Angstrom distribution, since it has jffs2
rootfs and newer kernel than one in google code project (I am trying to
get DSP programming working). But about 50% the time, the kernel will lock up during boot. And minicom serial port console
seems also sluggish. Anyone else has this kind of trouble?

Thanks,
Guo

Thanks for this..
But I don't quite understand how you packaged the file system... as a
ramfs??
Also, your bootcmd. Is this just copying the rootfs from flash to ram
and then the kernel uses at ramfs at /dv/ram0?

Thanks again

Bob

Guo Tang wrote:

Thanks for this..
But I don't quite understand how you packaged the file system... as a
ramfs??

I just download the rootfs from
http://beagleboard.googlecode.com/files/rd-ext2-8M.bin

I don't know how it is packaged. I am newbie to Linux.

Also, your bootcmd. Is this just copying the rootfs from flash to ram
and then the kernel uses at ramfs at /dv/ram0?

Yes. It is /dev/ram0 not /dv/ram0.

Robert Hibberdine wrote:

Thanks for your reply..

Dirk Behme wrote:

Robert Hibberdine wrote:

Hi all,

As I have not been able to boot from mmc/sd since a little "accident", I am now going through the process of getting my beagleboard to boot linux from NAND flash.

These are the steps I have taken

1. Erase all flash !
2. Unbrick board using u-boot v2 to load u-boot v1 etc.
3. Try reading x-loader from mmc using fatload. Board hangs
4. Load x-loader via serial and write to nand.
5. Load u-boot v1 via serial and write to nand
6. Load uimage via serial and write to nand

So far, so good. But when it comes to getting a file system for NAND I confess to be stuck. I understand a jffs2 file system is required but I don't know how to go about building one of these for the beagleboard.
   
What's the issue? Getting a root file system at all or jffs2 in particular?

Well, I just need a file system in NAND because at present my mmc doe not seem to work. And I was under the impression that for a NAND filesystem you needed jffs2...Can I use a ext3 filesystem in NAND?

Answered by Koen :wink:

To get a root fs, have a look to the file system images at [1] or koen's images [2].

To put root fs into NAND, the easiest way is to boot kernel, mount MMC card (with tar.gz image of root fs) and NAND root fs partition, erase NAND root fs partition from kernel using mtd utils and then just extract tar.gz root fs image from SD card to NAND fs partition. E.g. something like

Agreed that this would be the easiest way to do this BUT as I said I can't use my mmc/sd.

Your MMC is totally dead? You can't even mount it from kernel? Note that it is a difference to boot from MMC (this is done by ROM bootloader which might (but shouldn't) fail) or to boot from NAND and then mount MMC from kernel.

So I need to loadb my filesystem and then write it to NAND.

I propose to not write root fs from U-Boot. Use kernel instead to write jffs2 root fs to NAND.

The question is how would I package up an such an ext3 filesystem so I could load it into the board and write it to nand... ahhhh wait a minute, a possible answer just came to me, I could package it as a RAM file system. Would this work??

Yes, if you can't boot from MMC and kernel can't mount MMC as root fs (are you really sure?), you can use e.g. Ramdisk [1] or NFS [2] (or USB stick?) as kernel's root fs medium and then write root fs from kernel.

Dirk

Btw: If you have some luck and some experts are there discussing something like this would be faster and easier at IRC

[1] http://wiki.davincidsp.com/index.php?title=Initrd#initramfs

[2] http://elinux.org/BeagleBoardFAQ#NFS

As already mentioned for NAND you want different kind of filesystems
as the technology is quite different.

The most common one is jffs2, but recently ubifs[1] has emerged and
it's superior by far [2].

I just posted the script I use to generate both jffs2 and ubifs images:
http://gist.github.com/11332

In order to boot from jffs2:
root=/dev/mtdblock4 rootfstype=jffs2

In order to boot from ubifs:
ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs

The problem is how to write the image to NAND, that's the step I still
haven't been able to do on the Beagle. These are my notes, but
probably won't work:

fatload mmc 0 82000000 rootfs-ubifs.bin
nand unlock
nand ecc sw
nand erase 680000 10000000
nand write 82000000 680000 F20000

fatload mmc 0 82000000 rootfs-jffs2.bin
nand unlock
nand ecc sw
nand erase 680000 F980000
nand write 82000000 680000 B80000

Best regards.

[1] http://www.linux-mtd.infradead.org/doc/ubifs.html
[2] http://lwn.net/Articles/276025/

I just posted the script I use to generate both jffs2 and ubifs images:http://gist.github.com/11332

Your script refers to /usr/sbin/mkfs.jffs2, so I'm assuming that you
have installed MTD Utils on your Beagleboard? Where did you get
them!? I'm curious if you somehow compiled MTD Utils using a cross-
compiler, or if you've found the MTD Utils already compiled for the
Beagleboard somewhere?

I've been trying to cross-compile MTD Utils using CodeSourcery but
keep encountering problems that I think are related to zlib or LZO
libraries. I'm a windows developer and I'm very new to embedded
development, so this world of cross-compiling in Linux is making me
crazy!

The problem is how to write the image to NAND, that's the step I still haven't been able to do on the Beagle.

If you really do have MTD utilities that work on the Beagleboard, then
I think you can boot all the way into the kernel using an ext2
filesystem on top of a ramdisk, then use use the flash_eraseall and
nandwrite MTD utilities to prepare the NAND and to copy the jffs2 file
system over to proper file system partition in NAND (/dev/mtd4 or /dev/
mtdblock4, not quite sure which to use for sure).

After you get the jffs2 file system copied onto the NAND partition, I
think you need to reboot and set up u-boot to use rootfstype-jffs2
root=/dev/mtdblock4.

Please understand that I haven't done any of this myself yet because
I've been stuck trying to compile MTD-utils, but these are things I've
read about in my quest to get a jffs2 root file system working on
NAND. I'm hoping someoine out there has actually had some success
with this and will chime in and let us know how this is supposed to be
done.

I just posted the script I use to generate both jffs2 and ubifs images:http://gist.github.com/11332

Felipe,
Where did you get the MTD Utils? I see that your script expects
mkfs.jffs2 to be in /usr/sbin. I've been trying to cross compile the
MTD Utils using CodeSourcery, but I've encountered numberous issues.
Did your kernel already include MTD Utils, or did you have to compile
them separately?

No, that was on my workstation.

The problem is how to write the image to NAND, that's the step I still haven't been able to do on the Beagle.

Have you tried using the MTD utils flash_eraseall -j and nandwrite?
I've seen this approach used by others when they are preparing and
writing the nand with the jffs2 file system. I've not been able to
try this myself because I'm still trying to get MTD utils compiled.

I think I tried that a long time ago.

I prefer to use u-boot to flash images for NAND, but since that's not
working perhaps I should try with mtd-utils too.

I think Koen's images have mtd-utils installed.

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.

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?

Has anyone got their Beagleboard running the rootfs from a NAND
partition? If so, can you share some details about how you did it?

Where did you get the mkfs.jffs2, mkfs.yaffs2, or mkfs.ubifs tools? I
think these are part of MTD utils, but I haven't had any success cross-
compiling these utils for the Beagleboard. I also tried loading the
Angstrom Distribution [1] but didn't find the MTD-utils included in
that image.

How do you make the rootfs directory tree to untar on the NAND
partition? I know you can take some nice rootfs tar file that someone
else made and untar it, but how did they make that file?

Please forgive a newbie's ignorant questions here. I think there's
something I'm just not getting here.

[1] http://www.angstrom-distribution.org/demo/beagleboard/ (I used
the Sept 20, 2008 release)

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.

Where did you get the mkfs.jffs2, mkfs.yaffs2, or mkfs.ubifs tools? I
think these are part of MTD utils, but I haven't had any success cross-
compiling these utils for the Beagleboard. I also tried loading the
Angstrom Distribution [1] but didn't find the MTD-utils included in
that image.

There is also a fstool utility that should do the equivalent functions.

-- Hunyue

Hello.

In an attempt to create rootfs on nand, I was able cross compile
busybox and generate the rootfs.jffs2.img using mtd-utils.

I cleared about 1MB of the memory from 0x680000 and used the services
of u-boot nand write utility to flash the same.

At the time of booting, the kernel would uncompress and then spew a
lot of non-Ascii chars on the console. In short, it would simply not
boot.

So a few questions:

1. Does the basic mvista kernel have mtd/jffs2/nand support? I picked
up the kernel from [git clone git://source.mvista.com/git/linux-omap-2.6.git
] and ran the default board defconfig scripts before compiling the
kernel. The same image boots up like a breeze with ramfs.

2. Is my bootargs correct?
bootargs console=ttyS2,115200n8 noinitrd root=/dev/mtdblock4
rootfstype=jffs2 rw rootdelay=1 nohz=off

Best regards,
SS

Shobhraj Singh wrote:

Hello.

In an attempt to create rootfs on nand, I was able cross compile
busybox and generate the rootfs.jffs2.img using mtd-utils.

I cleared about 1MB of the memory from 0x680000 and used the services
of u-boot nand write utility to flash the same.

You really should try the "The other way is to create a blank
filesystem and add things to it like any other filesystem." way
described below, i.e. using the kernel to write the fs. Using kernel
itself to write the fs it has to mount later as rootfs is known to be
easier than writing (probably incomatible) fs image with (probably
incomatible) U-boot.

Maybe

http://wiki.davincidsp.com/index.php?title=Filesystem_in_NOR_or_NAND

and

http://elinux.org/BeagleBoardNAND

can help you.

(ignore the "Writing file system with U-Boot" section, unfortunately
what you want, the "Writing file system with kernel" is still missing)

At the time of booting, the kernel would uncompress and then spew a
lot of non-Ascii chars on the console. In short, it would simply not
boot.

So a few questions:

1. Does the basic mvista

It's not a MontaVista kernel...

kernel have mtd/jffs2/nand support? I picked
up the kernel from [git clone git://source.mvista.com/git/linux-omap-2.6.git

... it is the community kernel hosted on a MontaVista server.

If you enable mtd/jffs2/nand in your kernel, it has mtd/jffs2/nand
support.

] and ran the default board defconfig scripts before compiling the
kernel. The same image boots up like a breeze with ramfs.

2. Is my bootargs correct?
bootargs console=ttyS2,115200n8 noinitrd root=/dev/mtdblock4
rootfstype=jffs2 rw rootdelay=1 nohz=off

Regarding rootfs seems fine. You should use rootwait instead of
rootdelay=1, though.

Dirk

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?

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?

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?

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
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.

If someone sees something else that I've done wrong, please advise
me.

Thanks!
-Eric

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.

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,
right?

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?

I got the lockup problem resolved.

Thanks!
-Eric