NAND flash write goes wrong

NAND flash write goes wrong

[borasah]

Hi,

I have a MIPS based board and want to use its NAND flash for storage. NAND 
chip is a Samsung part: K9F1208UDA. It has 16KB erase block size and 512 byte 
page size.
	cat /proc/mtd
	dev:    size   erasesize  name
	mtd0: 02000000 00020000 "mtdram test device"
	mtd1: 00800000 00004000 "NAND FS 0"
	mtd2: 03800000 00004000 "NAND FS 1"

As you see there are two partitions on it. I want to use "NAND FS 1"(56MB) for 
rootFS storage. I obtained mtd-utils from the site and compiled them for both  
the host and the target. I am using "mkfs.jffs2 command on the host" to 
generate a jffs2 image.
	./mkfs.jffs2 -p 0x3800000 -s 0x200 -e 0x4000 -r rootfs -o img -l
Then on the target I do
	flash_eraseall -j /dev/mtd
In the beginning there was no bad block. But after some experiments I see 
many(43) "bad sector" warnings and this continues to increase when I write 
new images.
	Erasing 16 Kibyte @ 24000 --  0 % complete. Cleanmarker written at 24000.
	Skipping bad block at 0x00028000
	...
Is this normal? Then I do
	./nandwrite /dev/mtd2 img
It writes by skipping bad blocks.
	...
	Writing data to block 189c000
	Bad block at 189c000, 1 block(s) from 189c000 will be skipped
	Writing data to block 18a0000
	...
Everything seems normal. As a last item, I want to see if the image creation 
and write is successfull, do 
	mount -t jffs2 /dev/mtdblock2 /mnt
Results:
jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) 
instead
CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0
Empty flash at 0x00003f5c ends at 0x00004000
CLEANMARKER node found at 0x00004000 has totlen 0xc != normal 0x0
CLEANMARKER node found at 0x00008000 has totlen 0xc != normal 0x0
mtd->read(0x7a8c bytes from 0x8574) returned ECC error
Empty flash at 0x0000bffc ends at 0x0000c000
CLEANMARKER node found at 0x0000c000 has totlen 0xc != normal 0x0
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e30c: 0x2a1f 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e310: 0x4013 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e314: 0xeb6a 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e318: 0xd754 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e31c: 0xaca8 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e320: 0x0030 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e324: 0x1e8e 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e328: 0xe002 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e330: 0x3481 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000e340: 0x03e8 
instead
Further such events for this erase block will not be printed
...

I read the FAQ at http://www.linux-mtd.infradead.org/faq/jffs2.html. "Magic 
bitmask 0x1985 not found" points four things as cause. At my case, seems
	1) you flash driver is severely buggy so it reads trash instead of valid
 data;
	2) you did not manage to flash JFFS2 image correctly so that you ended up 
with garbage on your flash, although the original image was perfectly fine;

Now I am assuming 1 is correct which is vendor provided. But I dont see where 
I did wrong when generating the image? Can someone shed some light on this?
	# mtd_debug info /dev/mtd2
	mtd.type = MTD_NANDFLASH
	mtd.flags = MTD_CLEAR_BITS | MTD_ECC
	mtd.size = 58720256 (56M)
	mtd.erasesize = 16384 (16K)
	mtd.oobblock = 512
	mtd.oobsize = 16
	mtd.ecctype = MTD_ECC_NONE
	regions = 0

Thanks...

--
Bora SAHIN

Re: NAND flash write goes wrong

[Josh Boyer]

On Thu, 2007-05-10 at 21:50 +0300, borasah@gmail.com wrote:
> Hi,
> 
> I have a MIPS based board and want to use its NAND flash for storage. NAND 
> chip is a Samsung part: K9F1208UDA. It has 16KB erase block size and 512 byte 
> page size.
> 	cat /proc/mtd
> 	dev:    size   erasesize  name
> 	mtd0: 02000000 00020000 "mtdram test device"
> 	mtd1: 00800000 00004000 "NAND FS 0"
> 	mtd2: 03800000 00004000 "NAND FS 1"
> 
> As you see there are two partitions on it. I want to use "NAND FS 1"(56MB) for 
> rootFS storage. I obtained mtd-utils from the site and compiled them for both  
> the host and the target. I am using "mkfs.jffs2 command on the host" to 
> generate a jffs2 image.
> 	./mkfs.jffs2 -p 0x3800000 -s 0x200 -e 0x4000 -r rootfs -o img -l
> Then on the target I do
> 	flash_eraseall -j /dev/mtd

