GPMI driver ecc_write_page with oob data problem

[Iwo Mergler]

Hi Youxin,


I have only encountered the GPMI controller on the IMX28
processor, but I assume that it hasn't changed.

The GPMI controller is weird - it calculates ECC on small
subpages (512byte) at a time and *must* store / read
the ECC bytes immediately after the respective data block.

Since the controller does this on the fly, during DMA, you
can't influence the layout - all you transfer is the page
payload. The result is a strange physical layout in the NAND:

XX SPARE D512 ECC D512 ECC D512 ECC, etc.

In other words, ECC is interleaved with the data and
the whole thing spills over into the OOB. This interferes
with the bad block marker (first 2 bytes in OOB), so
the corresponding data bytes are set to 0 and relocated
into the 'XX' area above.

There is a little spare space at the beginning of the page
and maybe at the end of the OOB, but because everything
must be written in a single operation, you don't get to
write the OOB separately. So the MTD driver pretends
the OOB is read-only.

So, in summary, on the GPMI hardware, you can't have
OOB access independent of the data area. The driver
'solves' that by not giving you OOB access.

YAFFS2 inband tags are required.


Best regards,

Iwo


________________________________________
From: linux-mtd [linux-mtd-bounces at lists.infradead.org] On Behalf Of Youxin Su [suyouxin at gmail.com]
Sent: Thursday, 2 April 2015 10:03 AM
To: linux-mtd at lists.infradead.org
Subject: GPMI driver ecc_write_page with oob data problem

Hello all,

I am attempting to mount Yaffs2 on a GPMI controlled NAND flash on
IMX6. Unfortunately, I'm not able to mount it with default settings,
instead I have to mount it with "inband-tags" which means don't use
OOB area on NAND page to store data.

Then I am running into check why yaffs2 can't use OOB area.

We use MICRON MT29F32G08CBADAWP it has 8192 bytes payload and 744
bytes OOB as log show below:

[    0.982938] nand: Micron MT29F32G08CBADAWP
[    0.987056] nand: 4096MiB, MLC, page size: 8192, OOB size: 744
[    0.993508] gpmi-nand 112000.gpmi-nand: enable the asynchronous EDO mode 5

Since the IMX6 only support up to 40bits ECC corrections, we don't
want all the OOB used by BCH for ECC correction data. So we enabled
"fsl,use-minimum-ecc" which is still use the max 40 bits corrections
in BCH, after set_geometry_by_ecc_info does the calculation, its end
up following geometry:

page_size = 8762
write_size = 8129
metadat_size = 10
auxiliary_size = 24
oob_free->offset = 570
oob_free->length = 174

Which means we do have 174 bytes free OOB area can be used by file
system. After a few days tracing and debugging I've found out the GPMI
driver method gpmi_ecc_write_page actually does not write oob data(the
174 bytes area) to NAND flash at all? The flags "oob_required" never
been used in the method.

Does anybody else used GPMI with OOB data read/write before? Does it
work fine or Am I missing something?

Best regards,
Youxin

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/