* GPMI driver ecc_write_page with oob data problem @ 2015-04-01 23:03 Youxin Su 2015-04-02 4:38 ` Iwo Mergler 0 siblings, 1 reply; 4+ messages in thread From: Youxin Su @ 2015-04-01 23:03 UTC (permalink / raw) To: linux-mtd 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: GPMI driver ecc_write_page with oob data problem 2015-04-01 23:03 GPMI driver ecc_write_page with oob data problem Youxin Su @ 2015-04-02 4:38 ` Iwo Mergler 2015-04-02 9:40 ` Youxin Su 0 siblings, 1 reply; 4+ messages in thread From: Iwo Mergler @ 2015-04-02 4:38 UTC (permalink / raw) To: Youxin Su, linux-mtd 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@lists.infradead.org] On Behalf Of Youxin Su [suyouxin@gmail.com] Sent: Thursday, 2 April 2015 10:03 AM To: linux-mtd@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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GPMI driver ecc_write_page with oob data problem 2015-04-02 4:38 ` Iwo Mergler @ 2015-04-02 9:40 ` Youxin Su 2015-04-07 0:42 ` Iwo Mergler 0 siblings, 1 reply; 4+ messages in thread From: Youxin Su @ 2015-04-02 9:40 UTC (permalink / raw) To: Iwo Mergler; +Cc: linux-mtd Hi Iwo, Thank you for your explanation. On 2 April 2015 at 17:38, Iwo Mergler <Iwo.Mergler@netcommwireless.com> wrote: > 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. I've read the data sheet and have a brief idea of this BCH layout stuff. My question is why don't use SPARE area above as OOB area since in IMX6 BCH controller can support SPARE size up to 255 bytes. DMA can transfer this area if you make it bigger? What we need to do is just prepare OOB data to this SPARE area. > > 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. I am not really understand why pretends the OOB is read-only. In my mind it's not read-only. The GPMI driver provided a gpmi_ecc_write_oob method which MTD driver can use it to write OOB area separately. It may use by file system when it only needs to read/write only OOB data I believe. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/nand/gpmi-nand/gpmi-nand.c?id=refs/tags/v4.0-rc6#n1326 Regards, Youxin > Sent: Thursday, 2 April 2015 10:03 AM > To: linux-mtd@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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: GPMI driver ecc_write_page with oob data problem 2015-04-02 9:40 ` Youxin Su @ 2015-04-07 0:42 ` Iwo Mergler 0 siblings, 0 replies; 4+ messages in thread From: Iwo Mergler @ 2015-04-07 0:42 UTC (permalink / raw) To: Youxin Su; +Cc: linux-mtd On Thu, 2 Apr 2015 20:40:32 +1100 Youxin Su <suyouxin@gmail.com> wrote: > Hi Iwo, > > Thank you for your explanation. > > On 2 April 2015 at 17:38, Iwo Mergler > <Iwo.Mergler@netcommwireless.com> wrote: > > 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. > > I've read the data sheet and have a brief idea of this BCH layout > stuff. My question is why don't use SPARE area above as OOB area since > in IMX6 BCH controller can support SPARE size up to 255 bytes. DMA can > transfer this area if you make it bigger? What we need to do is just > prepare OOB data to this SPARE area. > I am not really understand why pretends the OOB is read-only. In my > mind it's not read-only. The GPMI driver provided a gpmi_ecc_write_oob > method which MTD driver can use it to write OOB area separately. It > may use by file system when it only needs to read/write only OOB data > I believe. That layout requires that you're writing page data and OOB simultaneously, since the XX contains the two data bytes which would otherwise fall into the bad block marker region. Filesystems like YAFFS and JFFS2 not only require OOB space, but also need to write this OOB space independently of the page data area. There is a way, but it's probably not worth the hassle. You'll have to rewrite MTD drivers for everything. It will allow to write OOB data first, before page data, but not the other way 'round. Bear in mind that I have only thought about this, but decided not to implement it in the end. I might have missed something and I'm a little unclear about some details. First, you need a NAND that allows sub-page writes, but you'll sacrifice sub-page write support for MTD. Next, you drop the bad block marker scheme on anything but the FCB structures and use a bad block table for the rest of the NAND. The FCBs can be marked bad anyway, so it's not a problem. All bootloaders and kernels will require BBT support implemented/enabled. Your factory procedure needs to scan the NAND for bad block markers and build the BBT before the first boot. Your new page structure is this: SPARE ECC D512 ECC D512 ECC, etc. The ECC over the spare area can be ECC0, if you don't want ECC protection for that. At this point, you can implement the OOB write as a subpage write, covering SPARE+ECC. For this, you need to arrange for a short DMA transfer of SPARE bytes, and ensure that the NAND page buffer is otherwise filled with 0xFF bytes. To write the page data, you do the opposite of the OOB operation above. Write the SPARE+ECC region as 0xFF and the page data and ECC to the rest of the page and (real) OOB. One or both of these may require byte-bashing via GPIO or creative on-the-fly reprogramming of the ECC controller. Bear in mind that the BCH ECC bytes of a 0xFF data block are *not* 0xFF. The BCH controller allows a memory-to-memory operation which could potentially help working around the limitations. Performance won't be impressive though. Due to the in-order write requirement, you must not write data before OOB in this scenario. I know that this is the way JFFS2 uses it - don't know about YAFFS. There are probably other ways to achieve OOB access, at various levels of performance and NAND endurance trade-offs. Almost always it will be specific for a file system and/or use case. Best regards, Iwo ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-07 0:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-01 23:03 GPMI driver ecc_write_page with oob data problem Youxin Su 2015-04-02 4:38 ` Iwo Mergler 2015-04-02 9:40 ` Youxin Su 2015-04-07 0:42 ` Iwo Mergler
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.