NAND flash write goes wrong

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

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

josh

Hi Josh,

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

---------------------------------------------------^^^^^^^

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

Hi,

Oops...

I am using 2.6.11. Is this valid for it?

Or I can use older mtd-utils?

--
Bora SAHIN

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.

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

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 (Битюцкий Артём)

Hi Artem,

Could you give a link to your fix ?

Thanks

Matthieu

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 (Битюцкий Артём)

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

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

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...

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

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.

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

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...

You mean "NAND_size - erase_size * x"?

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

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

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?

Ricard, thanks for the the information...

--
Bora SAHIN

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

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

Yes.

Yes.

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

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

Hi,

[Snip]

Thanks for the infos...

Hmm...

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