DM36x, NAND, U-Boot, and ECC (oh my!)

Mark,

mdeneen said:

 However, introducing these changes will cause U-Boot (and maybe Linux) to be unable to effectively write to nand.

This statement is wrong. If you erase the NAND completely and flash it again with the updated layouts, it should work fine without any issues, provided all of them are using the same algorithm and ECC layout.

Renjith,

With the updated layouts, Linux will be unable to read the BBT.  This will cause problems, yes?

Mark

Mark,

I don't think this will cause any issue as the BBT is typically kept towards the last block of the flash by u-boot. Also the manufacturer bad block marking will be within the first couple of bytes of the spare area. So I don't think that will cause any trouble. 

Renjith,

I agree with the location of the BBT.  What I'm saying is that the kernel spits out some ECC error messages when it tries to read the location of the bad blocks.  Maybe this is harmless and I should look into it further, but it felt as if Linux wouldn't know where the bad blocks were and I might potentially use one.

Mark

Mark,

Just try the command "nand scrub" from u-boot. If you are still seeing those logs, please share the logs.

Renjith,

I'll give this a shot.  I understand now more clearly how the BBT was written, and that this would not happen with a fresh NAND chip.

Mark

Mark,

I believe your original query is resolved. Can you mark this post as answered if you believe so?

Hi Mark, Renjith,

As far as I can tell Mark is correct in saying that the modified ECC layout (as per http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout) would interfere with the BBT descriptor.  The BBT is identified by a patttern in the OOB, at a certain offset (http://wiki.laptop.org/go/NAND_Flash_Bad_Block_Table#Bad_Block_Table_Format).  This is defined in my nand_bbt.c (kernel version 2.6.32.17), and from my understanding it is looking for "Bbt0" or "1tbB" (for the mirror table) at an offset of 8 bytes into the OOB, which happens to be right in the middle of some ECC data according to the RBL's layout.  We made the change for the ECC layout, initially intending to just use it for writing UBL and U-Boot to NAND and then to revert to the normal layout, but decided to just keep the RBL layout so that we could easily update U-Boot in the field if necessary.  However we then noticed that U-Boot and Linux were complaining "Bad block table not found for chip 0".

I have implemented this patch, to go along with the changes to the ECC layout:

Index: drivers/mtd/nand/nand_bbt.c
===================================================================
--- drivers/mtd/nand/nand_bbt.c (revision 149)
+++ drivers/mtd/nand/nand_bbt.c (working copy)
@@ -1116,9 +1116,15 @@
static struct nand_bbt_descr bbt_main_descr = {
.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
| NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+#ifdef CONFIG_MTD_NAND_DAVINCI_RBL_ECC_LAYOUT
+ .offs = 16,
+ .len = 4,
+ .veroffs = 20,
+#else
.offs = 8,
.len = 4,
.veroffs = 12,
+#endif
.maxblocks = 4,
.pattern = bbt_pattern
};
@@ -1126,9 +1132,15 @@
static struct nand_bbt_descr bbt_mirror_descr = {
.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
| NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
+#ifdef CONFIG_MTD_NAND_DAVINCI_RBL_ECC_LAYOUT
+ .offs = 16,
+ .len = 4,
+ .veroffs = 20,
+#else
.offs = 8,
.len = 4,
.veroffs = 12,
+#endif
.maxblocks = 4,
.pattern = mirror_pattern
};

My colleague just tested it and our U-Boot and Linux are happy with life again.  My knowledge of NAND OOB is quite sparse though, so I'm not sure if maybe I've moved the BBT descriptor to a location that is reserved for something else...