From panto at intracom.gr  Tue May  4 05:18:18 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Tue, 04 May 2004 12:18:18 +0300
Subject: MTD util patch for NAND
Message-ID: <40975FDA.3080904@intracom.gr>

Hello

The following patch fixes nandwrite/eraseall to work correctly on NANDs with
the current mtd code.

There is a new option for nandwrite -a/--autoplace which places the OOB
bytes according to the autoplaced OOB of the current code.

Regards

Pantelis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd-util-nand.diff
Type: text/x-patch
Size: 3442 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040504/2cb4107c/attachment.bin 

From ngbmoreau at yahoo.com.au  Wed May  5 03:23:52 2004
From: ngbmoreau at yahoo.com.au (NGB)
Date: Wed,  5 May 2004 17:23:52 +1000
Subject: MTD problem
Message-ID: <1083741832.40989688de363@tiger.enttec>

Hi 

I'm trying to get MTD to find the flash chip (28F128J3) on a EP9301 dev board.
so I can access the redboot partitions.

Redboot says:

RAM: 0x00000000-0x02000000, 0x00041c88-0x01fdd000 available
FLASH: 0x60000000 - 0x61000000, 128 blocks of 0x00020000 bytes each.

So I configured the kernel (2.4.21-rmk1-cirrus-1-2-1) like this:

CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
CONFIG_MTD_OBSOLETE_CHIPS=y
CONFIG_MTD_AMDSTD=y
# CONFIG_MTD_SHARP is not set
CONFIG_MTD_JEDEC=y

#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=60000000
CONFIG_MTD_PHYSMAP_LEN=1000000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2

But MTD still can't find the chips

physmap flash device: 1000000 at 60000000
CFI: Found no Physically mapped flash device at location zero

Any ideas ?

Thanks

Nic



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



From dwmw2 at infradead.org  Wed May  5 08:57:49 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 May 2004 13:57:49 +0100
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <4098DF0D.1040703@intracom.gr>
References: <4098DF0D.1040703@intracom.gr>
Message-ID: <1083761869.26125.1382.camel@imladris.demon.co.uk>

On Wed, 2004-05-05 at 15:33 +0300, Pantelis Antoniou wrote:
> Hello there.
> 
> The following patch allows you to have any filesystem over NAND when mounted
> read only.

Please don't do it like this. Do it as a block device 'translation
layer' instead. See nftl/ftl/mtdblock for examples.

Can you join irc.freenode.net #mtd ?

-- 
dwmw2




From panto at intracom.gr  Wed May  5 08:33:17 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Wed, 05 May 2004 15:33:17 +0300
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
Message-ID: <4098DF0D.1040703@intracom.gr>

Hello there.

The following patch allows you to have any filesystem over NAND when mounted
read only.

The main drive for this was that I wanted to use CRAMFS over NAND flash 
since
it has a much higher compression ratio than JFFS2.

How it works is pretty simple.

It's pretty reasonable assumption that bad blocks are created only when
writting to NAND. So in the read-only case it is possible to skip over 
the bad
blocks and offer a bad-block free block device to the upper layers.
This allows us to utilize any filesystem when  read-only.

In order to speed the mount operation the bad block detection is 
performed lazilly.

Using the patch I was able to mount as read-only CRAMFS/JFFS2 partitions
which contained simulated bad-blocks.

Awaiting your comments...

Regards

Pantelis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ro-mtdblock.diff
Type: text/x-patch
Size: 18936 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040505/b0663a36/attachment.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ro-mtdblock.diffstat
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20040505/b0663a36/attachment.pl 

From panto at intracom.gr  Wed May  5 09:03:38 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Wed, 05 May 2004 16:03:38 +0300
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <1083761869.26125.1382.camel@imladris.demon.co.uk>
References: <4098DF0D.1040703@intracom.gr>
	<1083761869.26125.1382.camel@imladris.demon.co.uk>
Message-ID: <4098E62A.2050702@intracom.gr>

David Woodhouse wrote:

>On Wed, 2004-05-05 at 15:33 +0300, Pantelis Antoniou wrote:
>
>>Hello there.
>>
>>The following patch allows you to have any filesystem over NAND when mounted
>>read only.
>>
>
>Please don't do it like this. Do it as a block device 'translation
>layer' instead. See nftl/ftl/mtdblock for examples.
>
>Can you join irc.freenode.net #mtd ?
>
>
Sorry I'm at work now and IRC is blocked.

I'll try to get into it when I get home in about 2 hours.

I'll take a look at nftl/ftl/mtdblock.

The patch is very small and it works perfectly however.
What are your main objections?

Regards

Pantelis



From ddaney at avtrex.com  Wed May  5 11:26:16 2004
From: ddaney at avtrex.com (David Daney)
Date: Wed, 05 May 2004 08:26:16 -0700
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <4098DF0D.1040703@intracom.gr>
References: <4098DF0D.1040703@intracom.gr>
Message-ID: <40990798.9020703@avtrex.com>

Pantelis Antoniou wrote:

> Hello there.
>
> The following patch allows you to have any filesystem over NAND when 
> mounted
> read only.
>
> The main drive for this was that I wanted to use CRAMFS over NAND 
> flash since
> it has a much higher compression ratio than JFFS2.
>
> How it works is pretty simple.
>
> It's pretty reasonable assumption that bad blocks are created only when
> writting to NAND. So in the read-only case it is possible to skip over 
> the bad
> blocks and offer a bad-block free block device to the upper layers.
> This allows us to utilize any filesystem when  read-only.
>
> In order to speed the mount operation the bad block detection is 
> performed lazilly.
>
> Using the patch I was able to mount as read-only CRAMFS/JFFS2 partitions
> which contained simulated bad-blocks.
>
> Awaiting your comments...
>
> Regards
>
> Pantelis
>
After more thought, I am in the process of doing something similar.

However my changes are not quite done yet.  Roughly it goes like this:

Write a new read-only block driver that skips bad blocks and uses ECC 
reads.  This allows any read only file system to use it (ie cramfs).  
The bad block map is kept in the first non-bad page in the partition, 
when the driver is installed it reads the bad block map.

To write the data into the mtd, you have a special version of nandwrite 
that checks for bad blocks while writing the image and finally writes 
the bad block map.

One difference between my approach and yours is that no existing mtd 
driver code is touched, it is simply another mtd block driver.

David Daney.



From phillip at lougher.demon.co.uk  Wed May  5 13:44:59 2004
From: phillip at lougher.demon.co.uk (Phillip Lougher)
Date: Wed, 05 May 2004 18:44:59 +0100
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <40990798.9020703@avtrex.com>
References: <4098DF0D.1040703@intracom.gr> <40990798.9020703@avtrex.com>
Message-ID: <4099281B.1070206@lougher.demon.co.uk>

David Daney wrote:
> Pantelis Antoniou wrote:
>>
>> The following patch allows you to have any filesystem over NAND when 
>> mounted
>> read only.
> After more thought, I am in the process of doing something similar.
> 

I have also been doing something similar to this - though I put the bad 
block handling into Squashfs (another RO compressed filesystem).  It 
therefore seems as if all the possible approaches have been tried: 
putting the bad block code in the NAND layer; implementing a new RO 
block-driver; and putting the bad block code in the RO filesystem!  It 
definately seems as if there is a requirement for this in the main source.

Pantelis have you looked at Squashfs?  This filesystem gives much better 
compression than CRAMFS.

Phillip




From ddaney at avtrex.com  Wed May  5 15:07:40 2004
From: ddaney at avtrex.com (David Daney)
Date: Wed, 05 May 2004 12:07:40 -0700
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <4099281B.1070206@lougher.demon.co.uk>
References: <4098DF0D.1040703@intracom.gr> <40990798.9020703@avtrex.com>
	<4099281B.1070206@lougher.demon.co.uk>
Message-ID: <40993B7C.1010607@avtrex.com>

Phillip Lougher wrote:

> David Daney wrote:
>
>> Pantelis Antoniou wrote:
>>
>>>
>>> The following patch allows you to have any filesystem over NAND when 
>>> mounted
>>> read only.
>>
>> After more thought, I am in the process of doing something similar.
>>
>
> I have also been doing something similar to this - though I put the 
> bad block handling into Squashfs (another RO compressed filesystem).  
> It therefore seems as if all the possible approaches have been tried: 
> putting the bad block code in the NAND layer; implementing a new RO 
> block-driver; and putting the bad block code in the RO filesystem!  It 
> definately seems as if there is a requirement for this in the main 
> source.
>
> Pantelis have you looked at Squashfs?  This filesystem gives much 
> better compression than CRAMFS.

It seems that if people want to use more than one type of RO filesystem, 
that putting the badblock handling in the block driver instead of every 
filesystem makes more sense.

David Daney.



From panto at intracom.gr  Thu May  6 03:12:58 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Thu, 06 May 2004 10:12:58 +0300
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <4099281B.1070206@lougher.demon.co.uk>
References: <4098DF0D.1040703@intracom.gr> <40990798.9020703@avtrex.com>
	<4099281B.1070206@lougher.demon.co.uk>
Message-ID: <4099E57A.7020108@intracom.gr>

Phillip Lougher wrote:

> David Daney wrote:
>
>> Pantelis Antoniou wrote:
>>
>>>
>>> The following patch allows you to have any filesystem over NAND when 
>>> mounted
>>> read only.
>>
>> After more thought, I am in the process of doing something similar.
>>
>
> I have also been doing something similar to this - though I put the 
> bad block handling into Squashfs (another RO compressed filesystem).  
> It therefore seems as if all the possible approaches have been tried: 
> putting the bad block code in the NAND layer; implementing a new RO 
> block-driver; and putting the bad block code in the RO filesystem!  It 
> definately seems as if there is a requirement for this in the main 
> source.
>
> Pantelis have you looked at Squashfs?  This filesystem gives much 
> better compression than CRAMFS.
>
I've taken a look at squashfs. It does seems nicer than CRAMFS.

My main problem is not that it's not in the kernel proper, but it's not 
in by bootloader too.
If you took a look at u-boot and implemented squashfs support I would 
probably switch.

> Phillip
>
>
>
>
Regards

Pantelis



From panto at intracom.gr  Thu May  6 03:20:25 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Thu, 06 May 2004 10:20:25 +0300
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
References: <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
Message-ID: <4099E739.4070803@intracom.gr>

Srinivasu.Vaduguri at nokia.com wrote:

>>It's pretty reasonable assumption that bad blocks are created only when
>>writting to NAND. So in the read-only case it is possible to skip over 
>>the bad
>>blocks and offer a bad-block free block device to the upper layers.
>>This allows us to utilize any filesystem when  read-only.
>>    
>>
>
>I had seen in the past that there can be bit errors (more than one bit) when we do 
>multiple reads (probably many) on the same block. So we will read corrupted data from NAND flash and we will not be able to decompress the data when using the CRAMFS. If we erase the block and rewrite the data, it works fine. This is my experience with a samsung NAND flash. 
>
>So using this above logic how will we detect if there are more than one bit errors while reading. Can we afford to rewrite the cramfs image again onto the NAND flash ?
>
>Please tell me if I got this problem because of any obvious mistake.
>
>
Hmm, that's the first time I've heard about this problem.

But if you have read errors, how can you be sure that you will be able 
to read the
block and write it somewhere else?

Maybe you can do something when writting your filesystem image when you 
detect
a simple bit error you can immediately mark the block bad.

How many times have you written the block in order for something like 
this to occur?

It seems to me that when you have a read only partition the solution is 
to be
carefull when writting your filesystem image.
First you avoid the bad block altogether, and secondly you always bit verify
the block. If the verify fails you immediately mark the block as bad and 
move
on.

I don't think that nandwrite does it though.

>regards,
>Srini
>
>
>
>
>
>
Regards

Pantelis



From tglx at linutronix.de  Thu May  6 04:02:25 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 6 May 2004 10:02:25 +0200
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <4099E739.4070803@intracom.gr>
References: <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
	<4099E739.4070803@intracom.gr>
Message-ID: <200405061002.25973.tglx@linutronix.de>

On Thursday 06 May 2004 09:20, Pantelis Antoniou wrote:
> Maybe you can do something when writting your filesystem image when you
> detect
> a simple bit error you can immediately mark the block bad.
>
> How many times have you written the block in order for something like
> this to occur?
>
> It seems to me that when you have a read only partition the solution is
> to be
> carefull when writting your filesystem image.
> First you avoid the bad block altogether, and secondly you always bit
> verify the block. If the verify fails you immediately mark the block as bad
> and move
> on.
>
> I don't think that nandwrite does it though.

No it doesnt. This could be fixed easily.

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de



From panto at intracom.gr  Thu May  6 05:39:01 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Thu, 06 May 2004 12:39:01 +0300
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
References: <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
Message-ID: <409A07B5.5050004@intracom.gr>

Srinivasu.Vaduguri at nokia.com wrote:

>>But if you have read errors, how can you be sure that you will be able 
>>to read the
>>block and write it somewhere else?
>>
>
>>Maybe you can do something when writting your filesystem image when you 
>>detect
>>a simple bit error you can immediately mark the block bad.
>>
>
>>How many times have you written the block in order for something like 
>>this to occur?
>>
>
>I haven't counted the number of times. But I remember reading some information,
>that even on multiple reads we do get bit errors and it is a symptom that the block
>slowly becoming bad after some time.
>
>
This is most disturbing if true.
Could you please hunt it down and sent me a link?

>>It seems to me that when you have a read only partition the solution is 
>>to be
>>carefull when writting your filesystem image.
>>First you avoid the bad block altogether, and secondly you always bit verify
>>the block. If the verify fails you immediately mark the block as bad and 
>>move on.
>>
>
>>I don't think that nandwrite does it though.
>>
>
>Yes, If verify fails we have to mark it bad. 
>
>But what I feel is, a read-only filesystem like cramfs is not that reliable on NAND flash.
>We have to detect a bad block early.
>
>
If the device slowly degrades when just read it's a major problem IMHO.
We could do borderline block migration before all is lost.

However I don't think that the problem is that bad.

I believe that this behaviour only occurs on heavily written blocks.
When you have a partition that is read-only by definition you're going
to write to it very few times it's very unlikely that you will run into
this problem.

I'm not familiar with JFFS2. What do we do when something like this
happens?

>Please comment if I am not right.
>
I would comment even if you were wrong ;)

>
>regards,
>Srini
>
>
>
>
>
>
>
Regards

Pantelis



From tglx at linutronix.de  Thu May  6 05:48:24 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 6 May 2004 11:48:24 +0200
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
References: <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
Message-ID: <200405061148.24573.tglx@linutronix.de>

On Thursday 06 May 2004 11:30, Srinivasu.Vaduguri at nokia.com wrote:
> >
> >How many times have you written the block in order for something like
> >this to occur?
>
> I haven't counted the number of times. But I remember reading some
> information, that even on multiple reads we do get bit errors and it is a
> symptom that the block slowly becoming bad after some time.

Hmm. Never seen this. I have some read only paritions which are accessed in 
stress testing and I never have seen, that a block gets bad due to reading.

> But what I feel is, a read-only filesystem like cramfs is not that reliable
> on NAND flash. We have to detect a bad block early.

Yep, but you can only detect it while writing / erasing.

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de



From panto at intracom.gr  Thu May  6 05:45:17 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Thu, 06 May 2004 12:45:17 +0300
Subject: [patch] Allow any filesystem on MTD Nand when Read Only
In-Reply-To: <200405061148.24573.tglx@linutronix.de>
References: <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
	<200405061148.24573.tglx@linutronix.de>
Message-ID: <409A092D.1060505@intracom.gr>

Thomas Gleixner wrote:

>On Thursday 06 May 2004 11:30, Srinivasu.Vaduguri at nokia.com wrote:
>
>>>How many times have you written the block in order for something like
>>>this to occur?
>>>
>>I haven't counted the number of times. But I remember reading some
>>information, that even on multiple reads we do get bit errors and it is a
>>symptom that the block slowly becoming bad after some time.
>>
>
>Hmm. Never seen this. I have some read only paritions which are accessed in 
>stress testing and I never have seen, that a block gets bad due to reading.
>
>
>>But what I feel is, a read-only filesystem like cramfs is not that reliable
>>on NAND flash. We have to detect a bad block early.
>>
>
>Yep, but you can only detect it while writing / erasing.
>
>
Actually when using ECC you *CAN* detect a single bit error.
You could use this information as a trigger to migrate the block
and then mark it bad immediately.

However it better be only one bit that flipped because if more
bits are gone you're screwed.

Regards

Pantelis




From panto at intracom.gr  Thu May  6 03:07:31 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Thu, 06 May 2004 10:07:31 +0300
Subject: [PATCH] Any RO filesystem on NAND
Message-ID: <4099E433.6050604@intracom.gr>

Hello.

The following patch implements any RO filesystem on MTD devices like
NANDs with bad blocks.

It is a modification for the mtd-block device when the partition/device 
is read only.

Regards

Pantelis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: block_ro.diff
Type: text/x-patch
Size: 3385 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040506/3ad0a3d3/attachment.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: block_ro.diffstat
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20040506/3ad0a3d3/attachment.pl 

From oyvind.harboe at zylin.com  Thu May  6 03:22:05 2004
From: oyvind.harboe at zylin.com (=?ISO-8859-1?Q?=D8yvind?= Harboe)
Date: Thu, 06 May 2004 09:22:05 +0200
Subject: fix for small jffs2 disks(resend)
Message-ID: <1083828124.24504.11.camel@famine>

With this patch, it is possible to write to small (e.g. single sector)
flash disks.

Single sector flash disks are useful for writing configuration data that
never change, e.g. in embedded devices for serial numbers, hardware
configuration, feature selection and the like.

It has been applied to the eCos repository. To read more:

http://ecos.sourceware.org/ml/ecos-patches/2004-04/msg00043.html

-- 

?yvind Harboe
http://www.zylin.com


-------------- next part --------------
? smalljffs2.txt
Index: build.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/build.c,v
retrieving revision 1.55
diff -w -u -r1.55 build.c
--- build.c	28 Oct 2003 17:02:44 -0000	1.55
+++ build.c	29 Apr 2004 07:35:07 -0000
@@ -259,6 +259,14 @@
 
 	c->resv_blocks_write = c->resv_blocks_deletion + (size / c->sector_size);
 
+	// If the flash disk is smaller than resv_blocks_write, then we 
+	// allow writing to the disk anyway. The flash disk is then most likely
+	// being used as write once - read many medimum, e.g. configuration of 
+	// static paramters.
+	if (c->resv_blocks_write * c->sector_size > c->flash_size) {
+	  c->resv_blocks_write = 0; 
+	}
+
 	/* When do we let the GC thread run in the background */
 
 	c->resv_blocks_gctrigger = c->resv_blocks_write + 1;

From panto at intracom.gr  Thu May  6 03:10:20 2004
From: panto at intracom.gr (Pantelis Antoniou)
Date: Thu, 06 May 2004 10:10:20 +0300
Subject: [PATCH] Various fixes for NAND.
Message-ID: <4099E4DC.6030401@intracom.gr>

Hello

The following patch does two things.

1. Adds an erase_shift member to the nand_chip structure
   so that we can avoid multiplications and divisions.

2. Makes the autoob the default oobinfo so that when no access
   from user space is made to fill it, it doesn't default to no ECC.

Regards

Pantelis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: various.diff
Type: text/x-patch
Size: 2713 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040506/f9c14c85/attachment.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: various.diffstat
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20040506/f9c14c85/attachment.pl 

