NAND flash write goes wrong

[Ricard Wanderlof]

On Fri, 11 May 2007, borasah at 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