[U-Boot] [PATCH 0/2] Introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY, and use it on cm_t35
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(+)
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;
Hi Nikita,
From: Nikita Kiryanov [mailto:nikita@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
Hi Pekon,
On 12/11/13 23:18, Gupta, Pekon wrote:
Hi Nikita,
From: Nikita Kiryanov [mailto:nikita@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... ;-)
Hi,
From: Igor Grinberg [mailto:grinberg@compulab.co.il]
On 12/11/13 23:18, Gupta, Pekon wrote:
From: Nikita Kiryanov [mailto:nikita@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-archi... " 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
On 12/12/13 11:16, Gupta, Pekon wrote:
Hi,
From: Igor Grinberg [mailto:grinberg@compulab.co.il]
On 12/11/13 23:18, Gupta, Pekon wrote:
From: Nikita Kiryanov [mailto:nikita@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-archi... " 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
On 12/11/2013 11:18 PM, Gupta, Pekon wrote:
Hi Nikita,
From: Nikita Kiryanov [mailto:nikita@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.
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 */
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(+)
participants (3)
-
Gupta, Pekon -
Igor Grinberg -
Nikita Kiryanov