[PATCH] Fixup for Numonyx M29W128 chips

[PATCH] Fixup for Numonyx M29W128 chips

[Darius Augulis]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: patch-mtd-fixup-M29W128G --]
[-- Type: text/plain, Size: 1347 bytes --]

From: Darius Augulis <augulis.darius@gmail.com>

Prevent NUMONYX M29W128G memories from using write buffer,
because it doesn't work properly.

Signed-off-by: Darius Augulis <augulis.darius@gmail.com>

Index: linux-2.6.29/drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
--- linux-2.6.29.orig/drivers/mtd/chips/cfi_cmdset_0002.c
+++ linux-2.6.29/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -282,6 +282,16 @@ static void fixup_s29gl032n_sectors(stru
 	}
 }
 
+static void fixup_M29W128G_write_buffer(struct mtd_info *mtd, void *param)
+{
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+	if (cfi->cfiq->BufWriteTimeoutTyp) {
+		pr_warning("Don't use write buffer on ST flash M29W128G\n");
+		cfi->cfiq->BufWriteTimeoutTyp = 0;
+	}
+}
+
 static struct cfi_fixup cfi_fixup_table[] = {
 	{ CFI_MFR_ATMEL, CFI_ID_ANY, fixup_convert_atmel_pri, NULL },
 #ifdef AMD_BOOTLOC_BUG
@@ -298,6 +308,7 @@ static struct cfi_fixup cfi_fixup_table[
 	{ CFI_MFR_AMD, 0x1301, fixup_s29gl064n_sectors, NULL, },
 	{ CFI_MFR_AMD, 0x1a00, fixup_s29gl032n_sectors, NULL, },
 	{ CFI_MFR_AMD, 0x1a01, fixup_s29gl032n_sectors, NULL, },
+	{ CFI_MFR_ST,  0x227E, fixup_M29W128G_write_buffer, NULL, },
 #if !FORCE_WORD_WRITE
 	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers, NULL, },
 #endif

Re: [PATCH] Fixup for Numonyx M29W128 chips

[massimo cirillo]

Hi Darius,
what kind of failure did you experiment with M29W?

In my opinion, complete removal of the buffer program feature is not a
good solution,
because you are taking away an important feature of the device, that results in
a very high performance decrease.

Moreover, if you make the fix applicable to all devices with 0x227E device ID,
you are removing the same feature from other devices too, such as M29EW
that has a much bigger buffer thus resulting in a dramatic performance decrease
for this device.

Re: [PATCH] Fixup for Numonyx M29W128 chips

[Darius Augulis]

Hi,

I'm getting jffs2 errors after write to flash. I don't have the output 
log now, but the idea is that after write to flash, jffs2 does not find 
magic numbers anymore. File system is broken.
It's completely resolved when write buffers are not used. I could make 
patch which disables write buffer only for M29W128 chips. Anyway it's 
not working, one who needs more performace, is welcome to fix this in 
better way...

Darius.

massimo cirillo wrote:
> Hi Darius,
> what kind of failure did you experiment with M29W?
>
> In my opinion, complete removal of the buffer program feature is not a
> good solution,
> because you are taking away an important feature of the device, that results in
> a very high performance decrease.
>
> Moreover, if you make the fix applicable to all devices with 0x227E device ID,
> you are removing the same feature from other devices too, such as M29EW
> that has a much bigger buffer thus resulting in a dramatic performance decrease
> for this device.
>
>   

Re: [PATCH] Fixup for Numonyx M29W128 chips

[massimo cirillo]

Hi ,
We performed a complete validation test session on this device,
using jffs2 in the 2.6.26.1 release kernel, without any failures.
Could you specify the test case and the related failure?
What kernel version did you use? Did you apply any patch?
Thanks,
Massimo

2009/3/26 Darius Augulis <augulis.darius@gmail.com>:
> Hi,
>
> I'm getting jffs2 errors after write to flash. I don't have the output log
> now, but the idea is that after write to flash, jffs2 does not find magic
> numbers anymore. File system is broken.
> It's completely resolved when write buffers are not used. I could make patch
> which disables write buffer only for M29W128 chips. Anyway it's not working,
> one who needs more performace, is welcome to fix this in better way...
>
> Darius.
>
> massimo cirillo wrote:
>>
>> Hi Darius,
>> what kind of failure did you experiment with M29W?
>>
>> In my opinion, complete removal of the buffer program feature is not a
>> good solution,
>> because you are taking away an important feature of the device, that
>> results in
>> a very high performance decrease.
>>
>> Moreover, if you make the fix applicable to all devices with 0x227E device
>> ID,
>> you are removing the same feature from other devices too, such as M29EW
>> that has a much bigger buffer thus resulting in a dramatic performance
>> decrease
>> for this device.
>>
>>
>
>

Re: [PATCH] Fixup for Numonyx M29W128 chips

[Darius Augulis]

massimo cirillo wrote:
> Hi ,
> We performed a complete validation test session on this device,
> using jffs2 in the 2.6.26.1 release kernel, without any failures.
> Could you specify the test case and the related failure?
> What kernel version did you use? Did you apply any patch?
> Thanks,
> Massimo

Hi,

I use newest 2.6.29 kernel. The same was with 2.6.28.
My flash device is M29W128GL.
This is the sequence how writing to flash crashes:

1. Mount new and fresh (empty) jffs2 partition.
2. Create emtpy file ("touch test")
3. Echo short string to this file ("echo test > test")
4. Unmount partition (optional)
5. Reboot system
6. Mount the same jffs2 partition
7. Create another file ("touch test2")
8. Try to write something to this file ("echo test > test2")
9. Get this error: [42949481.440000] Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
10. Unmount and reboot
11. Get jffs2 errors and broken file system:

starting pid 37, tty '': '/bin/mount -t jffs2 /dev/mtdblock3 /tmp/cfg'
[42949376.530000] Empty flash at 0x0000415c ends at 0x00004180
[42949376.550000] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00004180: 0xe3db instead
[42949376.580000] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00004184: 0xe3db instead
[42949376.600000] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000419c: 0x2452 instead


There absolutely no problem if write buffer is disabled.
So I don't guess this is hardware error. May it be memory chip defect?

Darius.





> 
> 2009/3/26 Darius Augulis <augulis.darius@gmail.com>:
>> Hi,
>>
>> I'm getting jffs2 errors after write to flash. I don't have the output log
>> now, but the idea is that after write to flash, jffs2 does not find magic
>> numbers anymore. File system is broken.
>> It's completely resolved when write buffers are not used. I could make patch
>> which disables write buffer only for M29W128 chips. Anyway it's not working,
>> one who needs more performace, is welcome to fix this in better way...
>>
>> Darius.
>>
>> massimo cirillo wrote:
>>> Hi Darius,
>>> what kind of failure did you experiment with M29W?
>>>
>>> In my opinion, complete removal of the buffer program feature is not a
>>> good solution,
>>> because you are taking away an important feature of the device, that
>>> results in
>>> a very high performance decrease.
>>>
>>> Moreover, if you make the fix applicable to all devices with 0x227E device
>>> ID,
>>> you are removing the same feature from other devices too, such as M29EW
>>> that has a much bigger buffer thus resulting in a dramatic performance
>>> decrease
>>> for this device.
>>>
>>>
>>
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: Re: [PATCH] Fixup for Numonyx M29W128 chips

[Richard Retanubun]

Hi Darius,

I am tracking this patch that you submitted for the MTD mailing list and
I think I am missing the rest of the discussion between this

http://lists.infradead.org/pipermail/linux-mtd/2009-April/025089.html

and the patch being committed to the kernel.org mainline here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/chips/cfi_cmdset_0002.c;h=61ea833e09086e631024f298575678ff3f123ea3;hb=HEAD

I am planning to use this flash part on our design also and was wondering if you got a chance to
exercise the part as an mtdblock or mtdchar device and if the issue persist there or is is only limited to using
the part with jffs2? when the issue does happen, does it happen ALL the time or some of the time?

Sorry if I'm re-asking somethings that you have explained before, feel free to point me to the
proper discussion thread if I am.

Thanks in advance for your time,

- Richard Retanubun.

Re: [PATCH] Fixup for Numonyx M29W128 chips

[Darius Augulis]

Richard Retanubun wrote:
> Hi Darius,

Hi Richard,

> 
> I am tracking this patch that you submitted for the MTD mailing list and
> I think I am missing the rest of the discussion between this
> 
> http://lists.infradead.org/pipermail/linux-mtd/2009-April/025089.html
> 
> and the patch being committed to the kernel.org mainline here:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/chips/cfi_cmdset_0002.c;h=61ea833e09086e631024f298575678ff3f123ea3;hb=HEAD 
> 

actually there is nothing to miss because discussion was finished with 
04/01/2009 post from myself. Seem David found it ready to main line.
If you thing it is regression please mail to ML.

> 
> I am planning to use this flash part on our design also and was 
> wondering if you got a chance to
> exercise the part as an mtdblock or mtdchar device and if the issue 
> persist there or is is only limited to using
> the part with jffs2? when the issue does happen, does it happen ALL the 
> time or some of the time?

I used it only with jffs2. If write buffer is enabled, error occurs 
every time.

> 
> Sorry if I'm re-asking somethings that you have explained before, feel 
> free to point me to the
> proper discussion thread if I am.

I thing this ML is the only place where this patch was discussed.

> 
> Thanks in advance for your time,
> 
> - Richard Retanubun.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>