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
Solved! Go to Solution.
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!
-----------------------------------------------------------------------------------------------------------------------
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!
-----------------------------------------------------------------------------------------------------------------------
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
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
};