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 <[email protected]> 
Sent: 2020年5月15日 18:02
To: Shivamurthy Shastri (sshivamurthy) <[email protected]>; Poonam 
Aggrwal <[email protected]>; Naresh Kamboju <[email protected]>; 
X.f. Ren <[email protected]>
Cc: Miquel Raynal <[email protected]>; [email protected]; 
Ashish Kumar <[email protected]>; Richard Weinberger <[email protected]>; 
Vignesh Raghavendra <[email protected]>; Boris Brezillon 
<[email protected]>; Chuanhong Guo <[email protected]>; Frieder 
Schrempf <[email protected]>; [email protected]; open 
list <[email protected]>; [email protected]
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) <[email protected]>
Sent: Friday, May 15, 2020 3:29 PM
To: Poonam Aggrwal <[email protected]>; Naresh Kamboju 
<[email protected]>
Cc: Miquel Raynal <[email protected]>; [email protected]; 
Ashish Kumar <[email protected]>; Richard Weinberger <[email protected]>; 
Vignesh Raghavendra <[email protected]>; Boris Brezillon 
<[email protected]>; Chuanhong Guo <[email protected]>; Frieder 
Schrempf <[email protected]>; [email protected]; open 
list <[email protected]>; Suram Suram <[email protected]>; 
[email protected]
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 <[email protected]> wrote on Fri, 15 May 2020
> 05:29:07 +0000:
>
> > Adding Ashish.
> >
> > Regards
> > Poonam
> >
> > > -----Original Message-----
> > > From: Naresh Kamboju <[email protected]>
> > > Sent: Friday, May 15, 2020 10:57 AM
> > > To: [email protected]; Miquel Raynal
> <[email protected]>;
> > > Shivamurthy Shastri <[email protected]>
> > > Cc: Richard Weinberger <[email protected]>; Vignesh Raghavendra 
> > > <[email protected]>; Boris Brezillon 
> > > <[email protected]>; Chuanhong Guo 
> > > <[email protected]>; Frieder Schrempf 
> > > <[email protected]>; [email protected]; open
> list <linux-
> > > [email protected]>; Poonam Aggrwal
> <[email protected]>;
> > > Suram Suram <[email protected]>; [email protected]
> > > Subject: Re: [PATCH v7 0/6] Add new series Micron SPI NAND devices
> > >
> > > On Wed, 11 Mar 2020 at 23:28, <[email protected]> wrote:
> > > >
> > > > From: Shivamurthy Shastri <[email protected]>
> > > >
> > > > 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 via email to