Possible bug in onenand_base ?

Fri Jul 16 08:04:08 EDT 2010

Hi Enric,

> -----Original Message-----
> From: Enric Balletbò i Serra [mailto:eballetbo at gmail.com]
> Sent: Thursday, July 15, 2010 4:49 PM
> To: Rohit Hassan Sathyanarayan
> Cc: linux-mtd at lists.infradead.org; dedekind1 at gmail.com; v.dalal at samsung.com
> Subject: Re: Possible bug in onenand_base ?
> 
> Hello Rohit,
> 
> 2010/7/15 Rohit Hassan Sathyanarayan <rohit.hs at samsung.com>:
> > Hi Eric,
> >
> >>
> >>-----Original Message-----
> >>From: Enric Balletbò i Serra [mailto:eballetbo at gmail.com]
> >>Sent: Wednesday, July 14, 2010 8:08 PM
> >>To: linux-mtd at lists.infradead.org
> >>Cc: dedekind1 at gmail.com; v.dalal at samsung.com; rohit.hs at samsung.com
> >>Subject: Re: Possible bug in onenand_base ?
> >>
> >>Hello,
> >>
> >>2010/7/14 ROHIT H.S <rohit.hs at samsung.com>
> >>>
> >>> Hi Artem,
> >>>
> >>> Rohit Hagargundgi , author of mtd: Flex-OneNAND support has left the organization.
> >>>
> >>> Any Flex OneNAND specific issues will be taken care by us from now onwards.
> >>>
> >>> >On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
> >>>
> >>> >> Hello,
> >>>
> >>> > >
> >>>
> >>> > >2010/7/8 Artem Bityutskiy <dedekind1 at gmail.com>:
> >>>
> >>> > >> On Thu, 2010-07-08 at 11:55 +0200, Enric Balletbò i Serra wrote:
> >>>
> >>> > >>> Hello,
> >>> > >>>
> >>>
> >>> > >> >I made new tests regarding this issue. Looks like the problem is > >> reading from the
> OneNAND device.
> >>> > >>
> >>>
> >>> > > >Did you try older kernel and then bisecting who is responsible for the
> >>> > > >breakage?
> >>>
> >>> > >
> >>>
> >>> > >Yes, before commit
> >>> > >5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
> >>> > >http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> 2.6.git;a=commit;h=5988af2319781bc8e0ce418affec4e09cfa77907
> >>> > >my OneNAND is working, after the commit, the OneNAND support is broken.
> >>>
> >>>
> >>> >Ok, we could revert it, but it is better to fix it. CCing the author of
> >>>
> >>> the commit.
> >>>
> >>> We tested Samsung Muxed OneNAND(DDP) on Apollon Board with
> >>>
> >>> kernel 2.6.35-rc4 and did not face any problems with DDP OneNand read/write.
> >>>
> >>> We didn't face any problem with the below code as pointed by Eric in
> >>>
> >>> file:: onenand_base.c
> >>> 378: default:
> >>> block = onenand_block(this, addr);
> >>> page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
> >>>
> >>>
> >>> We didn't changed anything in onenand_base.c and have runned nandtest utility. Below are the
> results.
> >>> mtd3 and mtd4 are our OneNAND paritions.
> >>>
> >>> ==================================================================
> >>> # nandtest /dev/mtd3
> >>> ECC corrections: 0
> >>> ECC failures : 0
> >>> Bad blocks : 1
> >>> BBT blocks : 0
> >>> Bad block at 0x00bc0000
> >>> 00fe0000: checking...
> >>> Finished pass 1 successfully
> >>> # nandtest /dev/mtd4
> >>> ECC corrections: 0
> >>> ECC failures : 0
> >>> Bad blocks : 0
> >>> BBT blocks : 0
> >>> 01fe0000: checking...
> >>> Finished pass 1 successfully
> >>>
> >>> ==================================================================
> >>>
> >>> We don't have Nymonix OneNAND DDP chip as used by Eric. So can't say why issue
> >>>
> >>> is coming up in that.
> >>>
> >>> Eric we need more details about the internal organization of Nymonix chips which you are using.
> >>>
> >>> Reciprocating the envirnoment is not possible but atleast we will try to
> >>>
> >>> figure out if there is any difference in internal organization.
> >>
> >>I have two different OneNAND from Numonyx and nandtest fails on all of them.
> >>
> >>The first one is a 2-Gbit OneNAND device from Numonyx composed of one
> >>dice with 2KB
> >>page, the device is equipped with two DataRAMs ( two planes)
> >>
> >>[   25.964904] OneNAND Manufacturer: Numonyx (0x20)
> >>[   25.964904] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
> >>[   25.969787] OneNAND version = 0x0031
> >>[   25.973388] Chip support all block unlock
> >>[   25.973388] Chip has 2 plane
> >>
> >>The second one is a 4-Gbit DDP OneNAND device from Numonyx composed of
> >>two 2-Gbit 2KB
> >>page dice stacked together, the device is equipped with two DataRAMs,
> >>
> >>[   29.368347] OneNAND Manufacturer: Numonyx (0x20)
> >>[   29.368347] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> >>[   29.373657] OneNAND version = 0x0031
> >>[   29.377258] Chip support all block unlock
> >>[   29.377258] Chip has 2 plane
> >>
> >>Note that these two devices have 2 planes, maybe this is difference.
> >>
> >>Have you tested with a OneNAND with 2 planes ?
> >
> >
> > Yes, we have tested 2 planes Muxed OneNAND DDP device from Samsung(KFN4G16Q2A) and
> > did not face any problem with read/write from latest linux kernel.
> >
> > Below is the device information captured from U-boot,
> > ==========================================================
> > U-Boot 2010.06 (Jul 15 2010 - 10:27:31)
> >
> > OMAP2420-GP revision 5
> > Samsung Apollon SDP Base Board + mDDR
> > DRAM:  64 MiB
> > Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> > OneNAND version = 0x0121
> > Chip support all block unlock
> > Chip has 2 plane
> > block = 2048, wp status = 0x2
> > Scanning device for bad blocks
> > onenand_bbt_wait: ecc error = 0x2222, controller = 0x2400
> > Bad eraseblock 2485 at 0x136a0000
> > OneNAND: 512 MiB
> > ==========================================================
> >
> > We haven't faced any issue with Samsung 2 plane DDP OneNAND device.
> > Can you please provide us the Numonyx 2 plane OneNAND Chip spec which you
> > are using.
> >
> 
> Unfortunately I can't send the Numonyx datasheet because is under NDA.
> Maybe someone from Numonyx can send us the datasheet. I think they
> should seriously consider provide this information to help all
> developers.
> 
> OTOH I investigated a little more, and I think I found something interesting.
> 
> Comparing the KFN4G16Q2A with the Numonyx device I see are very
> similar, so I compared the OneNAND configuration on Apollon board and
> the IGEP v2 board. I see a significant diference, the IGEP v2 board
> sets the CONFIG_MTD_ONENAND_2X_PROGRAM. Here are the results
> 
> # nandtest /dev/mtd4
> ECC corrections: 0
> ECC failures   : 0
> Bad blocks     : 2
> BBT blocks     : 0
> Bad block at 0x0a100000
> Bad block at 0x0a120000
> 0fa60000: checking...
> Finished pass 1 successfully
> 
> Surprise, works now !
> 
> Whitout CONFIG_MTD_ONENAND_2X_PROGRAM the mtd info shows
> # mtd_debug info /dev/mtd4
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 262668288 (250M)
> mtd.erasesize = 131072 (128K)
> mtd.writesize = 2048 (2K)
> mtd.oobsize = 64
> regions = 0
> 
> With CONFIG_MTD_ONENAND_2X_PROGRAM the mtd info shows
> # mtd_debug info /dev/mtd4
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 262668288 (250M)
> mtd.erasesize = 262144 (256K)
> mtd.writesize = 4096 (4K)
> mtd.oobsize = 64
> regions = 0
> 
> In conclusion, seems the problem is handling the 2X program feature
> and I suspect you can reproduce the issue enabling the
> CONFIG_MTD_ONENAND_2X_PROGRAM in the apollon defconfig. Please, can
> you test with your board ?

Your correct, problem is with properly handling 2X program feature.

We tested Samsung Muxed OneNAND(DDP) by enabling CONFIG_MTD_ONENAND_2X_PROGRAM 
in apollon defconfig and we faced the same issue pointed by you.

We are working on this issue.

Thanks for your pointers,

Regards,
Rohit Hassan & Vivek Dalal