Possible bug in onenand_base ?

Thu Jul 15 07:19:29 EDT 2010

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 ?

Thanks and best regards,
-- Enric