LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "X.f. Ren" <xiaofeng.ren@nxp.com>
To: Suram Suram <suram@nxp.com>,
	"Shivamurthy Shastri (sshivamurthy)" <sshivamurthy@micron.com>,
	Poonam Aggrwal <poonam.aggrwal@nxp.com>,
	Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	"shiva.linuxworks@gmail.com" <shiva.linuxworks@gmail.com>,
	Ashish Kumar <ashish.kumar@nxp.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Chuanhong Guo <gch981213@gmail.com>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>,
	"lkft-triage@lists.linaro.org" <lkft-triage@lists.linaro.org>
Subject: RE: [EXT] Re: [PATCH v7 0/6] Add new series Micron SPI NAND devices
Date: Fri, 15 May 2020 10:13:33 +0000	[thread overview]
Message-ID: <VI1PR0402MB36149C787150035402E1487D91BD0@VI1PR0402MB3614.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <AM6PR04MB6742280CFEC7C560FB16F093ABBD0@AM6PR04MB6742.eurprd04.prod.outlook.com>

Hello Suram, et al
Here are some information about those warming. Those warning should not impact testing.  
"
It is in the nature of NAND Flash that a small proportion of the blocks in the device are defective and therefore unusable from the day of manufacture (typically up to 1% is deemed acceptable by the manufacturer). Manufacturers perform thorough testing to identify any potentially bad blocks. When they have been identified, bad blocks are marked with a special marker in the OOB area of the block. This is the Manufacturer's Bad Block Marker (MBBM).

RAM resident BBT
RAM-resident BBTs are volatile and must be recreated every time the system is booted. The process involves scanning each block in the NAND device to check for bad block markers.

The main advantage of this approach is simplicity. This is particularly true for manufacturability, where is is possible for a generic NAND programmer to program pre-prepared images without the need to understand the underlying ECC scheme or any BBT formats.

There are, however, a number of disadvantages. In some cases these disadvantages preclude the use of RAM-resident BBTs.
NAND resident BBT
The use of NAND-Resident BBTs overcomes many of the issues associated with RAM-resident BBTs. For most cases this is the recommended method for recording and tracking bad blocks.

As a NAND-resident BBT is non-volatile, it is preserved across system boots. There should never be any reason to recreate the BBT by scanning the NAND device for bad block markers.

Typically, the BBT requires two bits of storage for each block. The table is stored in the last good block with a backup in the penultimate good block. By default, the last four physical blocks are reserved for BBTs. If there are fewer than two good blocks available in the last four, then the NAND device should be discarded.

In a ideal situation, the BBT should be built and written to Flash before any other data. This is mandatory in cases where it is not possible to use the ECC tags to distinguish between valid programmed ECC data and an MBBM. However, this has implications for manufacturability, as the NAND programmer needs to be taught how to write the BBT, including the relevant ECC scheme.

In some cases, it may be appropriate for the NAND Programmer to skip writing BBTs, and to defer BBT creation to the software drivers when the system is first booted. This avoids the complexities of customising the NAND Programmer, whilst retaining the benefits of using NAND-resident BBTs. This approach is only viable if there is no clash between the ECC layout and the MBBM location, or where ECC tags can be used to avoid ECC data being misinterpreted as a MBBM.
"


Best Regards
Ron

-----Original Message-----
From: Suram Suram <suram@nxp.com> 
Sent: 2020年5月15日 18:02
To: Shivamurthy Shastri (sshivamurthy) <sshivamurthy@micron.com>; Poonam Aggrwal <poonam.aggrwal@nxp.com>; Naresh Kamboju <naresh.kamboju@linaro.org>; X.f. Ren <xiaofeng.ren@nxp.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>; shiva.linuxworks@gmail.com; Ashish Kumar <ashish.kumar@nxp.com>; Richard Weinberger <richard@nod.at>; Vignesh Raghavendra <vigneshr@ti.com>; Boris Brezillon <boris.brezillon@collabora.com>; Chuanhong Guo <gch981213@gmail.com>; Frieder Schrempf <frieder.schrempf@kontron.de>; linux-mtd@lists.infradead.org; open list <linux-kernel@vger.kernel.org>; lkft-triage@lists.linaro.org
Subject: RE: [EXT] Re: [PATCH v7 0/6] Add new series Micron SPI NAND devices