Could you try without the -j and see if it fares any better?

josh

Re: NAND flash write goes wrong

[borasah]

Hi Josh,

> > I have a MIPS based board and want to use its NAND flash for storage.
> > NAND chip is a Samsung part: K9F1208UDA. It has 16KB erase block size and
> > 512 byte page size.
> > 	cat /proc/mtd
> > 	dev:    size   erasesize  name
> > 	mtd0: 02000000 00020000 "mtdram test device"
> > 	mtd1: 00800000 00004000 "NAND FS 0"
> > 	mtd2: 03800000 00004000 "NAND FS 1"
> >
> > As you see there are two partitions on it. I want to use "NAND FS
> > 1"(56MB) for rootFS storage. I obtained mtd-utils from the site and
> > compiled them for both the host and the target. I am using "mkfs.jffs2
> > command on the host" to generate a jffs2 image.
> > 	./mkfs.jffs2 -p 0x3800000 -s 0x200 -e 0x4000 -r rootfs -o img -l
> > Then on the target I do
> > 	flash_eraseall -j /dev/mtd
>
> Could you try without the -j and see if it fares any better?

Thanks for your suggestion. I tried it. But seems the same...

jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) 
instead
CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0
Empty flash at 0x00003f5c ends at 0x00004000
CLEANMARKER node found at 0x00004000 has totlen 0xc != normal 0x0
CLEANMARKER node found at 0x00008000 has totlen 0xc != normal 0x0
Empty flash at 0x0000bffc ends at 0x0000c000
CLEANMARKER node found at 0x0000c000 has totlen 0xc != normal 0x0
CLEANMARKER node found at 0x00010000 has totlen 0xc != normal 0x0
mtd->read(0x7a50 bytes from 0x105b0) returned ECC error
Empty flash at 0x00013ffc ends at 0x00014000
CLEANMARKER node found at 0x00014000 has totlen 0xc != normal 0x0
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000151c8: 0x004f 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000151cc: 0xfbba 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000151d0: 0x00ff 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000151d4: 0x9400 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000151d8: 0xff82 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000153ec: 0x81ed 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000153f0: 0x03e8 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000153f4: 0x69e8 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000153f8: 0x4fd0 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000153fc: 0x4fd0 
instead
Further such events for this erase block will not be printed
...
Inode #265 was a directory with children - removing those too...
Inode #266 was a directory with children - removing those too...
Inode #342 was a directory with children - removing those too...
...
mtd->read(0x118 bytes from 0x1d973c) returned ECC error
jffs2_get_inode_nodes(): Data CRC failed on node at 0x001d96f8: Read 
0x0dbe310a, calculated 0x6853096b
...


--
Bora SAHIN

Re: NAND flash write goes wrong

[Thomas Gleixner]

On Fri, 2007-05-11 at 00:37 +0300, borasah@gmail.com wrote:
> jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) 
---------------------------------------------------^^^^^^^

The virtual block support was removed two years ago. Please use an up to
date kernel.

http://www.linux-mtd.infradead.org/source.html#kernelversions

	tglx

Re: NAND flash write goes wrong

[borasah]

Hi,

> On Fri, 2007-05-11 at 00:37 +0300, borasah@gmail.com wrote:
> > jffs2: Erase block size too small (16KiB). Using virtual blocks size
> > (32KiB)
>
> ---------------------------------------------------^^^^^^^
>
> The virtual block support was removed two years ago.

Oops...

> Please use an up to date kernel.
> http://www.linux-mtd.infradead.org/source.html#kernelversions

I am using 2.6.11. Is this valid for it? 

Or I can use older mtd-utils?

--
Bora SAHIN

Re: NAND flash write goes wrong

[Ricard Wanderlof]

On Thu, 10 May 2007, borasah@gmail.com wrote:

