RE: [EXT] Re: [PATCH v2 3/3] mtd: rawnand: Support for sequential cache reads

Bean Huo
2023-06-26T09:44:07Z

I saw the NAND related to the issue with the NAND ID reported by chengzhihao1@huawei.com

> ID="0xec,0xa1,0x00,0x15" # 128M 128KB 2KB

This's a Samsung NAND flash manufacturer ID.

Hi, Jiaimeliao
You said you tested this patch, would you share what NAND and what SOC are you using?

Kind regards,
Bean

> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@bootlin.com>
> Sent: Friday, June 23, 2023 4:08 PM
> To: Måns Rullgård <mans@mansr.com>
> Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra
> <vigneshr@ti.com>; Tudor Ambarus <Tudor.Ambarus@microchip.com>; Pratyush
> Yadav <pratyush@kernel.org>; Michael Walle <michael@walle.cc>; linux-
> mtd@lists.infradead.org; Julien Su <juliensu@mxic.com.tw>; Jaime Liao
> <jaimeliao@mxic.com.tw>; Alvin Zhou <alvinzhou@mxic.com.tw>; Thomas
> Petazzoni <thomas.petazzoni@bootlin.com>; JaimeLiao <jaimeliao.tw@gmail.com>;
> Bean Huo <beanhuo@micron.com>
> Subject: [EXT] Re: [PATCH v2 3/3] mtd: rawnand: Support for sequential cache reads
>
> CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you
> recognize the sender and were expecting this message.
>
>
> Hi Bean,
>
> mans@mansr.com wrote on Fri, 23 Jun 2023 12:27:54 +0100:
>
> > Miquel Raynal <miquel.raynal@bootlin.com> writes:
> >
> > > Hi Måns,
> > >
> > > mans@mansr.com wrote on Thu, 22 Jun 2023 15:59:25 +0100:
> > >
> > >> Miquel Raynal <miquel.raynal@bootlin.com> writes:
> > >>
> > >> > From: JaimeLiao <jaimeliao.tw@gmail.com>
> > >> >
> > >> > Add support for sequential cache reads for controllers using the
> > >> > generic core helpers for their fast read/write helpers.
> > >> >
> > >> > Sequential reads may reduce the overhead when accessing
> > >> > physically continuous data by loading in cache the next page
> > >> > while the previous page gets sent out on the NAND bus.
> > >> >
> > >> > The ONFI specification provides the following additional commands
> > >> > to handle sequential cached reads:
> > >> >
> > >> > * 0x31 - READ CACHE SEQUENTIAL:
> > >> > Requires the NAND chip to load the next page into cache while keeping
> > >> > the current cache available for host reads.
> > >> > * 0x3F - READ CACHE END:
> > >> > Tells the NAND chip this is the end of the sequential cache read, the
> > >> > current cache shall remain accessible for the host but no more
> > >> > internal cache loading operation is required.
> > >> >
> > >> > On the bus, a multi page read operation is currently handled like this:
> > >> >
> > >> > 00 -- ADDR1 -- 30 -- WAIT_RDY (tR+tRR) -- DATA1_IN
> > >> > 00 -- ADDR2 -- 30 -- WAIT_RDY (tR+tRR) -- DATA2_IN
> > >> > 00 -- ADDR3 -- 30 -- WAIT_RDY (tR+tRR) -- DATA3_IN
> > >> >
> > >> > Sequential cached reads may instead be achieved with:
> > >> >
> > >> > 00 -- ADDR1 -- 30 -- WAIT_RDY (tR) -- \
> > >> > 31 -- WAIT_RDY (tRCBSY+tRR) -- DATA1_IN \
> > >> > 31 -- WAIT_RDY (tRCBSY+tRR) -- DATA2_IN \
> > >> > 3F -- WAIT_RDY (tRCBSY+tRR) -- DATA3_IN
> > >> >
> > >> > Below are the read speed test results with regular reads and
> > >> > sequential cached reads, on NXP i.MX6 VAR-SOM-SOLO in mapping
> > >> > mode with a NAND chip characterized with the following timings:
> > >> > * tR: 20 µs
> > >> > * tRCBSY: 5 µs
> > >> > * tRR: 20 ns
> > >> > and the following geometry:
> > >> > * device size: 2 MiB
> > >> > * eraseblock size: 128 kiB
> > >> > * page size: 2 kiB
> > >> >
> > >> > ============= Normal read @ 33MHz =================
> > >> > mtd_speedtest: eraseblock read speed is 15633 KiB/s
> > >> > mtd_speedtest: page read speed is 15515 KiB/s
> > >> > mtd_speedtest: 2 page read speed is 15398 KiB/s
> > >> > ===================================================
> > >> >
> > >> > ========= Sequential cache read @ 33MHz ===========
> > >> > mtd_speedtest: eraseblock read speed is 18285 KiB/s
> > >> > mtd_speedtest: page read speed is 15875 KiB/s
> > >> > mtd_speedtest: 2 page read speed is 16253 KiB/s
> > >> > ===================================================
> > >> >
> > >> > We observe an overall speed improvement of about 5% when reading
> > >> > 2 pages, up to 15% when reading an entire block. This is due to
> > >> > the ~14us gain on each additional page read (tR - (tRCBSY + tRR)).
> > >> >
> > >> > Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > >> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > >> > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com>
> > >> > ---
> > >> > drivers/mtd/nand/raw/nand_base.c | 119
> +++++++++++++++++++++++++++++--
> > >> > include/linux/mtd/rawnand.h | 9 +++
> > >> > 2 files changed, 124 insertions(+), 4 deletions(-)
> > >>
> > >> This change broke something on a TI AM3517 based system. What I'm
> > >> noticing is that the u-boot fw_setenv tool is failing due to the
> > >> MEMGETBADBLOCK ioctl reporting some blocks as bad when they are not.
> > >> Everything else is, somehow, working fine. Reverting this commit
> > >> fixes it, though I don't know why. I'm seeing the same behaviour
> > >> on multiple devices, so I doubt there is a problem with the flash memory.
> > >>
> > >> Is there anything I can test to get more information?
> > >>
> > >
> > > May I know what NAND chip you are using?
> >
> > It's a Micron MT29F4G16ABBDAH4-IT:D. From the kernel logs:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > nand: Micron MT29F4G16ABBDAH4
> > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>
> There is definitely something wrong with Micron's handling of the sequential reads.
> Can you make a setup on your side with one of these chips and try to reproduce?
>
> I will have to discard Micron's chips if we don't find a solution very soon, too bad, it
> is a nice performance improvement -when it works-.
>
> Thanks,
> Miquèl