+Ron who owns the test on this platform in NXP.

-----Original Message-----
From: Shivamurthy Shastri (sshivamurthy) <sshivamurthy@micron.com>
Sent: Friday, May 15, 2020 3:29 PM
To: Poonam Aggrwal <poonam.aggrwal@nxp.com>; Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>; shiva.linuxworks@gmail.com; Ashish Kumar <ashish.kumar@nxp.com>; Richard Weinberger <richard@nod.at>; Vignesh Raghavendra <vigneshr@ti.com>; Boris Brezillon <boris.brezillon@collabora.com>; Chuanhong Guo <gch981213@gmail.com>; Frieder Schrempf <frieder.schrempf@kontron.de>; linux-mtd@lists.infradead.org; open list <linux-kernel@vger.kernel.org>; Suram Suram <suram@nxp.com>; lkft-triage@lists.linaro.org
Subject: RE: [EXT] Re: [PATCH v7 0/6] Add new series Micron SPI NAND devices

Caution: EXT Email

Hi Naresh and Poonam,

> Subject: [EXT] Re: [PATCH v7 0/6] Add new series Micron SPI NAND 
> devices
>
> Hi Poonam,
>
> Poonam Aggrwal <poonam.aggrwal@nxp.com> wrote on Fri, 15 May 2020
> 05:29:07 +0000:
>
> > Adding Ashish.
> >
> > Regards
> > Poonam
> >
> > > -----Original Message-----
> > > From: Naresh Kamboju <naresh.kamboju@linaro.org>
> > > Sent: Friday, May 15, 2020 10:57 AM
> > > To: shiva.linuxworks@gmail.com; Miquel Raynal
> <miquel.raynal@bootlin.com>;
> > > Shivamurthy Shastri <sshivamurthy@micron.com>
> > > Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra 
> > > <vigneshr@ti.com>; Boris Brezillon 
> > > <boris.brezillon@collabora.com>; Chuanhong Guo 
> > > <gch981213@gmail.com>; Frieder Schrempf 
> > > <frieder.schrempf@kontron.de>; linux-mtd@lists.infradead.org; open
> list <linux-
> > > kernel@vger.kernel.org>; Poonam Aggrwal
> <poonam.aggrwal@nxp.com>;
> > > Suram Suram <suram@nxp.com>; lkft-triage@lists.linaro.org
> > > Subject: Re: [PATCH v7 0/6] Add new series Micron SPI NAND devices
> > >
> > > On Wed, 11 Mar 2020 at 23:28, <shiva.linuxworks@gmail.com> wrote:
> > > >
> > > > From: Shivamurthy Shastri <sshivamurthy@micron.com>
> > > >
> > > > This patchset is for the new series of Micron SPI NAND devices, 
> > > > and the following links are their datasheets.
> > >
> > > While boot NXP ls2088 device with mainline kernel the following 
> > > nand
> warning
> > > noticed. How critical this warning ?
>
> Are you sure this is the right thread? Shivamurthy added SPI-NAND 
> support, you are talking about a raw NAND device.
> > >
> > > [    1.357722] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x48
> > > [    1.364085] nand: Micron MT29F16G08ABACAWP
> > > [    1.368181] nand: 2048 MiB, SLC, erase size: 512 KiB, page size:
> > > 4096, OOB size: 224
> > > [    1.375932] nand: WARNING: 530000000.flash: the ECC used on your
> > > system is too weak compared to the one required by the NAND chip
>
> If you are talking about this one, it is pretty self explanatory: the 
> NAND chip requires a minimum correction which is not achieved here.
> Either because the ECC engine cannot reach the requested amount (you 
> cannot do anything) or because you requested a too low correction with 
> DT properties.
>

Minimum required ECC for this device is 8-bit. Below is the datasheet for your reference.

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.micron.com%2F-%2Fmedia%2Fclient%2Fglobal%2Fdocuments%2Fproducts%2Fdata-sheet%2Fnand-flash%2F70-series%2Fm72a_production_datasheet_revg.pdf%3Frev%3Dbb0a4ba04a1f40f98e29dc624d178dd8&amp;data=02%7C01%7Csuram%40nxp.com%7Cf699d2102f954d4d3bd208d7f8b69d35%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637251335518803010&amp;sdata=1HP9Nx2mpttYGyURYB8t1hRsLOX6cBi05wnq8tiok64%3D&amp;reserved=0