From Paul.Chitescu at IMC-Group.org  Thu May  6 12:19:27 2004
From: Paul.Chitescu at IMC-Group.org (Paul Chitescu)
Date: Thu, 6 May 2004 19:19:27 +0300
Subject: Patch: change in debug levels
Message-ID: <04050619192700.21912@S40WS4>

I hope this will help people to keep only usefull information displayed.

The patches are moving the informative MTD_open and MTD_close to MTD level 2, 
MTD_read, MTD_write and MTD_ioctl to MTD level 3; in JFFS2 many debug info 
messages were moved from level D1 to level D2.

Paul Chitescu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd+jffs2_message_levels.patch.gz
Type: application/x-gzip
Size: 6917 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040506/31b47c46/attachment.gz 

From GECGWS01/GEC%GEC at gec-tokyo.co.jp  Thu May  6 20:58:03 2004
From: GECGWS01/GEC%GEC at gec-tokyo.co.jp (GECGWS01/GEC%GEC at gec-tokyo.co.jp)
Date: Fri, 7 May 2004 09:58:03 +0900
Subject: Security Alert - InterScan for Lotus Notes
Message-ID: <OFDC6091BC.DED9D2AD-ON49256E8D.000550A4@gec-tokyo.co.jp>

InterScan has detected a virus during a real-time scan of the e-mail
traffic.

Date:        5/7/2004 9:58:3
Subject:   Mail Delivery (failure chyekn at gec-tokyo.co.jp)
From:       <linux-mtd at lists.infradead.org>
To:            chyekn at gec-tokyo.co.jp

Virus:        WORM_NETSKY.P
File:           message.scr
Action:      Uncleanable quarantine
Event:       Virus Scan





From bbick at ix.netcom.com  Thu May  6 21:49:49 2004
From: bbick at ix.netcom.com (Burt Bicksler)
Date: Thu, 06 May 2004 21:49:49 -0400
Subject: mkfs.jffs2 question
Message-ID: <1083894588.2408.30.camel@linux.local>

Hi,

I've just started working with JFFS2 and I have a couple of questions. 
First some details:

Kernel 2.4.25 running on AMD Au1000 based system with AMD Flash chip.

Using latest zlib from the zlib site.  Currently building mkfs.jffs2 on
SuSE 8.2 (Intel) platform.  Other tools (e.g. fcp) built cross-compiled
for mips32 (little endian).

MTD tools that I've tried:

Snapshot from 'snapgear' mkfs.jffs2 version 1.2 according to the source
file.

This one seems to build a JFFS2 file system that I can boot and access
with no problems.  I fixed problems getting it to build / link with 
the latest zlib version.

The one issue I see with this build is that even though I have specified
a devices file and I can see the device nodes when running jffs2dump on
the created image file, when I mount the file system from Flash the /dev
directory is empty!  

The only thing that spit out during the creation of the file system was
a message about /dev not having a parent directory so it was being 
skipped. But the /dev directory (and the node files from the devices.txt
 file WERE in the resulting image file as mentioned above).

It's probably something that I'm missing on the command line or in the 
file (but I just copied and tweaked the example from the util 
directory).

The other snapshot that I'm working with is the one from 04/30/2004. 
The mkfs.jffs2 version from source code is 1.40.

So far I haven't been able to create a JFFS2 file system that I can boot
 or mount with mkfs.jffs2 built from this snapshot.

Also, mkfs.jffs2 from this snapshot also whines about the /dev directory
not having a parent when building the image.  And the final difference
 is that the created image is nearly twice the size of that built with
 the mkfs.jffs2 from the older snapshot.

I'm using the same current zlib library in both cases, and tweaked the
 source so that it will build/link with zlib.

I suspect that part of the issue with the latest snapshot build may be
 that I'm still running with the older JFFS2 support that is part of the
 2.4.25 Kernel.

My questions:
1) Is there a note somewhere that I've missed saying what snapshots are
reasonably stable so that I know which one to work with for a 
semi-production release?

2) Has anyone else had a similar issue with the 04/30/2004 snapshot as 
far as the created image not mounting and being much larger than that 
created with older snapshots?

I've looked back through the archives and so far have not been able to 
locate anything related to the latest snapshot as applies to what I'm 
seeing.

Thanks,
Burt






From simon at baydel.com  Fri May  7 09:42:05 2004
From: simon at baydel.com (Simon Haynes)
Date: Fri, 7 May 2004 14:42:05 +0100
Subject: wbuf flush or remount ro 
Message-ID: <C98EE3515623@baydel.com>

David,

Just to recap 

It seems that the latest jffs2 CVS code does not flush wbuf when the 
filesystem is remounted read only. This can cause a gc operation to be 
abnormally terminated an error messages are generated on remount.

A while ago you suggested I do something like this. See attached 

I don't really know how to create a patch file so here is a diff and a patch.
If the patch is not correct would you please enlighten me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fs.patch
Type: text/x-diff
Size: 818 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040507/d81e7a8e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fs.diff
Type: text/x-diff
Size: 901 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040507/d81e7a8e/attachment-0001.bin 

From andreesje_werk at yahoo.com  Sun May  9 15:26:51 2004
From: andreesje_werk at yahoo.com (Andre Sodermans)
Date: Sun, 9 May 2004 12:26:51 -0700 (PDT)
Subject: diskonchip2000 support in 2.4.22
Message-ID: <20040509192651.76331.qmail@web41502.mail.yahoo.com>

hello all,
I can't access my diskonchip2000 partitions from
linux. I have linuxmz 2.4.18 installed on it and it
boots fine from diskonchip. 

The kernel I built for LFS5.0 is based on 2.4.22. 
I compiled the kernel with:
CONFIG_MTD = m
CONFIG_MTD_CHAR = m
CONFIG_NFTL = m

Running modprobe docprobe, I get:

DiskOnChip Millennium found at address: 0xD000
no flash chips recognized

It is actually a diskonchip2000.
There is no entry in /proc/mtd.

After I installed the kernel I noticed that I was
missing the /dev/msys/fla* so I created those. Also
the /dev/nftl* were missing, so I downloaded the
latest mtd snapshot and ran the MAKEDEV script.

I tried to mount -t ext2 /dev/msys/fla1 /mnt/doc -
result:
mount: /dev/msys/fla1 is not a valid block device

I tried to mount -t ext2 /dev/nftla
mount: /dev/nftla1: unknown device


Did I miss something?


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


From jonschl at umd.umich.edu  Sun May  9 15:41:05 2004
From: jonschl at umd.umich.edu (Jonathan M. Schlueter)
Date: Sun, 9 May 2004 15:41:05 -0400 (EDT)
Subject: diskonchip2000 support in 2.4.22
In-Reply-To: <20040509192651.76331.qmail@web41502.mail.yahoo.com>
References: <20040509192651.76331.qmail@web41502.mail.yahoo.com>
Message-ID: <Pine.GSO.4.58.0405091537500.27031@login1>


On Sun, 9 May 2004, Andre Sodermans wrote:

> hello all,
> I can't access my diskonchip2000 partitions from
> linux. I have linuxmz 2.4.18 installed on it and it
> boots fine from diskonchip.
>
> The kernel I built for LFS5.0 is based on 2.4.22.
> I compiled the kernel with:
> CONFIG_MTD = m
> CONFIG_MTD_CHAR = m
> CONFIG_NFTL = m
>
> Running modprobe docprobe, I get:
>
> DiskOnChip Millennium found at address: 0xD000
> no flash chips recognized
>
> It is actually a diskonchip2000.
> There is no entry in /proc/mtd.

Which driver are you using?

> After I installed the kernel I noticed that I was
> missing the /dev/msys/fla* so I created those. Also
> the /dev/nftl* were missing, so I downloaded the
> latest mtd snapshot and ran the MAKEDEV script.

/dev/msys/fla* are the dev files from M-Sys's custom driver

/dev/nftla  are the dev files for the mtd subsystem (this list)

They are two seperate and different methods of accessing the DiskonChip


> I tried to mount -t ext2 /dev/msys/fla1 /mnt/doc -
> result:
> mount: /dev/msys/fla1 is not a valid block device
>
> I tried to mount -t ext2 /dev/nftla
> mount: /dev/nftla1: unknown device
>
>
> Did I miss something?
>



Jon Schlueter


From andreesje_werk at yahoo.com  Sun May  9 16:32:12 2004
From: andreesje_werk at yahoo.com (Andre Sodermans)
Date: Sun, 9 May 2004 13:32:12 -0700 (PDT)
Subject: diskonchip2000 support in 2.4.22
In-Reply-To: <Pine.GSO.4.58.0405091537500.27031@login1>
Message-ID: <20040509203212.5193.qmail@web41505.mail.yahoo.com>

> > hello all,
> > I can't access my diskonchip2000 partitions from
> > linux. I have linuxmz 2.4.18 installed on it and
> it
> > boots fine from diskonchip.
> >
> > The kernel I built for LFS5.0 is based on 2.4.22.
> > I compiled the kernel with:
> > CONFIG_MTD = m
> > CONFIG_MTD_CHAR = m
> > CONFIG_NFTL = m
> >
> > Running modprobe docprobe, I get:
> >
> > DiskOnChip Millennium found at address: 0xD000
> > no flash chips recognized
> >
> > It is actually a diskonchip2000.
> > There is no entry in /proc/mtd.
> 
> Which driver are you using?

the one from the unpatched 2.4.22 kernel. I actually
forgot to mention the following config flags that I
used on my most recent kernel:
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCPROBE_ADDRESS=0
CONFIG_MTD_NAND_IDS=m

I then ran:
modprobe -a doc2000 nftl mtdchar
modprobe -a docprobe

I'm actually now building another kernel with the
latest mtd patch, just to be sure.

> 
> > After I installed the kernel I noticed that I was
> > missing the /dev/msys/fla* so I created those.
> Also
> > the /dev/nftl* were missing, so I downloaded the
> > latest mtd snapshot and ran the MAKEDEV script.
> 
> /dev/msys/fla* are the dev files from M-Sys's custom
> driver
> 
> /dev/nftla  are the dev files for the mtd subsystem
> (this list)
> 
> They are two seperate and different methods of
> accessing the DiskonChip
> 

Ok, I was being desperate, I meant to just use the one
from the kernel since the one from mtd is a lot
better.


> 
> > I tried to mount -t ext2 /dev/msys/fla1 /mnt/doc -
> > result:
> > mount: /dev/msys/fla1 is not a valid block device
> >
> > I tried to mount -t ext2 /dev/nftla
> > mount: /dev/nftla1: unknown device
> >
> >
> > Did I miss something?
> >
> 
> 
> 
> Jon Schlueter



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


From yomiechan at octopuscards.com  Sun May  9 20:56:11 2004
From: yomiechan at octopuscards.com (Yomie Chan)
Date: Mon, 10 May 2004 08:56:11 +0800
Subject: fsck.jffs2 partition
Message-ID: <B6FABB86BDB8D511A46C00902785F34D038D714F@CS-MAIL-1>

I have problems in file management on my dataflash occasionally on my arm
linux project on at91rm9200 which may indicate that I need to look at
fsck.jffs2 more seriously.

I cant find anything like that online. 
Can someone please kindly share their experience
Looking forward to your reply 
Best Regards,
Yomie


From andreesje_werk at yahoo.com  Sun May  9 21:47:24 2004
From: andreesje_werk at yahoo.com (Andre Sodermans)
Date: Sun, 9 May 2004 18:47:24 -0700 (PDT)
Subject: diskonchip2000 support in 2.4.22
In-Reply-To: <Pine.GSO.4.58.0405091537500.27031@login1>
Message-ID: <20040510014724.91283.qmail@web41505.mail.yahoo.com>

I rebuilt my kernel 2.4.22 after patching it with
mtd-snapshot-20040508.
I used the following config flags:

# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_PARTITIONS is not set
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_CHAR=m
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
# CONFIG_MTD_GEN_PROBE is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_CFI_UTIL is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_SC520CDP is not set
# CONFIG_MTD_NETSC520 is not set
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_ELAN_104NC is not set
# CONFIG_MTD_DILNETPC is not set
# CONFIG_MTD_OCTAGON is not set
# CONFIG_MTD_VMAX is not set
# CONFIG_MTD_SCx200_DOCFLASH is not set
# CONFIG_MTD_L440GX is not set
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_SCB2_FLASH is not set
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_PCMCIA is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
CONFIG_MTD_DOC2000=m
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_DOCPROBE=m
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
# CONFIG_MTD_DOCPROBE_HIGH is not set
# CONFIG_MTD_DOCPROBE_55AA is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
CONFIG_MTD_NAND_IDS=m


Then after bootup, I run:
modprobe -a doc2000 nftl mtdchar mtdblock
modprobe -a docprobe

Here is the output from dmesg:


NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c
$Revision: 1.34 $
Refusing to drive DiskOnChip 2000 TSOP until Bad Block
Table is correctly supported by INFTL
No recognised DiskOnChip devices found

What am I missing?



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


From dwmw2 at infradead.org  Mon May 10 02:55:42 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 10 May 2004 07:55:42 +0100
Subject: diskonchip2000 support in 2.4.22
In-Reply-To: <20040510014724.91283.qmail@web41505.mail.yahoo.com>
References: <20040510014724.91283.qmail@web41505.mail.yahoo.com>
Message-ID: <1084172142.21553.0.camel@imladris.demon.co.uk>

On Sun, 2004-05-09 at 18:47 -0700, Andre Sodermans wrote:
> Refusing to drive DiskOnChip 2000 TSOP until Bad Block
> Table is correctly supported by INFTL

> What am I missing?

-- 
dwmw2




From pascal.fifre at cleode.com  Mon May 10 06:08:56 2004
From: pascal.fifre at cleode.com (Pascal Fifre)
Date: Mon, 10 May 2004 12:08:56 +0200
Subject: PB with millenium plus 64
Message-ID: <000601c43676$ce9b6db0$3055a8c0@cleode.local>

Hi,

I'm developing a controller board with a DOC plus 64 MB.

In a first time, the OS not recognize it. Then I saw in the
doc2001plus.c  code, that the 16 bit access on DOC was not implemented.
Is it true?
I put my DOC in a 8 bit access and then, the OS recognize it, and the 2
FLASH chips (Mfr = 0x98 and Id = 0x75) were recognized too.
 
Then, when I've tried to format it with "nftl_format" on Linux. The
nftl_format  told me "Unrecognized Erase size, 0x8000 - I'm confused\n".

I modify the code for accepted the 0x8000 size and retry: this operation
made an ERASE operation on DOC. Since I did it, I can't read the ID chip
of flash (Manufacturer and Id chip)? I read always 0xFF on the 2
parameters.

I think, in the same time, the LOCK pin was on. Perhaps my DOC is
locked?
In this case how can I do to unlock it?

What's wrong with DOC?

Thanks a lot

Pascal FIFRE
Responsable Syst?mes Embarqu?s
CLEODE
5, rue de Broglie
22300 LANNION
Tel : 02 96 48 68 18
http://www.cleode.com




From simon at baydel.com  Mon May 10 10:04:58 2004
From: simon at baydel.com (Simon Haynes)
Date: Mon, 10 May 2004 15:04:58 +0100
Subject: New NAND interface
Message-ID: <D917588A7DC5@baydel.com>


I explained, recently, on #mtd, that jffs2 was generating bad crc messages 
when running an NAND, smc. It was suggested that I get the latest code from 
CVS. I did this and it has taken me a while to get things going. 

Firstly nand_scan() now checks that data_buf and oob_buf have been assigned. 
Previously I only allocated space for data_buf and I did this after nand_scan 
had, conveniently, filled in some sizes fo me.  

It would seem now that the nand driver needs to select the appropriate sizes.
In some ways I feel this duplicates what nand_scan does the table in 
nand_ids.c.

I was also unsure as to the size of the oob_buf. After looking at nand.c it 
seems that this should be the oobsize * (erasesize / blockize) ?

I guess this makes sense as each block will have it's own oob.

After this I ran into problems with an SSFDC module. This module provides an 
SSFDC compatible block interface. It uses the mtd layer to read/write it's 
own data and oob. I noticed data corruption via this interface and started to 
investigate.

It would appear that the NAND layer now assigns automatic oob placements for 
NAND drivers which do not specify autooob. In my case this meant that when 
the SSFDC module called nand_write oob data was calculated and written. The 
module then called nand_write_oob to write it's own oob. Two writes like this 
could destroy the oob data and data integrity. For the moment I have fixed 
this in my NAND driver by specifying autooob with the useecc field set to 0.

Firstly I am concerned that this might cause problems with other users of the 
NAND driver.  Is there cause for concern ?

Secondly my SSFDC layer will only work with my NAND driver.
I guess what I really need to do is change the SSFDC layer but I am not sure 
how to go about this. I do not simply what to change ECC positions but the 
contents of the oob. 

Can anyone explain how I should do this ?


Cheers

Simon.


From tglx at linutronix.de  Mon May 10 11:32:23 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 10 May 2004 17:32:23 +0200
Subject: New NAND interface
In-Reply-To: <D917588A7DC5@baydel.com>
References: <D917588A7DC5@baydel.com>
Message-ID: <200405101732.23971.tglx@linutronix.de>

On Monday 10 May 2004 16:04, Simon Haynes wrote:
> I explained, recently, on #mtd, that jffs2 was generating bad crc messages
> when running an NAND, smc. It was suggested that I get the latest code from
> CVS. I did this and it has taken me a while to get things going.
>
> Firstly nand_scan() now checks that data_buf and oob_buf have been
> assigned. Previously I only allocated space for data_buf and I did this
> after nand_scan had, conveniently, filled in some sizes fo me.
> It would seem now that the nand driver needs to select the appropriate
> sizes. In some ways I feel this duplicates what nand_scan does the table in
> nand_ids.c.

The ids provide information about the chip and its features. nand_scan is a 
bit more complicated now, as we read the extended id to get more information 
about the chip. This allows us to use one driver setup for different 
chiptypes.

> I was also unsure as to the size of the oob_buf. After looking at nand.c it
> seems that this should be the oobsize * (erasesize / blockize) ?

Yep. I explained this in 
http://lists.infradead.org/pipermail/linux-mtd/2004-April/009632.html

> I guess this makes sense as each block will have it's own oob.
>
> After this I ran into problems with an SSFDC module. This module provides
> an SSFDC compatible block interface. It uses the mtd layer to read/write
> it's own data and oob. I noticed data corruption via this interface and
> started to investigate.
>
> It would appear that the NAND layer now assigns automatic oob placements
> for NAND drivers which do not specify autooob. In my case this meant that
> when the SSFDC module called nand_write oob data was calculated and
> written. The module then called nand_write_oob to write it's own oob. Two
> writes like this could destroy the oob data and data integrity. For the
> moment I have fixed this in my NAND driver by specifying autooob with the
> useecc field set to 0.

Sorry, I was not aware that you have a block driver for SM-FAT. Is this driver 
available anywhere ? 

> Firstly I am concerned that this might cause problems with other users of
> the NAND driver.  Is there cause for concern ?

AFAIK, are JFFS2 and YAFFS the only clients of NAND driver, except your SSFDC 
module.

> Secondly my SSFDC layer will only work with my NAND driver.
> I guess what I really need to do is change the SSFDC layer but I am not
> sure how to go about this. I do not simply what to change ECC positions but
> the contents of the oob.

Yep. Have a look at YAFFS or JFFS2. There we build a oob layout where the ECC 
placement is defined. The useecc member is set to MTD_NANDECC_PLACE, which 
means you define the ECC positions.
The data for the oob area can either be programmed seperately or written along 
with the main area data. See http://linux-mtd.infradead.org/tech/nand.html or 
have a look into the YAFFS code.

