introduce nand write.ubi, and drop ffs for jffs2 too

In a future commit the behaviour of nand_write_skip_bad() will be further extended.

Convert the only flag currently passed to the nand_write_ skip_bad() function to a bitfield of only one allocated member. This should avoid an explosion of int's at the end of the parameter list or the ambiguous calls like

nand_write_skip_bad(info, offset, len, buf, 0, 1, 1); nand_write_skip_bad(info, offset, len, buf, 0, 1, 0);

Instead there will be:

nand_write_skip_bad(info, offset, len, buf, WITH_OOB |

			WITH_OTHER);

Signed-off-by Ben Gardiner <[email protected]>

---
 common/cmd_nand.c            |    3 ++-
 drivers/mtd/nand/nand_util.c |    8 ++++----
 include/nand.h               |    5 ++++-
 3 files changed, 10 insertions(+), 6 deletions(-)

common/cmd_nand.c +0 -0

index 7bd37de..69b2acc 100644

drivers/mtd/nand/nand_util.c +4 -4

index 5a6f7ae..2bd8758 100644
@@ -448,11 +448,11 @@ static int check_skip_len(nand_info_t *nand, loff_t offset, size_t length)
  * @param offset	offset in flash
  * @param length	buffer length
  * @param buffer        buffer to read from
