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 <su...@nxp.com> Sent: 2020年5月15日 18:02 To: Shivamurthy Shastri (sshivamurthy) <sshivamur...@micron.com>; Poonam Aggrwal <poonam.aggr...@nxp.com>; Naresh Kamboju <naresh.kamb...@linaro.org>; X.f. Ren <xiaofeng....@nxp.com> Cc: Miquel Raynal <miquel.ray...@bootlin.com>; shiva.linuxwo...@gmail.com; Ashish Kumar <ashish.ku...@nxp.com>; Richard Weinberger <rich...@nod.at>; Vignesh Raghavendra <vigne...@ti.com>; Boris Brezillon <boris.brezil...@collabora.com>; Chuanhong Guo <gch981...@gmail.com>; Frieder Schrempf <frieder.schre...@kontron.de>; linux-...@lists.infradead.org; open list <linux-kernel@vger.kernel.org>; lkft-tri...@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) <sshivamur...@micron.com> Sent: Friday, May 15, 2020 3:29 PM To: Poonam Aggrwal <poonam.aggr...@nxp.com>; Naresh Kamboju <naresh.kamb...@linaro.org> Cc: Miquel Raynal <miquel.ray...@bootlin.com>; shiva.linuxwo...@gmail.com; Ashish Kumar <ashish.ku...@nxp.com>; Richard Weinberger <rich...@nod.at>; Vignesh Raghavendra <vigne...@ti.com>; Boris Brezillon <boris.brezil...@collabora.com>; Chuanhong Guo <gch981...@gmail.com>; Frieder Schrempf <frieder.schre...@kontron.de>; linux-...@lists.infradead.org; open list <linux-kernel@vger.kernel.org>; Suram Suram <su...@nxp.com>; lkft-tri...@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.aggr...@nxp.com> wrote on Fri, 15 May 2020 > 05:29:07 +0000: > > > Adding Ashish. > > > > Regards > > Poonam > > > > > -----Original Message----- > > > From: Naresh Kamboju <naresh.kamb...@linaro.org> > > > Sent: Friday, May 15, 2020 10:57 AM > > > To: shiva.linuxwo...@gmail.com; Miquel Raynal > <miquel.ray...@bootlin.com>; > > > Shivamurthy Shastri <sshivamur...@micron.com> > > > Cc: Richard Weinberger <rich...@nod.at>; Vignesh Raghavendra > > > <vigne...@ti.com>; Boris Brezillon > > > <boris.brezil...@collabora.com>; Chuanhong Guo > > > <gch981...@gmail.com>; Frieder Schrempf > > > <frieder.schre...@kontron.de>; linux-...@lists.infradead.org; open > list <linux- > > > ker...@vger.kernel.org>; Poonam Aggrwal > <poonam.aggr...@nxp.com>; > > > Suram Suram <su...@nxp.com>; lkft-tri...@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.linuxwo...@gmail.com> wrote: > > > > > > > > From: Shivamurthy Shastri <sshivamur...@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&data=02%7C01%7Csuram%40nxp.com%7Cf699d2102f954d4d3bd208d7f8b69d35%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637251335518803010&sdata=1HP9Nx2mpttYGyURYB8t1hRsLOX6cBi05wnq8tiok64%3D&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&data=02%7C01%7Cpoona > m. > > > > aggrwal%40nxp.com%7C146f634c869f4c70baa108d7f8909ffb%7C686ea1d3bc > 2 > > > > b4c6fa92cd99c5c301635%7C0%7C0%7C637251172354638298&sdata=%2B > > > > Jhs%2Fb92%2BA56WzYdHe%2BBhXWfjk8feCGAFv%2BRzFKC9PM%3D&r > ese > > > rved=0 > > > > > > - Naresh > > Thanks, > Miquèl Thanks, Shiva