If you have more questions feel free to ask or let me have a look into the 
code so I can give you more detailed hints.

Thomas



From simon at baydel.com  Mon May 10 12:35:47 2004
From: simon at baydel.com (Simon Haynes)
Date: Mon, 10 May 2004 17:35:47 +0100
Subject: New NAND interface
In-Reply-To: <200405101732.23971.tglx@linutronix.de>
References: <D917588A7DC5@baydel.com> <200405101732.23971.tglx@linutronix.de>
Message-ID: <D9A158B823BE@baydel.com>

On Monday 10 May 2004 4:32 pm, Thomas Gleixner wrote:
> On Monday 10 May 2004 16:04, Simon Haynes wrote:
> > I explained, recently, on #mtd, that jffs2 was generating bad crc
>
> Yep. I explained this in
> http://lists.infradead.org/pipermail/linux-mtd/2004-April/009632.html
>

Sorry, I should have looked at the archives. This makes it all clear to me.

> > moment I have fixed this in my NAND driver by specifying autooob with the
> > useecc field set to 0.
>
> Sorry, I was not aware that you have a block driver for SM-FAT. Is this
> driver available anywhere ?
>

I have spoken to David about this and I am more than happy to provide the 
source to anyone. David, kindly, suggested I send the code to him and he 
would have a look before integrating it into the CVS system. I have not sent 
it to David as there are restrictions which would not make it suitable for 
all. I had planned to remove these and tidy things up but I just have not 
made the time. 

> > Firstly I am concerned that this might cause problems with other users of
> > the NAND driver.  Is there cause for concern ?
>
> AFAIK, are JFFS2 and YAFFS the only clients of NAND driver, except your
> SSFDC module.
>

I guess JFFS2 and YAFFS will not bothered about my NAND driver doing auto 
placement as they have their own schemes ?


> Secondly my SSFDC layer will only work with my NAND driver.
> If you have more questions feel free to ask or let me have a look into the
> code so I can give you more detailed hints.
>

As I said, I will supply you the code but I do not expect you to support it
and I do regard it as, incomplete, for gereral use.

> Thomas
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Thomas, 

Thankyou for your support, again :-). At some time I will look into how I can 
change the SSFDC layer to interface properly to mtd/nand. As my frig seems to 
work for now I am inclined to go with it, unless you think this otherwise.

Cheers 

Simon.


From ddaney at avtrex.com  Mon May 10 20:39:07 2004
From: ddaney at avtrex.com (David Daney)
Date: Mon, 10 May 2004 17:39:07 -0700
Subject: struct mtd_info and struct mtd_info_user not compatable...
Message-ID: <40A020AB.5050101@avtrex.com>

In the current cvs sources struct mtd_info has a member called oobavail 
in the spot that mtd_info_user has ecctype.

This causes mtd_debug to print incorrect information.

David Daney.



From josepascual at almudi.com  Tue May 11 04:38:53 2004
From: josepascual at almudi.com (Jose Pascual)
Date: Tue, 11 May 2004 10:38:53 +0200
Subject: symbolic link with jffs2
Message-ID: <035301c43733$643a7930$0319a8c0@dominio1.ingalmudi.com>

Hi,

I'm using kernel 2.4.25-vrs2 and my own patch for my specific board.
I updated my kernel to 14/4/2004 MTD snapshot (cvs).

I have mounted a jffs2 fs in mtdblock2 (nor in my case) but when I make
symbolic link something doesn't work as you can se below, (appear some ?
simbols in name, so symbolic links are broken)

do you have seen this problem before? any suggestion?

----------------------------------------------------------------
[root at IA-CPU-9200 lib]$ls -la
total 1534
drwxrwxrwx    1 root     root            0 Jan  1 00:18 .
drwxr-xr-x    1 root     root            0 Jan  1 00:17 ..
-rwxr-xr-x    1 root     root       116853 Dec 21  2003 ld-2.2.3.so
lrwxrwxrwx    1 root     root           11 Jan  1 00:16 ld-linux.so.2 ->
ld-2.2.3.so?1?.so?
-rwxr-xr-x    1 root     root      1348598 Dec 21  2003 libc-2.2.4.so
lrwxrwxrwx    1 root     root           13 Jan  1 00:16 libc.so.6 ->
libc-2.2.4.so?.so?
-rwxr-xr-x    1 root     root        29479 Dec 21  2003
libcrypt-2.2.3.so
lrwxrwxrwx    1 root     root           13 Jan  1 00:16 libcrypt.so ->
libcrypt.so.1?.so?
lrwxrwxrwx    1 root     root           17 Jan  1 00:16 libcrypt.so.1 ->
libcrypt-2.2.3.so?
-rwxrwxrwx    1 root     root        74712 Dec 21  2003
libpthread-0.8.so
lrwxrwxrwx    1 root     root           15 Jan  1 00:16 libpthread.so ->
libpthread.so.0?.2
lrwxrwxrwx    1 root     root           17 Jan  1 00:18 libpthread.so.0
-> libpthread-0.8.so?
lrwxrwxrwx    1 root     root           17 Jan  1 00:16
libpthread.so.0.bad -> libpthread-0.8.so?
[root at IA-CPU-9200 lib]$
----------------------------------------------------------------

thank you in advanced



From tglx at linutronix.de  Tue May 11 04:53:00 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 11 May 2004 10:53:00 +0200
Subject: New NAND interface
In-Reply-To: <D9A158B823BE@baydel.com>
References: <D917588A7DC5@baydel.com> <200405101732.23971.tglx@linutronix.de>
	<D9A158B823BE@baydel.com>
Message-ID: <200405111053.00541.tglx@linutronix.de>

On Monday 10 May 2004 18:35, Simon Haynes wrote:
> On Monday 10 May 2004 4:32 pm, Thomas Gleixner wrote:
> > On Monday 10 May 2004 16:04, Simon Haynes wrote:
> > > I explained, recently, on #mtd, that jffs2 was generating bad crc
> >
> > Yep. I explained this in
> > http://lists.infradead.org/pipermail/linux-mtd/2004-April/009632.html
>
> Sorry, I should have looked at the archives. This makes it all clear to me.

No problem.

> > > moment I have fixed this in my NAND driver by specifying autooob with
> > > the useecc field set to 0.
> >
> > Sorry, I was not aware that you have a block driver for SM-FAT. Is this
> > driver available anywhere ?
>
> I have spoken to David about this and I am more than happy to provide the
> source to anyone. David, kindly, suggested I send the code to him and he
> would have a look before integrating it into the CVS system. I have not
> sent it to David as there are restrictions which would not make it suitable
> for all. I had planned to remove these and tidy things up but I just have
> not made the time.

Ok

> > > Firstly I am concerned that this might cause problems with other users
> > > of the NAND driver.  Is there cause for concern ?
> >
> > AFAIK, are JFFS2 and YAFFS the only clients of NAND driver, except your
> > SSFDC module.
>
> I guess JFFS2 and YAFFS will not bothered about my NAND driver doing auto
> placement as they have their own schemes ?

Yep. The decision is:

Use the caller provided scheme else use the default autoplacement scheme.

> > Secondly my SSFDC layer will only work with my NAND driver.
> > If you have more questions feel free to ask or let me have a look into
> > the code so I can give you more detailed hints.
>
> As I said, I will supply you the code but I do not expect you to support it
> and I do regard it as, incomplete, for gereral use.

In general I try to support every known NAND driver client. I would be 
interested to look into the SSFDC code also to help to fix it so it can be 
included in the source base.

> Thankyou for your support, again :-). At some time I will look into how I
> can change the SSFDC layer to interface properly to mtd/nand. As my frig
> seems to work for now I am inclined to go with it, unless you think this
> otherwise.

Cheers 

Thomas





From simon at baydel.com  Tue May 11 05:47:18 2004
From: simon at baydel.com (Simon Haynes)
Date: Tue, 11 May 2004 10:47:18 +0100
Subject: New NAND interface
In-Reply-To: <200405111053.00541.tglx@linutronix.de>
References: <D9A158B823BE@baydel.com>
Message-ID: <40A0AF36.7429.C00B3@localhost>

On 11 May 2004 at 10:53, Thomas Gleixner wrote:

> On Monday 10 May 2004 18:35, Simon Haynes wrote:
> > On Monday 10 May 2004 4:32 pm, Thomas Gleixner wrote:
> > > On Monday 10 May 2004 16:04, Simon Haynes wrote:
> > > > I explained, recently, on #mtd, that jffs2 was generating bad
> > > > crc
> > support it and I do regard it as, incomplete, for gereral use.
> 
> In general I try to support every known NAND driver client. I would be
> interested to look into the SSFDC code also to help to fix it so it
> can be included in the source base.
> 

Thomas, 

I will email you the code, if you don't want it just junk it. I had a look at the YAFFS 
stuff last night. As I understand it I could just replace my calls to mtd->read and 
mtd->write with the ecc versions. I would then specify NULL for oob_buf and set 
oobinfo->useecc to MTD_NANDECC_OFF. 

Then I could put the NAND driver back to normal.


Thanks

Simon. 
__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon at baydel.com
__________________________



From yomiechan at octopuscards.com  Tue May 11 06:32:55 2004
From: yomiechan at octopuscards.com (Yomie Chan)
Date: Tue, 11 May 2004 18:32:55 +0800
Subject: fsck.jffs2 mtd partitions
Message-ID: <B6FABB86BDB8D511A46C00902785F34D038D7163@CS-MAIL-1>

I have problems in file management on my dataflash occasionally on my arm
linux project on at91rm9200 which may indicate that I need to look at
fsck.jffs2 more seriously.

I cant find anything like that online. 
Can someone please kindly share their experience
Looking forward to your reply 
Best Regards,
Yomie


From josepascual at almudi.com  Tue May 11 07:37:19 2004
From: josepascual at almudi.com (Jose Pascual)
Date: Tue, 11 May 2004 13:37:19 +0200
Subject: symbolic link with jffs2
In-Reply-To: <035301c43733$643a7930$0319a8c0@dominio1.ingalmudi.com>
Message-ID: <036d01c4374c$53563fa0$0319a8c0@dominio1.ingalmudi.com>

Hi,

It seems as strlen of names in symbolic links is wrong or the '\0' is
forgotten at the len of name,
the symlink is correct until first ? appear. Shouln't be a '\0' instead
Where ? appear.

regards
 
> 
> Hi,
> 
> I'm using kernel 2.4.25-vrs2 and my own patch for my specific 
> board. I updated my kernel to 14/4/2004 MTD snapshot (cvs).
> 
> I have mounted a jffs2 fs in mtdblock2 (nor in my case) but 
> when I make symbolic link something doesn't work as you can 
> se below, (appear some ? simbols in name, so symbolic links 
> are broken)
> 
> do you have seen this problem before? any suggestion?
> 
> ----------------------------------------------------------------
> [root at IA-CPU-9200 lib]$ls -la
> total 1534
> drwxrwxrwx    1 root     root            0 Jan  1 00:18 .
> drwxr-xr-x    1 root     root            0 Jan  1 00:17 ..
> -rwxr-xr-x    1 root     root       116853 Dec 21  2003 ld-2.2.3.so
> lrwxrwxrwx    1 root     root           11 Jan  1 00:16 
> ld-linux.so.2 ->
> ld-2.2.3.so?1?.so?
> -rwxr-xr-x    1 root     root      1348598 Dec 21  2003 libc-2.2.4.so
> lrwxrwxrwx    1 root     root           13 Jan  1 00:16 libc.so.6 ->
> libc-2.2.4.so?.so?
> -rwxr-xr-x    1 root     root        29479 Dec 21  2003
> libcrypt-2.2.3.so
> lrwxrwxrwx    1 root     root           13 Jan  1 00:16 libcrypt.so ->
> libcrypt.so.1?.so?
> lrwxrwxrwx    1 root     root           17 Jan  1 00:16 
> libcrypt.so.1 ->
> libcrypt-2.2.3.so?
> -rwxrwxrwx    1 root     root        74712 Dec 21  2003
> libpthread-0.8.so
> lrwxrwxrwx    1 root     root           15 Jan  1 00:16 
> libpthread.so ->
> libpthread.so.0?.2
> lrwxrwxrwx    1 root     root           17 Jan  1 00:18 
> libpthread.so.0
> -> libpthread-0.8.so?
> lrwxrwxrwx    1 root     root           17 Jan  1 00:16
> libpthread.so.0.bad -> libpthread-0.8.so?
> [root at IA-CPU-9200 lib]$
> ----------------------------------------------------------------
> 
> thank you in advanced
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list 
> http://lists.infradead.org/mailman/listinfo/lin> ux-mtd/
> 
> 
> 
> __________ Informaci?n de NOD32 1.755 (20040511) __________
> 
> Este mensaje ha sido analizado con  NOD32 Antivirus System 
http://www.nod32.com



__________ Informaci?n de NOD32 1.755 (20040511) __________

Este mensaje ha sido analizado con  NOD32 Antivirus System
http://www.nod32.com




From dvrabel at arcom.com  Tue May 11 07:42:38 2004
From: dvrabel at arcom.com (David Vrabel)
Date: Tue, 11 May 2004 12:42:38 +0100
Subject: symbolic link with jffs2
In-Reply-To: <036d01c4374c$53563fa0$0319a8c0@dominio1.ingalmudi.com>
References: <036d01c4374c$53563fa0$0319a8c0@dominio1.ingalmudi.com>
Message-ID: <40A0BC2E.1050809@arcom.com>

Jose Pascual wrote:
> 
> It seems as strlen of names in symbolic links is wrong

Big-endian glibc bug?

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/


From josepascual at almudi.com  Tue May 11 08:16:01 2004
From: josepascual at almudi.com (Jose Pascual)
Date: Tue, 11 May 2004 14:16:01 +0200
Subject: symbolic link with jffs2
In-Reply-To: <40A0BC2E.1050809@arcom.com>
Message-ID: <000001c43751$ba92fb90$0319a8c0@dominio1.ingalmudi.com>

> > 
> > It seems as strlen of names in symbolic links is wrong
> 
> Big-endian glibc bug?

I'm not sure, I'm working in an ARM CPU with little-endian. Everything
seems okey less symlink,

> 
> David Vrabel
> -- 
> David Vrabel, Design Engineer
> 
> Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
> Cambridge CB1 7EA, UK         Web: http://www.arcom.com/
> 
> 
> __________ Informaci?n de NOD32 1.756 (20040511) __________
> 
> Este mensaje ha sido analizado con  NOD32 Antivirus System 
http://www.nod32.com



__________ Informaci?n de NOD32 1.756 (20040511) __________

Este mensaje ha sido analizado con  NOD32 Antivirus System
http://www.nod32.com




From andreesje_werk at yahoo.com  Tue May 11 11:53:26 2004
From: andreesje_werk at yahoo.com (Andre Sodermans)
Date: Tue, 11 May 2004 08:53:26 -0700 (PDT)
Subject: diskonchip2000 support in 2.4.22
In-Reply-To: <1084172142.21553.0.camel@imladris.demon.co.uk>
Message-ID: <20040511155327.9810.qmail@web41502.mail.yahoo.com>

hmmmm

So, I do need 'CONFIG_INFTL'? I wasn't sure when I
built my most recent kernel.

Andre

--- David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sun, 2004-05-09 at 18:47 -0700, Andre Sodermans
> wrote:
> > Refusing to drive DiskOnChip 2000 TSOP until Bad
> Block
> > Table is correctly supported by INFTL
> 
> > What am I missing?
> 
> -- 
> dwmw2
> 
> 



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


From dwmw2 at infradead.org  Tue May 11 11:58:44 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 11 May 2004 16:58:44 +0100
Subject: diskonchip2000 support in 2.4.22
In-Reply-To: <20040511155327.9810.qmail@web41502.mail.yahoo.com>
References: <20040511155327.9810.qmail@web41502.mail.yahoo.com>
Message-ID: <1084291123.4426.26.camel@hades.cambridge.redhat.com>

On Tue, 2004-05-11 at 08:53 -0700, Andre Sodermans wrote:
> hmmmm
> 
> So, I do need 'CONFIG_INFTL'? I wasn't sure when I
> built my most recent kernel.

Yes, and then you need to write support for the Bad Block Table.
It's not hard -- I can help you. But I haven't got round to doing it
myself yet, and while it's not yet done the hardware driver deliberately
disables itself.

-- 
dwmw2



From pascal.fifre at cleode.com  Tue May 11 12:03:48 2004
From: pascal.fifre at cleode.com (Pascal Fifre)
Date: Tue, 11 May 2004 18:03:48 +0200
Subject: Millenium Plus
Message-ID: <004401c43771$8bcc7140$3055a8c0@cleode.local>

Hi,

I would like to know if someone tests the last version of linux mtd
source with Millenium Plus 64 MB.

Can I format this DiskOnChip with nftl_format ?

Help me please, help me

Thanks a lot

Pascal FIFRE
Responsable Syst?mes Embarqu?s
CLEODE
5, rue de Broglie
22300 LANNION
Tel : 02 96 48 68 18
http://www.cleode.com




From josepascual at almudi.com  Tue May 11 13:01:00 2004
From: josepascual at almudi.com (Jose Pascual)
Date: Tue, 11 May 2004 19:01:00 +0200
Subject: symbolic link with jffs2
In-Reply-To: <000001c43751$ba92fb90$0319a8c0@dominio1.ingalmudi.com>
Message-ID: <001f01c43779$893048f0$0319a8c0@dominio1.ingalmudi.com>

hi

I have found that symlink is broken if the length of char of the name is
pointing is odd
but not with even.

any suggestion?


> -----Mensaje original-----
> De: linux-mtd-bounces at lists.infradead.org 
> [mailto:linux-mtd-bounces at lists.infradead.org] En nombre de 
> Jose Pascual
> Enviado el: martes, 11 de mayo de 2004 14:16
> Para: 'David Vrabel'
> CC: linux-mtd at lists.infradead.org
> Asunto: RE: symbolic link with jffs2
> 
> 
> > > 
> > > It seems as strlen of names in symbolic links is wrong
> > 
> > Big-endian glibc bug?
> 
> I'm not sure, I'm working in an ARM CPU with little-endian. 
> Everything seems okey less symlink,
> 
> > 
> > David Vrabel
> > --
> > David Vrabel, Design Engineer
> > 
> > Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
> > Cambridge CB1 7EA, UK         Web: http://www.arcom.com/
> > 
> > 
> > __________ Informaci?n de NOD32 1.756 (20040511) __________
> > 
> > Este mensaje ha sido analizado con  NOD32 Antivirus System
> http://www.nod32.com
> 
> 
> 
> __________ Informaci?n de NOD32 1.756 (20040511) __________
> 
> Este mensaje ha sido analizado con  NOD32 Antivirus System
> http://www.nod32.com
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 
> __________ Informaci?n de NOD32 1.756 (20040511) __________
> 
> Este mensaje ha sido analizado con  NOD32 Antivirus System
> http://www.nod32.com
> 
> 
> 
> __________ Informaci?n de NOD32 1.756 (20040511) __________
> 
> Este mensaje ha sido analizado con  NOD32 Antivirus System
> http://www.nod32.com
> 
> 



From icampbell at arcom.com  Wed May 12 04:42:55 2004
From: icampbell at arcom.com (Ian Campbell)
Date: Wed, 12 May 2004 09:42:55 +0100
Subject: symbolic link with jffs2
In-Reply-To: <001f01c43779$893048f0$0319a8c0@dominio1.ingalmudi.com>
References: <001f01c43779$893048f0$0319a8c0@dominio1.ingalmudi.com>
Message-ID: <1084351374.9910.10.camel@icampbell-debian>