> Hi,
>
> I have a MIPS based board and want to use its NAND flash for storage. NAND
> chip is a Samsung part: K9F1208UDA. It has 16KB erase block size and 512 byte
> page size.
> 	cat /proc/mtd
> 	dev:    size   erasesize  name
> 	mtd0: 02000000 00020000 "mtdram test device"
> 	mtd1: 00800000 00004000 "NAND FS 0"
> 	mtd2: 03800000 00004000 "NAND FS 1"
>
> As you see there are two partitions on it. I want to use "NAND FS 1"(56MB) for
> rootFS storage. I obtained mtd-utils from the site and compiled them for both
> the host and the target. I am using "mkfs.jffs2 command on the host" to
> generate a jffs2 image.
> 	./mkfs.jffs2 -p 0x3800000 -s 0x200 -e 0x4000 -r rootfs -o img -l

I don't know if this is it but

- I wouldn't pad the output image using -p <padsize>. Since there may be
   bad blocks in the flash, the image might not fit if padded to the
   whole partition size. Just skip the -p and its argument. As long as
   the whole partition into which the image is written has been erased
   beforehand, jffs2 will be able to make use of the unused space.

- The -s <pagesize>  argument doesn't specify the page size of the
   flash chip, rather it should be the same as the 'page size' in the
   Linux system, normally 4096 for most architectures.

- In nand flash, the cleanmarkers are normally not part of the image
   as they reside in the 'spare area' in the flash. The JFFS2 driver will
   automatically create cleanmarkers when it scans the chip at first boot,
   and having them in the image will confuse the issue, even if it normally
   works anway (but with lots of warnings at boot time).
   So, add -n to the list of arguments to inhibit cleanmarker
   generation by mkfs.jffs2.

> ...
> 	Erasing 16 Kibyte @ 24000 --  0 % complete. Cleanmarker written at 24000.
> 	Skipping bad block at 0x00028000
> 	...
> Is this normal? Then I do
> 	./nandwrite /dev/mtd2 img
> It writes by skipping bad blocks.
> 	...
> 	Writing data to block 189c000
> 	Bad block at 189c000, 1 block(s) from 189c000 will be skipped
> 	Writing data to block 18a0000
> 	...

If there indeed are bad blocks it is correct to skip them both when 
erasing and writing.

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

Re: NAND flash write goes wrong

[Artem Bityutskiy]

Just FYI,

we have recently fixed a bug in MTD which caused JFFS2 to mark good
eraseblocks bad. It was caused by the mtdpart module. One had to have
partitions to trigger this bug. The bug was that when JFFS2 wanted to
mark eraseblock X within its partition as bad, mtdpart did not translate
correctly to the _absolute_ number, but marked _absolute_ eraseblock
number X as bad instead.

So basically, once one met a true bad eraseblock, JFFS2 started trying
to mark it as bad, but marked other eraseblock as bad instead.

I'd recommend everybody to backport this fix.

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

Re: NAND flash write goes wrong

[Matthieu CASTET]

Hi Artem,

Artem Bityutskiy a écrit :
> Just FYI,
> 
> we have recently fixed a bug in MTD which caused JFFS2 to mark good
> eraseblocks bad. It was caused by the mtdpart module. One had to have
> partitions to trigger this bug. The bug was that when JFFS2 wanted to
> mark eraseblock X within its partition as bad, mtdpart did not translate
> correctly to the _absolute_ number, but marked _absolute_ eraseblock
> number X as bad instead.
> 
> So basically, once one met a true bad eraseblock, JFFS2 started trying
> to mark it as bad, but marked other eraseblock as bad instead.
> 
> I'd recommend everybody to backport this fix.
> 
Could you give a link to your fix ?


Thanks

Matthieu

Re: NAND flash write goes wrong

[Artem Bityutskiy]

On Fri, 2007-05-11 at 09:16 +0200, Matthieu CASTET wrote:
> Could you give a link to your fix ?

http://git.infradead.org/?p=mtd-2.6.git;a=commit;h=74641d75275936796d239f828b80cb030e9f9b0a

