Choice of ECC strength in gpmi-nand driver

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Choice of ECC strength in gpmi-nand driver

Jump to solution
3,233 Views
austinphillips
Contributor II

Hello,

I'm using the the Linux BSP gpmi-nand.c driver from git://git.freescale.com/imx/linux-2.6-imx.git, tag rel_imx_4.1.15_1.2.0_ga with a Micron NAND MT29F4G08ABADAWP which has 2K + 64bytes OOB pages, and reports a minimum ECC strength of 4 bits per 512 byte data block.

The legacy gpmi-nand layout (fsl,legacy-bch-geometry [See Legacy gpmi-nand layout device tree option not handled correctly]) results in an ECC strength to be chosen as 8 bits.  The newer default BCH layout chooses an ECC of 4, which is minimum reported ECC strength required by the NAND part.

I'm curious as to why the default ECC strength for the NAND driver would be less than what could be supported by the available space in the part?

ie. With 2K + 64OOB pages, there is sufficient space to store ECC with 8 bit strength, so what is the reason the layout was changed from the legacy version (8 bit) to prefer a lower strength ECC (4 bit) by the newer layout?

Thank you

Austin

Labels (2)
0 Kudos
1 Solution
1,922 Views
igorpadykov
NXP Employee
NXP Employee

Hi Austin

you are right, driver chooses smallest ecc for nand still complying with its requirements defined in datasheet,

to avoid unnecessary overheads related to bigger ecc calculations.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
3 Replies
1,923 Views
igorpadykov
NXP Employee
NXP Employee

Hi Austin

you are right, driver chooses smallest ecc for nand still complying with its requirements defined in datasheet,

to avoid unnecessary overheads related to bigger ecc calculations.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,922 Views
austinphillips
Contributor II

Hi Igor,

Thank you for your reply.  It seems that using the smallest ECC behaviour should really be controlled by the fsl,use-minimum-ecc device tree entry as documented in the Documentation folder of the linux source tree, and not be the default behaviour.  The Freescale driver appears not to read fsl,use-minimum-ecc at all.

I think the mainline Linux kernel may utilise fsl,use-minimum-ecc but I haven't tested its behaviour.

Regards

Austin

0 Kudos
1,923 Views
arnoutdiels
Contributor III

Hi Austin,

I think the mainline Linux kernel may utilise fsl,use-minimum-ecc but I haven't tested its behaviour.

It seems to.

We're testing an upgrade from the v4.1 fsl imx branch to the v4.11 upstream, and ran into ECC issues too:

When trying to mount an ubi partition:

[  112.846068] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry

Our v4.1 DTS entry looked like this:

&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpmi_nand_1>;
status = "okay";
nand-on-flash-bbt;

};

I can confirm that by setting the fsl,use-minimum-ecc flag, I now get past these errors on v4.11:

&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpmi_nand_1>;
status = "okay";
nand-on-flash-bbt;
fsl,use-minimum-ecc; // Act like the V4.1 driver does by default
};

 

0 Kudos