Reduce boot time with jffs2 and CM-X255

Hi,

I use a cm-x255 compulab card and I boot on the NAND flash with jffs2 filesystem.

My problem is the boot is too long.

My method to boot on the NAND flash is :

1) I boot on the cm-x225 via nfs.

2) I format the flash:

flash_eraseall -j /dev/mtd1

3) I mount the flash :

mount -t jffs2 /dev/mtdblock1 /mountpoint

4) I put the distribution of my system on the flash:

cp -r /Distribution/* /mountpoint

5) I unmount the flash :

umount /mountpoint

6) Finally, I boot on the cm-x255 board with the 2.6.18 kernel and options are :

- Boot options : root=/dev/mtdblock1 rootfstype=jffs2 ip=192.168.82.70:::255.255.255.0:arm:eth0

- Miscellaneous filesystems : Journalling Flash File System v2 (JFFS2) support

JFFS2 debugging verbosity à 0

JFFS2 write-buffering support

JFFS2 summary support (EXPERIMENTAL)

I would like to know what I'm missing or what I have to do to decrease boot time ?

Thanks for any suggestion or help.

Michel

Hi Michel,

could you be more specific?
The boot time, in a production environment, is the time that elapses from the board reset to the login prompt. How long is that time on your cm-x255?

Enrico

Excuse me for the lack of informations.

I use a CM-X255 with a NAND Flash of 512 Mo
where roughly 250 Mo are used (90 Mo for the native distribution provided by Compulab and 160 Mo for specific applications).

At the boot, there's a scanning of the MTD1 (4096 blocks) corresponding to the NAND Flash. This scanning takes 1mn20s. The full boot time, from a reset to the login prompt, takes 4mn.

I hope that these precisions can be useful.

Thanks for any help or suggestion.

Michel

Are you sure you enable "Summary support"? What's your kernel version? Newer JFFS2 is quicker.

If you aready use latest JFFS2 and summary is enabled, then I am afraid you do not have many options - may be improving HW?. 512 MiB is quite large NAND for JFFS2.

Also, if you are curious, read one of the first chapters of my old JFFS3 document about JFFS2 scalability, it may be helpful to realize JFFS2 issues.
http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf

Best regards,
Artem Bityutskiy (Битюцкий Артём)

At least in the 2.6.18 kernels, summary support is marked as EXPERIMENTAL. Is it stable enough to be used for production? (I don't know, just curious).

/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30

Well, we heavily utilize it, and I know some serious projects like OLPC where summary is utilized. So I would say it is stable enough.

Best regards,
Artem Bityutskiy (Битюцкий Артём)

I don't know if this helps, but I have noted that when mounting a flash partition which contains lots of erased blocks/sectors, that jffs2 after the mount has completed in the background (re-)erases the blocks and writes cleanmarkers to them (the logic of this is clearly explained in the JFFS2 documentation on the mtd home page). For NOR flash, this can be alleviated easily by instructing mkfs.jffs2 to add cleanmarkers to unused parts of the image. For NAND flash, the cleanmarkers are stored in the out-of-band (OOB) area, which is normally not part of an image; consequently, it is easier to leave it up to jffs2 on the target system to erase and write cleanmarkers, which takes time, or at least takes up system resources, causing other processes to run slower. Admittedly, NAND is faster than NOR, but then you've got quite a lot of empty flash too (250 MB).

I don't know what the solution is - one idea is that a program like nandwrite could be instructed to write cleanmarkers to the OOB of unused parts of a partition. Currently there is no support for this but it could be added.

Hm, sidetracking here a bit, I'm thinking a general erase + write image utility for NAND flash would be useful, given that bad block management gets a bit hairy when you write to NAND and the write fails - should the block be re-erased (not really part of a nand writing tool's job) and retried, or just marked as bad (because most likely the block had recently been erased by an erasing tool)? Having erase+write in the same tool would make it easier for the tool to manage this, and it could also write jffs2 cleanmarkers to the oob as part of the whole procedure.

Except for testing, most of the flash writing I come across is writing a complete image (usually jffs2, but also boot images) to a flash partition.

/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30

Just do not include empty eraseblocks to the image.

nandwrite -o ?

I would recommend to improve/re-work/upgrade nandwrite instead of a new tool.

Best regards,
Artem Bityutskiy (Битюцкий Артём)

Yes, but that assumes the image contains the cleanmarkers. Can mkfs.jffs2 create images with cleanmarkers in the oob? And wouldn't that conflict with mtd ecc usage, i.e. doesn't ecc information then also have to be in the image?

Yes I think that's probably the best route. I've been thinking about this for some time, but haven't really come to a conclusion about exactly what to include in such an upgrade. (I know I've posted some ideas earlier on the list; thanks for the responses btw).

/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30

Hello Michel,

I think that first of all this is a design problem. If you want smaller boot time, you need to figure out what exactly you need during the boot time and create minimalistic partitions. Anything else can be mounted later on. Moreover, for the stuff that is effectively read-only I would recommend using read-only filesystem such as cramfs with a read-only translation layer, like this one: http://lists.infradead.org/pipermail/linux-mtd/2006-December/016973.html.

Well, that all doesn't mean you shouldn't use SUMMARY for your JFFS2 filesystem. :)

Vitaly

First, I would like to thanks all of you for your help and I want to specify that I'm newbie with jffs2 filesystem.

I have tried 2 methods to use the Flash :

1)

I didn't create a jffs2 image with mkfs.jffs2 and I didn't use sumtool. I just copy my system on the flash mounted as specified in my first post.

In this case, the boot time is about 4 minutes !!!

2)

I have created an jffs2 filesystem image :

./mkfs.jffs2 -r ../Distribution/ -o name.jffs2

and used sumtool :

./sumtool -i ../name.jffs2 -o name_1.jffs2

In the kernel, I enable "Summary support"

I tried to load this image in the flash with :

dd if=name_1.jffs2 of=/dev/mtdblock1

But I had an error message :

« dd: writing to `/dev/mtdblock1': Input/output error »

So I loaded this image with :

cp -r name_1.jffs2 /dev/mtdblock1

But when I boot the system I had :

« summary node crc error... »

With this second method, it doesn't work !!!

All I have read on the web deals about jffs2 filesystem image, so is it necessary to create a filesystem image ?

What is the difference between filesystem image and a copy of the system ?

What I'm missing in the second method to explain my error ?

Thanks in advance for any suggestion or help.

Michel

*Michel LECONTE <mailto:[email protected]>*
Tél : 02 99 57 15 81
Fax : 02 99 57 16 17

	
*SACET*
2 rue Maupertuis
Campus de Ker Lann
35170 - BRUZ - FRANCE
www.sacet.com <http://www.sacet.com/>