Although even with this fix JFFS2 does not survive I/O errors in many
cases, there were more error-path fixes. 2.6.20's JFFS2 is much better
in errors handling then older versions.

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

Re: NAND flash write goes wrong

[Artem Bityutskiy]

On Fri, 2007-05-11 at 10:42 +0300, Artem Bityutskiy wrote:
> On Fri, 2007-05-11 at 09:16 +0200, Matthieu CASTET wrote:
> > Could you give a link to your fix ?
> 
> http://git.infradead.org/?p=mtd-2.6.git;a=commit;h=74641d75275936796d239f828b80cb030e9f9b0a
> 
> Although even with this fix JFFS2 does not survive I/O errors in many
> cases, there were more error-path fixes. 2.6.20's JFFS2 is much better
> in errors handling then older versions.

Err, to make it clearer, _older_ JFFS2 will not survive I/O errors in
many cases even with this fix.

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

Re: NAND flash write goes wrong

[borasah]

> > compiled them for both the host and the target. I am using "mkfs.jffs2
> > command on the host" to generate a jffs2 image.
> > 	./mkfs.jffs2 -p 0x3800000 -s 0x200 -e 0x4000 -r rootfs -o img -l
>
> I don't know if this is it but
>
> - I wouldn't pad the output image using -p <padsize>. Since there may be
>    bad blocks in the flash, the image might not fit if padded to the
>    whole partition size. Just skip the -p and its argument. As long as
>    the whole partition into which the image is written has been erased
>    beforehand, jffs2 will be able to make use of the unused space.
>
> - The -s <pagesize>  argument doesn't specify the page size of the
>    flash chip, rather it should be the same as the 'page size' in the
>    Linux system, normally 4096 for most architectures.
>
> - In nand flash, the cleanmarkers are normally not part of the image
>    as they reside in the 'spare area' in the flash. The JFFS2 driver will
>    automatically create cleanmarkers when it scans the chip at first boot,
>    and having them in the image will confuse the issue, even if it normally
>    works anway (but with lots of warnings at boot time).
>    So, add -n to the list of arguments to inhibit cleanmarker
>    generation by mkfs.jffs2.

Thanks for the infos. OK, this means
	./mkfs.jffs2 -e 0x4000 -r rootfs -o img -l -n
or
	./mkfs.jffs2 -s 0x1000 -e 0x4000 -r rootfs -o img -l -n
right? I checked the target .config, it uses 4K as page size. But I gave

	Input file is not page aligned
	Data did not fit into device, due to bad blocks
	: Success

In fact, I tried without -p and with -n before. Without -p nandwrite gives the 
above message. Then I put -p and nandwrite started to write...

> > 	Erasing 16 Kibyte @ 24000 --  0 % complete. Cleanmarker written at
> > 24000. Skipping bad block at 0x00028000
> > 	...
> > Is this normal? Then I do
> > 	./nandwrite /dev/mtd2 img
> > It writes by skipping bad blocks.
> > 	...
> > 	Writing data to block 189c000
> > 	Bad block at 189c000, 1 block(s) from 189c000 will be skipped
> > 	Writing data to block 18a0000
> > 	...
>
> If there indeed are bad blocks it is correct to skip them both when
> erasing and writing.

OK. What I wanted to learn was different. In the begining there was no bad 
sector but by the passage of time, when I tried different combinations, bad 
sector numbers started to increase. Is this normal? Or are there some 
fundamentally different things between kernel version and mtd-utils so these 
marks them as bad?

Thanks...

--
Bora SAHIN

Re: NAND flash write goes wrong

[Ricard Wanderlof]

On Fri, 11 May 2007, borasah@gmail.com wrote:

> Thanks for the infos. OK, this means
> 	./mkfs.jffs2 -e 0x4000 -r rootfs -o img -l -n
> or
> 	./mkfs.jffs2 -s 0x1000 -e 0x4000 -r rootfs -o img -l -n
> right? I checked the target .config, it uses 4K as page size. But I gave
>
> 	Input file is not page aligned
> 	Data did not fit into device, due to bad blocks
> 	: Success
>
> In fact, I tried without -p and with -n before. Without -p nandwrite gives the
> above message. Then I put -p and nandwrite started to write...

