Hi Jon, I was interested to see the problem with YAFFS2 as we too are seeing the long mount times.
I took another approach to try to speed things up - I just assumed YAFFS was always slow... Step #1 make the partition smaller as well as the filesystem. I reduced the partition down to 256M and added another 256M partition. The effect of this is that the original mtd4 becomes mtd5 and I get a newer, smaller mtd3 & mtd4. Step #2 Use a ramdisk to display a 'splash screen' prior to mounting the root file system. Gives the user something on the display after about 20 seconds from power up. If there is no console then you don't know that the FLASH mount is what is slow ;-) I have had great fun with pivot_root & chroot to get this to work. I can post more details on how to do the above if anybody wants to know more. Regards Phil Q Phil Quiney, Senior Software Engineer Trinity Convergence Cambridge Business Park Cowley Road Cambridge CB4 0WZ, UK T: +44(0)1223-435536 F: +44(0)1223-435560 www.trinityconvergence.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Povey Sent: 24 July 2008 09:19 To: [email protected] Subject: YAFFS2 with checkpointing on DM355 Hooray, the list is back! :) Hello again everybody. I want to get YAFFS2 with checkpointing working on DM355. We are using the MV kernel which comes with a 2005 dated implementation of YAFFS2 which does not support checkpoints leading to very slow mount times (5.5s with my most trimmed-down filesystem so far). I got the latest YAFFS2 from CVS and it built, but does not work properly: it mounts an erased partition, you can write some files to it and unmount, but it fails to mount again: mount: wrong fs type, bad option, bad superblock on /dev/mtdblock3, or too many mounted file systems Also if I mount a clean mtd partition and try to untar about 200MB into it, half way through or so I start getting a lot of console messages about blocks being retired, and eventually "Allocator out!" messages and the partition apparently being full. Lots of blocks (seems like most) end up being marked bad and flash_erase won't erase them (I used a JTAG programmer to clear them). If anyone has faced and dealt with these issues then I'd like to hear from you. My guess from googling around is that it's to do with MTD layer incompatibility between MV and recent mainstream kernels so I was going to see how difficult it seemed to port the MTD layer back to MV. The other thought is, I wonder how much work would be needed to get Davinci git kernel working on DM355? iirc it's not yet working. For now I think I will be trying to make the root fs very very very small and living with the slow mount time :( -- Jon Povey, Design Engineer [EMAIL PROTECTED] | +44(0)1280 825983 Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