On Tue, 2004-05-11 at 18:01, Jose Pascual wrote:

> I have found that symlink is broken if the length of char of the name is
> pointing is odd but not with even.
> 
> any suggestion?

Way back in the mists of time I had a similar problem which turned out
to be due to copy_from/copy_to in my mapping driver not handling
unaligned copies properly.

I'm not sure if I am remembering right and I can't find any link to any
details -- but I would start by adding some print statements to
copy_from and making sure it is working right in all cases.

Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200



From jjcar1526 at hotmail.com  Wed May 12 10:13:37 2004
From: jjcar1526 at hotmail.com (J C)
Date: Wed, 12 May 2004 10:13:37 -0400
Subject: MD2811-D32 DOC
Message-ID: <BAY14-F215ScEbWIyTW000329ac@hotmail.com>

Hello all,

  I am having problems with the DOC MD2811-D32.  I am assuming to use the 
nand drivers for it since M-sys says it is nand technology.  The diskonchip 
module in the nand directory will not compile.  I am using kernel 
2.4.21-rmk1-omap and it is patched with the latest drivers.  Can anyone tell 
me if there is a newer version where diskonchip isn't broken date 3-27-2004 
on the diskonchip module.

Regards,
John

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com



From varsachin at it.iitb.ac.in  Wed May 12 10:14:09 2004
From: varsachin at it.iitb.ac.in (varsachin at it.iitb.ac.in)
Date: Wed, 12 May 2004 19:44:09 +0530 (IST)
Subject: booting from ide flash
Message-ID: <1683.10.129.178.16.1084371249.squirrel@www.it.iitb.ac.in>


hi,

I am sachin varadkar working in KReSIT IIT Bombay , India,I want to boot
linux from IDE flash so can you mail me the procedure of booting from ide
flash.


sachin varadkar.





From dwmw2 at infradead.org  Wed May 12 10:22:53 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 12 May 2004 15:22:53 +0100
Subject: MD2811-D32 DOC
In-Reply-To: <BAY14-F215ScEbWIyTW000329ac@hotmail.com>
References: <BAY14-F215ScEbWIyTW000329ac@hotmail.com>
Message-ID: <1084371773.4426.162.camel@hades.cambridge.redhat.com>

On Wed, 2004-05-12 at 10:13 -0400, J C wrote:
> Hello all,
> 
>   I am having problems with the DOC MD2811-D32.  I am assuming to use the 
> nand drivers for it since M-sys says it is nand technology.  The diskonchip 
> module in the nand directory will not compile.  I am using kernel 
> 2.4.21-rmk1-omap and it is patched with the latest drivers.  Can anyone tell 
> me if there is a newer version where diskonchip isn't broken date 3-27-2004 
> on the diskonchip module.

It might help if you were slightly more specific about the compilation
failure you see.

It probably won't help _much_ though. It's likely that it's because
you're using such an ancient kernel.

-- 
dwmw2



From lindazhu at utstar.com  Wed May 12 14:50:23 2004
From: lindazhu at utstar.com (Linda Zhu)
Date: Wed, 12 May 2004 14:50:23 -0400
Subject: JFFS2 problems on 32M AMD AM29LV128
Message-ID: <LCENIFAENEHNMKDCGDGBEECGCJAA.lindazhu@utstar.com>

Hi,

This is Linda. In our system, we run JFFS2 on AMD AM29LV128. We have total
32M
flash memory. It is partitioned into two part. First 1M memory is used by
loader,
the rest is used by JFFS2.

Originally, we use 16M flash. The JFFS2 run well on it. Recently, after we
increased the memory to 32M, we constantly encounter error messages as
indicated
below. If you can explain to me what these error messages mean, it is deeply
appreciated.