Sorry, I didn't get it completely right last time. It is good practice to 
pad the image to a complete eraseblock size, but it shouldn't fill the 
whole nand flash partition space available, in case there are bad blocks.

So yes, it should be padded with -p, but not to the full size of the 
partition, but a couple of eraseblocks less.

-p specified to nandwrite should also work as it pads the image with 0xff.

>> If there indeed are bad blocks it is correct to skip them both when
>> erasing and writing.
>
> OK. What I wanted to learn was different. In the begining there was no bad
> sector but by the passage of time, when I tried different combinations, bad
> sector numbers started to increase. Is this normal? Or are there some
> fundamentally different things between kernel version and mtd-utils so these
> marks them as bad?

Blocks (nand flash terminology rejects the name 'sectors' in favor of 
'blocks' and 'pages') can go bad with time, but we're talking about 
thousands if not tens of thousands of erase/write cycles here. So it seems 
there's something wrong here.

There was a patch posted just a week or so ago here which fixed a problem 
with bad block marking and recognition when not using a flash-based bad 
block table.

My (limited) experience is that when the jffs2 driver detects more and 
more bad blocks over a short period of time, it is the result of a 
hardware problem i.e. the communication with the nand flash doesn't work 
properly, causing some reads, writes or erase operations to fail. (Case in 
point: during debugging of one of our products I accidentally allocated a 
network traffic indicator output pin to one of the nand flash signals, 
which caused all sorts of weird nand flash problems if the flash was 
accessed at the same time as the network. As long as the network was 
silent, there were no problems whatsoever).

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

Re: NAND flash write goes wrong

[borasah]

> > 	Input file is not page aligned
> > 	Data did not fit into device, due to bad blocks
> >
> > 	: Success
> >
> > In fact, I tried without -p and with -n before. Without -p nandwrite
> > gives the above message. Then I put -p and nandwrite started to write...
>
> Sorry, I didn't get it completely right last time. It is good practice to
> pad the image to a complete eraseblock size, but it shouldn't fill the
> whole nand flash partition space available, in case there are bad blocks.

Hmm, you say if the erase block size is 100, and the last part of the image is 
64, the remaining 36 should be padded with 0xFF, but all the other free ones 
can remain as is? 

mkfs.jffs2 -p without SIZE does the above one or to the end of the NAND flash? 
I think the first one...

> So yes, it should be padded with -p, but not to the full size of the
> partition, but a couple of eraseblocks less.

You mean "NAND_size - erase_size * x"? 

> -p specified to nandwrite should also work as it pads the image with 0xff.

Hmm. You dont have to specify -p to the mkfs.jffs2, nandwrite can also do it 
for you, right?

> >> If there indeed are bad blocks it is correct to skip them both when
> >> erasing and writing.
> >
> > OK. What I wanted to learn was different. In the begining there was no
> > bad sector but by the passage of time, when I tried different
> > combinations, bad sector numbers started to increase. Is this normal? Or
> > are there some fundamentally different things between kernel version and
> > mtd-utils so these marks them as bad?
>
> Blocks (nand flash terminology rejects the name 'sectors' in favor of
> 'blocks' and 'pages') can go bad with time, but we're talking about
> thousands if not tens of thousands of erase/write cycles here. So it seems
> there's something wrong here.

Yes, I think too. Now ~140 bad sector is reported during the boot. I just did 
at most 50 read/write...

> There was a patch posted just a week or so ago here which fixed a problem
> with bad block marking and recognition when not using a flash-based bad
> block table.

I'm new to the list. Is this Artem's patch? I applied it, but no success... 
Maybe http://lists.infradead.org/pipermail/linux-mtd/2007-May/018087.html?

> My (limited) experience is that when the jffs2 driver detects more and
> more bad blocks over a short period of time, it is the result of a
> hardware problem i.e. the communication with the nand flash doesn't work
> properly, causing some reads, writes or erase operations to fail. (Case in
> point: during debugging of one of our products I accidentally allocated a
> network traffic indicator output pin to one of the nand flash signals,
> which caused all sorts of weird nand flash problems if the flash was
> accessed at the same time as the network. As long as the network was
> silent, there were no problems whatsoever).