- * @param withoob	whether write with yaffs format
+ * @param flags		flags mmofying the behaviour of the write to NAND
  * @return		0 in case of success
  */
 int nand_write_skip_bad(nand_info_t *nand, loff_t offset, size_t *length,
-			u_char *buffer, int withoob)
+			u_char *buffer, int flags)
 {
 	int rval = 0, blocksize;
 	size_t left_to_write = *length;

@@ -460,7 +460,7 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t offset, size_t *length,
 	int need_skip;
 
 #ifdef CONFIG_CMD_NAND_YAFFS
-	if (withoob) {
+	if (flags & WITH_OOB) {
 		int pages;
 		pages = nand->erasesize / nand->writesize;
 		blocksize = (pages * nand->oobsize) + nand->erasesize;

@@ -529,7 +529,7 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t offset, size_t *length,
 			write_size = blocksize - block_offset;
 
 #ifdef CONFIG_CMD_NAND_YAFFS
-		if (withoob) {
+		if (flags & WITH_OOB) {
 			int page, pages;
 			size_t pagesize = nand->writesize;
 			size_t pagesize_oob = pagesize + nand->oobsize;

include/nand.h +0 -0

index 7459bd0..628317a 100644

Add another nand write. variant, ubi. This command will request of nand_write_skip_bad() that all trailing all-0xff pages will be dropped from eraseblocks as they are written as-per the reccommended behaviour of the UBI FAQ.

It was found that on da850evm, where the NAND ECC used does not map all 0xff data to 0xff ECC, that flashing UBI and JFFS2 image from U-boot with nand write[.e] command resulted in alot of ECC errors... for UBI the result was an unmountable filesystem on second attach from linux. For JFFS2 the result was a multitude of ECC errors printed on the cosole on the second mount in Linux -- the filesystem remains mountable for awhile but eventually collapses.

Hi Ben,

Quoted 6 lines

It was found that on da850evm, where the NAND ECC used does not map all 0xff data to 0xff ECC, that flashing UBI and JFFS2 image from U-boot with nand write[.e] command resulted in alot of ECC errors... for UBI the result was an unmountable filesystem on second attach from linux. For JFFS2 the result was a multitude of ECC errors printed on the cosole on the second mount in Linux -- the filesystem remains mountable for awhile but eventually collapses.

I am not sure that I can follow you here so I have to ask you to clarify the problem for me.

I understand that a page of 0xffs does _not_ have an ECC of all 0xffs. Actually I would be surprised if there was any ECC having this property, so I doubt that this is da850 specific, correct?

So I am wondering about two things:

- If I erase a page in NAND, will the ECC be updated by someone or will it be 0xffs? If the latter, then is it "normal" to have ECC errors on freshly erased pages?

- If we (correctly) "write" 0xffs even to an erased page, a generated ECC should match this content, so I do not see where ECC errors should come from in this setting.

Summarily, I do not understand where the ECC errors came from in your setup and what the faulting party in that scenario actually is/was.

Can you please enlighten me?

Quoted 22 lines

Hi Ben,

Quoted 6 lines

It was found that on da850evm, where the NAND ECC used does not map all 0xff data to 0xff ECC, that flashing UBI and JFFS2 image from U-boot with nand write[.e] command resulted in alot of ECC errors... for UBI the result was an unmountable filesystem on second attach from linux. For JFFS2 the result was a multitude of ECC errors printed on the cosole on the second mount in Linux -- the filesystem remains mountable for awhile but eventually collapses.

I am not sure that I can follow you here so I have to ask you to clarify the problem for me.

I understand that a page of 0xffs does _not_ have an ECC of all 0xffs. Actually I would be surprised if there was any ECC having this property, so I doubt that this is da850 specific, correct?

So I am wondering about two things:

- If I erase a page in NAND, will the ECC be updated by someone or will it be 0xffs? If the latter, then is it "normal" to have ECC errors on freshly erased pages?

Quoted 8 lines

- If we (correctly) "write" 0xffs even to an erased page, a generated ECC should match this content, so I do not see where ECC errors should come from in this setting.

Summarily, I do not understand where the ECC errors came from in your setup and what the faulting party in that scenario actually is/was.

Can you please enlighten me?

I do not know why I'm in CC, but I see that the code to skip all 0xFFs looks like it was copied from UBI. The reason why UBI and UBI user-space tools skip NAND pages with all 0xFFs when writing is described here:

http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo

If it is too long to read, in short:

1. if we write to flash, we always write to an erased eraseblock, obviously :-)

2. erased erase block contains all 0xFFs, so skipping 0xFF NAND pages is harmless.
3. writing 0xFF pages has side-effects - the ECC bytes in OOB will be used
4. If we are flashing an UBIFS image, UBIFS will use the half-filled eraseblocks, and if the "free" pages were written with 0xFFs, they'll become unusable.

So we skip 0xFF pages at the end. Not all, only the last ones. E.g., if your eraseblock consists of 4 pages, and you write "data, 0xFFs, data, 0xFFs", then we'll only write "data, 0xFFs, data", so that the last NAND page can be used later.

Sorry for my poor English, and I'm writing in a hurry - have to have to a pub to farewell several colleagues who are leaving the company :)

Hi Ben,

Quoted 6 lines

It was found that on da850evm, where the NAND ECC used does not map all 0xff data to 0xff ECC, that flashing UBI and JFFS2 image from U-boot with nand write[.e] command resulted in alot of ECC errors... for UBI the result was an unmountable filesystem on second attach from linux. For JFFS2 the result was a multitude of ECC errors printed on the cosole on the second mount in Linux -- the filesystem remains mountable for awhile but eventually collapses.

I am not sure that I can follow you here so I have to ask you to clarify the problem for me.

I understand that a page of 0xffs does _not_ have an ECC of all 0xffs. Actually I would be surprised if there was any ECC having this property, so I doubt that this is da850 specific, correct?

Quoted 2 lines

[...]
Can you please enlighten me?

I do not know why I'm in CC, but I see that the code to skip all 0xFFs looks like it was copied from UBI. The reason why UBI and UBI user-space tools skip NAND pages with all 0xFFs when writing is described here:

http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo

[...]

Quoted 6 lines

Quoted 1 line

Can you please enlighten me?

[...]
If it is too long to read, in short:

1. if we write to flash, we always write to an erased eraseblock, obviously :-)

Yes - I simply wasn't sure if the software layers below (in U-Boot) would do an "erase on demand" before writing. ?Reading the code, this isn't the case (I should have known this), so the skipping should really be safe.

Quoted 8 lines

2. erased erase block contains all 0xFFs, so skipping 0xFF NAND pages is harmless.
3. writing 0xFF pages has side-effects - the ECC bytes in OOB will be used
4. If we are flashing an UBIFS image, UBIFS will use the half-filled eraseblocks, and if the "free" pages were written with 0xFFs, they'll become unusable.

Quoted 7 lines

So we skip 0xFF pages at the end. Not all, only the last ones. E.g., if your eraseblock consists of 4 pages, and you write "data, 0xFFs, data, 0xFFs", then we'll only write "data, 0xFFs, data", so that the last NAND page can be used later.

Sorry for my poor English, and I'm writing in a hurry - have to have to a pub to farewell several colleagues who are leaving the company :)

Thanks for your input.

So I still fail to see where the ECC errors come from. ?The closes thing that makes sense for me, is that Bens problem very likely wasn't ECC connected at all but the result of the "not capable to write twice". I.e. his NAND flashes cannot be written to twice. ?When he flashed the images in U-Boot, there were trailing empty blocks that got programmed and UBIFS assumed that it _could_ write to them so it tried and failed and somehow got tripped up over this.

If this is the case then we should change the commit message to point to the real problem that this patch fixes.