yaffs-request@lists.aleph1.co.uk дµÀ£º
Send yaffs mailing list submissions to
yaffs@lists.aleph1.co.uk

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
or, via email, send a message with subject or body 'help' to
yaffs-request@lists.aleph1.co.uk

You can reach the person managing the list at
yaffs-owner@lists.aleph1.co.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yaffs digest..."


Today's Topics:

1. Re: The nandflash chip seems to be making badblocks easily,
what can I do? (ian@brightstareng.com)
2. Saving checkpoint on remount read-only (Mikhail Ryleev)
3. Re: Saving checkpoint on remount read-only (Vitaly Wool)
4. Re: The nandflash chip seems to be making badblocks easily,
what can I do? (Vitaly Wool)


----------------------------------------------------------------------

Message: 1
Date: Fri, 9 Mar 2007 11:19:20 -0500
From: ian@brightstareng.com
Subject: Re: [Yaffs] The nandflash chip seems to be making badblocks
easily, what can I do?
To: yi zhang
Cc: yaffs@lists.aleph1.co.uk
Message-ID: <200703091119.20701.ian@brightstareng.com>
Content-Type: text/plain; charset="utf-8"

On Friday 09 March 2007 03:34, yi zhang wrote:
> My system was based on PXA270,consists of
> linux2.6.9 + intel patches + cramfs + yaffs,
> nandflash was samsung K9F1208, 64M. and this chip was mounted
> as 3 yaffs partitions, After a period of usage of this system,
> there may appear a lot of badblocks,we can see the badblock
> messages in the kernel booting messages, and sometime one of
> the 3 partitions could be damaged entirely. the partitons
> which marked as badblocks cannot be erased by the 'mkyaffs'
> tool.when this occurs, the worst way is that the nandflash
> chip could be changed to another nandflash chip.

Yi, see:

http://aleph1.co.uk/lurker/list/message/20070214.151530.af180dc0.en.html

Disable bad-block marking when bringing up new designs/code --
hack Yaffs to stop it marking blocks bad -- grep for
'MarkNANDBlockBad'.

There is probably an issue with reading/writing the
spare/oob/tags meta data. See the numerous posts on this
subject. Make sure NAND is working properly at the MTD level.

Make sure the problem of interfacing Yaffs with MTD's oob i/o is
working -- this may require tweaks to Yaffs and/or MTD depending
on the versions of both.