Ricard, thanks for the the information...

--
Bora SAHIN

Re: NAND flash write goes wrong

[Ricard Wanderlof]

On Fri, 11 May 2007, borasah@gmail.com wrote:

>> Sorry, I didn't get it completely right last time. It is good practice to
>> pad the image to a complete eraseblock size, but it shouldn't fill the
>> whole nand flash partition space available, in case there are bad blocks.
>
> Hmm, you say if the erase block size is 100, and the last part of the image is
> 64, the remaining 36 should be padded with 0xFF, but all the other free ones
> can remain as is?

If the partition has been erased, all the other free ones will also be 
0xff.

> mkfs.jffs2 -p without SIZE does the above one or to the end of the NAND flash?
> I think the first one...

Yes, it pads up to the next eraseblock. Again, if the partition was newly 
erased, the rest of the partition will also contain 0xff.

>> So yes, it should be padded with -p, but not to the full size of the
>> partition, but a couple of eraseblocks less.
>
> You mean "NAND_size - erase_size * x"?

Yes.

>> -p specified to nandwrite should also work as it pads the image with 0xff.
>
> Hmm. You dont have to specify -p to the mkfs.jffs2, nandwrite can also 
> do it for you, right?

Yes.

>> Blocks (nand flash terminology rejects the name 'sectors' in favor of
>> 'blocks' and 'pages') can go bad with time, but we're talking about
>> thousands if not tens of thousands of erase/write cycles here. So it seems
>> there's something wrong here.
>
> Yes, I think too. Now ~140 bad sector is reported during the boot. I just did
> at most 50 read/write...

You sound far from wearing the chip out. There must be another problem 
there somewhere.

>> There was a patch posted just a week or so ago here which fixed a problem
>> with bad block marking and recognition when not using a flash-based bad
>> block table.
>
> I'm new to the list. Is this Artem's patch? I applied it, but no success...
> Maybe http://lists.infradead.org/pipermail/linux-mtd/2007-May/018087.html?

By Thomas Knobloch I believe, but yes, that's the patch I was thinking of.

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

Re: NAND flash write goes wrong

[borasah]

Hi,

[Snip]

Thanks for the infos...

> >> Blocks (nand flash terminology rejects the name 'sectors' in favor of
> >> 'blocks' and 'pages') can go bad with time, but we're talking about
> >> thousands if not tens of thousands of erase/write cycles here. So it
> >> seems there's something wrong here.
> >
> > Yes, I think too. Now ~140 bad sector is reported during the boot. I just
> > did at most 50 read/write...
>
> You sound far from wearing the chip out. There must be another problem
> there somewhere.

Hmm...

> >> There was a patch posted just a week or so ago here which fixed a
> >> problem with bad block marking and recognition when not using a
> >> flash-based bad block table.
> >
> > I'm new to the list. Is this Artem's patch? I applied it, but no
> > success... Maybe
> > http://lists.infradead.org/pipermail/linux-mtd/2007-May/018087.html?
>
> By Thomas Knobloch I believe, but yes, that's the patch I was thinking of.

I applied it but no success...

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

I tried K9F1208U0A with linux-2.6.20 -> JFFS2 file system. I successfully used 
the part. 

Secondly, I tried yaffs with that part in the linux-2.6.11. It was successful 
too.

--
Bora SAHIN

RE: NAND flash write goes wrong

[Ricard Wanderlof]

On Mon, 14 May 2007, sathish.madhava@wipro.com wrote:

> Dear Ricard
> I have a small question on Yaffs.
> Do we have any utility for creating a Yaffs image as we have it for
> jffs2 ( mkfs.jffs2 from mtd-util2-1.0.0).
>
> In some places I read that to create yaffs, I need to copy the source 
> files of yaffs into the kernel/fs/yaffs and then build to kernel to get 
> mkyaffs and mkyaffsimage. Is it necessary ? or can I directly create a 
> yaffs image and then flash it to NAND and give the boot arguments so as 
> to boot it using yaffs image.

I have no experiance of using yaffs. Try the yaffs home page at 
http://www.aleph1.co.uk/taxonomy/term/31/index.html .

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