[PATCH 0/3] mtd: nand/docg4: set of fixes and enhancements

[PATCH 0/3] mtd: nand/docg4: set of fixes and enhancements

[Mike Dunn]

Hi, this is a short set of minor fixes and enhancements to the docg4, tested on
my Palm Treo 680.

Mike Dunn (3):
  mtd: nand/docg4: add support for writing in reliable mode
  mtd: nand/docg4: reserve bb marker area in ecclayout
  mtd: nand/docg4: fix and improve read of factory bbt

 drivers/mtd/nand/docg4.c |   73 ++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 64 insertions(+), 9 deletions(-)

-- 
1.7.8.6

[PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode

[Mike Dunn]

The controller on the docg4 has a "reliable" mode, where consecutive 2k pages
are used in parallel.  The initial program loader (IPL) on my Treo 680 expects
the secondary program loader (SPL) to be written in this mode.  This patch adds
support for writing data in reliable mode, by way of a module parameter.
Support for reading in this mode (as the IPL does) is not supported yet, but
alternate (even-numbered) 2k pages written in reliable mode can be read normally
(odd-numbered pages will contain junk and generate ecc errors).

Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---

u-boot now runs on my Treo at power-up.  Yay!

 drivers/mtd/nand/docg4.c |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index 799da5d..54b1e5e 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -46,6 +46,25 @@
 #include <linux/bitrev.h>
 
 /*
+ * In "reliable mode" consecutive 2k pages are used in parallel (in some
+ * fashion) to store the same data.  The data can be read back from the
+ * even-numbered pages in the normal manner; odd-numbered pages will appear to
+ * contain junk.  Systems that boot from the docg4 typically write the secondary
+ * program loader (SPL) code in this mode.  The SPL is loaded by the initial
+ * program loader (IPL, stored in the docg4's 2k NOR-like region that is mapped
+ * to the reset vector address).  This module parameter enables you to use this
+ * driver to write the SPL.  When in this mode, no more than 2k of data can be
+ * written at a time, because the addresses do not increment in the normal
+ * manner, and the starting offset must be within an even-numbered 2k region;
+ * i.e., invalid starting offsets are 0x800, 0xa00, 0xc00, 0xe00, 0x1800,
+ * 0x1a00, ...  Reliable mode is a special case and should not be used unless
+ * you know what you're doing.
+ */
+static bool reliable_mode;
+module_param(reliable_mode, bool, 0);
+MODULE_PARM_DESC(reliable_mode, "pages are programmed in reliable mode");
+
+/*
  * You'll want to ignore badblocks if you're reading a partition that contains
  * data written by the TrueFFS library (i.e., by PalmOS, Windows, etc), since
  * it does not use mtd nand's method for marking bad blocks (using oob area).
@@ -113,6 +132,7 @@ struct docg4_priv {
 #define DOCG4_SEQ_PAGEWRITE		0x16
 #define DOCG4_SEQ_PAGEPROG		0x1e
 #define DOCG4_SEQ_BLOCKERASE		0x24
+#define DOCG4_SEQ_SETMODE		0x45
 
 /* DOC_FLASHCOMMAND register commands */
 #define DOCG4_CMD_PAGE_READ             0x00
@@ -122,6 +142,8 @@ struct docg4_priv {
 #define DOC_CMD_PROG_BLOCK_ADDR		0x60
 #define DOCG4_CMD_PAGEWRITE		0x80
 #define DOC_CMD_PROG_CYCLE2		0x10
+#define DOCG4_CMD_FAST_MODE		0xa3 /* functionality guessed */
+#define DOC_CMD_RELIABLE_MODE		0x22
 #define DOC_CMD_RESET			0xff
 
 /* DOC_POWERMODE register bits */
@@ -611,6 +633,14 @@ static void write_page_prologue(struct mtd_info *mtd, uint32_t docg4_addr)
 	dev_dbg(doc->dev,
 	      "docg4: %s: g4 addr: %x\n", __func__, docg4_addr);
 	sequence_reset(mtd);
+
+	if (unlikely(reliable_mode)) {
+		writew(DOCG4_SEQ_SETMODE, docptr + DOC_FLASHSEQUENCE);
+		writew(DOCG4_CMD_FAST_MODE, docptr + DOC_FLASHCOMMAND);
+		writew(DOC_CMD_RELIABLE_MODE, docptr + DOC_FLASHCOMMAND);
+		write_nop(docptr);
+	}
+
 	writew(DOCG4_SEQ_PAGEWRITE, docptr + DOC_FLASHSEQUENCE);
 	writew(DOCG4_CMD_PAGEWRITE, docptr + DOC_FLASHCOMMAND);
 	write_nop(docptr);
@@ -691,6 +721,15 @@ static void docg4_command(struct mtd_info *mtd, unsigned command, int column,
 		break;
 
 	case NAND_CMD_SEQIN:
+		if (unlikely(reliable_mode)) {
+			uint16_t g4_page = g4_addr >> 16;
+
+			/* writes to odd-numbered 2k pages are invalid */
+			if (g4_page & 0x01)
+				dev_warn(doc->dev,
+					 "invalid reliable mode address\n");
+		}
+
 		write_page_prologue(mtd, g4_addr);
 
 		/* hack for deferred write of oob bytes */
-- 
1.7.8.6

Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode

[Robert Jarzmik]

Mike Dunn <mikedunn@newsguy.com> writes:

> The controller on the docg4 has a "reliable" mode, where consecutive 2k pages
> are used in parallel.  The initial program loader (IPL) on my Treo 680 expects
> the secondary program loader (SPL) to be written in this mode.  This patch adds
> support for writing data in reliable mode, by way of a module parameter.
> Support for reading in this mode (as the IPL does) is not supported yet, but
> alternate (even-numbered) 2k pages written in reliable mode can be read normally
> (odd-numbered pages will contain junk and generate ecc errors).

Hi Mike,

I was considering adding this to the docg3 driver, but I didn't because I was
afraid what would happen if you change this mode *after* mounting a partition.
Imagine you have your rootfs mounted on /dev/mtd2, and u-boot is in /dev/mtd1 :
wouldn't changing the reliable mode to write "mtd1" corrupt all writes to mtd2 ?

The patch I chose to make barebox (instead of u-boot) work was to write the
barebox part with a special tool which "duplicates" pages, which ends up in the
same flash writes.

My feeling here is this mode should be "mtd partition bound", not driver bound
if you want to have it in your driver.

Cheers.

--
Robert

Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode

[Robert Jarzmik]

Robert Jarzmik <robert.jarzmik@free.fr> writes:

> I was considering adding this to the docg3 driver, but I didn't because I was
> afraid what would happen if you change this mode *after* mounting a partition.
> Imagine you have your rootfs mounted on /dev/mtd2, and u-boot is in /dev/mtd1 :
> wouldn't changing the reliable mode to write "mtd1" corrupt all writes to mtd2
> ?

I will rephrase that : I didn't "succeed" in having that parameter mtd partition
bound. If you find a way, I'll steal it for docg3 driver :)

If you don't, your patch is fine :
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>

-- 
Robert

Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode

[Mike Dunn]

On 12/09/2012 02:38 AM, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@free.fr> writes:
> 
>> I was considering adding this to the docg3 driver, but I didn't because I was
>> afraid what would happen if you change this mode *after* mounting a partition.
>> Imagine you have your rootfs mounted on /dev/mtd2, and u-boot is in /dev/mtd1 :
>> wouldn't changing the reliable mode to write "mtd1" corrupt all writes to mtd2
>> ?
> 
> I will rephrase that : I didn't "succeed" in having that parameter mtd partition
> bound. If you find a way, I'll steal it for docg3 driver :)


Yeah, I seemed to recall that reliable mode is supported in the docg3 driver.


> 
> If you don't, your patch is fine :
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> 

Thanks Robert.

Mike

Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode

[Mike Dunn]

Hi Robert.  Nice to hear from you.

On 12/09/2012 02:25 AM, Robert Jarzmik wrote:
> Mike Dunn <mikedunn@newsguy.com> writes:
> 
>> The controller on the docg4 has a "reliable" mode, where consecutive 2k pages
>> are used in parallel.  The initial program loader (IPL) on my Treo 680 expects
>> the secondary program loader (SPL) to be written in this mode.  This patch adds
>> support for writing data in reliable mode, by way of a module parameter.
>> Support for reading in this mode (as the IPL does) is not supported yet, but
>> alternate (even-numbered) 2k pages written in reliable mode can be read normally
>> (odd-numbered pages will contain junk and generate ecc errors).
> 
> Hi Mike,
> 
> I was considering adding this to the docg3 driver, but I didn't because I was
> afraid what would happen if you change this mode *after* mounting a partition.


Well, it's a module parameter, so the mode can't change unless the module is
reloaded, which means everything must be umounted first, right?


> Imagine you have your rootfs mounted on /dev/mtd2, and u-boot is in /dev/mtd1 :
> wouldn't changing the reliable mode to write "mtd1" corrupt all writes to mtd2 ?


I think this may only apply to docg3 (and docp3).  If I'm interpreting your
point correctly and IIRC from working with the docp3... the docg4 doesn't have
"planes".  Reliable mode uses *consecutive* 2k pages on the docg4, so the
side-effects of writing in reliable mode are restricted to the adjacent page,
not some far-away offset.  The lack of "planes" on the docg4 greatly simplifies
things.

Does this make sense?


> 
> The patch I chose to make barebox (instead of u-boot) work was to write the
> barebox part with a special tool which "duplicates" pages, which ends up in the
> same flash writes.
> 
> My feeling here is this mode should be "mtd partition bound", not driver bound
> if you want to have it in your driver.


My thinking is that it's a special case, probably limited to writing the SPL, so
making it a module parameter where the user has to explicitly specify it would
make it available to users without too much risk.  I also put a scary warning
about it in a comment in the driver source.

BTW, I think that my factory babdblock tables are written in reliable mode, so
it would be useful to add support to the driver for reading in this mode as well
(this patch only writes in reliable mode).  Data written in reliable mode can
still be read normally from the even-numbered 2k pages (I don't recall if this
is the case for the docg3), so I can read the factory bbt now, just not as reliably.

Thanks,
Mike

Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode

[Robert Jarzmik]

Mike Dunn <mikedunn@newsguy.com> writes:

Hi Mike,

Sorry for the late reply, I was taken over by work.

> Well, it's a module parameter, so the mode can't change unless the module is
> reloaded, which means everything must be umounted first, right?
Right.

>> Imagine you have your rootfs mounted on /dev/mtd2, and u-boot is in /dev/mtd1 :
>> wouldn't changing the reliable mode to write "mtd1" corrupt all writes to mtd2 ?
> I think this may only apply to docg3 (and docp3).  If I'm interpreting your
> point correctly and IIRC from working with the docp3... the docg4 doesn't have
> "planes".  Reliable mode uses *consecutive* 2k pages on the docg4, so the
> side-effects of writing in reliable mode are restricted to the adjacent page,
> not some far-away offset.  The lack of "planes" on the docg4 greatly simplifies
> things.
>
> Does this make sense?
Yes. As a side note, the reliable mode of docg3 write on consecutive 512b pages
(see log in commit c3de8a8a5a28603f8d318245992dbcda2e88a007).

>> The patch I chose to make barebox (instead of u-boot) work was to write the
>> barebox part with a special tool which "duplicates" pages, which ends up in the
>> same flash writes.
>> 
>> My feeling here is this mode should be "mtd partition bound", not driver bound
>> if you want to have it in your driver.
> My thinking is that it's a special case, probably limited to writing the SPL, so
> making it a module parameter where the user has to explicitly specify it would
> make it available to users without too much risk.  I also put a scary warning
> about it in a comment in the driver source.
OK, your choice.

As I have now the rootfs (ubifs on /dev/mtd2) on /, I cannot use docg3 as a
module and remove it anymore. Hence my hope somebody comes out with a solution
so that I have :
 - /dev/mtd1 in reliable mode (for the SPL)
 - /dev/mtd2 in normal mode (for root filesystem)

By now, I chose to use the SPL to rewrite itself (ie. barebox overwrites
/dev/mtd2 content). That's a bit sub-optimal as a fully booted kernel would be
able to make more checks (reread written blocks, check OOB signatures, ...).

> BTW, I think that my factory babdblock tables are written in reliable mode, so
> it would be useful to add support to the driver for reading in this mode as well
> (this patch only writes in reliable mode).  Data written in reliable mode can
> still be read normally from the even-numbered 2k pages (I don't recall if this
> is the case for the docg3), so I can read the factory bbt now, just not as
> reliably.
Ah good point, I will check on the docg3 how it worked, to see if they used also
the reliable mode for BBT table.

Cheers.

-- 
Robert

[PATCH 2/3] mtd: nand/docg4: reserve bb marker area in ecclayout

[Mike Dunn]

Modify the nand_ecclayout to place the two bb marker bytes in the oob region
off-limits to the user. 

Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
 drivers/mtd/nand/docg4.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index 54b1e5e..04e5fa9 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -214,15 +214,17 @@ struct docg4_priv {
 #define DOCG4_FACTORY_BBT_PAGE 16 /* page where read-only factory bbt lives */
 
 /*
- * Oob bytes 0 - 6 are available to the user.
- * Byte 7 is hamming ecc for first 7 bytes.  Bytes 8 - 14 are hw-generated ecc.
+ * Bytes 0, 1 are used as badblock marker.
+ * Bytes 2 - 6 are available to the user.
+ * Byte 7 is hamming ecc for first 7 oob bytes only.
+ * Bytes 8 - 14 are hw-generated ecc covering entire page + oob bytes 0 - 14.
  * Byte 15 (the last) is used by the driver as a "page written" flag.
  */
 static struct nand_ecclayout docg4_oobinfo = {
 	.eccbytes = 9,
 	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14, 15},
-	.oobavail = 7,
-	.oobfree = { {0, 7} }
+	.oobavail = 5,
+	.oobfree = { {.offset = 2, .length = 5} }
 };
 
 /*
-- 
1.7.8.6

[PATCH 3/3] mtd: nand/docg4: fix and improve read of factory bbt

[Mike Dunn]

This patch does two things related to reading the factory badblock table during
initialization: (1) fix error where a non-zero return code from
docg4_read_page() is assumed to be an error (it was later changed to be
max_bitflips; thanks to Brian Norris for bringing this to my attention a while
back), and (2) if there is an error reading the factory bbt, it tries reading
another (redundant) factory bbt table.

Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
 drivers/mtd/nand/docg4.c |   24 +++++++++++++++++++-----
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index 04e5fa9..18fa448 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -212,6 +212,7 @@ struct docg4_priv {
 #define DOCG4_T                4   /* BCH alg corrects up to 4 bit errors */
 
 #define DOCG4_FACTORY_BBT_PAGE 16 /* page where read-only factory bbt lives */
+#define DOCG4_REDUNDANT_BBT_PAGE 24 /* page where redundant factory bbt lives */
 
 /*
  * Bytes 0, 1 are used as badblock marker.
@@ -1020,16 +1021,15 @@ static int __init read_factory_bbt(struct mtd_info *mtd)
 	struct docg4_priv *doc = nand->priv;
 	uint32_t g4_addr = mtd_to_docg4_address(DOCG4_FACTORY_BBT_PAGE, 0);
 	uint8_t *buf;
-	int i, block, status;
+	int i, block;
+	__u32 eccfailed_stats = mtd->ecc_stats.failed;
 
 	buf = kzalloc(DOCG4_PAGE_SIZE, GFP_KERNEL);
 	if (buf == NULL)
 		return -ENOMEM;
 
 	read_page_prologue(mtd, g4_addr);
-	status = docg4_read_page(mtd, nand, buf, 0, DOCG4_FACTORY_BBT_PAGE);
-	if (status)
-		goto exit;
+	docg4_read_page(mtd, nand, buf, 0, DOCG4_FACTORY_BBT_PAGE);
 
 	/*
 	 * If no memory-based bbt was created, exit.  This will happen if module
@@ -1041,6 +1041,20 @@ static int __init read_factory_bbt(struct mtd_info *mtd)
 	if (nand->bbt == NULL)  /* no memory-based bbt */
 		goto exit;
 
+	if (mtd->ecc_stats.failed > eccfailed_stats) {
+		/*
+		 * Whoops, an ecc failure ocurred reading the factory bbt.
+		 * It is stored redundantly, so we get another chance.
+		 */
+		eccfailed_stats = mtd->ecc_stats.failed;
+		docg4_read_page(mtd, nand, buf, 0, DOCG4_REDUNDANT_BBT_PAGE);
+		if (mtd->ecc_stats.failed > eccfailed_stats) {
+			dev_warn(doc->dev,
+				 "The factory bbt could not be read!\n");
+			goto exit;
+		}
+	}
+
 	/*
 	 * Parse factory bbt and update memory-based bbt.  Factory bbt format is
 	 * simple: one bit per block, block numbers increase left to right (msb
@@ -1060,7 +1074,7 @@ static int __init read_factory_bbt(struct mtd_info *mtd)
 	}
  exit:
 	kfree(buf);
-	return status;
+	return 0;
 }
 
 static int docg4_block_markbad(struct mtd_info *mtd, loff_t ofs)
-- 
1.7.8.6

Re: [PATCH 0/3] mtd: nand/docg4: set of fixes and enhancements

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Fri, 2012-12-07 at 12:07 -0800, Mike Dunn wrote:
> Hi, this is a short set of minor fixes and enhancements to the docg4, tested on
> my Palm Treo 680.
> 
> Mike Dunn (3):
>   mtd: nand/docg4: add support for writing in reliable mode
>   mtd: nand/docg4: reserve bb marker area in ecclayout
>   mtd: nand/docg4: fix and improve read of factory bbt

Pushed to l2-mtd.git, thanks!

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]