Charles/Wookey/Vitaly - Can we add some BOLD statements to the
Yaffs web pages that advise new users as to the issues, pitfalls
and best practices for bringing up new MTD based platforms.
Shouldn't we add a load option or config option to disable
bad-block marking. Perhaps add some test code that can be used
to verify i/o to the spare/oob area is working as needed. The
tags issue comes up weekly as the first (negative) experience
with new users. [yes, I know if I suggest something like this I
should code it too, but I freelance with Bright Star... blah
blah, I'm busy, excuse..., I have kids, excuse...]

-imcd



------------------------------

Message: 2
Date: Fri, 9 Mar 2007 19:57:00 -0800
From: "Mikhail Ryleev"
Subject: [Yaffs] Saving checkpoint on remount read-only
To: yaffs@lists.aleph1.co.uk
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Skipped content of type multipart/alternative-------------- next part --------------
--- old/yaffs_fs.c 2007-02-13 17:09:06.000000000 -0800
+++ new/yaffs_fs.c 2007-03-09 19:26:49.000000000 -0800
@@ -158,6 +158,8 @@
static int yaffs_write_super(struct super_block *sb);
#endif

+static int yaffs_remount_fs(struct super_block *, int *, char *);
+
#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,17))
static int yaffs_statfs(struct dentry *dentry, struct kstatfs *buf);
#elif (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,0))
@@ -250,6 +252,7 @@
.read_inode = yaffs_read_inode,
.put_inode = yaffs_put_inode,
.put_super = yaffs_put_super,
+ .remount_fs = yaffs_remount_fs,
.delete_inode = yaffs_delete_inode,
.clear_inode = yaffs_clear_inode,
.sync_fs = yaffs_sync_fs,
@@ -1414,6 +1417,35 @@

static LIST_HEAD(yaffs_dev_list);

+static int yaffs_remount_fs(struct super_block *sb, int *flags, char *data)
+{
+ yaffs_Device *dev = yaffs_SuperToDevice(sb);
+
+ if( *flags & MS_RDONLY ) {
+ struct mtd_info *mtd = yaffs_SuperToDevice(sb)->genericDevice;
+
+ T(YAFFS_TRACE_OS,
+ (KERN_DEBUG "yaffs_remount_fs: %s: RO\n", dev->name ));
+
+ yaffs_GrossLock(dev);
+
+ yaffs_FlushEntireDeviceCache(dev);
+
+ yaffs_CheckpointSave(dev);
+
+ if (mtd->sync)
+ mtd->sync(mtd);
+
+ yaffs_GrossUnlock(dev);
+ }
+ else {
+ T(YAFFS_TRACE_OS,
+ (KERN_DEBUG "yaffs_remount_fs: %s: RW\n", dev->name ));
+ }
+
+ return 0;
+}
+
static void yaffs_put_super(struct super_block *sb)
{
yaffs_Device *dev = yaffs_SuperToDevice(sb);
@@ -1423,12 +1455,13 @@
yaffs_GrossLock(dev);

yaffs_FlushEntireDeviceCache(dev);
-
+
+ yaffs_CheckpointSave(dev);
+
if (dev->putSuperFunc) {
dev->putSuperFunc(sb);
}
-
- yaffs_CheckpointSave(dev);
+
yaffs_Deinitialise(dev);

yaffs_GrossUnlock(dev);

------------------------------

Message: 3
Date: Sat, 10 Mar 2007 08:23:15 +0300
From: "Vitaly Wool"
Subject: Re: [Yaffs] Saving checkpoint on remount read-only
To: "Mikhail Ryleev"
Cc: yaffs@lists.aleph1.co.uk
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello Mikhail,

On 3/10/07, Mikhail Ryleev wrote:
> Hi, all
>
> The attached patch implements saving of yaffs checkpoint in case fs is
> remounted read-only. This allows the usage of checkpoint mechanizm even if,
> for some reason, the system can not cleanly unmount yaffs filesystem but can
> remount it read-only.
>
> It also fixes a problem with an implementation of yaffs_put_super that
> "puts" mtd device before saving yaffs checkpoint.

thanks, looks nice, but can you please split it in two patches: one
for read-only checkpointing and the other one to fix the calls order?

Thanks,
Vitaly



------------------------------

Message: 4
Date: Sat, 10 Mar 2007 08:30:51 +0300
From: "Vitaly Wool"
Subject: Re: [Yaffs] The nandflash chip seems to be making badblocks
easily, what can I do?
To: "yi zhang"
Cc: yaffs@lists.aleph1.co.uk
Message-ID:

Content-Type: text/plain; charset=GB2312; format=flowed

Yi,

On 3/9/07, yi zhang wrote:
> My system was based on PXA270£¬consists of
> linux2.6.9 + intel patches + cramfs +¡¡yaffs,
> nandflash was samsung K9F1208, 64M. and this chip was mounted as 3 yaffs
> partitions, After a period of usage of this system, there may appear a lot
> of badblocks,we can see the badblock messages in the kernel booting
> messages, and sometime one of the 3 partitions could be damaged entirely.
> the partitons which marked as badblocks cannot be erased by the 'mkyaffs'
> tool.when this occurs, the worst way is that the nandflash chip could be
> changed to another nandflash chip.

can you please try testing on a bare (i.e. freshly-erased) partition?
So, not to bring possible mkyaffs problems in -- to locate the kernel
problems first?
 
I'd expect that the problem is yaffs2 rewrites bad block marker in
OOB. Is this chip a 512b page or 2k page?

Vitaly

------------------------------
mkyaffs tool works well.because I can see the print messages of this tool,
and if the nandflash has no badblocks, after this formatting operation, the
/dev/mtdblock/n is empty, this state is good.
 
my nandchip is 512b page, and the fs is yaffs, NOT yaffs2.
 
could you give me more suggestion please?


ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä-3.5GÈÝÁ¿£¬20M¸½¼þ£¡