How read_oob() should work for HW_SYNDROME NAND controller?
Masahiro Yamada
yamada.masahiro at socionext.com
Tue Nov 29 23:05:36 PST 2016
Hi.
(CCing Intel engineers because this is related to Denali driver
and comments from them are very appreciated.)
I am tacking on Denali NAND driver rework.
My question is:
Which data should chip->ecc.read_oob() get
in case of a controller with syndrome-like ECC engine.
For example, say we have a NAND chip
with 2048 byte page + 64 byte oob.
(the picture in the right side.)
And let's say the controller's ecc.size = 1024 and ecc.bytes == 14.
I am omitting BBM to make the situation simpler.
The Denali NAND controller interleaves
payload and ECC like the picture in the left side.
|-----------| |-----------|
| | | |
| Payload0 | | |
| | | |
| (ecc.size | | |
| 1024B) | | Main Page |
| | | area |
|-----------| | |
| ECC0 | | 2048B |
| (ecc.bytes| | |
| 14B) | | |
|-----------| | |
| | | |
| Payload1 | | |
| | | |
| (ecc.size | | |
| 1024B) | |-----------|
| | | |
|-----------| | |
| ECC1 | | OOB area |
| (ecc.bytes| | |
| 14B) | | 64B |
|-----------| | |
| OOB free | | |
| 36B | | |
|-----------| |-----------|
The controller can transfer
Main page area, OOB area, or both of them,
like the physical structure of the device
in the right-side picture.
This is different from how
Denali controller uses the page logically
(in the left-side picture).
The current read_oob() implementation in the Denali driver
simply get the data in the physical OOB area.
It corresponds the tail of Payload1 + ECC1 + OOB free.
I am afraid the behavior is different from
the reference implementation of
nand_read_page_raw_syndrome()
nand_read_oob_syndrome()
I think we should collect ECC sections
into oob_poi to get along with the ooblayout APIs.
The Denali IP also supports lowlevel
command-base interface to issue NAND_CMD_RNDOUT
and cherry-pick ECC sections.
But, more simply, I can transfer the whole page + oob
into a temporary buffer, then only copy
ECC sections into oob_poi.
Comments are very appreciated.
--
Best Regards
Masahiro Yamada
More information about the linux-mtd
mailing list