[U-Boot] [PATCH 0/2] Introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY, and use it on cm_t35

[U-Boot] [PATCH 0/2] Introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY, and use it on cm_t35

[Nikita Kiryanov]

Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
(d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
configured. The change is not incorrect, but it does cause compatibility issues
for boards that depended on the old behavior. Therefore, instead of reverting
the change, a quirks option is introduced to allow boards to get the old
behavior back. This config option is then used in cm_t35.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Nikita Kiryanov (2):
  arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY
  arm: omap: cm_t35: fix nand sw ecc incompatibility with X-Loader

 doc/README.nand              | 7 +++++++
 drivers/mtd/nand/omap_gpmc.c | 4 ++++
 include/configs/cm_t35.h     | 1 +
 3 files changed, 12 insertions(+)

-- 
1.8.1.2

[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Nikita Kiryanov]

Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
(d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
configured, both during boot, and during ecc switch, in a way that is not
backwards compatible with older systems (for example, X-Loader on CM-T35 relies
on the old behavior).

The culprit is the line which assigns ecc.size for software ECC.
Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for
software ecc, relying on nand_scan_tail() to select a default for ecc.size
(256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which
is likely to not be 256.

With this change, "nandecc sw" no longer sets up software ECC the old way,
which makes it unusable to those who rely on the old behavior, and if the user
wants to default to hardware ECC, the old software ECC configuration becomes
completely unattainable.

To provide backwards compatibility, introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY.
If this CONFIG option is set, omap_select_ecc_scheme() will assign the old
default to ecc.size, instead of the value of pagesize.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Pekon Gupta <pekon@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
---
 doc/README.nand              | 7 +++++++
 drivers/mtd/nand/omap_gpmc.c | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/doc/README.nand b/doc/README.nand
index b91f198..a115260 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -232,6 +232,13 @@ Platform specific options
 		- ecc calculation using GPMC hardware engine,
 		- error detection using ELM hardware engine.
 
+   CONFIG_NAND_OMAP_SW_ECC_LEGACY
+   	On OMAP platforms, this CONFIG is used to force pre v2014.01
+   	configuration of software ECC. This is necessary for old systems which
+   	rely on the old behavior (such as systems that boot with X-Loader).
+   	Use this CONFIG if you have an old software stack and are having
+   	problems reading U-Boot data that was written using software ECC.
+
 NOTE:
 =====
 
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 23a961c..0eb65d5 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -774,7 +774,11 @@ static int omap_select_ecc_scheme(struct nand_chip *nand,
 		bch_priv.type		= 0;
 		nand->ecc.mode		= NAND_ECC_SOFT;
 		nand->ecc.layout	= NULL;
+#ifdef CONFIG_NAND_OMAP_SW_ECC_LEGACY
+		nand->ecc.size		= 256;
+#else
 		nand->ecc.size		= pagesize;
+#endif
 		bch->ecc_scheme		= OMAP_ECC_HAM1_CODE_SW;
 		break;
 
-- 
1.8.1.2

[U-Boot] [PATCH 2/2] arm: omap: cm_t35: fix nand sw ecc incompatibility with X-Loader

[Nikita Kiryanov]

cm_t35 boards use X-Loader to boot U-Boot. X-Loader expects U-Boot to be written
to NAND with software ECC.
Use CONFIG_NAND_OMAP_SW_ECC_LEGACY to make U-Boot configure software ECC in
X-Loader compatible way.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@ti.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
---
 include/configs/cm_t35.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 2e865c0..9bcaa75 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -158,6 +158,7 @@
  */
 #define CONFIG_SYS_NAND_QUIET_TEST
 #define CONFIG_NAND_OMAP_GPMC
+#define CONFIG_NAND_OMAP_SW_ECC_LEGACY
 #define CONFIG_SYS_NAND_ADDR		NAND_BASE	/* physical address */
 							/* to access nand */
 #define CONFIG_SYS_NAND_BASE		NAND_BASE	/* physical address */
-- 
1.8.1.2

[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Gupta, Pekon]

Hi Nikita,

>From: Nikita Kiryanov [mailto:nikita at compulab.co.il]
>Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
>(d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
>configured, both during boot, and during ecc switch, in a way that is not
>backwards compatible with older systems (for example, X-Loader on CM-T35 relies
>on the old behavior).
>
>The culprit is the line which assigns ecc.size for software ECC.
>Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for
>software ecc, relying on nand_scan_tail() to select a default for ecc.size
>(256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which
>is likely to not be 256.
>
Then its just one-line change.. Remove "ecc.size = pagesize".
Why do you need to add a newer config for that ?
This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility
with legacy devices. (As also mentioned in doc/README.nand)
-----------------------------
  CONFIG_NAND_OMAP_ECCSCHEME
	On OMAP platforms, this CONFIG specifies NAND ECC scheme.
	It can take following values:
	OMAP_ECC_HAM1_CODE_SW
		1-bit Hamming code using software lib.
		(for legacy devices only)
-----------------------------

But I don't have any board to boot-test this, because all my boards
have newer ROM code, which auto-detects BCH8 or BCH16 based
on block-size of NAND device connected to it.

Also, I suggest to migrate to 'HAM1_HW' as this should be compatible to
OMAP3 ROM code (for NAND boot), at-least I could check that based
on NAND ecc-layout given in OMAP35xx TRM.
'HAM1_SW' will un-necessary burden your CPU by calculating ECC in
software, inspite the fact that GPMC controller can do that in hardware.


with regards, pekon

[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Igor Grinberg]

Hi Pekon,

On 12/11/13 23:18, Gupta, Pekon wrote:
> Hi Nikita,
> 
>> From: Nikita Kiryanov [mailto:nikita at compulab.co.il]
>> Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
>> (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
>> configured, both during boot, and during ecc switch, in a way that is not
>> backwards compatible with older systems (for example, X-Loader on CM-T35 relies
>> on the old behavior).
>>
>> The culprit is the line which assigns ecc.size for software ECC.
>> Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for
>> software ecc, relying on nand_scan_tail() to select a default for ecc.size
>> (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which
>> is likely to not be 256.
>>
> Then its just one-line change.. Remove "ecc.size = pagesize".
> Why do you need to add a newer config for that ?

Well, we think that having that line is actually the right behavior,
and it is a pity we did not have this from the start in the X-Loader.
So that is why we did not want to change it in a brutal way...
But if you say:

> This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility
> with legacy devices. (As also mentioned in doc/README.nand)
> -----------------------------
>   CONFIG_NAND_OMAP_ECCSCHEME
> 	On OMAP platforms, this CONFIG specifies NAND ECC scheme.
> 	It can take following values:
> 	OMAP_ECC_HAM1_CODE_SW
> 		1-bit Hamming code using software lib.
> 		(for legacy devices only)
> -----------------------------

then it makes real sense to just revert the ecc.size setting to
what it was prior to your patches.

> 
> But I don't have any board to boot-test this, because all my boards
> have newer ROM code, which auto-detects BCH8 or BCH16 based
> on block-size of NAND device connected to it.
> 
> Also, I suggest to migrate to 'HAM1_HW' as this should be compatible to
> OMAP3 ROM code (for NAND boot), at-least I could check that based
> on NAND ecc-layout given in OMAP35xx TRM.

The problem is not the ROM code...
Our systems are in production phase already for a long time and
we have customers relying on the old behavior,
so we cannot just switch the ECC to HW and stop using the SW one.

> 'HAM1_SW' will un-necessary burden your CPU by calculating ECC in
> software, inspite the fact that GPMC controller can do that in hardware.

Well, that is indeed the case.
I think TI should have think about it in first place before
releasing the SW ECC based drivers... ;-)


-- 
Regards,
Igor.

[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Gupta, Pekon]

Hi,

>From: Igor Grinberg [mailto:grinberg at compulab.co.il]
>>On 12/11/13 23:18, Gupta, Pekon wrote:
>>> From: Nikita Kiryanov [mailto:nikita at compulab.co.il]
>>> Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
>>> (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
>>> configured, both during boot, and during ecc switch, in a way that is not
>>> backwards compatible with older systems (for example, X-Loader on CM-T35 relies
>>> on the old behavior).
>>>
>>> The culprit is the line which assigns ecc.size for software ECC.
>>> Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for
>>> software ecc, relying on nand_scan_tail() to select a default for ecc.size
>>> (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which
>>> is likely to not be 256.
>>>
>> Then its just one-line change.. Remove "ecc.size = pagesize".
>> Why do you need to add a newer config for that ?
>
>Well, we think that having that line is actually the right behavior,
>and it is a pity we did not have this from the start in the X-Loader.
>So that is why we did not want to change it in a brutal way...
>But if you say:
>
>> This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility
>> with legacy devices. (As also mentioned in doc/README.nand)
>> -----------------------------
>>   CONFIG_NAND_OMAP_ECCSCHEME
>> 	On OMAP platforms, this CONFIG specifies NAND ECC scheme.
>> 	It can take following values:
>> 	OMAP_ECC_HAM1_CODE_SW
>> 		1-bit Hamming code using software lib.
>> 		(for legacy devices only)
>> -----------------------------
>
>then it makes real sense to just revert the ecc.size setting to
>what it was prior to your patches.
>
Yes, please fix this.. 


>>
>> But I don't have any board to boot-test this, because all my boards
>> have newer ROM code, which auto-detects BCH8 or BCH16 based
>> on block-size of NAND device connected to it.
>>
>> Also, I suggest to migrate to 'HAM1_HW' as this should be compatible to
>> OMAP3 ROM code (for NAND boot), at-least I could check that based
>> on NAND ecc-layout given in OMAP35xx TRM.
>
>The problem is not the ROM code...
>Our systems are in production phase already for a long time and
>we have customers relying on the old behavior,
>so we cannot just switch the ECC to HW and stop using the SW one.
>
I understand, sorry my update caused you regression, but OMAP3 EVM,
were released so long back [1], that I myself find it difficult to get a working
setup to test. 


>> 'HAM1_SW' will un-necessary burden your CPU by calculating ECC in
>> software, inspite the fact that GPMC controller can do that in hardware.
>
>Well, that is indeed the case.
>I think TI should have think about it in first place before
>releasing the SW ECC based drivers... ;-)
>
Though I'm not the right person to answer this, but some of my assumptions
on why TI continued supporting HAM1_SW at the time of
OMAP3 production (2006-2007) [1]:
- Noone could have predict which ecc-scheme would become popular, and
  so TI kept both HAM1_SW and introduced HAM1_HW.
- Also, I think TI introduced HAM1_SW because they did not want to
  be gated if GPMC hardware engine had some silicon issues.

But if I'm not wrong, you cannot boot from NAND when using HAM1_SW,
because the ecc-layout for HAM1_SW is in-compatible to ROM code. So, I still
suggest you to migrate to HAM1_HW, or higher ecc-schemes like BCH8.
Also in mainline kernel HAM1_SW support is deprecated for omap2.c. I can help
you to migrate to higher ecc-schemes, if your customer agrees..


[1] http://www.prnewswire.com/news-releases/texas-instruments-new-omaptm-3-architecture-will-spark-development-of-a-new-class-of-mobile-phones-55318217.html
" TI's OMAP3430 multimedia processor is expected to sample in mid-2006, with
 volume production scheduled for 2007.  For additional information regarding
 the OMAP3430 processor, please visit http://www.ti.com/omap3 ."


with regards, pekon

[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Igor Grinberg]

On 12/12/13 11:16, Gupta, Pekon wrote:
> Hi,
> 
>> From: Igor Grinberg [mailto:grinberg at compulab.co.il]
>>> On 12/11/13 23:18, Gupta, Pekon wrote:
>>>> From: Nikita Kiryanov [mailto:nikita at compulab.co.il]
>>>> Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
>>>> (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
>>>> configured, both during boot, and during ecc switch, in a way that is not
>>>> backwards compatible with older systems (for example, X-Loader on CM-T35 relies
>>>> on the old behavior).
>>>>
>>>> The culprit is the line which assigns ecc.size for software ECC.
>>>> Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for
>>>> software ecc, relying on nand_scan_tail() to select a default for ecc.size
>>>> (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which
>>>> is likely to not be 256.
>>>>
>>> Then its just one-line change.. Remove "ecc.size = pagesize".
>>> Why do you need to add a newer config for that ?
>>
>> Well, we think that having that line is actually the right behavior,
>> and it is a pity we did not have this from the start in the X-Loader.
>> So that is why we did not want to change it in a brutal way...
>> But if you say:
>>
>>> This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility
>>> with legacy devices. (As also mentioned in doc/README.nand)
>>> -----------------------------
>>>   CONFIG_NAND_OMAP_ECCSCHEME
>>> 	On OMAP platforms, this CONFIG specifies NAND ECC scheme.
>>> 	It can take following values:
>>> 	OMAP_ECC_HAM1_CODE_SW
>>> 		1-bit Hamming code using software lib.
>>> 		(for legacy devices only)
>>> -----------------------------
>>
>> then it makes real sense to just revert the ecc.size setting to
>> what it was prior to your patches.
>>
> Yes, please fix this.. 
> 
> 
>>>
>>> But I don't have any board to boot-test this, because all my boards
>>> have newer ROM code, which auto-detects BCH8 or BCH16 based
>>> on block-size of NAND device connected to it.
>>>
>>> Also, I suggest to migrate to 'HAM1_HW' as this should be compatible to
>>> OMAP3 ROM code (for NAND boot), at-least I could check that based
>>> on NAND ecc-layout given in OMAP35xx TRM.
>>
>> The problem is not the ROM code...
>> Our systems are in production phase already for a long time and
>> we have customers relying on the old behavior,
>> so we cannot just switch the ECC to HW and stop using the SW one.
>>
> I understand, sorry my update caused you regression, but OMAP3 EVM,
> were released so long back [1], that I myself find it difficult to get a working
> setup to test. 

This is understood. I'm not blaming anyone...

> 
> 
>>> 'HAM1_SW' will un-necessary burden your CPU by calculating ECC in
>>> software, inspite the fact that GPMC controller can do that in hardware.
>>
>> Well, that is indeed the case.
>> I think TI should have think about it in first place before
>> releasing the SW ECC based drivers... ;-)
>>
> Though I'm not the right person to answer this, but some of my assumptions
> on why TI continued supporting HAM1_SW at the time of
> OMAP3 production (2006-2007) [1]:
> - Noone could have predict which ecc-scheme would become popular, and
>   so TI kept both HAM1_SW and introduced HAM1_HW.
> - Also, I think TI introduced HAM1_SW because they did not want to
>   be gated if GPMC hardware engine had some silicon issues.

Well, once again, I'm not blaming anyone, and
the above are pretty much valid arguments.
I myself make similar decisions based on similar facts...

> 
> But if I'm not wrong, you cannot boot from NAND when using HAM1_SW,
> because the ecc-layout for HAM1_SW is in-compatible to ROM code.

Indeed that is the case, but I'm not talking about the ROM code.

> So, I still
> suggest you to migrate to HAM1_HW, or higher ecc-schemes like BCH8.

This will work for new projects based on the OMAP3 hardware,
and it will introduce an overhead which we cannot live with.
If we migrate completely to ECC HW, it will most likely break our
customers production. That is why we have to support OMAP3
hardware with SW ECC.

> Also in mainline kernel HAM1_SW support is deprecated for omap2.c.

This is new to me, I haven't been following OMAP GPMC NAND driver
for a while... I will check this.
Nevertheless, our customers production is not based on mainline kernel.

> I can help
> you to migrate to higher ecc-schemes, if your customer agrees..

Thanks for the proposition, but I don't see this happening any when
in the near future.

> 
> 
> [1] http://www.prnewswire.com/news-releases/texas-instruments-new-omaptm-3-architecture-will-spark-development-of-a-new-class-of-mobile-phones-55318217.html
> " TI's OMAP3430 multimedia processor is expected to sample in mid-2006, with
>  volume production scheduled for 2007.  For additional information regarding
>  the OMAP3430 processor, please visit http://www.ti.com/omap3 ."
> 
> 
> with regards, pekon
> 

-- 
Regards,
Igor.

[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Nikita Kiryanov]

On 12/11/2013 11:18 PM, Gupta, Pekon wrote:
> Hi Nikita,
>
>> From: Nikita Kiryanov [mailto:nikita at compulab.co.il]
>> Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
>> (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
>> configured, both during boot, and during ecc switch, in a way that is not
>> backwards compatible with older systems (for example, X-Loader on CM-T35 relies
>> on the old behavior).
>>
>> The culprit is the line which assigns ecc.size for software ECC.
>> Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for
>> software ecc, relying on nand_scan_tail() to select a default for ecc.size
>> (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which
>> is likely to not be 256.
>>
> Then its just one-line change.. Remove "ecc.size = pagesize".
> Why do you need to add a newer config for that ?
> This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility
> with legacy devices. (As also mentioned in doc/README.nand)
> -----------------------------
>    CONFIG_NAND_OMAP_ECCSCHEME
> 	On OMAP platforms, this CONFIG specifies NAND ECC scheme.
> 	It can take following values:
> 	OMAP_ECC_HAM1_CODE_SW
> 		1-bit Hamming code using software lib.
> 		(for legacy devices only)
> -----------------------------

OK if that's the case then that makes things easier. New patch coming
up.

-- 
Regards,
Nikita.

[U-Boot] [PATCH 0/2] Introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY, and use it on cm_t35

[Nikita Kiryanov]

This series is superceded by the following patch:
http://patchwork.ozlabs.org/patch/300617/

On 12/11/2013 06:57 PM, Nikita Kiryanov wrote:
> Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform"
> (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is
> configured. The change is not incorrect, but it does cause compatibility issues
> for boards that depended on the old behavior. Therefore, instead of reverting
> the change, a quirks option is introduced to allow boards to get the old
> behavior back. This config option is then used in cm_t35.
>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Cc: Tom Rini <trini@ti.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Pekon Gupta <pekon@ti.com>
> Nikita Kiryanov (2):
>    arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY
>    arm: omap: cm_t35: fix nand sw ecc incompatibility with X-Loader
>
>   doc/README.nand              | 7 +++++++
>   drivers/mtd/nand/omap_gpmc.c | 4 ++++
>   include/configs/cm_t35.h     | 1 +
>   3 files changed, 12 insertions(+)
>


-- 
Regards,
Nikita.