Choice of ECC strength in gpmi-nand driver

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Choice of ECC strength in gpmi-nand driver

跳至解决方案
3,374 次查看
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

标签 (2)
0 项奖励
回复
1 解答
2,063 次查看
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 项奖励
回复
3 回复数
2,064 次查看
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 项奖励
回复
2,063 次查看
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 项奖励
回复
2,064 次查看
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 项奖励
回复