===============problem no.1 =====================
172.16.133.223 login: root
Password:
sh-2.05# mount -t jffs2 /dev/mtdblock/1 /mnt/jffs2
jffs2_scan_inode_node(): Data CRC failed on node at 0x00fc49a0: Read
0x140e2b245
jffs2_scan_inode_node(): CRC failed on node at 0x01696db0: Read 0xffffffff,
cal5
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01696db8:
0x4a78 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01696dc0:
0x0004 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01696dcc:
0x0001 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01696ddc:
0x0001 id
jffs2_scan_empty(): Empty block at 0x01696de4 ends at 0x016971ac (with
0x1985c0y
jffs2_scan_inode_node(): Data CRC failed on node at 0x01a90a60: Read
0x4eec817c6
sh-2.05# cd /mnt/jffs2/tftpboot/
sh-2.05# cp /home/lindazhu/icm3/icm2_upgrade.gz .
Warning: DQ5 raised while program operation was in progress, however
operation K
Warning: DQ5 raised while program operation was in progress, however
operation K
Warning: DQ5 raised while program operation was in progress, however
operation K
Warning: DQ5 raised while program operation was in progress, however
operation K
Warning: DQ5 raised while program operation was in progress, however
operation K
Warning: DQ5 raised while program operation was in progress, however
operation K

======================================================
The problems occurred when we login in from NFS, then tried to mount to
jffs2.
And then tried to copy a gz file from NFS file server to flash.



============= problem no. 2 ==========================
bash-2.05# cp /mnt/nfs/home/lindazhu/icm3/icm2_upgrade.gz .
Warning: DQ5 raised while program operation was in progress, however
operation c
ompleted OK
Warning: DQ5 raised while program operation was in progress, however
operation c
ompleted OK
Warning: DQ5 raised while program operation was in progress, however
operation c
ompleted OK
Waiting for write to complete timed out in do_write_oneword.<5>Write of 4164
byt
es at 0x011a71e8 failed. returned -5, retlen 1528
cp: write: Input/output error
========================================================
The problem occurred when we login in with FLASH file system. Then tried to
copy
a 3M file from NFS server to flash. The copy couldn't complete, because the
writing
operation failed.

Please advice what might be the problem and how to resolve it.

Many many thanks,
Linda



From f.janot at ateme.fr  Mon May 17 11:48:31 2004
From: f.janot at ateme.fr (Frederic Janot)
Date: Mon, 17 May 2004 17:48:31 +0200
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND chip
Message-ID: <1084808911.1659.20.camel@localhost>

Hi,

I've got a problem when using jffs2 filesystem on a nand flash device.

I've created a root file system image on my pc (little-endian) from
/rootfs directory which contain all needed files. I burn this image into
a nand flash (samsung k9f5608 - 32MB nand with 512+16 bytes per pages)
on a board with a power pc processor (big-endian).

So, on the pc, i do :
# mkfs.jffs2 -p --root=/rootfs -e 16384 -b -o fs_img

My flash partitions are :
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00004000 "Nand Flash Kernel"
mtd1: 01a00000 00004000 "Nand Flash RootFS"
mtd2: 00200000 00004000 "Nand Flash Test"

On my target, from an nfs mount root file system, i do :
# nandwrite -j /dev/mtd1 /fs_img

After that, I reboot my board and make the kernel boot from nand root
file system. The first boot is ok but when i reboot one more time, I
have the following message :
Empty flash at 0x0047b900 ends at 0x0047ba00
jffs2_get_inode_nodes(): Data CRC failed on node at 0x015fc000: Read
0x5a62bf55, calculated 0x349968c2

And each time I reboot, there is one message more. (I do nothing else
than login and reboot)
Empty flash at 0x0047b900 ends at 0x0047ba00
Empty flash at 0x015fc268 ends at 0x015fc400
jffs2_get_inode_nodes(): Data CRC failed on node at 0x015fc000: Read
0x5a62bf55, calculated 0x349968c2
jffs2_get_inode_nodes(): Data CRC failed on node at 0x015fc778: Read
0xdf13fb17, calculated 0xbdff7e75

etc ...

Do you have any idea on what happens ?

Thanks

Frederic Janot




From wookey at aleph1.co.uk  Mon May 17 12:39:45 2004
From: wookey at aleph1.co.uk (Wookey)
Date: Mon, 17 May 2004 17:39:45 +0100
Subject: blkmtd (and YAFFS)
Message-ID: <20040517163945.GJ12570@knossos.aleph1.co.uk>

I just came across the blkmtd which is a driver that does the opposite of
mtdblock, and allows JFFS2 (and maybe YAFFS) on IDE-type devices. 

I know we're not supposed to talk about CF cards here, but I'm not sure who
else to ask about this...

We have recently found that it's very easy to wear out crummy CF cards using
conventional disk-journalling systems (ext3 wears a hole in the end of a
512MB flash card in <10 reboots) because every write goes through the
journal section of the device, and clearly its internal controller is
doing a very simple sector->flashpage mapping (yes, we should have turned
off atime, but still it's amazingly exactly not what you wanted :-) 

So what I really want to do is use something that distributes the writes
better than the internal controller so I'm thinking that YAFFS or JFFS2
should do a better job, but still give us journalling/power fail safety.

blkmtd appears to allow this but I see few mentions of it since early 2002.
Is it stable, does it work, has anyone ever tried it with YAFFS?

Is there a better FS for this purpose (anyone know if reiserfs helps
distribute writes around your 'disk' at all?)

thanx for any info you can provide.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/


From dwmw2 at infradead.org  Mon May 17 14:27:36 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 17 May 2004 19:27:36 +0100
Subject: blkmtd (and YAFFS)
In-Reply-To: <20040517163945.GJ12570@knossos.aleph1.co.uk>
References: <20040517163945.GJ12570@knossos.aleph1.co.uk>
Message-ID: <1084818456.4831.10.camel@hades.cambridge.redhat.com>

On Mon, 2004-05-17 at 17:39 +0100, Wookey wrote:
> blkmtd appears to allow this but I see few mentions of it since early 2002.
> Is it stable, does it work, has anyone ever tried it with YAFFS?

It doesn't give you OOB data, so I don't know if it will work with
YAFFS. It certainly works with JFFS2.

The JFFS2 support could be severely optimised on blkmtd though --
batching into 512 byte writes as we do for NAND but without the ECC or
putting cleanmarkers in the OOB area (or possibly without cleanmarkers
at all although that's harder).

-- 
dwmw2



From paris at disp.uniroma2.it  Mon May 17 11:37:58 2004
From: paris at disp.uniroma2.it (Cristiano Paris)
Date: Mon, 17 May 2004 17:37:58 +0200
Subject: Low-level access to USB pendrive
Message-ID: <20040517153758.GA9992@sackville.theshire.org>

Hi everyone,

I know that the external interface to usb flash pendrives is implemented
as a block device. I also know that this is a logical organization of the
underlying flash memory. The question is: is it possible to access the
flash memory directly bypassing this "logical-to-physical" mapping layer?

Thanks

Cristiano

----
Web: http://www.disp.uniroma2.it/users/paris/

Public PGP/GnuPG key
pub  1024D/32CA6D54 2004-01-23 Cristiano Paris (RHPK) <c.paris at email.it>
     Key fingerprint = 3BFD 9884 230A 1F17 391C  1434 80CB 2C7A 32CA 6D54
----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040517/1d88e197/attachment.bin 

From dwmw2 at infradead.org  Mon May 17 18:25:01 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 17 May 2004 23:25:01 +0100
Subject: Low-level access to USB pendrive
In-Reply-To: <20040517153758.GA9992@sackville.theshire.org>
References: <20040517153758.GA9992@sackville.theshire.org>
Message-ID: <1084832701.6607.597.camel@imladris.demon.co.uk>

On Mon, 2004-05-17 at 17:37 +0200, Cristiano Paris wrote:
> Hi everyone,
> 
> I know that the external interface to usb flash pendrives is implemented
> as a block device. I also know that this is a logical organization of the
> underlying flash memory. The question is: is it possible to access the
> flash memory directly bypassing this "logical-to-physical" mapping layer?

Generally no. A USB pendrive is a SCSI-over-USB disk. If there's a way
to bypass its internal 'translation layer' and access the flash
directly, it's very manufacturer-specific and not documented.

-- 
dwmw2




From lokeshk at hotmail.com  Mon May 17 19:20:53 2004
From: lokeshk at hotmail.com (lokesh kumar)
Date: Mon, 17 May 2004 19:20:53 -0400
Subject: jffs2 2.4.18 kernel problem
Message-ID: <BAY1-F74G7Tyc1ZoHGt0001c7c9@hotmail.com>

Hi,
I have a jffs2 partition on my mpc8xx board, running 2.4.18 kernel. I am 
using mtd snapshot of july 2002. The mtd partition size is 2MB.

I enabled the mtd options in kernel, and then built an image for this 
partition using

mkfs.jffs2 -e 0x20000 -b -r rootdir -o img

and then I copy this image over this partition using u-boot or debugger. I 
can then boot the board and mount this partition on a mount point. Then I 
can cd to this partition and create a directory and copy a file to this 
directory. Now, I turn the power off and when I reboot, I can mount the file 
system and can see that the directory and file exist, but when I say "rm -fr 
file" or "rm -fr directory", it crashes the kernel saying "kernel access of 
bad area"

What am I doing wrong?

Lokesh

_________________________________________________________________
Express yourself with the new version of MSN Messenger! Download today - 
it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/



From tglx at linutronix.de  Mon May 17 19:21:16 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 18 May 2004 01:21:16 +0200
Subject: jffs2 2.4.18 kernel problem
In-Reply-To: <BAY1-F74G7Tyc1ZoHGt0001c7c9@hotmail.com>
References: <BAY1-F74G7Tyc1ZoHGt0001c7c9@hotmail.com>
Message-ID: <200405180121.16354.tglx@linutronix.de>

On Tuesday 18 May 2004 01:20, lokesh kumar wrote:
> Hi,
> I have a jffs2 partition on my mpc8xx board, running 2.4.18 kernel. I am
> using mtd snapshot of july 2002. The mtd partition size is 2MB.
>
> I enabled the mtd options in kernel, and then built an image for this
> partition using
>
> mkfs.jffs2 -e 0x20000 -b -r rootdir -o img
>
> and then I copy this image over this partition using u-boot or debugger. I
> can then boot the board and mount this partition on a mount point. Then I
> can cd to this partition and create a directory and copy a file to this
> directory. Now, I turn the power off and when I reboot, I can mount the
> file system and can see that the directory and file exist, but when I say
> "rm -fr file" or "rm -fr directory", it crashes the kernel saying "kernel
> access of bad area"
>
> What am I doing wrong?

Not much. You just use an ancient kernel and a pre ancient version of mtd

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de



From manningc2 at actrix.gen.nz  Mon May 17 22:41:25 2004
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Tue, 18 May 2004 14:41:25 +1200
Subject: blkmtd (and YAFFS)
In-Reply-To: <20040517163945.GJ12570@knossos.aleph1.co.uk>
References: <20040517163945.GJ12570@knossos.aleph1.co.uk>
Message-ID: <20040518070547.9FF6D5209@blood.actrix.co.nz>

As David already pointed out, CF hides the ECC stuff (indeed some CF is not 
even based on NAND flash) so YAFFS is probably not really the best choice.

> I know we're not supposed to talk about CF cards here, but I'm not sure who
> else to ask about this...

Yes, mentioning CF on mtd is poor form :-).
>
> We have recently found that it's very easy to wear out crummy CF cards
> using conventional disk-journalling systems (ext3 wears a hole in the end
> of a 512MB flash card in <10 reboots) because every write goes through the
> journal section of the device, and clearly its internal controller is doing
> a very simple sector->flashpage mapping (yes, we should have turned off
> atime, but still it's amazingly exactly not what you wanted :-)
>
> So what I really want to do is use something that distributes the writes
> better than the internal controller so I'm thinking that YAFFS or JFFS2
> should do a better job, but still give us journalling/power fail safety.
>
> blkmtd appears to allow this but I see few mentions of it since early 2002.
> Is it stable, does it work, has anyone ever tried it with YAFFS?

CF always has been and always will be a "Kleenex technology" for the consumer 
market. Designing it in as part of a rugged system has always been ill 
advised.

CF controllers don't do explicit wear levelling. At least some do "implicit 
wear levelling"  by using a free pool rather like SmartMedia does. It would 
appear though that some don't even do that.

CF cards do not necessarily fail due to wear-out. They can get screwed up by 
corrupting their logical to physical mapping which I hunch is the more likely 
scenario. If this is happening then extra wear levelling is not going to help.

>
> Is there a better FS for this purpose (anyone know if reiserfs helps
> distribute writes around your 'disk' at all?)

You're making the (possibly invalid) assumption that your failures are due to 
wear out. If that is indeed the case then some such wear levelling fs might 
help. 

The biggest problem I see is that YAFFS and JFFSx achieve their robustness by 
dealing with the flash directly and do not have logical to physical mapping 
layers. Balancing YAFFS of JFFSx on top of something that relies on a logical 
to physical mapping just gives a false sense of security since there is no 
mechanism to repair errors at that level.

Both YAFFS anf JFFSx are journaling/log structured file systems. They can 
cope with write failures and can handle unclean dismounts, but they cannot 
recover data that has been lost; for that you need a RAID system or such. A 
corruption in a CF card results in lost info which will not be recoverable.


-- Charles



From simon at baydel.com  Tue May 18 06:20:43 2004
From: simon at baydel.com (Simon Haynes)
Date: Tue, 18 May 2004 11:20:43 +0100
Subject: jffs2_get_inode_nodes(): Data CRC failed on NAND chip
In-Reply-To: <1084808911.1659.20.camel@localhost>
Message-ID: <40A9F18B.12350.192BB7@localhost>

I have had similar problems to this.  As you reboot you must make sure that root is 
remounted read only. If you don't a reboot can cause the JFFS2 garbage collector to 
be stopped mid operation. JFFS2 is verbose in error reporting. I suspect that your 
files are still ok. There was a bug in the JFFS2 layer which caused the garbage 
collector not to flush it's write buffer on remount read only. This would not screw up 
the filesystem but it would generate messages for uncleanly finished garbage 
operations. I have discussed this recently and it should be available via CVS now.

I have had discussions about the empty flash messages too. It seems it is not a 
problem. If the message concerns you move it to KERN_DEBUG

Hope this helps

Simon.

On 17 May 2004 at 17:48, Frederic Janot wrote:

> Hi,
> 
> I've got a problem when using jffs2 filesystem on a nand flash device.
> 
> I've created a root file system image on my pc (little-endian) from
> /rootfs directory which contain all needed files. I burn this image
> into a nand flash (samsung k9f5608 - 32MB nand with 512+16 bytes per
> pages) on a board with a power pc processor (big-endian).
> 
> So, on the pc, i do :
> # mkfs.jffs2 -p --root=/rootfs -e 16384 -b -o fs_img
> 
> My flash partitions are :
> # cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00400000 00004000 "Nand Flash Kernel"
> mtd1: 01a00000 00004000 "Nand Flash RootFS"
> mtd2: 00200000 00004000 "Nand Flash Test"
> 
> On my target, from an nfs mount root file system, i do :
> # nandwrite -j /dev/mtd1 /fs_img
> 
> After that, I reboot my board and make the kernel boot from nand root
> file system. The first boot is ok but when i reboot one more time, I
> have the following message : Empty flash at 0x0047b900 ends at
> 0x0047ba00 jffs2_get_inode_nodes(): Data CRC failed on node at
> 0x015fc000: Read 0x5a62bf55, calculated 0x349968c2
> 
> And each time I reboot, there is one message more. (I do nothing else
> than login and reboot) Empty flash at 0x0047b900 ends at 0x0047ba00
> Empty flash at 0x015fc268 ends at 0x015fc400 jffs2_get_inode_nodes():
> Data CRC failed on node at 0x015fc000: Read 0x5a62bf55, calculated
> 0x349968c2 jffs2_get_inode_nodes(): Data CRC failed on node at
> 0x015fc778: Read 0xdf13fb17, calculated 0xbdff7e75
> 
> etc ...
> 
> Do you have any idea on what happens ?
> 
> Thanks
> 
> Frederic Janot
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon at baydel.com
__________________________



From Sieme.Teuling at echostar.com  Tue May 18 07:42:43 2004
From: Sieme.Teuling at echostar.com (Teuling, Sieme)
Date: Tue, 18 May 2004 05:42:43 -0600
Subject: patch for nand support linux-2.4.21 jffs2?
Message-ID: <C86A9402F6A07E47B2F50A302DFA9BAE044C58@alm-exch.europe.echostar.com>

Hi,

I'm working with a linux 2.4.21 port and I just found out jffs2 has no
nand support (bad block handling) in this version.
Is there a patch available to solve this?, or if not, what is the best
thing to do to get the 2.4.21 to work with nand flashes?

Please help,

Sieme


From tglx at linutronix.de  Tue May 18 08:31:03 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 18 May 2004 14:31:03 +0200
Subject: patch for nand support linux-2.4.21 jffs2?
In-Reply-To: <C86A9402F6A07E47B2F50A302DFA9BAE044C58@alm-exch.europe.echostar.com>
References: <C86A9402F6A07E47B2F50A302DFA9BAE044C58@alm-exch.europe.echostar.com>
Message-ID: <200405181431.03242.tglx@linutronix.de>

On Tuesday 18 May 2004 13:42, Teuling, Sieme wrote:
> Hi,
>
> I'm working with a linux 2.4.21 port and I just found out jffs2 has no
> nand support (bad block handling) in this version.
> Is there a patch available to solve this?, or if not, what is the best
> thing to do to get the 2.4.21 to work with nand flashes?

Use current MTD CVS code. 

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de



From Sieme.Teuling at echostar.com  Tue May 18 10:07:06 2004
From: Sieme.Teuling at echostar.com (Teuling, Sieme)
Date: Tue, 18 May 2004 08:07:06 -0600
Subject: patch for nand support linux-2.4.21 jffs2?
Message-ID: <C86A9402F6A07E47B2F50A302DFA9BAE044C60@alm-exch.europe.echostar.com>

Thanx for the replies,

I have tried to run the mtd patch from cvs on my kernel tree (sh patchin.sh
-j /../linux-2.4.21), but now my kernel doesn't compile anymore, I get:

fs/fs.o(.text+0x4d860): In function `jffs2_gc_fetch_inode':
/../linux-2.4.21/fs/jffs2/fs.c:561: undefined reference to `ilookup'

Is this a known problem with a know solution?


Sieme,


From dwmw2 at infradead.org  Tue May 18 10:28:41 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 18 May 2004 15:28:41 +0100
Subject: patch for nand support linux-2.4.21 jffs2?
In-Reply-To: <C86A9402F6A07E47B2F50A302DFA9BAE044C60@alm-exch.europe.echostar.com>
References: 
	 <C86A9402F6A07E47B2F50A302DFA9BAE044C60@alm-exch.europe.echostar.com>
Message-ID: <1084890521.26438.13.camel@hades.cambridge.redhat.com>

On Tue, 2004-05-18 at 08:07 -0600, Teuling, Sieme wrote:
> Is this a known problem with a know solution?

Problem and solution are 2.4.21 and 2.4.26 respectively.

-- 
dwmw2



From Sieme.Teuling at echostar.com  Tue May 18 10:59:38 2004
From: Sieme.Teuling at echostar.com (Teuling, Sieme)
Date: Tue, 18 May 2004 08:59:38 -0600
Subject: patch for nand support linux-2.4.21 jffs2?
Message-ID: <C86A9402F6A07E47B2F50A302DFA9BAE044C61@alm-exch.europe.echostar.com>

Ay!, I guess that means I'm looking at a fairly big merging effort, since
using 2.4.26 is unfortunally not an option for me (we already ported 2.4.21
to an embedded platform).

Do you guess merging the 2.4.26 mtd/jffs2 code into the 2.4.21 kernel is the
(feasible) approach which most likely will take the least effort?, or is
that likely just as much work as trying to merge the latest snapshot into
the 2.4.21 kernel?

Thanx in advance,

-----Original Message-----
From: David Woodhouse [mailto:dwmw2 at infradead.org] 
Sent: Tuesday, May 18, 2004 4:29 PM
To: Teuling, Sieme
Cc: 'linux-mtd at lists.infradead.org'
Subject: Re: patch for nand support linux-2.4.21 jffs2?


On Tue, 2004-05-18 at 08:07 -0600, Teuling, Sieme wrote:
> Is this a known problem with a know solution?

Problem and solution are 2.4.21 and 2.4.26 respectively.

-- 
dwmw2


From dwmw2 at infradead.org  Tue May 18 11:10:13 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 18 May 2004 16:10:13 +0100
Subject: patch for nand support linux-2.4.21 jffs2?
In-Reply-To: <C86A9402F6A07E47B2F50A302DFA9BAE044C61@alm-exch.europe.echostar.com>
References: 
	 <C86A9402F6A07E47B2F50A302DFA9BAE044C61@alm-exch.europe.echostar.com>
Message-ID: <1084893013.28151.2.camel@hades.cambridge.redhat.com>

On Tue, 2004-05-18 at 08:59 -0600, Teuling, Sieme wrote:
> Ay!, I guess that means I'm looking at a fairly big merging effort, since
> using 2.4.26 is unfortunally not an option for me (we already ported 2.4.21
> to an embedded platform).

The changes from 2.4.21 to 2.4.26 should be relatively easy to merge.
Save yourself the heartache and just do it. As an added bonus you get a
kernel which isn't remotely exploitable.

> Do you guess merging the 2.4.26 mtd/jffs2 code into the 2.4.21 kernel is the
> (feasible) approach which most likely will take the least effort?, or is
> that likely just as much work as trying to merge the latest snapshot into
> the 2.4.21 kernel?

The only way you'll get it working is if you start backporting changes
in the core VFS code from 2.4.26. 

Put 2.4.21 into CVS, update the CVS tree to 2.4.26 too. Now check out
2.4.21 and apply your own patches, having made sure there's no
gratuitous whitespace noise in your changes. Then CVS update and you
should find it's fairly easy to make it work.

-- 
dwmw2



From wookey at aleph1.co.uk  Tue May 18 14:20:03 2004
From: wookey at aleph1.co.uk (Wookey)
Date: Tue, 18 May 2004 19:20:03 +0100
Subject: blkmtd (and YAFFS)
In-Reply-To: <20040518070547.9FF6D5209@blood.actrix.co.nz>
References: <20040517163945.GJ12570@knossos.aleph1.co.uk>
	<20040518070547.9FF6D5209@blood.actrix.co.nz>
Message-ID: <20040518182003.GH12570@knossos.aleph1.co.uk>

+++ Charles Manning [04-05-18 14:41 +1200]:
> As David already pointed out, CF hides the ECC stuff (indeed some CF is not 
> even based on NAND flash) 

It didn't used to be - I assume it pretty-well all is these days.

> so YAFFS is probably not really the best choice.

OK.

> > I know we're not supposed to talk about CF cards here, but I'm not sure who
> > else to ask about this...
> 
> Yes, mentioning CF on mtd is poor form :-).
> >
> > We have recently found that it's very easy to wear out crummy CF cards
> > using conventional disk-journalling systems (ext3 wears a hole in the end
> > of a 512MB flash card in <10 reboots) because every write goes through the
> > journal section of the device, and clearly its internal controller is doing
> > a very simple sector->flashpage mapping (yes, we should have turned off
> > atime, but still it's amazingly exactly not what you wanted :-)
> >
> > So what I really want to do is use something that distributes the writes
> > better than the internal controller so I'm thinking that YAFFS or JFFS2
> > should do a better job, but still give us journalling/power fail safety.
> >
> > blkmtd appears to allow this but I see few mentions of it since early 2002.
> > Is it stable, does it work, has anyone ever tried it with YAFFS?
> 
> CF always has been and always will be a "Kleenex technology" for the consumer 
> market. Designing it in as part of a rugged system has always been ill 
> advised.

I'm well aware of how crap it is, but the problem is that we have a consumer
device that uses CF cards (and MMC, and internal NAND). Now it's being
Linuxified we want to make the CF as 'least-bad' as possible.

> CF controllers don't do explicit wear levelling. At least some do "implicit 
> wear levelling"  by using a free pool rather like SmartMedia does. It would 
> appear though that some don't even do that.
> 
> CF cards do not necessarily fail due to wear-out. They can get screwed up by 
> corrupting their logical to physical mapping which I hunch is the more likely 
> scenario. If this is happening then extra wear levelling is not going to help.

OK. In this case reformatting didn't work but making the partition 32MB
smaller and thus avoiding the flash previously used by the ext3 journal
fixed the problem. It is possible that the controller got confused, or that
it simply started to run out of spare blocks to fill in holes with - it is
of course very hard to know when given a block box like this.


> > Is there a better FS for this purpose (anyone know if reiserfs helps
> > distribute writes around your 'disk' at all?)
> 
> You're making the (possibly invalid) assumption that your failures are due to 
> wear out. If that is indeed the case then some such wear levelling fs might 
> help. 
> 
> The biggest problem I see is that YAFFS and JFFSx achieve their robustness by 
> dealing with the flash directly and do not have logical to physical mapping 
> layers. Balancing YAFFS of JFFSx on top of something that relies on a logical 
> to physical mapping just gives a false sense of security since there is no 
> mechanism to repair errors at that level.
>
> Both YAFFS anf JFFSx are journaling/log structured file systems. They can 
> cope with write failures and can handle unclean dismounts, but they cannot 
> recover data that has been lost; for that you need a RAID system or such. A 
> corruption in a CF card results in lost info which will not be recoverable.

Yes, but we are relying on the CF card controller to substitute bad sectors
and essentialy say to the filesystem layer that 'everything is always OK'.

The 'problem' we want to address is not using a filesystem that does a lot
of writing in one place (e.g FAT cluster table on every write, ext2 inode
tables on every write? (I don't know how spread about these are).

A log-structure Filing system, even without the error-checking and bad-block
detection, should still spread it's writes out relatively helpfully.

Are you sure it's of no benefit to use them over a CF controller?

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/


From manningc2 at actrix.gen.nz  Tue May 18 19:13:38 2004
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Wed, 19 May 2004 11:13:38 +1200
Subject: blkmtd (and YAFFS)
In-Reply-To: <20040518182003.GH12570@knossos.aleph1.co.uk>
References: <20040517163945.GJ12570@knossos.aleph1.co.uk>
	<20040518070547.9FF6D5209@blood.actrix.co.nz>
	<20040518182003.GH12570@knossos.aleph1.co.uk>
Message-ID: <20040518231540.D9BEC47D4@blood.actrix.co.nz>


> > Both YAFFS anf JFFSx are journaling/log structured file systems. They can
> > cope with write failures and can handle unclean dismounts, but they
> > cannot recover data that has been lost; for that you need a RAID system
> > or such. A corruption in a CF card results in lost info which will not be
> > recoverable.
>
> Yes, but we are relying on the CF card controller to substitute bad sectors
> and essentialy say to the filesystem layer that 'everything is always OK'.
>
> The 'problem' we want to address is not using a filesystem that does a lot
> of writing in one place (e.g FAT cluster table on every write, ext2 inode
> tables on every write? (I don't know how spread about these are).

This assumes that the failure is caused by endurance issues and that the 
flash is "wearing out".  Given the number of times I've seen CF cards go 
stupid (even when very new and in very low usage) I doubt this theory very 
much. I suspect that the most common wonkiness is caused by logical to 
physical mapping errors or some such.
>
> A log-structure Filing system, even without the error-checking and
> bad-block detection, should still spread it's writes out relatively
> helpfully.
>
> Are you sure it's of no benefit to use them over a CF controller?
>

Perhaps there is, but my main point is that no matter what you balance on top 
of CF you can't see stuff that got lost by some internal CF screwup.

Where a log structured or transaction based fs should help is in being able 
to at least save some parts of the fs that might get lost in a FAT fsor might 
help recover data that goes missing (by using a back-up).

Of course the less you write, the less chance there is of messing things up.

-- CHarles



From simon at baydel.com  Wed May 19 05:55:06 2004
From: simon at baydel.com (Simon Haynes)
Date: Wed, 19 May 2004 10:55:06 +0100
Subject: patch for nand support linux-2.4.21 jffs2?
In-Reply-To: <C86A9402F6A07E47B2F50A302DFA9BAE044C61@alm-exch.europe.echostar.com>
Message-ID: <40AB3D0A.13074.1F3574@localhost>

On 18 May 2004 at 8:59, Teuling, Sieme wrote:

> Ay!, I guess that means I'm looking at a fairly big merging effort,
> since using 2.4.26 is unfortunally not an option for me (we already
> ported 2.4.21 to an embedded platform).

I used an ilookup patch for 2.4.21 and this seemed to work for me.
I got mine from the web but I think there is a patch in cvs mtd/patches

Cheers

Simon.

__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon at baydel.com
__________________________



From dwmw2 at infradead.org  Wed May 19 06:09:27 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 19 May 2004 11:09:27 +0100
Subject: patch for nand support linux-2.4.21 jffs2?
In-Reply-To: <40AB3D0A.13074.1F3574@localhost>
References: <40AB3D0A.13074.1F3574@localhost>
Message-ID: <1084961366.28151.56.camel@hades.cambridge.redhat.com>

On Wed, 2004-05-19 at 10:55 +0100, Simon Haynes wrote:
> On 18 May 2004 at 8:59, Teuling, Sieme wrote:
> 
> > Ay!, I guess that means I'm looking at a fairly big merging effort,
> > since using 2.4.26 is unfortunally not an option for me (we already
> > ported 2.4.21 to an embedded platform).
> 
> I used an ilookup patch for 2.4.21 and this seemed to work for me.
> I got mine from the web but I think there is a patch in cvs mtd/patches

It's buggy. There are other fixes to it in 2.4.26.

-- 
dwmw2



From munro.biswal at smartbridges.com  Thu May 20 07:43:29 2004
From: munro.biswal at smartbridges.com (Munro Biswal)
Date: Thu, 20 May 2004 11:43:29 +0000
Subject: Read only jffs2 filesystem
Message-ID: <40AC99E1.40904@smartbridges.com>

Iam using a 6 MTD partition structure wherein i have two jffs2 
    filesystems and when i boot up, it  mounts the filesystem as  
    readonly.Even if i reboot my board, i get the root filesystem to be 
    mounted readonly.
    I cannot write anything to the filesystem
    What could be the problem??
    

Thanks in advance!
Regards,
Munro.




From waite at skycomputers.com  Thu May 20 08:33:05 2004
From: waite at skycomputers.com (Brian Waite)
Date: Thu, 20 May 2004 08:33:05 -0400
Subject: Read only jffs2 filesystem
In-Reply-To: <40AC99E1.40904@smartbridges.com>
References: <40AC99E1.40904@smartbridges.com>
Message-ID: <200405200833.05829.waite@skycomputers.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the default mount options are ro for mtd. To change this, , you can do 
2 things:

1) On the Linux cmdline root=/dev/mtdblockN rw
2) From the prompt/init scripts:  mount -oremount,rw -t jffs2 /dev/mtdblockN /

Or you may have set the partitions to be read only oin the MTD map you 
created. (Check the mask_flags) 

Finally, depending on your FLASH chips, the chips may always powerup in the 
Locked state, mine do, and you will need to unlock them before writing. I do 
thins under u-boot but iy could also be done with the unlock mtd command.

Those are my suggestions.

Thanks
Brian


On Thursday 20 May 2004 07:43 am, Munro Biswal wrote:
> Iam using a 6 MTD partition structure wherein i have two jffs2
>     filesystems and when i boot up, it  mounts the filesystem as
>     readonly.Even if i reboot my board, i get the root filesystem to be
>     mounted readonly.
>     I cannot write anything to the filesystem
>     What could be the problem??
>
>
> Thanks in advance!
> Regards,
> Munro.
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFArKWBmxLCz0u+Ko8RAkvjAKCltIjy5NZBFoe4/VsYrD46TuxQbgCfbYIX
yr3/q4S8Juq4vFXF6HOr7Co=
=2hU/
-----END PGP SIGNATURE-----


From dwmw2 at infradead.org  Thu May 20 10:23:47 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 20 May 2004 15:23:47 +0100 (BST)
Subject: Administivia -- mailing list server changes.
Message-ID: <Pine.LNX.4.44.0405201507340.17303-100000@pentafluge.infradead.org>


The mailing lists I run have now been moved from pentafluge.infradead.org 
(physically hosted in Cambridge) to canuck.infradead.org (in Ottawa).

This is because I was given 48 hours notice that pentafluge has to be 
removed from its current home. This isn't even as long as my ex-employer 
gave me when they finally suggested I might like to remove a different 
machine two _years_ after I no longer worked there. No reason has been 
given for the sudden urgency of this.

Unfortunately, the result of this is that I haven't had time to wind down 
the DNS timeouts to give a smooth changeover -- so the MX, A and AAAA 
records for 'lists.infradead.org' will continue to point to the wrong 
place in many caches until some time next week.

The MX records shouldn't matter too much -- hence mail will keep working 
-- because canuck was already listed as a backup. For access to the 
mailman interface and the archives, you may need to know in the meantime 
that its IP addresses is 2002:cde9:d907::1 (or 205.233.217.7 for those of 
you still stuck on IPv4).

Obviously the changeover hasn't been as well-planned and tested as I'd
like; please let me know if there are any problems.

The machine known as '{phoenix,cvs,www}.infradead.org' will also be made
homeless. I plan to move WWW services over to canuck some time today or
tomorrow once once I get bored of watching the mail logs for anomalies and
want something else to worry about.

A new home is being arranged, but the lead time for a DSL installation was
15 days, starting from two days ago. 

There exists a possibility that our esteemed IS folks won't _actually_
pull the plug with that little notice and reason; that they'll hear my
plea for a reasonable stay of execution while I'm waiting for the new home
to be made ready. If it _doesn't_ happen that way, then the CVS server
will probably be going IPv6-only on the wrong end of an ISDN line until
the new home is ready.

-- 
dwmw2




From gurhan at hatipoglu.biz  Thu May 20 08:38:40 2004
From: gurhan at hatipoglu.biz (Gurhan Hatipoglu)
Date: Thu, 20 May 2004 15:38:40 +0300
Subject: Fwd: NAND Flash Problem.
Message-ID: <200405201538.40677.gurhan@hatipoglu.biz>

Hello sir/madam;

I forwarded the message attached, by the advice of CVS group. Please inform me 
about the problem forwarded.

Thanks in advance.

Gurhan Hatipoglu
Alpamis Co.
-------------- next part --------------
An embedded message was scrubbed...
From: Gurhan Hatipoglu <gurhan at hatipoglu.biz>
Subject: NAND Flash Problem.
Date: Thu, 13 May 2004 11:32:39 +0300
Size: 3172
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20040520/9762e07b/attachment.mht 

From tglx at linutronix.de  Thu May 20 14:46:10 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 20 May 2004 20:46:10 +0200
Subject: Fwd: NAND Flash Problem.
In-Reply-To: <200405201538.40677.gurhan@hatipoglu.biz>
References: <200405201538.40677.gurhan@hatipoglu.biz>
Message-ID: <200405202046.10681.tglx@linutronix.de>

On Thursday 20 May 2004 14:38, Gurhan Hatipoglu wrote:
> Hello sir/madam;
>
> I forwarded the message attached, by the advice of CVS group. Please inform
> me about the problem forwarded.

CVS is no group. It's a read only mailing list which keeps you informed of 
changes in the CVS.

> I'm working on Hyundai GMS30C7201 board, using ARM Linux V.2.4.18 Rmk 3.

Is this the kernel from Hynix ? Use the reworked one available from my 
homepage.

> In addition to NOR Flash, we mounted KM29U64000T 64Kbit NAND flash on the
> board to use as a disk, I changed sample VIA board driver according to the
> directions given in the Document directory

Which version of MTD do you use ? The one in the kernel source ? 
Use latest MTD CVS code, as everything else does not properly support NAND.

> and by referencing addresses in
> hardware.h (NAND_BASE 0xf2000000, physical address is 0x08000000).
> When I boot the system, VM error is appearing, as below and system is
> crashing. When I test ioremap for physical address 0x0800000, system is
> giving no nand flash found message.

The pyhsical address must be converted to a virtual adress by ioremap. Get the 
physical address through which the NAND chip can be accessed. In your driver 
use: 
nand_virt = ioremap (nand_phys, SZ_1K);
nand_virt must be stored in the IO_ADDR_R and IO_ADDR_W members of the nand 
chip structure.

> Function entered at [<c0093284>] from [<c00952b0>]
> Function entered at [<c0095278>] from [<c000ee60>]
>  r8 = C00C2B44  r7 = C00C6C20  r6 = C01342E8  r5 = C00E6120
>  r4 = C0134260

Such a backtrace is worthless, as I dont know anything of your kernel. Decode 
it with ksymoops. Read linux/Documentation/oops-tracing.txt

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Mon May 24 07:42:34 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 24 May 2004 12:42:34 +0100
Subject: Linux MTD CVS / lists.infradead.org -- outage / relocation notice
Message-ID: <1085398954.27156.55.camel@imladris.demon.co.uk>

[ Reply-To set to personal reply. Please don't cross-post. ]

For some time now, the machines running mailing list and CVS services
for Linux MTD development have been on the public side of the Red Hat
Cambridge network. For generously allowing this I would like to thank
the previous manager of the Cambridge office, now with eCosCentric, and
the old sysadmin there, now also moved on.

Last week, some members of the Red Hat IS department took it upon
themselves to demand that the machines be removed. That in itself is not
entirely unreasonable -- but they gave such a short period of notice
that there wasn't enough time to arrange new locations for the machines.
In fact the disconnection was so hasty that there wouldn't even have
been enough notice to turn the DNS expiry times down for the changeover
had I the new homes been already arranged beforehand and had I been able
to move into them during the week.

Although I immediately started to arrange new locations, the Red Hat IS
team did not even do me the courtesy of replying to my email in which I
stated the time it would take to move the machines and requested an
extension of their arbitrarily short deadline to cover this.

However, the deadline of noon on Thursday passed, so I assumed that
sanity had prevailed. Unfortunately this was not the case; on Friday
morning I arrived at work to find that the machines had been
disconnected, still without the courtesy of a reply to my email.

Even now, no reason has been given for the sudden urgency of the
disconnection; no reason why it could not have been done with sufficient
notice to allow a smooth transition or indeed even a single weekend to
perform a more careful migration of services.

In the meantime, the lists.infradead.org mailing lists have been moved
to an alternative machine, which was already an MX backup so mailing
list traffic should continue to work. For list administration tasks, you
may need to use the IP address 2002:cde9:d907::1 or 205.233.217.7
instead of 'lists.infradead.org' until the DNS propagates. 

The CVS server, cvs.infradead.org aka phoenix.infradead.org, is
currently IPv6-only on 2002:c1ed:8229:10:2c0:f0ff:fe31:e18 and will
remain IPv6-only on a 64K ISDN line for the next couple of weeks until
its new home is ready. Those who use it for CVS access or for email and
have a real IPv4 address may want to investigate the three lines they
need to add to their networking config to get IPv6 connectivity using
6to4. Alternatively, contact me to arrange an account on another machine
in the cluster (which will of course be able to communicate with phoenix
via IPv6).

Web services will be coming back up within the next few days in another
location.

All these changes have been made at fairly short notice and without the
amount of planning I would normally have wanted. So please let me know
as soon as possible if anything seems (unexpectedly) wrong.

I apologise for the disruption caused by this unforeseen move. Although
caused by events not strictly within my control, I have to admit that I
have had cause to deal with these people before, and I do know what
they're like. I should not have allowed a situation to arise where a
group of such small-minded, obstructive little men could achieve such
disruption.

-- 
dwmw2




From john.carlos at atc.army.mil  Tue May 25 06:46:40 2004
From: john.carlos at atc.army.mil (Carlos, John J USAATC)
Date: Tue, 25 May 2004 06:46:40 -0400
Subject: DOC MD2811-D32  on Arm linux  seeking guidance???
Message-ID: <EFF9A3506F74924AB5CC77BDC66E79351812A1@atcml01.atc.army.mil>

Hello All,

  I have a development board with an OMAP5910 processor.  I patched my
2.4.21 kernel with the mtd snapshot 20040405.tar.gz.  I had to change how
ReadDOC and WriteDOC worked.  Seems that inw and outw work to access my
chip, the addressing must not be shifted properly for an arm core on my
board.  I had to put the proper wakeup sequence in the drivers and probing
functions.  I had to have 3 reads from offset 0x1fff and four write to
address 0x1006,0x1076,0x1006,0x1076 values 0x1c,0xe3,0x1d,0xe2.  After that
the chip could be read and the id read ID=0x40.  I had formatted the DOC
using the manufacturers console program to fat.  I start things up and you
can see the messages I get from my system.

I also tried the nand subsystem instead of the M-sys subsystem.  For some
reason the nand subsystem isn't passing the correct base I/O to nand_scan?
My question is which subsystem is preferred or better.  Are both subsystems
working fully?  Am I leaving something out?  Have I not prepared the DOC
properly so it can be used/mounted, and if not how should I prep it for
use??

Thanks for the help!
John 


M-sys output:

Using /lib/modules/2.4.21-rmk1-omap1/kernel/fs/fat/fat.o
# insmod vfat
Using /lib/modules/2.4.21-rmk1-omap1/kernel/fs/vfat/vfat.o
# insmod docecc
Using /lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/devices/docecc.o
# insmod nand_ids
Using /lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/nand/nand_ids.o
# insmod nand_ecc
Using /lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/nand/nand_ecc.o
# insmod nand
Using /lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/nand/nand.o
# insmod doc2001plus
Using
/lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/devices/doc2001plus.o
# insmod docprobe
Using /lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/devices/docprobe.o
Using configured DiskOnChip probe address 0xc000000
TP1
emifs_config=0x      12
emifs_cs3_config=0x    3331
emifs_cs0_config=0x  2130b0
emifs_cs0_config=0x  215051
mode is ?? 0x   1
ID is ?? 0x  40
read ID directly =0xffff
read CS3 directly =0x3331
read byte=0x  40
read word=0x  40
read long=0x      40
window=0xc2044000 reg=0x    1046 potential=0xc2044000
In DOCPROBE Toggle= 82
In DOCPROBE Toggle= 86
In DOCPROBE ChipID= 40
ID is ?? 0x  40
In DOCPROBE before case switch ChipID= 40
here in case 0 section
In DOCPROBEeck again ChipID= 64
TP3
TP3
TP2
TP4
DiskOnChip Millennium Plus found at address 0xC000000
mrf=0x  98 dummy=0x40
Flash chip found: Manufacturer ID: 98, Chip ID: A5 (Toshiba:NAND 2GiB 1,8V
8-bit
)
mrf=0x  91 dummy=0x491
1 flash chips found. Total DiskOnChip size: 2048 MiB
Division by zero in kernel.
Function entered at [<c00227c4>] from [<c0122728>]
Function entered at [<c00b7390>] from [<c00b8138>]
Function entered at [<c00b8120>] from [<c00b623c>]
Function entered at [<c00b61cc>] from [<c00b4894>]
 r7 = C0154058  r6 = C1CBD600  r5 = C0154130  r4 = C01541F0
Function entered at [<c00b4854>] from [<c00b03b8>]
 r6 = C1CBD600  r5 = C015406C  r4 = C0154158
Function entered at [<c00b0340>] from [<c203f9a0>]
 r7 = C2040250  r6 = C203FE1C  r5 = C203FA08  r4 = C203FDE4
Function entered at [<c203f834>] from [<c20425dc>]
Function entered at [<c2042060>] from [<c2042668>]
Function entered at [<c204263c>] from [<c002bd88>]
 r5 = 00000000  r4 = C2042000
Function entered at [<c002b690>] from [<c001d4e0>]
INFTL: could not find valid boot record?
INFTL: could not mount device
Division by zero in kernel.
Function entered at [<c00227c4>] from [<c0122728>]
Function entered at [<c00b512c>] from [<c00b5c9c>]
Function entered at [<c00b5c84>] from [<c00b4dc8>]
Function entered at [<c00b4d58>] from [<c00b4894>]
 r7 = C0154058  r6 = C1CBD600  r5 = C0154130  r4 = C0154194
Function entered at [<c00b4854>] from [<c00b03b8>]
 r6 = C1CBD600  r5 = C015406C  r4 = C0154158
Function entered at [<c00b0340>] from [<c203f9a0>]
 r7 = C2040250  r6 = C203FE1C  r5 = C203FA08  r4 = C203FDE4
Function entered at [<c203f834>] from [<c20425dc>]
Function entered at [<c2042060>] from [<c2042668>]
Function entered at [<c204263c>] from [<c002bd88>]
 r5 = 00000000  r4 = C2042000
Function entered at [<c002b690>] from [<c001d4e0>]
Could not find valid boot record
NFTL: could not mount device
insmod: init_module: docprobe: Resource temporarily unavailable
#


Nand subsytem output:

# insmod diskonchip
Using /lib/modules/2.4.21-rmk1-omap1/kernel/drivers/mtd/nand/diskonchip.o
Chip _D= 0x  40
Chip _D= 0x  40
Chip _D= 0x  40
mymtd.name= <NULL> #chips=0x  10
Entering In nand_scan IO_base=0x       0



From yoush at cs.msu.su  Tue May 25 12:52:05 2004
From: yoush at cs.msu.su (Nikita V. Youshchenko)
Date: Tue, 25 May 2004 20:52:05 +0400
Subject: Smartmedia block device code
Message-ID: <200405252052.05706@zigzag.lvk.cs.msu.su>

Hello.

AFAIK, linux-mtd still has no read-write SmartMedia driver.

About a year ago I created a driver that implements a read-write block 
device for SmartMedia nandflash, for an embedded device with arm processor 
running Linux 2.2.1 kernel. With this driver, card could be mounted 
read-write, file interchange with USB card readers was possible; also 
there is a number of ioctls() for lowlevel card access, and a user-level 
tool for doing low-level card manipulations.

I'm not interested in this code today (and I don't have hardware). However, 
maybe someone needs it?

It's attached, and also available from 
http://zigzag.lvk.cs.msu.su/~nikita/sm.tar.bz2

It does not use mtd infrastructure (AFAIK there was none in 2.2 kernel), 
and probably needs some obvious fixes to run on any kernel other than was 
used on that device. But is should be more or less trivial to port it to 
recent kernels and MTD infrastructure.

Nikita

P.S.
If you wish to reply, please CC: to yoush at cs.msu.su - I am not on the list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sm.tar.bz2
Type: application/x-tbz
Size: 14 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040525/144c07bd/attachment.bin 

From yoush at cs.msu.su  Tue May 25 15:02:59 2004
From: yoush at cs.msu.su (Nikita V. Youshchenko)
Date: Tue, 25 May 2004 23:02:59 +0400
Subject: Smartmedia block device code
In-Reply-To: <1085508830.3456.248.camel@hades.cambridge.redhat.com>
References: <200405252052.05706@zigzag.lvk.cs.msu.su>
	<1085508830.3456.248.camel@hades.cambridge.redhat.com>
Message-ID: <200405252302.59296@sercond.localdomain>


> On Tue, 2004-05-25 at 20:52 +0400, Nikita V. Youshchenko wrote:
> > Hello.
> >
> > AFAIK, linux-mtd still has no read-write SmartMedia driver.
> >
> > About a year ago I created a driver that implements a read-write block
> > device for SmartMedia nandflash, for an embedded device with arm
> > processor running Linux 2.2.1 kernel. With this driver, card could be
> > mounted read-write, file interchange with USB card readers was
> > possible; also there is a number of ioctls() for lowlevel card access,
> > and a user-level tool for doing low-level card manipulations.
> >
> > I'm not interested in this code today (and I don't have hardware).
> > However, maybe someone needs it?
>
> That's useful -- thanks.
>
> > It's attached, and also available from
> > http://zigzag.lvk.cs.msu.su/~nikita/sm.tar.bz2
>
> Unfortunately both seem to be an empty tar archive :)

Oh sorry, re-attaching and re-uploading ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sm.tar.bz2
Type: application/x-tbz
Size: 22462 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040525/8e3c28f2/attachment.bin 

From john.carlos at atc.army.mil  Wed May 26 08:25:23 2004
From: john.carlos at atc.army.mil (Carlos, John J USAATC)
Date: Wed, 26 May 2004 08:25:23 -0400
Subject: INFTL/DOC
Message-ID: <EFF9A3506F74924AB5CC77BDC66E79351812A2@atcml01.atc.army.mil>

Hello All,

  I have a DOC Mil plus 32Mb chip on a arm core board.  When I load the
inftl modules it places the 94 block device in the /proc/devices file but
doesn't find the DOC.  I am not sure if my problem is that I don't have a
memory map for the device?  When I load the diskonchip module the chip is
found by the first part but the address doesn't seem to get passed to the
nand_scan section.  What am I missing so that the DOC gets seen by the inftl
module?  Do I need a memory map if I am trying to ,mount the device
manually?  If so, should I be adding a map for the device in the maps
directory in the board specific source code? 

Thanks
John



From Daniel.Eisenhut at med.ge.com  Wed May 26 17:21:20 2004
From: Daniel.Eisenhut at med.ge.com (Eisenhut, Daniel (MED))
Date: Wed, 26 May 2004 16:21:20 -0500
Subject: Accessing an MTD device from kernel space
Message-ID: <77FE4A1FA59FF947845A42194AD6676202E30F72@uswaumsx07medge.med.ge.com>

To list,

I've successfully setup MTD devices for our NOR flash chips and
everything is working great from userspace.  But I have a need to access
the NOR flash from within kernelspace, such as in a /proc entry.

What is the best way to access the flash from within the kernel?  The
only way I've be able to so far is to just dereference a pointer
pointing to the flash address.  But this creates two issues (that I know
about):

1. A race condition between my proc entry that reads the flash and
another process using the MTD device.

2. The MTD device does not always leave the flash chip in read mode.

Is there anything setup in the current MTD code to allow access from
within the kernel?

Thanks...
Dan



From tglx at linutronix.de  Wed May 26 17:26:29 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 26 May 2004 23:26:29 +0200
Subject: Accessing an MTD device from kernel space
In-Reply-To: <77FE4A1FA59FF947845A42194AD6676202E30F72@uswaumsx07medge.med.ge.com>
References: <77FE4A1FA59FF947845A42194AD6676202E30F72@uswaumsx07medge.med.ge.com>
Message-ID: <200405262326.29385.tglx@linutronix.de>

On Wednesday 26 May 2004 23:21, Eisenhut, Daniel (MED) wrote:
> To list,
>
> I've successfully setup MTD devices for our NOR flash chips and
> everything is working great from userspace.  But I have a need to access
> the NOR flash from within kernelspace, such as in a /proc entry.
>
> What is the best way to access the flash from within the kernel?  The
> only way I've be able to so far is to just dereference a pointer
> pointing to the flash address.  But this creates two issues (that I know
> about):
>
> 1. A race condition between my proc entry that reads the flash and
> another process using the MTD device.
>
> 2. The MTD device does not always leave the flash chip in read mode.
>
> Is there anything setup in the current MTD code to allow access from
> within the kernel?

Just use the mtd API which is used from fs drivers and anything else which 
accessed the mtd devices from kernel space

mtd->read(....), mtd->erase(...) 

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From deisenhut at wi.rr.com  Wed May 26 19:38:34 2004
From: deisenhut at wi.rr.com (Dan Eisenhut)
Date: Wed, 26 May 2004 18:38:34 -0500
Subject: Accessing an MTD device from kernel space
In-Reply-To: <200405262326.29385.tglx@linutronix.de>
References: <77FE4A1FA59FF947845A42194AD6676202E30F72@uswaumsx07medge.med.ge.com>
	<200405262326.29385.tglx@linutronix.de>
Message-ID: <1085614713.9876.4.camel@localhost>

On Wed, 2004-05-26 at 16:26, Thomas Gleixner wrote:
> Just use the mtd API which is used from fs drivers and anything else which 
> accessed the mtd devices from kernel space
> 
> mtd->read(....), mtd->erase(...) 

Thanks...  I dug through the fs/jffs2 directory and figured out how to
use the get_mtd_device() and mtd->read() functions.  Its working great.

Dan




From wh3cq at hotmail.com  Thu May 27 05:11:00 2004
From: wh3cq at hotmail.com (w h)
Date: Thu, 27 May 2004 09:11:00 +0000
Subject: about syncflash lock and jffs2
Message-ID: <BAY19-F21ZFkTEPcOhN0005664a@hotmail.com>

Hi,everyone:

I've worked on Moto Dragonball MX9328MXL for more than 4 months and on 
jffs2 for about two months. But Now some problems in mtd and jffs2 trouble 
me so much that I almost tear my hair and can do nothing. I do need some 
help.

I try to use jffs2 as root filesystem on SyncFlash(micron mt28s4m16lc_6, 
two chips, total 16M) in my board. Linux OS and jffs2 root fs can start up 
but with some infomation like this:
...
Erase at ****(some address) failed immediately:-EROFS.Is the sector locked?
Erase at ****(some address) failed immediately:-EROFS.Is the sector locked?
Erase at ****(some address) failed immediately:-EROFS.Is the sector locked?
Erase at ****(some address) failed immediately:-EROFS.Is the sector locked?
Erase at ****(some address) failed immediately:-EROFS.Is the sector locked?
Erase at ****(some address) failed immediately:-EROFS.Is the sector locked?
...

after it starts up, I run 
#cat /proc/mtd
dev:         size       erasesize    name
mtd0:     00100000       20000    bootloader
mtd0:     00200000       20000    kernel
mtd2:     00B00000       20000    filesystem
mtd3:     00200000       20000    fdisk

but if I try to "mkdir" or save file in some directory,it gives "Permission 
denied"

if running "cat /proc/mounts", I can see: 
/dev/mtdblock/2 / jffs2 rw 0 0 
???????????? 
???????????? 
#df 
filesystem           1k -block    used    available use% mounted on 
/dev/mtdblock/2    13312       13312        0       100%     / 
?????????????????????????????? 
?????????????????????????????? 
the size of filesystem partition is 11M , the jffs2.img which I download 
only takes up 6M, how dose "use%=100%" come from? 

What I use is SyncFlash(micron mt28s4m16lc_6, two chips, total 16M), is it 
posssible that the SyncFlash is locked(refer to the startup information) so 
I can't "mkdir" or save file?
Does anyone know the specific parameters when using command "unlock"?

Thanks.

Best Reguard to everyone who see this mail,
susan

_________________________________________________________________
??????????????? MSN Hotmail?  http://www.hotmail.com  




From john.carlos at atc.army.mil  Thu May 27 07:56:45 2004
From: john.carlos at atc.army.mil (Carlos, John J USAATC)
Date: Thu, 27 May 2004 07:56:45 -0400
Subject: Help with DOC Mil Plus
Message-ID: <EFF9A3506F74924AB5CC77BDC66E79351812A3@atcml01.atc.army.mil>

I am having major problems.  I have 2.4.21 running on an arm core.  I have
patched mtd with a recent snapshot.  I have had addressing problems with the
way the manufacturer designed the board.  Inw and Outw work with the chip.
I can read the chip ID reg but when DoC_ScanChips runs I get the wrong size
of the chip.  Looking at the code the size is a function of chipshift.  Can
someone explain what the chipshift variable represents????  I am not having
much luck getting the DOC to work, I could really use some help.......

Thanks,
John



From a.hawkins at cabletime.com  Fri May 28 05:41:29 2004
From: a.hawkins at cabletime.com (Andy Hawkins)
Date: 28 May 2004 10:41:29 +0100
Subject: Large flash concatenation
Message-ID: <1085737289.5617.3.camel@adh>

Hi,

I'm trying to add support to the kernel for concatenating a number of
large flash devices (1Gb Samsung K9F1G08).

I've added the following line to nand_ids.c:

	{"NAND 1GiB 3,3V", 0xf1, 30, 0x4000, 0},

and the devices are correctly detected (I've also written the required
code in drivers/mtd/nand), showing a size of 0x40000000 for each device.
However, when I concatenate 15 of these devices, I end up with a
partition of size 0xc000000. I assume that this is because the total
size is stored in 32 bits, and as such is overflowing.

I want to be able to use these multiple chips as a single flash
filesystem (probably JFFS2).

Can anyone help as to how I can do this?

Many thanks.

Andy





From dwmw2 at infradead.org  Fri May 28 06:22:18 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 28 May 2004 11:22:18 +0100
Subject: Help with DOC Mil Plus
In-Reply-To: <EFF9A3506F74924AB5CC77BDC66E79351812A3@atcml01.atc.army.mil>
References: <EFF9A3506F74924AB5CC77BDC66E79351812A3@atcml01.atc.army.mil>
Message-ID: <1085739737.26119.50.camel@hades.cambridge.redhat.com>

On Thu, 2004-05-27 at 07:56 -0400, Carlos, John J USAATC wrote:
> I am having major problems.  I have 2.4.21 running on an arm core.  I have
> patched mtd with a recent snapshot.  I have had addressing problems with the
> way the manufacturer designed the board.  Inw and Outw work with the chip.
> I can read the chip ID reg 

What are the IDs you read from the chip? Precisely what model of chip is
it? Can you show the actual kernel output?

>  Looking at the code the size is a function of chipshift.  Can
> someone explain what the chipshift variable represents????  

log2 of chip size.

-- 
dwmw2




From dwmw2 at infradead.org  Fri May 28 06:28:43 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 28 May 2004 11:28:43 +0100
Subject: Large flash concatenation
In-Reply-To: <1085737289.5617.3.camel@adh>
References: <1085737289.5617.3.camel@adh>
Message-ID: <1085740123.26119.62.camel@hades.cambridge.redhat.com>

On Fri, 2004-05-28 at 10:41 +0100, Andy Hawkins wrote:
> Hi,
> 
> I'm trying to add support to the kernel for concatenating a number of
> large flash devices (1Gb Samsung K9F1G08).
> 
> I've added the following line to nand_ids.c:
> 
> 	{"NAND 1GiB 3,3V", 0xf1, 30, 0x4000, 0},

Er, that part is 1Gib, not 1GiB. 1Gib is 128MiB.

> I want to be able to use these multiple chips as a single flash
> filesystem (probably JFFS2).

That's a lot of flash -- JFFS2 doesn't scale too well at the moment.

To make JFFS2 work better, we need to reduce the memory usage -- partly
by reducing the size of some structures (we can drop totlen from the
jffs2_raw_node_ref with a bit of effort), and partly by reducing the
_number_ of such structures -- perhaps we should increase the maximum
data payload on a single node from 4KiB to 16KiB or more -- thereby
reducing the number of nodes a lot.

We also really need to do checkpointing to reduce mount time.

It would be interesting to try JFFS2 -- but I suspect you may do better
with YAFFS2 at the moment.

-- 
dwmw2




From tglx at linutronix.de  Fri May 28 06:27:34 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 28 May 2004 12:27:34 +0200
Subject: Large flash concatenation
In-Reply-To: <1085737289.5617.3.camel@adh>
References: <1085737289.5617.3.camel@adh>
Message-ID: <200405281227.34312.tglx@linutronix.de>

On Friday 28 May 2004 11:41, Andy Hawkins wrote:
> Hi,
>
> I'm trying to add support to the kernel for concatenating a number of
> large flash devices (1Gb Samsung K9F1G08).
>
> I've added the following line to nand_ids.c:
>
> 	{"NAND 1GiB 3,3V", 0xf1, 30, 0x4000, 0},
>
> and the devices are correctly detected (I've also written the required
> code in drivers/mtd/nand), showing a size of 0x40000000 for each device.

The device size is not 1GiB in words: One GigaByte.
The device size for chips with the id code 0xf1 is
1 GigaBit which is 128 MegaByte

The erasesize is wrong, as it is 64KiB and not 16KiB, but see below (1.)

> However, when I concatenate 15 of these devices, I end up with a
> partition of size 0xc000000. I assume that this is because the total
> size is stored in 32 bits, and as such is overflowing.

15 * 128 Megabyte =  2013265920 Bytes = 0x78000000
which fits into 32 bit

1. Please use the latest NAND code, as the support for the larger devices is 
already there and the old code does not handle the large page devices.
We have actually problems with CVS access (is IPV6 only). I can provide a 
current snapshot on request.

2. The nand driver itself can handle multiple chips now. The scan function
supports multiple chip detection. Do not use the concat function for this 
purpose. The chips are provided as one big device to the MTD layer if you do 
not use partitions.

> I want to be able to use these multiple chips as a single flash
> filesystem (probably JFFS2).

It might turn out that JFFS2 is not the first choice for this concatenated 
device size, but it should work. Maybe YAFFS2 would be more suitable. It's 
not released yet AFAIK, but it should be available soon. 

You can join #mtd on irc.freenode.net if you want.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From a.hawkins at cabletime.com  Fri May 28 06:42:42 2004
From: a.hawkins at cabletime.com (Andy Hawkins)
Date: 28 May 2004 11:42:42 +0100
Subject: Large flash concatenation
In-Reply-To: <200405281227.34312.tglx@linutronix.de>
References: <1085737289.5617.3.camel@adh>
	<200405281227.34312.tglx@linutronix.de>
Message-ID: <1085740962.5617.9.camel@adh>

Hi,

Thanks to both Thomas and David for replying.

On Fri, 2004-05-28 at 11:27, Thomas Gleixner wrote:
> 1. Please use the latest NAND code, as the support for the larger devices is 
> already there and the old code does not handle the large page devices.
> We have actually problems with CVS access (is IPV6 only). I can provide a 
> current snapshot on request.

I'm now doing that. I've downloaded the latest snapshot
(mtd-snapshot-20040527.tar.bz2) and am trying to get it to compile now.

> 2. The nand driver itself can handle multiple chips now. The scan function
> supports multiple chip detection. Do not use the concat function for this 
> purpose. The chips are provided as one big device to the MTD layer if you do 
> not use partitions.

How do I do this? Each chip appears at a separate address (we've used
the lower 6 bits of the address lines to decode the chip selects for
each chip). At the moment, I'm looping over all the possible addresses
calling 'nand_scan' at each address. Is this this correct way to do
this?

> It might turn out that JFFS2 is not the first choice for this concatenated 
> device size, but it should work. Maybe YAFFS2 would be more suitable. It's 
> not released yet AFAIK, but it should be available soon. 

We haven't made a final choice of filesystem as of yet, I just want to
get the devices up and running so that I can write / read them (to prove
our hardware design is correct).

> You can join #mtd on irc.freenode.net if you want.

That might be a good idea. Thanks for letting me know about that.

Andy





From tglx at linutronix.de  Fri May 28 06:44:57 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 28 May 2004 12:44:57 +0200
Subject: Large flash concatenation
In-Reply-To: <1085740962.5617.9.camel@adh>
References: <1085737289.5617.3.camel@adh>
	<200405281227.34312.tglx@linutronix.de>
	<1085740962.5617.9.camel@adh>
Message-ID: <200405281244.57973.tglx@linutronix.de>

On Friday 28 May 2004 12:42, Andy Hawkins wrote:
> Hi,
>
> Thanks to both Thomas and David for replying.
>
> On Fri, 2004-05-28 at 11:27, Thomas Gleixner wrote:
> > 1. Please use the latest NAND code, as the support for the larger devices
> > is already there and the old code does not handle the large page devices.
> > We have actually problems with CVS access (is IPV6 only). I can provide a
> > current snapshot on request.
>
> I'm now doing that. I've downloaded the latest snapshot
> (mtd-snapshot-20040527.tar.bz2) and am trying to get it to compile now.

The snapshot is outdated due to the same reason. I'm building one and putting 
it somewhere for download.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From a.hawkins at cabletime.com  Fri May 28 06:58:53 2004
From: a.hawkins at cabletime.com (Andy Hawkins)
Date: 28 May 2004 11:58:53 +0100
Subject: Large flash concatenation
In-Reply-To: <200405281244.57973.tglx@linutronix.de>
References: <1085737289.5617.3.camel@adh>
	<200405281227.34312.tglx@linutronix.de> <1085740962.5617.9.camel@adh>
	<200405281244.57973.tglx@linutronix.de>
Message-ID: <1085741933.5617.11.camel@adh>

On Fri, 2004-05-28 at 11:44, Thomas Gleixner wrote:
> The snapshot is outdated due to the same reason. I'm building one and putting 
> it somewhere for download.

Excellent, I'll hold off until your one is ready then.

Many thanks.

Andy





From tglx at linutronix.de  Fri May 28 07:15:42 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 28 May 2004 13:15:42 +0200
Subject: Large flash concatenation
In-Reply-To: <1085741933.5617.11.camel@adh>
References: <1085737289.5617.3.camel@adh>
	<200405281244.57973.tglx@linutronix.de>
	<1085741933.5617.11.camel@adh>
Message-ID: <200405281315.42825.tglx@linutronix.de>

On Friday 28 May 2004 12:58, Andy Hawkins wrote:
> On Fri, 2004-05-28 at 11:44, Thomas Gleixner wrote:
> > The snapshot is outdated due to the same reason. I'm building one and
> > putting it somewhere for download.
>
> Excellent, I'll hold off until your one is ready then.

http://www.linutronix.de/data/mtd-20040528-tglx-1.tar.bz2

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From tglx at linutronix.de  Fri May 28 07:20:53 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 28 May 2004 13:20:53 +0200
Subject: Large flash concatenation
In-Reply-To: <1085740962.5617.9.camel@adh>
References: <1085737289.5617.3.camel@adh>
	<200405281227.34312.tglx@linutronix.de>
	<1085740962.5617.9.camel@adh>
Message-ID: <200405281320.53554.tglx@linutronix.de>

On Friday 28 May 2004 12:42, Andy Hawkins wrote:
> Hi,
>
> > 2. The nand driver itself can handle multiple chips now. The scan
> > function supports multiple chip detection. Do not use the concat function
> > for this purpose. The chips are provided as one big device to the MTD
> > layer if you do not use partitions.
>
> How do I do this? Each chip appears at a separate address (we've used
> the lower 6 bits of the address lines to decode the chip selects for
> each chip). At the moment, I'm looping over all the possible addresses
> calling 'nand_scan' at each address. Is this this correct way to do
> this?

nand_scan now takes a parameter maxchips. This tells nand_scan to scan for up 
to maxchips chips.

The selection is simple. Only one chip can be selected at a time. 
All you have to do is write your own select_chip function and set the function 
pointer in the nand chip structure to this function before calling nand_scan

the function gets the chipnr (0 - maxchip-1) which should be selected or -1 to 
deselect.
Inside this function you simply modify the IO_ADDR_R and IO_ADDR_W fields of 
the nand structure so the appropriate chip gets selected.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From rschmitt at bluepeach.com  Fri May 28 07:40:07 2004
From: rschmitt at bluepeach.com (Richard Schmitt)
Date: Fri, 28 May 2004 07:40:07 -0400 (EDT)
Subject: NAND Bad Block Algorithm, JFFS2, and CRAMFS
Message-ID: <65335.10.0.1.2.1085744407.squirrel@mail.bluepeach.com>


We are using JFFS2 on NAND devices and are currently running into a
problem that I was hoping to get some guidance on.

We've created a 14MB partition.  We've configured the NAND driver to -
Verify Writes
- Enable ECC
- Disable Bad Block Checking

We've disabled Bad Block checking because as we understand it, this must
be disabled in order to support JFFS2.  I have a question on this that
I'll raise a bit further on.

We can copy a 64K jffs2 image onto the flash and mount it without problem.
 When we try to copy a 7MB image onto the flash, the copy will fail with a
generic 'input/output error'.

Our hypothesis is that there is a bad block somewhere in the flash that is
not hit with the 64K image but is hit with the 7MB image.  Because of this
and with Verify Writes enabled, the copy will fail.

This brings us back to the question introduced earlier.  If we need to
disable bad block checking with NAND in order to support JFFS2, then how
do we copy a JFFS2 image onto the flash if the flash has a bad block in
it?

The second piece of this question is that we really wanted to support two
partitions, one with a JFFS2, and another with CRAMFS.  We wanted to run
with the bad block algorithm on CRAMFS and without it on the JFFS2 one.
We've heard rummblings that this is not supported. Is that true or is
there some way that we can get that to work.

Rich
-- 
Richard Schmitt
CTO
Blue Peach Solutions
Phone: 877.BLU.PEACH (877.258-7322) x 704
Fax: 508.302.6183
http://www.bluepeach.com








From tglx at linutronix.de  Fri May 28 08:56:34 2004
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 28 May 2004 14:56:34 +0200
Subject: NAND Bad Block Algorithm, JFFS2, and CRAMFS
In-Reply-To: <65335.10.0.1.2.1085744407.squirrel@mail.bluepeach.com>
References: <65335.10.0.1.2.1085744407.squirrel@mail.bluepeach.com>
Message-ID: <200405281456.34587.tglx@linutronix.de>

On Friday 28 May 2004 13:40, Richard Schmitt wrote:
> We are using JFFS2 on NAND devices and are currently running into a
> problem that I was hoping to get some guidance on.
>
> We've created a 14MB partition.  We've configured the NAND driver to -
> Verify Writes
> - Enable ECC
> - Disable Bad Block Checking

Which version of NAND are you using ? Where do you disable bad block checking 
- in nand_erase I assume ?

> We've disabled Bad Block checking because as we understand it, this must
> be disabled in order to support JFFS2.  I have a question on this that
> I'll raise a bit further on.

Why so ?

> We can copy a 64K jffs2 image onto the flash and mount it without problem.
>  When we try to copy a 7MB image onto the flash, the copy will fail with a
> generic 'input/output error'.

You _CANNOT_ copy with cp xyz /dev/mtdx, therefor we have mtdutils, nandwrite 
is your friend, buit it relies on the intact bad block information.

> Our hypothesis is that there is a bad block somewhere in the flash that is
> not hit with the 64K image but is hit with the 7MB image.  Because of this
> and with Verify Writes enabled, the copy will fail.

By disabling the bad block check in erase you have managed to destroy the bad 
block info. Hopefully you remember which blocks were bad so you can try to 
mark them as bad again. 

> This brings us back to the question introduced earlier.  If we need to
> disable bad block checking with NAND in order to support JFFS2, then how
> do we copy a JFFS2 image onto the flash if the flash has a bad block in
> it?

Who said that ?

> The second piece of this question is that we really wanted to support two
> partitions, one with a JFFS2, and another with CRAMFS.  We wanted to run
> with the bad block algorithm on CRAMFS and without it on the JFFS2 one.
> We've heard rummblings that this is not supported. Is that true or is
> there some way that we can get that to work.

Trusting rumblings is almost not a good idea.

There are some efforts to make CRAMFS work on top of NAND with respect to bad 
blocks. Other efforts are on the way to provide a SSFDC compatible glue 
layer.
The recent changes in NAND provide extended bad block support including flash 
based bad block tables. I really have no clue where this information comes 
from.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn?t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Fri May 28 09:14:10 2004
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 28 May 2004 14:14:10 +0100
Subject: Large flash concatenation
In-Reply-To: <200405281244.57973.tglx@linutronix.de>
References: <1085737289.5617.3.camel@adh>
	<200405281227.34312.tglx@linutronix.de> <1085740962.5617.9.camel@adh>
	<200405281244.57973.tglx@linutronix.de>
Message-ID: <1085750049.26119.198.camel@hades.cambridge.redhat.com>

On Fri, 2004-05-28 at 12:44 +0200, Thomas Gleixner wrote:
> The snapshot is outdated due to the same reason. I'm building one and putting 
> it somewhere for download.

The snapshots stopped working because CVS doesn't handle pserver on
IPv6. Anonymous CVS access is now done over SSH:

	export CVS_RSH=`which ssh`
	cvs -d :ext:anoncvs at cvs.infradead.org:/home/cvs co mtd

The snapshots should be up to date again starting from tonight's.

-- 
dwmw2




From confirm-unbounce-1085807169-184235986-23114 at yahoogroups.com  Sat May 29 02:38:07 2004
From: confirm-unbounce-1085807169-184235986-23114 at yahoogroups.com (Yahoo! Groups)
Date: 29 May 2004 06:38:07 -0000
Subject: Please reactivate your Yahoo! Groups account 
Message-ID: <BP22656.1085812687@yahoogroups.com>



Hello,

You belong to one or more email groups provided by Yahoo! Groups 
(groups.yahoo.com). Email from these groups can be recognized by
looking for a group name in the message Subject line, like
[pet-owners] or [music-fans].

Recently, messages sent to you from Yahoo! Groups have been
returned to us as undeliverable. To prevent any problems with your
email service, we have temporarily turned your Yahoo! Groups 
account OFF.

If you are reading this message now, the delivery problem appears to
be fixed. However, we won't know that the problem is fixed until you
tell us.

To turn your Yahoo! Groups account ON:

- Please REPLY to this message. Send that reply back to us without
changing anything.

OR

- While connected to the Internet, click on the following Web link (or
copy and paste it into your Web browser and hit the RETURN key):

  http://groups.yahoo.com/unbounce?adj=184235986,23114&p=1085807169 

Once we get a response from you, we will turn your Yahoo! Groups 
account back ON, and you will begin to receive messages from your
groups again.

After you respond, you can read any messages you might have missed
while your account was off by visiting:

  http://groups.yahoo.com/mygroups

Thank you for using Yahoo! Groups!


Yahoo! Groups Customer Care

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 






From gary at mlbassoc.com  Fri May 28 10:58:03 2004
From: gary at mlbassoc.com (Gary Thomas)
Date: Fri, 28 May 2004 08:58:03 -0600
Subject: MTD updates
Message-ID: <1085756283.26522.8.camel@hermes>

David,

Just a final check - here's what I propose to check in.  Note: I hope to
have these changes pushed into the Linux/PPC trees someday soon (I'm
working in it...)

-- 
Gary Thomas <gary at mlbassoc.com>
MLB Associates
-------------- next part --------------
? fs/jffs2/ecos/jffs2-200302041443.epk
? fs/jffs2/ecos/jffs2-200311190423.epk
? fs/jffs2/ecos/jffs2-200312111628.epk
? fs/jffs2/ecos/jffs2-200402170804.epk
? fs/jffs2/ecos/jffs2-200403090905.epk
? fs/jffs2/ecos/jffs2-200403310527.epk
? fs/jffs2/ecos/jffs2-200403312046.epk
? fs/jffs2/ecos/jffs2-200404211238.epk
Index: drivers/mtd/maps/Config.in
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/maps/Config.in,v
retrieving revision 1.67
diff -u -5 -p -r1.67 Config.in
--- drivers/mtd/maps/Config.in	12 Apr 2004 06:38:39 -0000	1.67
+++ drivers/mtd/maps/Config.in	28 May 2004 14:54:32 -0000
@@ -33,10 +33,11 @@ if [ "$CONFIG_X86" = "y" ]; then
    dep_tristate '  CFI Flash device mapped on SnapGear/SecureEdge' CONFIG_MTD_NETtel $CONFIG_MTD_PARTITIONS
    dep_tristate '  BIOS flash chip on Intel SCB2 boards' CONFIG_MTD_SCB2_FLASH $CONFIG_MTD_GEN_PROBE
 fi
 
 if [ "$CONFIG_PPC32" = "y" ]; then
+  dep_tristate '  CFI Flash device mapping exported by RedBoot' CONFIG_MTD_CFI_REDBOOT $CONFIG_MTD_CFI
   if [ "$CONFIG_6xx" = "y" -a "$CONFIG_8260" = "y" ]; then
     dep_tristate '  Flash device on SBC8240' CONFIG_MTD_SBC8240 $CONFIG_MTD_JEDECPROBE
   fi
   if [ "$CONFIG_8xx" = "y" ]; then
     if [ "$CONFIG_TQM8xxL" = "y" ]; then
Index: drivers/mtd/maps/Makefile.common
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/maps/Makefile.common,v
retrieving revision 1.11
diff -u -5 -p -r1.11 Makefile.common
--- drivers/mtd/maps/Makefile.common	13 May 2004 22:21:26 -0000	1.11
+++ drivers/mtd/maps/Makefile.common	28 May 2004 14:54:32 -0000
@@ -66,7 +66,8 @@ obj-$(CONFIG_MTD_ARCTIC)	+= arctic-mtd.o
 obj-$(CONFIG_MTD_H720X)		+= h720x-flash.o
 obj-$(CONFIG_MTD_SBC8240)	+= sbc8240.o
 obj-$(CONFIG_MTD_NOR_TOTO)	+= omap-toto-flash.o
 obj-$(CONFIG_MTD_MPC1211)	+= mpc1211.o
 obj-$(CONFIG_MTD_IXP4XX)	+= ixp4xx.o
+obj-$(CONFIG_MTD_CFI_REDBOOT)	+= redboot-mtd.o
 
 -include $(TOPDIR)/Rules.make
Index: drivers/mtd/maps/redboot-mtd.c
===================================================================
RCS file: drivers/mtd/maps/redboot-mtd.c
diff -N drivers/mtd/maps/redboot-mtd.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ drivers/mtd/maps/redboot-mtd.c	28 May 2004 14:54:32 -0000
@@ -0,0 +1,103 @@
+/*
+ * $Id: redboot-mtd.c,v 1.1.6.1 2004/05/28 12:19:31 gthomas Exp $
+ *
+ * Handle mapping of the flash on various Motorola PPC platforms
+ * Patterned after "rpxlite.c"
+ *
+ * Copyright (c) 2003, 2004 Gary Thomas <gary at mlbassoc.com>
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/io.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+
+#if 0
+#define dprintk(p) printk p
+#else
+#define dprintk(p)
+#endif
+
+extern int parse_cmdline_partitions(struct mtd_info *master, 
+				    struct mtd_partition **pparts,
+				    const char *mtd_id);
+
+static const char *probes[] = { "RedBoot", "cmdlinepart", NULL };
+
+static struct mtd_partition *mtd_parts;
+static struct mtd_info *mymtd;
+#define PROBETYPES { "cfi_probe", 0 }
+#define MTDID      "RedBoot-nor"    /* for mtdparts= partitioning */
+
+struct map_info redboot_mtd_map = {
+    .name = "PowerPC/RedBoot 8xx/8xxx boards",
+};
+
+int __init init_redboot_mtd(void)
+{
+    struct mtd_partition *parts;
+    int nb_parts = 0;
+    int parsed_nr_parts = 0;
+    char *part_type;
+    bd_t *bp = (bd_t *)__res;
+
+    redboot_mtd_map.phys = bp->bi_flashbase;
+    redboot_mtd_map.size = bp->bi_flashsize;
+    redboot_mtd_map.buswidth = bp->bi_flashwidth/8;
+    redboot_mtd_map.virt = (unsigned long)ioremap(bp->bi_flashbase, bp->bi_flashsize);
+    if (!redboot_mtd_map.virt) {
+        printk("%s: can't ioremap FLASH\n", __FUNCTION__);
+        return -EIO;
+    }
+    printk("PowerPC/RedBoot 8xx/8xxx flash device: 0x%x bytes at 0x%x (%d bits wide)\n", 
+           bp->bi_flashsize, bp->bi_flashbase, bp->bi_flashwidth);
+
+    simple_map_init(&redboot_mtd_map);
+
+    mymtd = do_map_probe("cfi_probe", &redboot_mtd_map);
+    if (mymtd) {
+        mymtd->owner = THIS_MODULE;
+#ifdef CONFIG_MTD_REDBOOT_PARTS
+        parsed_nr_parts = parse_mtd_partitions(mymtd, probes, &mtd_parts, 0);
+        if (parsed_nr_parts > 0)
+            part_type = "detected";
+#endif
+	if (parsed_nr_parts > 0) {
+            parts = mtd_parts;
+            nb_parts = parsed_nr_parts;
+	}
+	if (nb_parts == 0) {
+            printk("PowerPC/RedBoot 8xx/8xxx flash: no partition info available, registering whole flash at once\n");
+            add_mtd_device(mymtd);
+	} else {
+            add_mtd_partitions(mymtd, parts, nb_parts);
+	}
+        return 0;
+    }
+
+    iounmap((void *)redboot_mtd_map.map_priv_1);
+    return -ENXIO;
+}
+
+static void __exit cleanup_redboot_mtd(void)
+{
+    if (mymtd) {
+        del_mtd_device(mymtd);
+        map_destroy(mymtd);
+    }
+    if (redboot_mtd_map.map_priv_1) {
+        iounmap((void *)redboot_mtd_map.map_priv_1);
+        redboot_mtd_map.map_priv_1 = 0;
+    }
+}
+
+module_init(init_redboot_mtd);
+module_exit(cleanup_redboot_mtd);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Gary Thomas <gary at mlbassoc.com>");
+MODULE_DESCRIPTION("MTD map driver for PowerPC 8xx/8xxx boards running RedBoot");
Index: drivers/mtd/nand/Config.in
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nand/Config.in,v
retrieving revision 1.17
diff -u -5 -p -r1.17 Config.in
--- drivers/mtd/nand/Config.in	10 May 2004 07:28:18 -0000	1.17
+++ drivers/mtd/nand/Config.in	28 May 2004 14:54:32 -0000
@@ -39,6 +39,11 @@ if [ "$CONFIG_PPCHAMELEONEVB" = "y" ]; t
 fi
 
 if [ "$CONFIG_SOC_AU1550" = "y" ]; then
    dep_tristate '  NAND Flash Driver for Au1550 controller' CONFIG_MTD_NAND_AU1550 $CONFIG_MTD_NAND 
 fi
+
+if [ "$CONFIG_TAMS_MOAB" = "y" ]; then
+   dep_tristate '  NAND Flash device on TAMS MOAB board' CONFIG_MTD_NAND_TAMS_MOAB $CONFIG_MTD_NAND
+fi
+
 endmenu
Index: drivers/mtd/nand/Makefile.common
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nand/Makefile.common,v
retrieving revision 1.7
diff -u -5 -p -r1.7 Makefile.common
--- drivers/mtd/nand/Makefile.common	26 May 2004 13:35:52 -0000	1.7
+++ drivers/mtd/nand/Makefile.common	28 May 2004 14:54:33 -0000
@@ -17,10 +17,11 @@ obj-$(CONFIG_MTD_NAND_EDB7312)  += edb73
 obj-$(CONFIG_MTD_NAND_TX4925NDFMC)  += tx4925ndfmc.o
 obj-$(CONFIG_MTD_NAND_TX4938NDFMC)  += tx4938ndfmc.o
 obj-$(CONFIG_MTD_NAND_AU1550)	  += au1550nd.o
 obj-$(CONFIG_MTD_NAND_IDS)	+= nand_ids.o
 obj-$(CONFIG_MTD_NAND_PPCHAMELEONEVB)   += ppchameleonevb.o
+obj-$(CONFIG_MTD_NAND_TAMS_MOAB)	+= tams_moab.o
 
 nand-objs = nand_base.o nand_bbt.o
 
 -include $(TOPDIR)/Rules.make
 
Index: drivers/mtd/nand/tams_moab.c
===================================================================
RCS file: drivers/mtd/nand/tams_moab.c
diff -N drivers/mtd/nand/tams_moab.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ drivers/mtd/nand/tams_moab.c	28 May 2004 14:54:33 -0000
@@ -0,0 +1,214 @@
+/*
+ *  drivers/mtd/nand/tams_moab.c
+ *    Coyright (C) Gary Thomas (linux at mlbassoc.com)
+ *
+ *  Derived from drivers/mtd/nand/edb7312.c & autcu12.c
+ *       Copyright (C) 2002 Marius Gr?ger (mag at sysgo.de)
+ *       Copyright (c) 2001 Thomas Gleixner (gleixner at autronix.de)
+ *
+ * $Id: tams_moab.c,v 1.1.2.3 2004/05/28 12:14:57 gthomas Exp $
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  Overview:
+ *   This is a device driver for the NAND flash device found on the
+ *   TAMS MOAB board which utilizes the Toshiba TC58V256AFT part. This 
+ *   is a 256Mibit (32MiB x 8 bits) NAND flash device.
+ */
+
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <platforms/ibm405gpr.h>
+
+/*
+ * MTD structure for MOAB board
+ */
+static struct mtd_info *moab_mtd = NULL;
+
+/*
+ * Values specific to the MOAB board (PowerPC 405GPr)
+ */
+#define MOAB_NAND_PHYS_BASE 0xC0000000
+#define MOAB_NAND_CLE       0x00010000  // GPIO 15 - asserts CLE to NAND device
+#define MOAB_NAND_ALE       0x00020000  // GPIO 14 - asserts ALE to NAND device
+#define MOAB_NAND_CE        0x00004000  // GPIO 17 - asserts CE to NAND device (active low)
+#define MOAB_NAND_BSY       0x00000200  // GPIO 22 - NAND RDY
+
+/*
+ * Mapped access to device
+ */
+static int moab_dev_base;
+static gpio_t *moab_gpio_base;
+
+/*
+ * Module stuff
+ */
+
+#ifdef CONFIG_MTD_PARTITIONS
+/*
+ * Define static partitions for flash device
+ */
+static struct mtd_partition partition_info[] = {
+	{ name: "MOAB Nand Flash",
+		  offset: 0,
+		  size: 128*1024*1024 }
+};
+#define NUM_PARTITIONS 1
+
+extern int parse_cmdline_partitions(struct mtd_info *master, 
+				    struct mtd_partition **pparts,
+				    const char *mtd_id);
+
+static const char *probes[] = { "RedBoot", "cmdlinepart", NULL };
+
+#endif
+static u_char data_buf[512 + 16];
+static u_char oob_buf[16 * 32];
+
+
+/* 
+ *	hardware specific access to control-lines
+ */
+static void moab_hwcontrol(struct mtd_info *mtd, int cmd) 
+{
+    switch(cmd) {
+		
+    case NAND_CTL_SETCLE: 
+        moab_gpio_base->or |= MOAB_NAND_CLE;
+        break;
+    case NAND_CTL_CLRCLE: 
+        moab_gpio_base->or &= ~MOAB_NAND_CLE;
+        break;
+    case NAND_CTL_SETALE:
+        moab_gpio_base->or |= MOAB_NAND_ALE;
+        break;
+    case NAND_CTL_CLRALE:
+        moab_gpio_base->or &= ~MOAB_NAND_ALE;
+        break;
+    case NAND_CTL_SETNCE:
+        moab_gpio_base->or &= ~MOAB_NAND_CE;
+        break;
+    case NAND_CTL_CLRNCE:
+        moab_gpio_base->or |= MOAB_NAND_CE;
+        break;
+    }
+}
+
+/*
+ *	read device ready pin
+ */
+#include <linux/delay.h>
+static int moab_device_ready(struct mtd_info *mtd)
+{
+    udelay(1000);
+    return ((moab_gpio_base->ir & MOAB_NAND_BSY) != 0);
+}
+
+/*
+ * Main initialization routine
+ */
+static int __init moab_init (void)
+{
+	struct nand_chip *this;
+	const char *part_type = 0;
+	int mtd_parts_nb = 0;
+	struct mtd_partition *mtd_parts = 0;
+	int moab_fio_base;
+	
+	/* Allocate memory for MTD device structure and private data */
+        printk("%s.%d\n", __FUNCTION__, __LINE__);
+	moab_mtd = kmalloc(sizeof(struct mtd_info) + 
+			     sizeof(struct nand_chip),
+			     GFP_KERNEL);
+	if (!moab_mtd) {
+		printk("Unable to allocate MOAB NAND MTD device structure.\n");
+		return -ENOMEM;
+	}
+	
+	/* map physical adresses */
+        printk("%s.%d\n", __FUNCTION__, __LINE__);
+	moab_dev_base = (unsigned long)ioremap(MOAB_NAND_PHYS_BASE, 1024);
+        printk("NAND - %x at %x\n", MOAB_NAND_PHYS_BASE, moab_dev_base);
+	if(!moab_dev_base) {
+		printk("ioremap MOAB NAND flash failed\n");
+		kfree(moab_mtd);
+		return -EIO;
+	}
+        /* Why isn't the GPIO just mapped by the platform? */
+	moab_gpio_base = (gpio_t *)ioremap(GPIO0_BASE, 1024);
+	if(!moab_gpio_base) {
+		printk("ioremap MOAB GPIO failed\n");
+		iounmap((void *)moab_dev_base);
+		kfree(moab_mtd);
+		return -EIO;
+	}
+	
+	/* Get pointer to private data */
+	this = (struct nand_chip *) (&moab_mtd[1]);
+	
+	/* Initialize structures */
+	memset((char *) moab_mtd, 0, sizeof(struct mtd_info));
+	memset((char *) this, 0, sizeof(struct nand_chip));
+	
+	/* Link the private data with the MTD structure */
+	moab_mtd->priv = this;
+	
+	/* insert callbacks */
+	this->IO_ADDR_R = moab_dev_base;
+	this->IO_ADDR_W = moab_dev_base;
+	this->hwcontrol = moab_hwcontrol;
+	this->dev_ready = moab_device_ready;
+	/* 15 us command delay time */
+	this->chip_delay = 15;
+        this->eccmode = NAND_ECC_SOFT;
+        /* Set internal data buffer */
+        this->data_buf = data_buf;
+        this->oob_buf = oob_buf;
+
+	/* Scan to find existence of the device */
+	if (nand_scan (moab_mtd, 1)) {
+		iounmap((void *)moab_dev_base);
+		iounmap((void *)moab_gpio_base);
+		kfree (moab_mtd);
+		return -ENXIO;
+	}
+	
+        mtd_parts_nb = parse_mtd_partitions(moab_mtd, probes, &mtd_parts, 0);
+        if (mtd_parts_nb < 0)
+            return mtd_parts_nb;
+	
+	/* Register the partitions */
+	add_mtd_partitions(moab_mtd, mtd_parts, mtd_parts_nb);
+	
+	/* Return happy */
+	return 0;
+}
+module_init(moab_init);
+
+/*
+ * Clean up routine
+ */
+static void __exit moab_cleanup (void)
+{
+	struct nand_chip *this = (struct nand_chip *) &moab_mtd[1];
+	
+	/* Unregister the device */
+	del_mtd_device (moab_mtd);
+	
+	/* Free internal data buffer */
+	kfree (this->data_buf);
+	
+	/* Free the MTD device structure */
+	kfree (moab_mtd);
+}
+module_exit(moab_cleanup);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Gary Thomas <linux at mlbassoc.com>");
+MODULE_DESCRIPTION("MTD map driver for TAMS MOAB board");

From inox_kas at yahoo.com  Sun May 30 23:12:29 2004
From: inox_kas at yahoo.com (kas turi)
Date: Sun, 30 May 2004 20:12:29 -0700 (PDT)
Subject: Floating point exception
Message-ID: <20040531031229.87538.qmail@web21002.mail.yahoo.com>

Hi
  I have merged the latest JFFS2 filesystem, mtd
drivers and block drivers on my 2.4.7 timesys linux
kernel. The snap shot I have used for merging is
"mtd-snapshot-20040527.tar". I am running this kernel
on my 8270 Powerpc board with AM29LV128ML flash chip.
The bus width is 32, interleave is 2 and flash size is
32M. The kernel boots up with JFFS2 as the root file
system.
  All the file operations such as list, copy and
delete are working fine. Finally when I issue a
shutdown to boot  my board I get an exception:
floating point used in kernel (task=c5158000,
pc=ff000104)
Oops: Exception in kernel mode, sig: 4
NIP: FF020000 XER: 20000000 LR: FF000104 SP: C5159DE0
REGS: c5159d30 TRAP: 0700MSR: 00083002 EE: 0 PR: 0 FP:
1 ME: 1 IR/DR: 00
TASK = c5158000[931] 'shutdown' Last syscall: 114
last math 00000000 last altivec 00000000
GPR00: 00001032 C5159DE0 C5158000 001DF1D4 FF000104
00001002 00003854 C01E3459
GPR08: 00000013 C01E0000 0000C000 80000088 24022088
1001B608 10000000 7FFFFB48
GPR16: 10010000 00000000 00000000 00000004 00009032
05159F40 00000000 C0004070
GPR24: C0003DE0 7FFFFEDD 30029C78 00000008 C01BBBEC
C5158000 00000000 FF000104
Call backtrace:
7FFFFEDD 816100A8

The same kernel with 1.5 years old snapshot of JFFS2
works fine. Any idea what could be the issue.

Thanks in advance. 


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 



From dk.dbox2 at gmx.net  Mon May 31 06:30:57 2004
From: dk.dbox2 at gmx.net (dkey)
Date: Mon, 31 May 2004 12:30:57 +0200
Subject: [PATCH] fs/Kconfig
Message-ID: <200405311230.57838.dk.dbox2@gmx.net>

this patch selects ZLIB_INFLATE/DEFLATE if JFFS2_ZLIB is selected.

greets dkey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kconfig.diff
Type: text/x-diff
Size: 293 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20040531/048b98d5/attachment.bin 

