[PATCH v4 0/5] refactoring and fix for Meson NAND
Arseniy Krasnov
AVKrasnov at sberdevices.ru
Mon May 15 02:44:34 PDT 2023
Hello,
this patchset does several things:
1) It fixes unstable behaviour of Meson driver, for example random ECC
errors during reads. It is done by changing 'meson_nfc_queue_rb()'
implementation. Sequence of commands inside this function is updated.
This patch is suggested by Liang Yang <liang.yang at amlogic.com>.
Here is link to discussion:
https://lore.kernel.org/linux-mtd/a9f8307a-77d7-a69f-ce11-2629909172d2@sberdevices.ru/T/#ma8097bad0228f81a3d11a14389cdec44f45b86c8
2) It moves OOB free bytes to non-protected by ECC area. Here are some
details:
Current OOB free bytes are 4 bytes (2 x 2 user bytes) under ECC engine.
Here is how it looks like in the current implementation:
[ 2B user bytes ][ 14B ECC codes ]
[ 2B user bytes ][ 14B ECC codes ]
[ 16B unused area, not protected by ECC ]
[ 16B unused area, not protected by ECC ]
All 4 user bytes are protected by ECC. This patch changes OOB free
bytes in this way:
[ 2B unused area ][ 14B ECC codes ]
[ 2B unused area ][ 14B ECC codes ]
[ 16B user bytes, not protected by ECC ]
[ 16B user bytes, not protected by ECC ]
Now OOB user bytes are 32 bytes instead of 4 bytes and not protected
by ECC.
Motivation of this layout comes from problem with JFFS2. It uses OOB
free bytes for cleanmarkers. Each cleanmarker is 4 bytes and written
by JFFS2 driver (small remark - cleanmarkers are always written in
case of NAND storage for JFFS2).
We have two ways to write this data to OOB (e.g. user bytes):
1) ECC mode. In this case it will be ECC covered user bytes, e.g.
writing this bytes will update ECC codes. Problem fires, when
JFFS2 tries to write this page later - this write makes controller
to update ECC codes again, but it is impossible to do it correctly,
because we can't update bits from 0 to 1 (only from 1 to 0).
2) Raw mode. In this case ECC codes won't be updated. But later, it
will be impossible to read this page in ECC mode, because we have
some user bytes, but ECC codes are missed.
So let's move OOB free bytes out of ECC area. In this case we can
read/write OOB separately in raw mode and at the same time work with
data in ECC mode. JFFS2 is happy now. User bytes are untouched - all
of them are ignored during non-OOB access.
I've tested this with mount/unmount/read/write cases for JFFS2 and
nanddump/nandwrite utlities on AXG family (A113X SoC).
Here is link to discussion:
https://lore.kernel.org/linux-mtd/a9f8307a-77d7-a69f-ce11-2629909172d2@sberdevices.ru/T/#m3087bd06386a7f430cd5e343e22b25d724d3e2d7
3) Changes size of OOB read access - now, in both ECC and raw modes whole
OOB (e.g. 64 bytes) is returned to the caller.
4) Checks buffer length on accesses to NAND controller.
5) Removes useless bitwise OR with zeroes.
Link to v1:
https://lore.kernel.org/linux-mtd/20230412061700.1492474-1-AVKrasnov@sberdevices.ru/
Link to v2:
https://lore.kernel.org/linux-mtd/20230426073632.3905682-1-AVKrasnov@sberdevices.ru/
Link to v3:
https://lore.kernel.org/linux-mtd/20230510110835.26115-1-AVKrasnov@sberdevices.ru/
Changelog:
v1 -> v2:
* Add patch which renames dts value for chip select.
* Add patch which moves OOB to non-protected ECC area.
v2 -> v3:
* Change patch which fixes read/write access according discussion link
in 1) above.
v3 -> v4:
* Remove patch which renames dts value for chip select.
Here is link to discussion:
https://lore.kernel.org/linux-mtd/20230510110835.26115-7-AVKrasnov@sberdevices.ru/
* Pass 1 to 'meson_nfc_queue_rb()' in case of NAND_OP_WAITRDY_INSTR.
This fixes ONFI page processing during NAND driver initialization.
Arseniy Krasnov (5):
mtd: rawnand: meson: fix command sequence for read/write
mtd: rawnand: meson: move OOB to non-protected ECC area
mtd: rawnand: meson: always read whole OOB bytes
mtd: rawnand: meson: check buffer length
mtd: rawnand: meson: remove unneeded bitwise OR with zeroes
drivers/mtd/nand/raw/meson_nand.c | 270 ++++++++++++++++++++++++------
1 file changed, 220 insertions(+), 50 deletions(-)
--
2.35.0
More information about the linux-arm-kernel
mailing list