i.MX6 and NAND flash H27UBG8T2CTR

[vladislavkasik]

Hello,

We have ongoing i.MX6 design with SK Hynix H27UBG8T2CTR NAND flash. It is MLC, 32Gbit, 8192 bytes per page, 2M block and 640 bytes OOB with 40bit/1KBytes ECC Level, see the attached datasheet. We are using current Yocto imx-3.10.53-1.1.0_ga BSP and Duallite i.MX6

We have encountered 2 issues:

1. The flash does not get auto detected properly both in u-boot and Linux kernel apparently due to a slightly different ID structure. It gets detected only as 4k page flash with 128 byte OOB only.
2. If we add the flash manually into the Linux kernel into nand_flash_ids in nand_ids.c:

       {"H27UBG8T2CTR 32G 3.3V 8-bit",
           { .id = {0xad, 0xd7, 0x94, 0x91, 0x60, 0x44} },
             SZ_8K, SZ_4K, SZ_2M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K) },
   

   then the flash seems to get detected properly however we get the following error:

   nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
   nand: Hynix H27UBG8T2CTR 32G 3.3V 8-bit
   nand: 4096MiB, MLC, page size: 8192, OOB size: 640
   gpmi-nand 112000.gpmi-nand: We can not support this nand chip. Its required ecc strength(44) is beyond our capability(40).
   gpmi-nand 112000.gpmi-nand: Error setting BCH geometry : 1
   gpmi-nand 112000.gpmi-nand: driver registration failed: 1
   gpmi-nand: probe of 112000.gpmi-nand failed with error 1

My question is, can this flash be supported by the i.MX6 NAND/BCH controller using selected settings?

Is it a good idea to lower ECC strength under what has been specified by the NAND manufacturer to fit in the nand flash controller capability or we should rather consider using different chip?

Thank you very much for any advice beforehand!

Vladislav

[vladislavkasik]

Just to sum the situation up. Although Linux kernel can be persuaded to support this NAND as a MTD device, there currently exist no Linux software implementation that can handle large MLC NAND flashes properly.

From available solutions only UBI/UBIFS or YAFFS2 can support large NAND flashes but none of them currently address MLC issues, such as read and program disturbances. See Yaffs NAND flash failure mitigation | Yaffs and Memory Technology Device (MTD) Subsystem for Linux. for more details.

UBIFS moreover does not survive several mounts/umounts probably due to a software bug. YAFFS2 requires "inbound-tags" mount option probably due to small metadata size or OOB read/write problem.

Both read and program disturbances are a problem for long-term use (we actually tested this) so if anyone is designing a commercial product that should survive longer than a standard warranty period then eMMC or SD are definitely much better options.

[igorpadykov]

Hi Vladislav

as log states no, this flash can not be supported by the i.MX6 NAND/BCH controller.

It requires 44bit ecc for covering both data and metadata, example of such calculations

can be found in i.MX6DQ Reference Manual 17.2.3 Determining the ECC layout for a device.

Regarding lower ECC strength, seems this is not good since it can affect NAND reliability

and can not be guaranteed by datasheet.

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[vladislavkasik]

Hi Igor,

I dug a bit deeper and I think that the default calculation of ECC strength is not implemented correctly in gpmi-nand.c (in the attachment). According to the calculation in the datasheet, it should be 24 for 512 byte data blocks, however if the block is smaller than OOB then the driver increments the data block size to 1024 bytes and gf_len to 14 and there it is 44 - too much. Ideally the driver should revert the block size back (together with gf_len) when the calculated strength is beyond device capabilities. As far as I understood there is no technical limitation for the block size to be smaller than OOB and it is just for compatibility issues.

Anyway the specified NAND_ECC_INFO is ignored by default. There is a device tree option "fsl,use-minimum-ecc" for gpmi that makes it to use this configuration directly without trying to find the best value, in this case 40 bits / 1024 bytes.

So basically there are two options I have, to use minimum 40 / 1024, apparently specified by the flash manufacturer, or maximum possible by the BCH which is 24 / 512 and is better than the minimum but it means some tweaking of the driver. Is my assumption correct? How much difference in reliability would that make?

Best regards,

Vladislav

[igorpadykov]

Hi Vladislav

I think reliability with bigger ecc is better,

that is 40 / 1024. Regarding difference in reliability,

seems both options may work on fresh NAND.

However on high temperatures and big number of write

cycles there may be difference, for such details probably one

can contact vendor of that NAND part.

Best regards

igor

[vladislavkasik]

Hi Igor,

40bit / 1024k seems to work however when I try nandtest application on the device I get many ECC corrected bits for every block, such as:

a5200000: reading...
 870 bit(s) ECC corrected at a5200000
a5400000: reading...
 861 bit(s) ECC corrected at a5400000
a5600000: reading...
 896 bit(s) ECC corrected at a5600000
a5800000: reading...
 813 bit(s) ECC corrected at a5800000

Also if I try to write some data with nandwrite and then read them back several times with nanddump then the number of ECC corrected bits is slightly changing with every read.

Is this normal with this kind of type of MLC flash or something else may be wrong? I have tried to measure timing and signal levels with oscilloscope but all appears fine. We used MLC NAND flash before and it definitely did not exhibit such behavior, it was 1Gbit though.

Best regards,

Vladislav

[igorpadykov]

Hi Vladislav

if read back data is correct, then I think this is

normal.

Best regards

igor