ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption

Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix onenand rate detection to avoid filesystem corruption") partially fixed onenand configuration when GPMC module is reset. Finish the job by also providing the correct values in ONENAND_REG_SYS_CFG1 register.

Signed-off-by Ivaylo Dimitrov <[email protected]>

---
 arch/arm/mach-omap2/gpmc-onenand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/mach-omap2/gpmc-onenand.c +3 -3

index 7b76ce0..8633c70 100644
@@ -101,10 +101,8 @@ static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
 
 static void set_onenand_cfg(void __iomem *onenand_base)
 {
-	u32 reg;
+	u32 reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
 
-	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
-	reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
 	reg |=	(latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
 		ONENAND_SYS_CFG1_BL_16;
 	if (onenand_flags & ONENAND_FLAG_SYNCREAD)

@@ -123,6 +121,7 @@ static void set_onenand_cfg(void __iomem *onenand_base)
 		reg |= ONENAND_SYS_CFG1_VHF;
 	else
 		reg &= ~ONENAND_SYS_CFG1_VHF;
+
 	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
 }
 

@@ -289,6 +288,7 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
 		}
 	}
 
+	onenand_async.sync_write = true;
 	omap2_onenand_calc_async_timings(&t);
 
 	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);

Signature · 1 line

1.9.1

OK. So probably the INT or RDY polarity made the ECC not work.

Aaro, care to dump out also the nolo configured CFG1 value from n8x0 and n9(50)?

You can do it by adding something like this to the beginning of set_onenand_cfg():

Hi

Quoted 3 lines · Tony Lindgren

OK. So probably the INT or RDY polarity made the ECC not work.

Well, ECC disable bit (ONENAND_SYS_CFG1_NO_ECC) was set as well, so most probably it was the bugger :)

Quoted 6 lines

Aaro, care to dump out also the nolo configured CFG1 value from n8x0 and n9(50)?

You can do it by adding something like this to the beginning of set_onenand_cfg():

Also, do not forget to restore HWMOD_INIT_NO_RESET in gpmc_hwmod in question and (maybe) revert e7b11dc7b77bfce0a351230a5feeadc1d0bba997.

Quoted 4 lines · Ivaylo Dimitrov

Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix onenand rate detection to avoid filesystem corruption") partially fixed onenand configuration when GPMC module is reset. Finish the job by also providing the correct values in ONENAND_REG_SYS_CFG1 register.

OK. So probably the INT or RDY polarity made the ECC not work.

Aaro, care to dump out also the nolo configured CFG1 value from n8x0 and n9(50)?

You can do it by adding something like this to the beginning of set_onenand_cfg():

pr_info("CFG1: 0x%04x\n", readw(onenand_base + ONENAND_REG_SYS_CFG1));

And presumably the values are the same as on n900. If not, we should do the legacy file system flash test on all of them before committing this fix.

Hi,

Quoted 11 lines · Tony Lindgren

Quoted 4 lines · Ivaylo Dimitrov

Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix onenand rate detection to avoid filesystem corruption") partially fixed onenand configuration when GPMC module is reset. Finish the job by also providing the correct values in ONENAND_REG_SYS_CFG1 register.

OK. So probably the INT or RDY polarity made the ECC not work.

Aaro, care to dump out also the nolo configured CFG1 value from n8x0 and n9(50)?

Quoted 8 lines

You can do it by adding something like this to the beginning of set_onenand_cfg():

pr_info("CFG1: 0x%04x\n", readw(onenand_base + ONENAND_REG_SYS_CFG1));

And presumably the values are the same as on n900. If not, we should do the legacy file system flash test on all of them before committing this fix.

I got these (with CONFIG_OMAP_GPMC_DEBUG also enabled):

N800:

[    2.803100] CFG1: 0x46c0
[    3.150115] CFG1: 0x06c0

N810:

[    2.802368] CFG1: 0x46c0
[    3.148620] CFG1: 0x06c0

N900:

[    4.965576] CFG1: 0x46c0
[    5.333740] CFG1: 0x06c0

N950:

[    4.217193] CFG1: 0x66c4
[    4.583221] CFG1: 0x06c0

N9:

[    4.212677] CFG1: 0x66c4
[    4.578613] CFG1: 0x06c0

Also.. There's a chance somebody has created a onenand file system with recent mainline kernels that did the reset and disabled ECC. So with Ivaylo's patch fixing that, those may not mount properly any longer. Most likely people just keep their maemo rootfs there though with the MMC being available.

Hi,

Quoted 6 lines · Tony Lindgren

Also.. There's a chance somebody has created a onenand file system with recent mainline kernels that did the reset and disabled ECC. So with Ivaylo's patch fixing that, those may not mount properly any longer. Most likely people just keep their maemo rootfs there though with the MMC being available.

I guess this is possible, but what worries me more is that the longer the patch is not pushed, the higher the chance somebody to end-up with broken rootfs. Wouldn't it be better to push it, thus preventing that happening?

BTW the differences for N9/50 come from ONENAND_SYS_CFG1_HF bit and ONENAND_SYS_CFG1_BRL_6 vs ONENAND_SYS_CFG1_BRL_4. Both are changed (later in the code) anyway, so I guess it is safe to reset them to default values.

Or, maybe the correct fix is to issue RESET command to onenand controller after GPMC reset? RESET command is supposed to put all the bits to their default values.

Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix onenand rate detection to avoid filesystem corruption") partially fixed onenand configuration when GPMC module is reset. Finish the job by also providing the correct values in ONENAND_REG_SYS_CFG1 register.

Signed-off-by Ivaylo Dimitrov <[email protected]>

---
 arch/arm/mach-omap2/gpmc-onenand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/mach-omap2/gpmc-onenand.c +3 -3

index 7b76ce0..8633c70 100644
@@ -101,10 +101,8 @@ static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
 
 static void set_onenand_cfg(void __iomem *onenand_base)
 {
-	u32 reg;
+	u32 reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
 
-	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
-	reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
 	reg |=	(latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
 		ONENAND_SYS_CFG1_BL_16;
 	if (onenand_flags & ONENAND_FLAG_SYNCREAD)

@@ -123,6 +121,7 @@ static void set_onenand_cfg(void __iomem *onenand_base)
 		reg |= ONENAND_SYS_CFG1_VHF;
 	else
 		reg &= ~ONENAND_SYS_CFG1_VHF;
+
 	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
 }
 

@@ -289,6 +288,7 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
 		}
 	}
 
+	onenand_async.sync_write = true;
 	omap2_onenand_calc_async_timings(&t);
 
 	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);

Signature · 6 lines

1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

The remaining combinations of AES-CBC and SHA* have already been marked as allowed. This commit does the same for SHA224 and SHA384.

Signed-off-by Aleksander Jan Bajkowski <[email protected]>

---
 crypto/testmgr.c | 2 ++
 1 file changed, 2 insertions(+)