> > >
> > > [    1.388767] Bad block table found at page 524160, version 0x01
> > > [    1.396833] Bad block table found at page 524032, version 0x01
> > > [    1.403781] nand_read_bbt: bad block at 0x000002d00000
> > > [    1.408921] nand_read_bbt: bad block at 0x000002d80000
> > > [    1.414750] fsl,ifc-nand 530000000.nand: IFC NAND device at
> > > 0x530000000, bank 2
> > >
> > >
> > > Full test log,
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fqa-
> > > reports.linaro.org%2Flkft%2Flinux-mainline-oe%2Fbuild%2Fv5.7-rc5-5
> > > 5-
> > >
> g1ae7efb38854%2Ftestrun%2F18254%2Flog&amp;data=02%7C01%7Cpoona
> m.
> > >
> aggrwal%40nxp.com%7C146f634c869f4c70baa108d7f8909ffb%7C686ea1d3bc
> 2
> > >
> b4c6fa92cd99c5c301635%7C0%7C0%7C637251172354638298&amp;sdata=%2B
> > >
> Jhs%2Fb92%2BA56WzYdHe%2BBhXWfjk8feCGAFv%2BRzFKC9PM%3D&amp;r
> ese
> > > rved=0
> > >
> > > - Naresh
>
> Thanks,
> Miquèl

Thanks,
Shiva

      reply	other threads:[~2020-05-15 10:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 17:57 shiva.linuxworks
2020-03-11 17:57 ` [PATCH v7 1/6] mtd: spinand: micron: Generalize the OOB layout structure and function names shiva.linuxworks
2020-03-12 21:33   ` Miquel Raynal
2020-03-11 17:57 ` [PATCH v7 2/6] mtd: spinand: micron: Describe the SPI NAND device MT29F2G01ABAGD shiva.linuxworks
2020-03-12 21:33   ` Miquel Raynal
2020-03-11 17:57 ` [PATCH v7 3/6] mtd: spinand: micron: Add new Micron SPI NAND devices shiva.linuxworks
2020-03-12 21:33   ` Miquel Raynal
2020-03-11 17:57 ` [PATCH v7 4/6] mtd: spinand: micron: identify SPI NAND device with Continuous Read mode shiva.linuxworks
2020-03-12 21:33   ` Miquel Raynal
2020-03-11 17:57 ` [PATCH v7 5/6] mtd: spinand: micron: Add M70A series Micron SPI NAND devices shiva.linuxworks
2020-03-12 21:33   ` Miquel Raynal
2020-03-11 17:57 ` [PATCH v7 6/6] mtd: spinand: micron: Add new Micron SPI NAND devices with multiple dies shiva.linuxworks
2020-03-12 21:33   ` Miquel Raynal
2020-03-12 19:16 ` [EXT] [PATCH v7 0/6] Add new series Micron SPI NAND devices Shivamurthy Shastri (sshivamurthy)
2020-03-12 19:39   ` Miquel Raynal
2020-05-15  5:27 ` Naresh Kamboju
2020-05-15  5:29   ` Poonam Aggrwal
2020-05-15  7:33     ` Miquel Raynal
2020-05-15  9:59       ` [EXT] " Shivamurthy Shastri (sshivamurthy)
2020-05-15 10:02         ` Suram Suram
2020-05-15 10:13           ` X.f. Ren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR0402MB36149C787150035402E1487D91BD0@VI1PR0402MB3614.eurprd04.prod.outlook.com \
    --to=xiaofeng.ren@nxp.com \
    --cc=ashish.kumar@nxp.com \
    --cc=boris.brezillon@collabora.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=gch981213@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=naresh.kamboju@linaro.org \
    --cc=poonam.aggrwal@nxp.com \
    --cc=richard@nod.at \
    --cc=shiva.linuxworks@gmail.com \
    --cc=sshivamurthy@micron.com \
    --cc=suram@nxp.com \
    --cc=vigneshr@ti.com \
    --subject='RE: [EXT] Re: [PATCH v7 0/6] Add new series Micron SPI NAND devices' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).