* Possible bug in onenand_base ?
@ 2010-07-14 8:52 ROHIT H.S
2010-07-14 14:37 ` Enric Balletbò i Serra
2010-07-18 16:47 ` Artem Bityutskiy
0 siblings, 2 replies; 32+ messages in thread
From: ROHIT H.S @ 2010-07-14 8:52 UTC (permalink / raw)
To: dedekind1, v.dalal, linux-mtd, rohit.hs
[-- Attachment #1: Type: text/html, Size: 3933 bytes --]
[-- Attachment #2: 201007141422012_BEI0XT4N.jpg --]
[-- Type: image/jpeg, Size: 72722 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-14 8:52 Possible bug in onenand_base ? ROHIT H.S
@ 2010-07-14 14:37 ` Enric Balletbò i Serra
2010-07-15 9:25 ` Rohit Hassan Sathyanarayan
2010-07-18 16:47 ` Artem Bityutskiy
1 sibling, 1 reply; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-14 14:37 UTC (permalink / raw)
To: linux-mtd; +Cc: rohit.hs, v.dalal, dedekind1
Hello,
2010/7/14 ROHIT H.S <rohit.hs@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 ?
Best regards,
-- Enric
^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: Possible bug in onenand_base ?
2010-07-14 14:37 ` Enric Balletbò i Serra
@ 2010-07-15 9:25 ` Rohit Hassan Sathyanarayan
2010-07-15 11:19 ` Enric Balletbò i Serra
0 siblings, 1 reply; 32+ messages in thread
From: Rohit Hassan Sathyanarayan @ 2010-07-15 9:25 UTC (permalink / raw)
To: 'Enric Balletbò i Serra', linux-mtd; +Cc: v.dalal, dedekind1
Hi Eric,
>
>-----Original Message-----
>From: Enric Balletbò i Serra [mailto:eballetbo@gmail.com]
>Sent: Wednesday, July 14, 2010 8:08 PM
>To: linux-mtd@lists.infradead.org
>Cc: dedekind1@gmail.com; v.dalal@samsung.com; rohit.hs@samsung.com
>Subject: Re: Possible bug in onenand_base ?
>
>Hello,
>
>2010/7/14 ROHIT H.S <rohit.hs@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.
Regards,
Rohit Hassan
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-15 9:25 ` Rohit Hassan Sathyanarayan
@ 2010-07-15 11:19 ` Enric Balletbò i Serra
2010-07-16 12:04 ` Rohit Hassan Sathyanarayan
0 siblings, 1 reply; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-15 11:19 UTC (permalink / raw)
To: Rohit Hassan Sathyanarayan; +Cc: v.dalal, linux-mtd, dedekind1
Hello Rohit,
2010/7/15 Rohit Hassan Sathyanarayan <rohit.hs@samsung.com>:
> Hi Eric,
>
>>
>>-----Original Message-----
>>From: Enric Balletbò i Serra [mailto:eballetbo@gmail.com]
>>Sent: Wednesday, July 14, 2010 8:08 PM
>>To: linux-mtd@lists.infradead.org
>>Cc: dedekind1@gmail.com; v.dalal@samsung.com; rohit.hs@samsung.com
>>Subject: Re: Possible bug in onenand_base ?
>>
>>Hello,
>>
>>2010/7/14 ROHIT H.S <rohit.hs@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
^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: Possible bug in onenand_base ?
2010-07-15 11:19 ` Enric Balletbò i Serra
@ 2010-07-16 12:04 ` Rohit Hassan Sathyanarayan
0 siblings, 0 replies; 32+ messages in thread
From: Rohit Hassan Sathyanarayan @ 2010-07-16 12:04 UTC (permalink / raw)
To: 'Enric Balletbò i Serra'; +Cc: v.dalal, linux-mtd, dedekind1
Hi Enric,
> -----Original Message-----
> From: Enric Balletbò i Serra [mailto:eballetbo@gmail.com]
> Sent: Thursday, July 15, 2010 4:49 PM
> To: Rohit Hassan Sathyanarayan
> Cc: linux-mtd@lists.infradead.org; dedekind1@gmail.com; v.dalal@samsung.com
> Subject: Re: Possible bug in onenand_base ?
>
> Hello Rohit,
>
> 2010/7/15 Rohit Hassan Sathyanarayan <rohit.hs@samsung.com>:
> > Hi Eric,
> >
> >>
> >>-----Original Message-----
> >>From: Enric Balletbò i Serra [mailto:eballetbo@gmail.com]
> >>Sent: Wednesday, July 14, 2010 8:08 PM
> >>To: linux-mtd@lists.infradead.org
> >>Cc: dedekind1@gmail.com; v.dalal@samsung.com; rohit.hs@samsung.com
> >>Subject: Re: Possible bug in onenand_base ?
> >>
> >>Hello,
> >>
> >>2010/7/14 ROHIT H.S <rohit.hs@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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-14 8:52 Possible bug in onenand_base ? ROHIT H.S
2010-07-14 14:37 ` Enric Balletbò i Serra
@ 2010-07-18 16:47 ` Artem Bityutskiy
1 sibling, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-07-18 16:47 UTC (permalink / raw)
To: rohit.hs; +Cc: v.dalal, linux-mtd
Hi,
On Wed, 2010-07-14 at 08:52 +0000, ROHIT H.S wrote:
> 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.
OK, thanks for replying.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-08 10:22 ` Artem Bityutskiy
@ 2010-07-12 14:59 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-12 14:59 UTC (permalink / raw)
To: dedekind1; +Cc: Kyungmin Park, linux-omap, linux-mtd, Rohit Hagargundgi
Hello,
2010/7/8 Artem Bityutskiy <dedekind1@gmail.com>:
> On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
>> Hello,
>>
>> 2010/7/8 Artem Bityutskiy <dedekind1@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.
Comparing the onenand_base.c file before commit
5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
and after the commit I made a little patch which seems solves the
issue. The patch has two parts.
The first part replaces line 380 with 'page = (int) (addr >>
this->page_shift);' like before apply the Flex-OneNAND support. I
suppose this is not the better solution, but with this the nandtest
tool works for me. Maybe the author of the commit can clarify this.
The second part (1964) adds two lines which I think are missed when
the Flex-OneNAND support was applied.
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 26caf25..a39d906 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -377,7 +377,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift;
+ page = (int) (addr >> this->page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
@@ -1961,6 +1961,9 @@ static int onenand_write_ops_nolock(struct
mtd_info *mtd, loff_t to,
/* In partial page write we don't update bufferram */
onenand_update_bufferram(mtd, to, !ret && !subpage);
+ ONENAND_SET_BUFFERRAM1(this);
+ onenand_update_bufferram(mtd, to +
this->writesize, !ret && !subpage);
+
if (ret) {
printk(KERN_ERR "%s: write failed %d\n",
__func__, ret);
Best regards,
Enric
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-07-12 14:59 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-12 14:59 UTC (permalink / raw)
To: dedekind1; +Cc: Rohit Hagargundgi, linux-mtd, linux-omap, Kyungmin Park
Hello,
2010/7/8 Artem Bityutskiy <dedekind1@gmail.com>:
> On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
>> Hello,
>>
>> 2010/7/8 Artem Bityutskiy <dedekind1@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.
Comparing the onenand_base.c file before commit
5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
and after the commit I made a little patch which seems solves the
issue. The patch has two parts.
The first part replaces line 380 with 'page = (int) (addr >>
this->page_shift);' like before apply the Flex-OneNAND support. I
suppose this is not the better solution, but with this the nandtest
tool works for me. Maybe the author of the commit can clarify this.
The second part (1964) adds two lines which I think are missed when
the Flex-OneNAND support was applied.
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 26caf25..a39d906 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -377,7 +377,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift;
+ page = (int) (addr >> this->page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
@@ -1961,6 +1961,9 @@ static int onenand_write_ops_nolock(struct
mtd_info *mtd, loff_t to,
/* In partial page write we don't update bufferram */
onenand_update_bufferram(mtd, to, !ret && !subpage);
+ ONENAND_SET_BUFFERRAM1(this);
+ onenand_update_bufferram(mtd, to +
this->writesize, !ret && !subpage);
+
if (ret) {
printk(KERN_ERR "%s: write failed %d\n",
__func__, ret);
Best regards,
Enric
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-08 10:11 ` Enric Balletbò i Serra
@ 2010-07-08 10:22 ` Artem Bityutskiy
-1 siblings, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-07-08 10:22 UTC (permalink / raw)
To: Enric Balletbò i Serra
Cc: Kyungmin Park, linux-omap, linux-mtd, Rohit Hagargundgi
On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
> Hello,
>
> 2010/7/8 Artem Bityutskiy <dedekind1@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.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-07-08 10:22 ` Artem Bityutskiy
0 siblings, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-07-08 10:22 UTC (permalink / raw)
To: Enric Balletbò i Serra
Cc: Rohit Hagargundgi, linux-mtd, linux-omap, Kyungmin Park
On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
> Hello,
>
> 2010/7/8 Artem Bityutskiy <dedekind1@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.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-08 9:58 ` Artem Bityutskiy
@ 2010-07-08 10:11 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-08 10:11 UTC (permalink / raw)
To: dedekind1; +Cc: Kyungmin Park, linux-omap, linux-mtd
Hello,
2010/7/8 Artem Bityutskiy <dedekind1@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.
Cheers,
Enric
>
> --
> Best Regards,
> Artem Bityutskiy (Артём Битюцкий)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-07-08 10:11 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-08 10:11 UTC (permalink / raw)
To: dedekind1; +Cc: linux-mtd, linux-omap, Kyungmin Park
Hello,
2010/7/8 Artem Bityutskiy <dedekind1@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.
Cheers,
Enric
>
> --
> Best Regards,
> Artem Bityutskiy (Артём Битюцкий)
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-07-08 9:55 ` Enric Balletbò i Serra
@ 2010-07-08 9:58 ` Artem Bityutskiy
-1 siblings, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-07-08 9:58 UTC (permalink / raw)
To: Enric Balletbò i Serra; +Cc: Kyungmin Park, linux-omap, linux-mtd
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?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-07-08 9:58 ` Artem Bityutskiy
0 siblings, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-07-08 9:58 UTC (permalink / raw)
To: Enric Balletbò i Serra; +Cc: linux-mtd, linux-omap, Kyungmin Park
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?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-05-12 13:16 ` Enric Balletbò i Serra
@ 2010-07-08 9:55 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-08 9:55 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hello,
I made new tests regarding this issue. Looks like the problem is
reading from the OneNAND device.
TEST 1
# modprobe mtd_pagetest dev=4
[ 126.505340]
[ 126.506866] =================================================
[ 126.512756] mtd_pagetest: MTD device: 4
[ 126.520477] mtd_pagetest: MTD device size 262668288, eraseblock
size 262144, page size 4096, count of eraseblocks 1002, pages per
eraseblock 64, OOB size 64
[ 126.535034] mtd_pagetest: scanning for bad eraseblocks
[ 126.540771] mtd_pagetest: scanned 1002 eraseblocks, 0 are bad
[ 126.546630] mtd_pagetest: erasing whole device
[ 128.406890] mtd_pagetest: erased 1002 eraseblocks
[ 128.411712] mtd_pagetest: writing whole device
[ 128.451721] mtd_pagetest: written up to eraseblock 0
[ 137.443817] mtd_pagetest: written up to eraseblock 256
[ 146.440216] mtd_pagetest: written up to eraseblock 512
[ 155.430755] mtd_pagetest: written up to eraseblock 768
[ 163.618225] mtd_pagetest: written 1002 eraseblocks
[ 163.623168] mtd_pagetest: verifying all eraseblocks
[ 163.632965] onenand_wait: ECC error = 0x4488
[ 163.638031] onenand_wait: ECC error = 0x4884
[ 163.642486] onenand_wait: ECC error = 0x8888
[ 163.647247] onenand_wait: ECC error = 0x8888
[ 163.651733] mtd_pagetest: error: read failed at 0x0
[ 163.656890] mtd_pagetest: error -74 occurred
[ 163.661224] =================================================
TEST 2
# nandtest -l 262144 /dev/mtd4
ECC corrections: 0
ECC failures : 260
Bad blocks : 0
BBT blocks : 0
00000000: reading...[ 837.103302] onenand_wait: ECC error = 0x8488
[ 837.109832] onenand_wait: ECC error = 0x8488
[ 837.114532] onenand_wait: ECC error = 0x8888
(...)
[ 837.683624] onenand_wait: ECC error = 0x8448
[ 837.688079] onenand_wait: ECC error = 0x8488
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
(...)
I suspect currently OneNAND with 2 planes is broken. Someone with this
type of device can try these tests ?
Thanks in advance,
Enric
2010/5/12 Enric Balletbò i Serra <eballetbo@gmail.com>:
> I answer to myself.
>
> DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
> a single die can also have '2 planes'. I'm right ?
>
> Sorry for these newbie questions, I'm just introducing to OneNAND devices.
>
> Cheers,
>
> Enric
>
> 2010/5/12 Enric Balletbò i Serra <eballetbo@gmail.com>:
>> Hello,
>>
>> I have a bit of time to investigate more.
>>
>> I have two boards with two different OneNAND chips populated.
>>
>> The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
>>
>> [ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
>> [ 26.412170] OneNAND version = 0x0031
>> [ 26.415771] Chip support all block unlock
>> [ 26.419830] Chip has 2 plane
>>
>> The second is a single die of 2-Gbit.
>>
>> [ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
>> [ 32.902557] OneNAND version = 0x0031
>> [ 32.906188] Chip support all block unlock
>> [ 32.910247] Chip has 2 plane
>>
>> As I understand the bit 3 of DEVICE_ID register indicates if package
>> is a single-die or a dual-die, so
>>
>> - Muxed OneNAND(DDP) 512MB 1.8V 16-bit -> device id: 0x58 -> bit 3 is
>> 1 -> dual-die
>> - Muxed OneNAND 256MB 1.8V 16-bit -> device id: 0x40 -> bit 3 is 0 ->single-die
>>
>> The question is, why those devices are reporting 'Chip has 2 plane' ?
>>
>> Sorry if this is a trivial question but I'm not sure about DDP and '2
>> plane' concepts. Are the same ?
>>
>> Cheers,
>>
>> Enric
>>
>> 2010/5/6 Enric Balletbò i Serra <eballetbo@gmail.com>:
>>> Hi,
>>>
>>> 2010/5/6 Kyungmin Park <kmpark@infradead.org>:
>>>> Hi,
>>>>
>>>> What's your chip version? maybe some mis-probe it seems to be probed
>>>> at 4KiB pagesize OneNAND.
>>>
>>> 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,
>>> and two-plane NAND Flash memory array,
>>>
>>> These two component enables simultaneous program of 4KiB (
>>> CONFIG_MTD_ONENAND_2X_PROGRAM)
>>>
>>> Cheers,
>>>
>>> Enric
>>>
>>>>
>>>> Thank you,
>>>> Kyungmin Park
>>>>
>>>> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
>>>> <eballetbo@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>>>>> Hi,
>>>>>>
>>>>>> Can you add this statement at below the code?
>>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>>>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>>>>> this->page_mask);
>>>>>
>>>>> Yes,
>>>>>
>>>>> With this code nandtest fails:
>>>>>
>>>>> onenand_base.c
>>>>>
>>>>> 377: default:
>>>>> block = onenand_block(this, addr);
>>>>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>>>>> page = (int) (addr - onenand_addr(this, block)) >>
>>>>> this->page_shift;
>>>>>
>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>>> page, (int)
>>>>> onenand_addr(this, block), ((int) addr >>
>>>>> this->page_shift) &
>>>>> this->page_mask);
>>>>>
>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>> /* Make the even block number */
>>>>> block &= ~1;
>>>>> /* Is it the odd plane? */
>>>>> if (addr & this->writesize)
>>>>> block++;
>>>>> page >>= 1;
>>>>> }
>>>>> page &= this->page_mask;
>>>>> break;
>>>>>
>>>>>
>>>>> --- start log nandtest fail ---
>>>>> # nandtest -l 262144 /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 0
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 00000000: writing...
>>>>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>>>>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>>>>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>>>>> (...)
>>>>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>>>>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>>>>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>>>>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>>>>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>>>>> (...)
>>>>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>>>>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>>>>> 00000000: reading...
>>>>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>>>>> [ 243.505249] onenand_wait: ECC error = 0x8488
>>>>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>>>>> [ 243.514587] onenand_wait: ECC error = 0x8488
>>>>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>>>>> (...)
>>>>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>>>>> [ 244.094268] onenand_wait: ECC error = 0x8448
>>>>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>>>>> [ 244.103790] onenand_wait: ECC error = 0x8488
>>>>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>>>>> [ 244.114196] onenand_wait: ECC error = 0x8488
>>>>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>>>>> [ 244.123535] onenand_wait: ECC error = 0x8488
>>>>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>>>>> (...)
>>>>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>>>>> [ 244.703369] onenand_wait: ECC error = 0x8448
>>>>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>>>>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>>>>
>>>>> ECC failed at 00000000
>>>>> 00000000: checking...
>>>>> compare failed. seed 1804289383
>>>>> Byte 0x1 is 5a should be da
>>>>> Byte 0x3 is 82 should be 92
>>>>> Byte 0x4 is 10 should be 1a
>>>>> Byte 0x5 is 21 should be b7
>>>>>
>>>>> --- end log nandtest fail ---
>>>>>
>>>>>
>>>>> With this other code nandtest pass
>>>>>
>>>>> onenand_base.c
>>>>>
>>>>> 377: default:
>>>>> block = onenand_block(this, addr);
>>>>> page = (int) (addr >> this->page_shift);
>>>>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>>>>> this->page_shift; */
>>>>>
>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>>> page, (int)
>>>>> onenand_addr(this, block), ((int) addr >>
>>>>> this->page_shift) &
>>>>> this->page_mask);
>>>>>
>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>> /* Make the even block number */
>>>>> block &= ~1;
>>>>> /* Is it the odd plane? */
>>>>> if (addr & this->writesize)
>>>>> block++;
>>>>> page >>= 1;
>>>>> }
>>>>> page &= this->page_mask;
>>>>> break;
>>>>>
>>>>> --- start log nandtest pass ---
>>>>> # nandtest -l 262144 /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 33
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 00000000: writing...
>>>>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>>>>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>>>>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>>>>> (...)
>>>>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>>>>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>>>>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>>>>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>>>>> (...)
>>>>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>>>>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>>>>> 00000000: reading...
>>>>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>>>>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>>>>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>>>>> (...)
>>>>>
>>>>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>>>>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>>>>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>>>>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>>>>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>>>>> (...)
>>>>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>>>>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>>>>> 00000000: checking...
>>>>> Finished pass 1 successfully
>>>>> --- end log nandtest pass ---
>>>>>
>>>>>>
>>>>>> In my test environment, it displays the correct page number.
>>>>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>>>>> '(addr >> this->page_shift) & this->page_mask'.
>>>>>>
>>>>>
>>>>> Looks like page number is wrong ?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Enric
>>>>>
>>>>>> Thank you,
>>>>>> Kyungmin Park
>>>>>>
>>>>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>>>>> <eballetbo@gmail.com> wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>>>>
>>>>>>> Before this commit when I run the nandtest program all is ok
>>>>>>> ---
>>>>>>> # nandtest /dev/mtd3
>>>>>>> ECC corrections: 0
>>>>>>> ECC failures : 0
>>>>>>> Bad blocks : 0
>>>>>>> BBT blocks : 0
>>>>>>> 002c0000: checking...
>>>>>>> Finished pass 1 successfully
>>>>>>> --
>>>>>>>
>>>>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>>>>> fails with:
>>>>>>> ---
>>>>>>> # nandtest /dev/mtd3
>>>>>>> ECC corrections: 0
>>>>>>> ECC failures : 0
>>>>>>> Bad blocks : 0
>>>>>>> BBT blocks : 0
>>>>>>> 00000000: reading...
>>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>>> ( ... lots of ECC errors ... )
>>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>>> ECC failed at 00000000
>>>>>>> 00000000: checking...
>>>>>>> compare failed. seed 1804289383
>>>>>>> Byte 0x1 is 5a should be da
>>>>>>> Byte 0x3 is 82 should be 92
>>>>>>> Byte 0x4 is 10 should be 1a
>>>>>>> ( ... )
>>>>>>> ---
>>>>>>>
>>>>>>> Investigating a little I see a significant difference introduced by
>>>>>>> this patch. In line
>>>>>>>
>>>>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>>>>> this->page_shift; (patch applied)
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>>>>
>>>>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>>>>> the proper solution (probably this breaks other onenands devices, I
>>>>>>> can't test).
>>>>>>>
>>>>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>>>>> page )
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> ///:~Enric
>>>>>>>
>>>>>>> ---
>>>>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>>>>> b/drivers/mtd/onenand/onenand_base.c
>>>>>>> index 081f97d..b1d50a3 100644
>>>>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>>>>> int cmd, loff_t addr, size_t le
>>>>>>>
>>>>>>> default:
>>>>>>> block = (int) onenand_block(this, addr);
>>>>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>>>>> + page = (int) (addr >> this->page_shift);
>>>>>>>
>>>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>>>> /* Make the even block number */
>>>>>>> ---
>>>>>>>
>>>>>>> ______________________________________________________
>>>>>>> Linux MTD discussion mailing list
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>>>>
>>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>
>>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-07-08 9:55 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-07-08 9:55 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hello,
I made new tests regarding this issue. Looks like the problem is
reading from the OneNAND device.
TEST 1
# modprobe mtd_pagetest dev=4
[ 126.505340]
[ 126.506866] =================================================
[ 126.512756] mtd_pagetest: MTD device: 4
[ 126.520477] mtd_pagetest: MTD device size 262668288, eraseblock
size 262144, page size 4096, count of eraseblocks 1002, pages per
eraseblock 64, OOB size 64
[ 126.535034] mtd_pagetest: scanning for bad eraseblocks
[ 126.540771] mtd_pagetest: scanned 1002 eraseblocks, 0 are bad
[ 126.546630] mtd_pagetest: erasing whole device
[ 128.406890] mtd_pagetest: erased 1002 eraseblocks
[ 128.411712] mtd_pagetest: writing whole device
[ 128.451721] mtd_pagetest: written up to eraseblock 0
[ 137.443817] mtd_pagetest: written up to eraseblock 256
[ 146.440216] mtd_pagetest: written up to eraseblock 512
[ 155.430755] mtd_pagetest: written up to eraseblock 768
[ 163.618225] mtd_pagetest: written 1002 eraseblocks
[ 163.623168] mtd_pagetest: verifying all eraseblocks
[ 163.632965] onenand_wait: ECC error = 0x4488
[ 163.638031] onenand_wait: ECC error = 0x4884
[ 163.642486] onenand_wait: ECC error = 0x8888
[ 163.647247] onenand_wait: ECC error = 0x8888
[ 163.651733] mtd_pagetest: error: read failed at 0x0
[ 163.656890] mtd_pagetest: error -74 occurred
[ 163.661224] =================================================
TEST 2
# nandtest -l 262144 /dev/mtd4
ECC corrections: 0
ECC failures : 260
Bad blocks : 0
BBT blocks : 0
00000000: reading...[ 837.103302] onenand_wait: ECC error = 0x8488
[ 837.109832] onenand_wait: ECC error = 0x8488
[ 837.114532] onenand_wait: ECC error = 0x8888
(...)
[ 837.683624] onenand_wait: ECC error = 0x8448
[ 837.688079] onenand_wait: ECC error = 0x8488
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
(...)
I suspect currently OneNAND with 2 planes is broken. Someone with this
type of device can try these tests ?
Thanks in advance,
Enric
2010/5/12 Enric Balletbò i Serra <eballetbo@gmail.com>:
> I answer to myself.
>
> DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
> a single die can also have '2 planes'. I'm right ?
>
> Sorry for these newbie questions, I'm just introducing to OneNAND devices.
>
> Cheers,
>
> Enric
>
> 2010/5/12 Enric Balletbò i Serra <eballetbo@gmail.com>:
>> Hello,
>>
>> I have a bit of time to investigate more.
>>
>> I have two boards with two different OneNAND chips populated.
>>
>> The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
>>
>> [ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
>> [ 26.412170] OneNAND version = 0x0031
>> [ 26.415771] Chip support all block unlock
>> [ 26.419830] Chip has 2 plane
>>
>> The second is a single die of 2-Gbit.
>>
>> [ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
>> [ 32.902557] OneNAND version = 0x0031
>> [ 32.906188] Chip support all block unlock
>> [ 32.910247] Chip has 2 plane
>>
>> As I understand the bit 3 of DEVICE_ID register indicates if package
>> is a single-die or a dual-die, so
>>
>> - Muxed OneNAND(DDP) 512MB 1.8V 16-bit -> device id: 0x58 -> bit 3 is
>> 1 -> dual-die
>> - Muxed OneNAND 256MB 1.8V 16-bit -> device id: 0x40 -> bit 3 is 0 ->single-die
>>
>> The question is, why those devices are reporting 'Chip has 2 plane' ?
>>
>> Sorry if this is a trivial question but I'm not sure about DDP and '2
>> plane' concepts. Are the same ?
>>
>> Cheers,
>>
>> Enric
>>
>> 2010/5/6 Enric Balletbò i Serra <eballetbo@gmail.com>:
>>> Hi,
>>>
>>> 2010/5/6 Kyungmin Park <kmpark@infradead.org>:
>>>> Hi,
>>>>
>>>> What's your chip version? maybe some mis-probe it seems to be probed
>>>> at 4KiB pagesize OneNAND.
>>>
>>> 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,
>>> and two-plane NAND Flash memory array,
>>>
>>> These two component enables simultaneous program of 4KiB (
>>> CONFIG_MTD_ONENAND_2X_PROGRAM)
>>>
>>> Cheers,
>>>
>>> Enric
>>>
>>>>
>>>> Thank you,
>>>> Kyungmin Park
>>>>
>>>> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
>>>> <eballetbo@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>>>>> Hi,
>>>>>>
>>>>>> Can you add this statement at below the code?
>>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>>>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>>>>> this->page_mask);
>>>>>
>>>>> Yes,
>>>>>
>>>>> With this code nandtest fails:
>>>>>
>>>>> onenand_base.c
>>>>>
>>>>> 377: default:
>>>>> block = onenand_block(this, addr);
>>>>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>>>>> page = (int) (addr - onenand_addr(this, block)) >>
>>>>> this->page_shift;
>>>>>
>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>>> page, (int)
>>>>> onenand_addr(this, block), ((int) addr >>
>>>>> this->page_shift) &
>>>>> this->page_mask);
>>>>>
>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>> /* Make the even block number */
>>>>> block &= ~1;
>>>>> /* Is it the odd plane? */
>>>>> if (addr & this->writesize)
>>>>> block++;
>>>>> page >>= 1;
>>>>> }
>>>>> page &= this->page_mask;
>>>>> break;
>>>>>
>>>>>
>>>>> --- start log nandtest fail ---
>>>>> # nandtest -l 262144 /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 0
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 00000000: writing...
>>>>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>>>>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>>>>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>>>>> (...)
>>>>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>>>>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>>>>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>>>>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>>>>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>>>>> (...)
>>>>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>>>>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>>>>> 00000000: reading...
>>>>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>>>>> [ 243.505249] onenand_wait: ECC error = 0x8488
>>>>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>>>>> [ 243.514587] onenand_wait: ECC error = 0x8488
>>>>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>>>>> (...)
>>>>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>>>>> [ 244.094268] onenand_wait: ECC error = 0x8448
>>>>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>>>>> [ 244.103790] onenand_wait: ECC error = 0x8488
>>>>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>>>>> [ 244.114196] onenand_wait: ECC error = 0x8488
>>>>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>>>>> [ 244.123535] onenand_wait: ECC error = 0x8488
>>>>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>>>>> (...)
>>>>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>>>>> [ 244.703369] onenand_wait: ECC error = 0x8448
>>>>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>>>>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>>>>
>>>>> ECC failed at 00000000
>>>>> 00000000: checking...
>>>>> compare failed. seed 1804289383
>>>>> Byte 0x1 is 5a should be da
>>>>> Byte 0x3 is 82 should be 92
>>>>> Byte 0x4 is 10 should be 1a
>>>>> Byte 0x5 is 21 should be b7
>>>>>
>>>>> --- end log nandtest fail ---
>>>>>
>>>>>
>>>>> With this other code nandtest pass
>>>>>
>>>>> onenand_base.c
>>>>>
>>>>> 377: default:
>>>>> block = onenand_block(this, addr);
>>>>> page = (int) (addr >> this->page_shift);
>>>>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>>>>> this->page_shift; */
>>>>>
>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>>> page, (int)
>>>>> onenand_addr(this, block), ((int) addr >>
>>>>> this->page_shift) &
>>>>> this->page_mask);
>>>>>
>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>> /* Make the even block number */
>>>>> block &= ~1;
>>>>> /* Is it the odd plane? */
>>>>> if (addr & this->writesize)
>>>>> block++;
>>>>> page >>= 1;
>>>>> }
>>>>> page &= this->page_mask;
>>>>> break;
>>>>>
>>>>> --- start log nandtest pass ---
>>>>> # nandtest -l 262144 /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 33
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 00000000: writing...
>>>>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>>>>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>>>>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>>>>> (...)
>>>>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>>>>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>>>>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>>>>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>>>>> (...)
>>>>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>>>>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>>>>> 00000000: reading...
>>>>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>>>>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>>>>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>>>>> (...)
>>>>>
>>>>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>>>>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>>>>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>>>>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>>>>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>>>>> (...)
>>>>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>>>>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>>>>> 00000000: checking...
>>>>> Finished pass 1 successfully
>>>>> --- end log nandtest pass ---
>>>>>
>>>>>>
>>>>>> In my test environment, it displays the correct page number.
>>>>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>>>>> '(addr >> this->page_shift) & this->page_mask'.
>>>>>>
>>>>>
>>>>> Looks like page number is wrong ?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Enric
>>>>>
>>>>>> Thank you,
>>>>>> Kyungmin Park
>>>>>>
>>>>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>>>>> <eballetbo@gmail.com> wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>>>>
>>>>>>> Before this commit when I run the nandtest program all is ok
>>>>>>> ---
>>>>>>> # nandtest /dev/mtd3
>>>>>>> ECC corrections: 0
>>>>>>> ECC failures : 0
>>>>>>> Bad blocks : 0
>>>>>>> BBT blocks : 0
>>>>>>> 002c0000: checking...
>>>>>>> Finished pass 1 successfully
>>>>>>> --
>>>>>>>
>>>>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>>>>> fails with:
>>>>>>> ---
>>>>>>> # nandtest /dev/mtd3
>>>>>>> ECC corrections: 0
>>>>>>> ECC failures : 0
>>>>>>> Bad blocks : 0
>>>>>>> BBT blocks : 0
>>>>>>> 00000000: reading...
>>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>>> ( ... lots of ECC errors ... )
>>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>>> ECC failed at 00000000
>>>>>>> 00000000: checking...
>>>>>>> compare failed. seed 1804289383
>>>>>>> Byte 0x1 is 5a should be da
>>>>>>> Byte 0x3 is 82 should be 92
>>>>>>> Byte 0x4 is 10 should be 1a
>>>>>>> ( ... )
>>>>>>> ---
>>>>>>>
>>>>>>> Investigating a little I see a significant difference introduced by
>>>>>>> this patch. In line
>>>>>>>
>>>>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>>>>> this->page_shift; (patch applied)
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>>>>
>>>>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>>>>> the proper solution (probably this breaks other onenands devices, I
>>>>>>> can't test).
>>>>>>>
>>>>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>>>>> page )
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> ///:~Enric
>>>>>>>
>>>>>>> ---
>>>>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>>>>> b/drivers/mtd/onenand/onenand_base.c
>>>>>>> index 081f97d..b1d50a3 100644
>>>>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>>>>> int cmd, loff_t addr, size_t le
>>>>>>>
>>>>>>> default:
>>>>>>> block = (int) onenand_block(this, addr);
>>>>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>>>>> + page = (int) (addr >> this->page_shift);
>>>>>>>
>>>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>>>> /* Make the even block number */
>>>>>>> ---
>>>>>>>
>>>>>>> ______________________________________________________
>>>>>>> Linux MTD discussion mailing list
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>>>>
>>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-05-12 10:29 ` Enric Balletbò i Serra
@ 2010-05-12 13:16 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-12 13:16 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
I answer to myself.
DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
a single die can also have '2 planes'. I'm right ?
Sorry for these newbie questions, I'm just introducing to OneNAND devices.
Cheers,
Enric
2010/5/12 Enric Balletbò i Serra <eballetbo@gmail.com>:
> Hello,
>
> I have a bit of time to investigate more.
>
> I have two boards with two different OneNAND chips populated.
>
> The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
>
> [ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> [ 26.412170] OneNAND version = 0x0031
> [ 26.415771] Chip support all block unlock
> [ 26.419830] Chip has 2 plane
>
> The second is a single die of 2-Gbit.
>
> [ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
> [ 32.902557] OneNAND version = 0x0031
> [ 32.906188] Chip support all block unlock
> [ 32.910247] Chip has 2 plane
>
> As I understand the bit 3 of DEVICE_ID register indicates if package
> is a single-die or a dual-die, so
>
> - Muxed OneNAND(DDP) 512MB 1.8V 16-bit -> device id: 0x58 -> bit 3 is
> 1 -> dual-die
> - Muxed OneNAND 256MB 1.8V 16-bit -> device id: 0x40 -> bit 3 is 0 ->single-die
>
> The question is, why those devices are reporting 'Chip has 2 plane' ?
>
> Sorry if this is a trivial question but I'm not sure about DDP and '2
> plane' concepts. Are the same ?
>
> Cheers,
>
> Enric
>
> 2010/5/6 Enric Balletbò i Serra <eballetbo@gmail.com>:
>> Hi,
>>
>> 2010/5/6 Kyungmin Park <kmpark@infradead.org>:
>>> Hi,
>>>
>>> What's your chip version? maybe some mis-probe it seems to be probed
>>> at 4KiB pagesize OneNAND.
>>
>> 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,
>> and two-plane NAND Flash memory array,
>>
>> These two component enables simultaneous program of 4KiB (
>> CONFIG_MTD_ONENAND_2X_PROGRAM)
>>
>> Cheers,
>>
>> Enric
>>
>>>
>>> Thank you,
>>> Kyungmin Park
>>>
>>> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
>>> <eballetbo@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>>>> Hi,
>>>>>
>>>>> Can you add this statement at below the code?
>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>>>> this->page_mask);
>>>>
>>>> Yes,
>>>>
>>>> With this code nandtest fails:
>>>>
>>>> onenand_base.c
>>>>
>>>> 377: default:
>>>> block = onenand_block(this, addr);
>>>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>>>> page = (int) (addr - onenand_addr(this, block)) >>
>>>> this->page_shift;
>>>>
>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>> page, (int)
>>>> onenand_addr(this, block), ((int) addr >>
>>>> this->page_shift) &
>>>> this->page_mask);
>>>>
>>>> if (ONENAND_IS_2PLANE(this)) {
>>>> /* Make the even block number */
>>>> block &= ~1;
>>>> /* Is it the odd plane? */
>>>> if (addr & this->writesize)
>>>> block++;
>>>> page >>= 1;
>>>> }
>>>> page &= this->page_mask;
>>>> break;
>>>>
>>>>
>>>> --- start log nandtest fail ---
>>>> # nandtest -l 262144 /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 0
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 00000000: writing...
>>>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>>>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>>>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>>>> (...)
>>>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>>>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>>>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>>>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>>>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>>>> (...)
>>>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>>>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>>>> 00000000: reading...
>>>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>>>> [ 243.505249] onenand_wait: ECC error = 0x8488
>>>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>>>> [ 243.514587] onenand_wait: ECC error = 0x8488
>>>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>>>> (...)
>>>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>>>> [ 244.094268] onenand_wait: ECC error = 0x8448
>>>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>>>> [ 244.103790] onenand_wait: ECC error = 0x8488
>>>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>>>> [ 244.114196] onenand_wait: ECC error = 0x8488
>>>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>>>> [ 244.123535] onenand_wait: ECC error = 0x8488
>>>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>>>> (...)
>>>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>>>> [ 244.703369] onenand_wait: ECC error = 0x8448
>>>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>>>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>>>
>>>> ECC failed at 00000000
>>>> 00000000: checking...
>>>> compare failed. seed 1804289383
>>>> Byte 0x1 is 5a should be da
>>>> Byte 0x3 is 82 should be 92
>>>> Byte 0x4 is 10 should be 1a
>>>> Byte 0x5 is 21 should be b7
>>>>
>>>> --- end log nandtest fail ---
>>>>
>>>>
>>>> With this other code nandtest pass
>>>>
>>>> onenand_base.c
>>>>
>>>> 377: default:
>>>> block = onenand_block(this, addr);
>>>> page = (int) (addr >> this->page_shift);
>>>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>>>> this->page_shift; */
>>>>
>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>> page, (int)
>>>> onenand_addr(this, block), ((int) addr >>
>>>> this->page_shift) &
>>>> this->page_mask);
>>>>
>>>> if (ONENAND_IS_2PLANE(this)) {
>>>> /* Make the even block number */
>>>> block &= ~1;
>>>> /* Is it the odd plane? */
>>>> if (addr & this->writesize)
>>>> block++;
>>>> page >>= 1;
>>>> }
>>>> page &= this->page_mask;
>>>> break;
>>>>
>>>> --- start log nandtest pass ---
>>>> # nandtest -l 262144 /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 33
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 00000000: writing...
>>>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>>>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>>>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>>>> (...)
>>>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>>>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>>>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>>>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>>>> (...)
>>>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>>>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>>>> 00000000: reading...
>>>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>>>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>>>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>>>> (...)
>>>>
>>>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>>>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>>>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>>>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>>>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>>>> (...)
>>>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>>>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>>>> 00000000: checking...
>>>> Finished pass 1 successfully
>>>> --- end log nandtest pass ---
>>>>
>>>>>
>>>>> In my test environment, it displays the correct page number.
>>>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>>>> '(addr >> this->page_shift) & this->page_mask'.
>>>>>
>>>>
>>>> Looks like page number is wrong ?
>>>>
>>>> Cheers,
>>>>
>>>> Enric
>>>>
>>>>> Thank you,
>>>>> Kyungmin Park
>>>>>
>>>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>>>> <eballetbo@gmail.com> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>>>
>>>>>> Before this commit when I run the nandtest program all is ok
>>>>>> ---
>>>>>> # nandtest /dev/mtd3
>>>>>> ECC corrections: 0
>>>>>> ECC failures : 0
>>>>>> Bad blocks : 0
>>>>>> BBT blocks : 0
>>>>>> 002c0000: checking...
>>>>>> Finished pass 1 successfully
>>>>>> --
>>>>>>
>>>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>>>> fails with:
>>>>>> ---
>>>>>> # nandtest /dev/mtd3
>>>>>> ECC corrections: 0
>>>>>> ECC failures : 0
>>>>>> Bad blocks : 0
>>>>>> BBT blocks : 0
>>>>>> 00000000: reading...
>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>> ( ... lots of ECC errors ... )
>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>> ECC failed at 00000000
>>>>>> 00000000: checking...
>>>>>> compare failed. seed 1804289383
>>>>>> Byte 0x1 is 5a should be da
>>>>>> Byte 0x3 is 82 should be 92
>>>>>> Byte 0x4 is 10 should be 1a
>>>>>> ( ... )
>>>>>> ---
>>>>>>
>>>>>> Investigating a little I see a significant difference introduced by
>>>>>> this patch. In line
>>>>>>
>>>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>>>> this->page_shift; (patch applied)
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>>>
>>>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>>>> the proper solution (probably this breaks other onenands devices, I
>>>>>> can't test).
>>>>>>
>>>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>>>> page )
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> ///:~Enric
>>>>>>
>>>>>> ---
>>>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>>>> b/drivers/mtd/onenand/onenand_base.c
>>>>>> index 081f97d..b1d50a3 100644
>>>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>>>> int cmd, loff_t addr, size_t le
>>>>>>
>>>>>> default:
>>>>>> block = (int) onenand_block(this, addr);
>>>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>>>> + page = (int) (addr >> this->page_shift);
>>>>>>
>>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>>> /* Make the even block number */
>>>>>> ---
>>>>>>
>>>>>> ______________________________________________________
>>>>>> Linux MTD discussion mailing list
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-12 13:16 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-12 13:16 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
I answer to myself.
DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
a single die can also have '2 planes'. I'm right ?
Sorry for these newbie questions, I'm just introducing to OneNAND devices.
Cheers,
Enric
2010/5/12 Enric Balletbò i Serra <eballetbo@gmail.com>:
> Hello,
>
> I have a bit of time to investigate more.
>
> I have two boards with two different OneNAND chips populated.
>
> The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
>
> [ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> [ 26.412170] OneNAND version = 0x0031
> [ 26.415771] Chip support all block unlock
> [ 26.419830] Chip has 2 plane
>
> The second is a single die of 2-Gbit.
>
> [ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
> [ 32.902557] OneNAND version = 0x0031
> [ 32.906188] Chip support all block unlock
> [ 32.910247] Chip has 2 plane
>
> As I understand the bit 3 of DEVICE_ID register indicates if package
> is a single-die or a dual-die, so
>
> - Muxed OneNAND(DDP) 512MB 1.8V 16-bit -> device id: 0x58 -> bit 3 is
> 1 -> dual-die
> - Muxed OneNAND 256MB 1.8V 16-bit -> device id: 0x40 -> bit 3 is 0 ->single-die
>
> The question is, why those devices are reporting 'Chip has 2 plane' ?
>
> Sorry if this is a trivial question but I'm not sure about DDP and '2
> plane' concepts. Are the same ?
>
> Cheers,
>
> Enric
>
> 2010/5/6 Enric Balletbò i Serra <eballetbo@gmail.com>:
>> Hi,
>>
>> 2010/5/6 Kyungmin Park <kmpark@infradead.org>:
>>> Hi,
>>>
>>> What's your chip version? maybe some mis-probe it seems to be probed
>>> at 4KiB pagesize OneNAND.
>>
>> 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,
>> and two-plane NAND Flash memory array,
>>
>> These two component enables simultaneous program of 4KiB (
>> CONFIG_MTD_ONENAND_2X_PROGRAM)
>>
>> Cheers,
>>
>> Enric
>>
>>>
>>> Thank you,
>>> Kyungmin Park
>>>
>>> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
>>> <eballetbo@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>>>> Hi,
>>>>>
>>>>> Can you add this statement at below the code?
>>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>>>> this->page_mask);
>>>>
>>>> Yes,
>>>>
>>>> With this code nandtest fails:
>>>>
>>>> onenand_base.c
>>>>
>>>> 377: default:
>>>> block = onenand_block(this, addr);
>>>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>>>> page = (int) (addr - onenand_addr(this, block)) >>
>>>> this->page_shift;
>>>>
>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>> page, (int)
>>>> onenand_addr(this, block), ((int) addr >>
>>>> this->page_shift) &
>>>> this->page_mask);
>>>>
>>>> if (ONENAND_IS_2PLANE(this)) {
>>>> /* Make the even block number */
>>>> block &= ~1;
>>>> /* Is it the odd plane? */
>>>> if (addr & this->writesize)
>>>> block++;
>>>> page >>= 1;
>>>> }
>>>> page &= this->page_mask;
>>>> break;
>>>>
>>>>
>>>> --- start log nandtest fail ---
>>>> # nandtest -l 262144 /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 0
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 00000000: writing...
>>>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>>>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>>>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>>>> (...)
>>>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>>>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>>>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>>>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>>>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>>>> (...)
>>>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>>>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>>>> 00000000: reading...
>>>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>>>> [ 243.505249] onenand_wait: ECC error = 0x8488
>>>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>>>> [ 243.514587] onenand_wait: ECC error = 0x8488
>>>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>>>> (...)
>>>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>>>> [ 244.094268] onenand_wait: ECC error = 0x8448
>>>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>>>> [ 244.103790] onenand_wait: ECC error = 0x8488
>>>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>>>> [ 244.114196] onenand_wait: ECC error = 0x8488
>>>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>>>> [ 244.123535] onenand_wait: ECC error = 0x8488
>>>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>>>> (...)
>>>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>>>> [ 244.703369] onenand_wait: ECC error = 0x8448
>>>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>>>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>>>
>>>> ECC failed at 00000000
>>>> 00000000: checking...
>>>> compare failed. seed 1804289383
>>>> Byte 0x1 is 5a should be da
>>>> Byte 0x3 is 82 should be 92
>>>> Byte 0x4 is 10 should be 1a
>>>> Byte 0x5 is 21 should be b7
>>>>
>>>> --- end log nandtest fail ---
>>>>
>>>>
>>>> With this other code nandtest pass
>>>>
>>>> onenand_base.c
>>>>
>>>> 377: default:
>>>> block = onenand_block(this, addr);
>>>> page = (int) (addr >> this->page_shift);
>>>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>>>> this->page_shift; */
>>>>
>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>>> page, (int)
>>>> onenand_addr(this, block), ((int) addr >>
>>>> this->page_shift) &
>>>> this->page_mask);
>>>>
>>>> if (ONENAND_IS_2PLANE(this)) {
>>>> /* Make the even block number */
>>>> block &= ~1;
>>>> /* Is it the odd plane? */
>>>> if (addr & this->writesize)
>>>> block++;
>>>> page >>= 1;
>>>> }
>>>> page &= this->page_mask;
>>>> break;
>>>>
>>>> --- start log nandtest pass ---
>>>> # nandtest -l 262144 /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 33
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 00000000: writing...
>>>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>>>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>>>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>>>> (...)
>>>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>>>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>>>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>>>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>>>> (...)
>>>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>>>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>>>> 00000000: reading...
>>>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>>>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>>>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>>>> (...)
>>>>
>>>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>>>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>>>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>>>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>>>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>>>> (...)
>>>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>>>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>>>> 00000000: checking...
>>>> Finished pass 1 successfully
>>>> --- end log nandtest pass ---
>>>>
>>>>>
>>>>> In my test environment, it displays the correct page number.
>>>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>>>> '(addr >> this->page_shift) & this->page_mask'.
>>>>>
>>>>
>>>> Looks like page number is wrong ?
>>>>
>>>> Cheers,
>>>>
>>>> Enric
>>>>
>>>>> Thank you,
>>>>> Kyungmin Park
>>>>>
>>>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>>>> <eballetbo@gmail.com> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>>>
>>>>>> Before this commit when I run the nandtest program all is ok
>>>>>> ---
>>>>>> # nandtest /dev/mtd3
>>>>>> ECC corrections: 0
>>>>>> ECC failures : 0
>>>>>> Bad blocks : 0
>>>>>> BBT blocks : 0
>>>>>> 002c0000: checking...
>>>>>> Finished pass 1 successfully
>>>>>> --
>>>>>>
>>>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>>>> fails with:
>>>>>> ---
>>>>>> # nandtest /dev/mtd3
>>>>>> ECC corrections: 0
>>>>>> ECC failures : 0
>>>>>> Bad blocks : 0
>>>>>> BBT blocks : 0
>>>>>> 00000000: reading...
>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>> ( ... lots of ECC errors ... )
>>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>>> ECC failed at 00000000
>>>>>> 00000000: checking...
>>>>>> compare failed. seed 1804289383
>>>>>> Byte 0x1 is 5a should be da
>>>>>> Byte 0x3 is 82 should be 92
>>>>>> Byte 0x4 is 10 should be 1a
>>>>>> ( ... )
>>>>>> ---
>>>>>>
>>>>>> Investigating a little I see a significant difference introduced by
>>>>>> this patch. In line
>>>>>>
>>>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>>>> this->page_shift; (patch applied)
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>>>
>>>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>>>> the proper solution (probably this breaks other onenands devices, I
>>>>>> can't test).
>>>>>>
>>>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>>>> page )
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> ///:~Enric
>>>>>>
>>>>>> ---
>>>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>>>> b/drivers/mtd/onenand/onenand_base.c
>>>>>> index 081f97d..b1d50a3 100644
>>>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>>>> int cmd, loff_t addr, size_t le
>>>>>>
>>>>>> default:
>>>>>> block = (int) onenand_block(this, addr);
>>>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>>>> + page = (int) (addr >> this->page_shift);
>>>>>>
>>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>>> /* Make the even block number */
>>>>>> ---
>>>>>>
>>>>>> ______________________________________________________
>>>>>> Linux MTD discussion mailing list
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-05-06 13:02 ` Enric Balletbò i Serra
@ 2010-05-12 10:29 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-12 10:29 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit -> device id: 0x58 -> bit 3 is
1 -> dual-die
- Muxed OneNAND 256MB 1.8V 16-bit -> device id: 0x40 -> bit 3 is 0 ->single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra <eballetbo@gmail.com>:
> Hi,
>
> 2010/5/6 Kyungmin Park <kmpark@infradead.org>:
>> Hi,
>>
>> What's your chip version? maybe some mis-probe it seems to be probed
>> at 4KiB pagesize OneNAND.
>
> 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,
> and two-plane NAND Flash memory array,
>
> These two component enables simultaneous program of 4KiB (
> CONFIG_MTD_ONENAND_2X_PROGRAM)
>
> Cheers,
>
> Enric
>
>>
>> Thank you,
>> Kyungmin Park
>>
>> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
>> <eballetbo@gmail.com> wrote:
>>> Hi,
>>>
>>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>>> Hi,
>>>>
>>>> Can you add this statement at below the code?
>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>>> this->page_mask);
>>>
>>> Yes,
>>>
>>> With this code nandtest fails:
>>>
>>> onenand_base.c
>>>
>>> 377: default:
>>> block = onenand_block(this, addr);
>>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>>> page = (int) (addr - onenand_addr(this, block)) >>
>>> this->page_shift;
>>>
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>> page, (int)
>>> onenand_addr(this, block), ((int) addr >>
>>> this->page_shift) &
>>> this->page_mask);
>>>
>>> if (ONENAND_IS_2PLANE(this)) {
>>> /* Make the even block number */
>>> block &= ~1;
>>> /* Is it the odd plane? */
>>> if (addr & this->writesize)
>>> block++;
>>> page >>= 1;
>>> }
>>> page &= this->page_mask;
>>> break;
>>>
>>>
>>> --- start log nandtest fail ---
>>> # nandtest -l 262144 /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 0
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 00000000: writing...
>>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>>> (...)
>>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>>> (...)
>>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>>> 00000000: reading...
>>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>>> [ 243.505249] onenand_wait: ECC error = 0x8488
>>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>>> [ 243.514587] onenand_wait: ECC error = 0x8488
>>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>>> (...)
>>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>>> [ 244.094268] onenand_wait: ECC error = 0x8448
>>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>>> [ 244.103790] onenand_wait: ECC error = 0x8488
>>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>>> [ 244.114196] onenand_wait: ECC error = 0x8488
>>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>>> [ 244.123535] onenand_wait: ECC error = 0x8488
>>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>>> (...)
>>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>>> [ 244.703369] onenand_wait: ECC error = 0x8448
>>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>>
>>> ECC failed at 00000000
>>> 00000000: checking...
>>> compare failed. seed 1804289383
>>> Byte 0x1 is 5a should be da
>>> Byte 0x3 is 82 should be 92
>>> Byte 0x4 is 10 should be 1a
>>> Byte 0x5 is 21 should be b7
>>>
>>> --- end log nandtest fail ---
>>>
>>>
>>> With this other code nandtest pass
>>>
>>> onenand_base.c
>>>
>>> 377: default:
>>> block = onenand_block(this, addr);
>>> page = (int) (addr >> this->page_shift);
>>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>>> this->page_shift; */
>>>
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>> page, (int)
>>> onenand_addr(this, block), ((int) addr >>
>>> this->page_shift) &
>>> this->page_mask);
>>>
>>> if (ONENAND_IS_2PLANE(this)) {
>>> /* Make the even block number */
>>> block &= ~1;
>>> /* Is it the odd plane? */
>>> if (addr & this->writesize)
>>> block++;
>>> page >>= 1;
>>> }
>>> page &= this->page_mask;
>>> break;
>>>
>>> --- start log nandtest pass ---
>>> # nandtest -l 262144 /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 33
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 00000000: writing...
>>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>>> (...)
>>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>>> (...)
>>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>>> 00000000: reading...
>>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>>> (...)
>>>
>>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>>> (...)
>>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>>> 00000000: checking...
>>> Finished pass 1 successfully
>>> --- end log nandtest pass ---
>>>
>>>>
>>>> In my test environment, it displays the correct page number.
>>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>>> '(addr >> this->page_shift) & this->page_mask'.
>>>>
>>>
>>> Looks like page number is wrong ?
>>>
>>> Cheers,
>>>
>>> Enric
>>>
>>>> Thank you,
>>>> Kyungmin Park
>>>>
>>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>>> <eballetbo@gmail.com> wrote:
>>>>> Hello all,
>>>>>
>>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>>
>>>>> Before this commit when I run the nandtest program all is ok
>>>>> ---
>>>>> # nandtest /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 0
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 002c0000: checking...
>>>>> Finished pass 1 successfully
>>>>> --
>>>>>
>>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>>> fails with:
>>>>> ---
>>>>> # nandtest /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 0
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 00000000: reading...
>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>> ( ... lots of ECC errors ... )
>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>> ECC failed at 00000000
>>>>> 00000000: checking...
>>>>> compare failed. seed 1804289383
>>>>> Byte 0x1 is 5a should be da
>>>>> Byte 0x3 is 82 should be 92
>>>>> Byte 0x4 is 10 should be 1a
>>>>> ( ... )
>>>>> ---
>>>>>
>>>>> Investigating a little I see a significant difference introduced by
>>>>> this patch. In line
>>>>>
>>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>>> this->page_shift; (patch applied)
>>>>>
>>>>> instead of
>>>>>
>>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>>
>>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>>> the proper solution (probably this breaks other onenands devices, I
>>>>> can't test).
>>>>>
>>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>>> page )
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> ///:~Enric
>>>>>
>>>>> ---
>>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>>> b/drivers/mtd/onenand/onenand_base.c
>>>>> index 081f97d..b1d50a3 100644
>>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>>> int cmd, loff_t addr, size_t le
>>>>>
>>>>> default:
>>>>> block = (int) onenand_block(this, addr);
>>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>>> + page = (int) (addr >> this->page_shift);
>>>>>
>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>> /* Make the even block number */
>>>>> ---
>>>>>
>>>>> ______________________________________________________
>>>>> Linux MTD discussion mailing list
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-12 10:29 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-12 10:29 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit -> device id: 0x58 -> bit 3 is
1 -> dual-die
- Muxed OneNAND 256MB 1.8V 16-bit -> device id: 0x40 -> bit 3 is 0 ->single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra <eballetbo@gmail.com>:
> Hi,
>
> 2010/5/6 Kyungmin Park <kmpark@infradead.org>:
>> Hi,
>>
>> What's your chip version? maybe some mis-probe it seems to be probed
>> at 4KiB pagesize OneNAND.
>
> 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,
> and two-plane NAND Flash memory array,
>
> These two component enables simultaneous program of 4KiB (
> CONFIG_MTD_ONENAND_2X_PROGRAM)
>
> Cheers,
>
> Enric
>
>>
>> Thank you,
>> Kyungmin Park
>>
>> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
>> <eballetbo@gmail.com> wrote:
>>> Hi,
>>>
>>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>>> Hi,
>>>>
>>>> Can you add this statement at below the code?
>>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>>> this->page_mask);
>>>
>>> Yes,
>>>
>>> With this code nandtest fails:
>>>
>>> onenand_base.c
>>>
>>> 377: default:
>>> block = onenand_block(this, addr);
>>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>>> page = (int) (addr - onenand_addr(this, block)) >>
>>> this->page_shift;
>>>
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>> page, (int)
>>> onenand_addr(this, block), ((int) addr >>
>>> this->page_shift) &
>>> this->page_mask);
>>>
>>> if (ONENAND_IS_2PLANE(this)) {
>>> /* Make the even block number */
>>> block &= ~1;
>>> /* Is it the odd plane? */
>>> if (addr & this->writesize)
>>> block++;
>>> page >>= 1;
>>> }
>>> page &= this->page_mask;
>>> break;
>>>
>>>
>>> --- start log nandtest fail ---
>>> # nandtest -l 262144 /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 0
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 00000000: writing...
>>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>>> (...)
>>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>>> (...)
>>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>>> 00000000: reading...
>>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>>> [ 243.505249] onenand_wait: ECC error = 0x8488
>>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>>> [ 243.514587] onenand_wait: ECC error = 0x8488
>>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>>> (...)
>>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>>> [ 244.094268] onenand_wait: ECC error = 0x8448
>>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>>> [ 244.103790] onenand_wait: ECC error = 0x8488
>>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>>> [ 244.114196] onenand_wait: ECC error = 0x8488
>>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>>> [ 244.123535] onenand_wait: ECC error = 0x8488
>>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>>> (...)
>>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>>> [ 244.703369] onenand_wait: ECC error = 0x8448
>>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>>
>>> ECC failed at 00000000
>>> 00000000: checking...
>>> compare failed. seed 1804289383
>>> Byte 0x1 is 5a should be da
>>> Byte 0x3 is 82 should be 92
>>> Byte 0x4 is 10 should be 1a
>>> Byte 0x5 is 21 should be b7
>>>
>>> --- end log nandtest fail ---
>>>
>>>
>>> With this other code nandtest pass
>>>
>>> onenand_base.c
>>>
>>> 377: default:
>>> block = onenand_block(this, addr);
>>> page = (int) (addr >> this->page_shift);
>>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>>> this->page_shift; */
>>>
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>>> page, (int)
>>> onenand_addr(this, block), ((int) addr >>
>>> this->page_shift) &
>>> this->page_mask);
>>>
>>> if (ONENAND_IS_2PLANE(this)) {
>>> /* Make the even block number */
>>> block &= ~1;
>>> /* Is it the odd plane? */
>>> if (addr & this->writesize)
>>> block++;
>>> page >>= 1;
>>> }
>>> page &= this->page_mask;
>>> break;
>>>
>>> --- start log nandtest pass ---
>>> # nandtest -l 262144 /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 33
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 00000000: writing...
>>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>>> (...)
>>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>>> (...)
>>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>>> 00000000: reading...
>>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>>> (...)
>>>
>>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>>> (...)
>>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>>> 00000000: checking...
>>> Finished pass 1 successfully
>>> --- end log nandtest pass ---
>>>
>>>>
>>>> In my test environment, it displays the correct page number.
>>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>>> '(addr >> this->page_shift) & this->page_mask'.
>>>>
>>>
>>> Looks like page number is wrong ?
>>>
>>> Cheers,
>>>
>>> Enric
>>>
>>>> Thank you,
>>>> Kyungmin Park
>>>>
>>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>>> <eballetbo@gmail.com> wrote:
>>>>> Hello all,
>>>>>
>>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>>
>>>>> Before this commit when I run the nandtest program all is ok
>>>>> ---
>>>>> # nandtest /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 0
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 002c0000: checking...
>>>>> Finished pass 1 successfully
>>>>> --
>>>>>
>>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>>> fails with:
>>>>> ---
>>>>> # nandtest /dev/mtd3
>>>>> ECC corrections: 0
>>>>> ECC failures : 0
>>>>> Bad blocks : 0
>>>>> BBT blocks : 0
>>>>> 00000000: reading...
>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>> ( ... lots of ECC errors ... )
>>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>>> ECC failed at 00000000
>>>>> 00000000: checking...
>>>>> compare failed. seed 1804289383
>>>>> Byte 0x1 is 5a should be da
>>>>> Byte 0x3 is 82 should be 92
>>>>> Byte 0x4 is 10 should be 1a
>>>>> ( ... )
>>>>> ---
>>>>>
>>>>> Investigating a little I see a significant difference introduced by
>>>>> this patch. In line
>>>>>
>>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>>> this->page_shift; (patch applied)
>>>>>
>>>>> instead of
>>>>>
>>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>>
>>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>>> the proper solution (probably this breaks other onenands devices, I
>>>>> can't test).
>>>>>
>>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>>> page )
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> ///:~Enric
>>>>>
>>>>> ---
>>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>>> b/drivers/mtd/onenand/onenand_base.c
>>>>> index 081f97d..b1d50a3 100644
>>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>>> int cmd, loff_t addr, size_t le
>>>>>
>>>>> default:
>>>>> block = (int) onenand_block(this, addr);
>>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>>> + page = (int) (addr >> this->page_shift);
>>>>>
>>>>> if (ONENAND_IS_2PLANE(this)) {
>>>>> /* Make the even block number */
>>>>> ---
>>>>>
>>>>> ______________________________________________________
>>>>> Linux MTD discussion mailing list
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-05-06 11:44 ` Kyungmin Park
@ 2010-05-06 13:02 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-06 13:02 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hi,
2010/5/6 Kyungmin Park <kmpark@infradead.org>:
> Hi,
>
> What's your chip version? maybe some mis-probe it seems to be probed
> at 4KiB pagesize OneNAND.
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,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
>
> Thank you,
> Kyungmin Park
>
> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
> <eballetbo@gmail.com> wrote:
>> Hi,
>>
>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>> Hi,
>>>
>>> Can you add this statement at below the code?
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>> this->page_mask);
>>
>> Yes,
>>
>> With this code nandtest fails:
>>
>> onenand_base.c
>>
>> 377: default:
>> block = onenand_block(this, addr);
>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>> page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift;
>>
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>> page, (int)
>> onenand_addr(this, block), ((int) addr >>
>> this->page_shift) &
>> this->page_mask);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> block &= ~1;
>> /* Is it the odd plane? */
>> if (addr & this->writesize)
>> block++;
>> page >>= 1;
>> }
>> page &= this->page_mask;
>> break;
>>
>>
>> --- start log nandtest fail ---
>> # nandtest -l 262144 /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> 00000000: writing...
>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>> (...)
>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>> (...)
>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>> 00000000: reading...
>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>> [ 243.505249] onenand_wait: ECC error = 0x8488
>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>> [ 243.514587] onenand_wait: ECC error = 0x8488
>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>> (...)
>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>> [ 244.094268] onenand_wait: ECC error = 0x8448
>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>> [ 244.103790] onenand_wait: ECC error = 0x8488
>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>> [ 244.114196] onenand_wait: ECC error = 0x8488
>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>> [ 244.123535] onenand_wait: ECC error = 0x8488
>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>> (...)
>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>> [ 244.703369] onenand_wait: ECC error = 0x8448
>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>
>> ECC failed at 00000000
>> 00000000: checking...
>> compare failed. seed 1804289383
>> Byte 0x1 is 5a should be da
>> Byte 0x3 is 82 should be 92
>> Byte 0x4 is 10 should be 1a
>> Byte 0x5 is 21 should be b7
>>
>> --- end log nandtest fail ---
>>
>>
>> With this other code nandtest pass
>>
>> onenand_base.c
>>
>> 377: default:
>> block = onenand_block(this, addr);
>> page = (int) (addr >> this->page_shift);
>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift; */
>>
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>> page, (int)
>> onenand_addr(this, block), ((int) addr >>
>> this->page_shift) &
>> this->page_mask);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> block &= ~1;
>> /* Is it the odd plane? */
>> if (addr & this->writesize)
>> block++;
>> page >>= 1;
>> }
>> page &= this->page_mask;
>> break;
>>
>> --- start log nandtest pass ---
>> # nandtest -l 262144 /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 33
>> Bad blocks : 0
>> BBT blocks : 0
>> 00000000: writing...
>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>> (...)
>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>> (...)
>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>> 00000000: reading...
>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>> (...)
>>
>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>> (...)
>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>> 00000000: checking...
>> Finished pass 1 successfully
>> --- end log nandtest pass ---
>>
>>>
>>> In my test environment, it displays the correct page number.
>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>> '(addr >> this->page_shift) & this->page_mask'.
>>>
>>
>> Looks like page number is wrong ?
>>
>> Cheers,
>>
>> Enric
>>
>>> Thank you,
>>> Kyungmin Park
>>>
>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>> <eballetbo@gmail.com> wrote:
>>>> Hello all,
>>>>
>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>
>>>> Before this commit when I run the nandtest program all is ok
>>>> ---
>>>> # nandtest /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 0
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 002c0000: checking...
>>>> Finished pass 1 successfully
>>>> --
>>>>
>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>> fails with:
>>>> ---
>>>> # nandtest /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 0
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 00000000: reading...
>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>> ( ... lots of ECC errors ... )
>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>> ECC failed at 00000000
>>>> 00000000: checking...
>>>> compare failed. seed 1804289383
>>>> Byte 0x1 is 5a should be da
>>>> Byte 0x3 is 82 should be 92
>>>> Byte 0x4 is 10 should be 1a
>>>> ( ... )
>>>> ---
>>>>
>>>> Investigating a little I see a significant difference introduced by
>>>> this patch. In line
>>>>
>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>> this->page_shift; (patch applied)
>>>>
>>>> instead of
>>>>
>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>
>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>> the proper solution (probably this breaks other onenands devices, I
>>>> can't test).
>>>>
>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>> page )
>>>>
>>>> Thanks in advance,
>>>>
>>>> ///:~Enric
>>>>
>>>> ---
>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>> b/drivers/mtd/onenand/onenand_base.c
>>>> index 081f97d..b1d50a3 100644
>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>> int cmd, loff_t addr, size_t le
>>>>
>>>> default:
>>>> block = (int) onenand_block(this, addr);
>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>> + page = (int) (addr >> this->page_shift);
>>>>
>>>> if (ONENAND_IS_2PLANE(this)) {
>>>> /* Make the even block number */
>>>> ---
>>>>
>>>> ______________________________________________________
>>>> Linux MTD discussion mailing list
>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-06 13:02 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-06 13:02 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hi,
2010/5/6 Kyungmin Park <kmpark@infradead.org>:
> Hi,
>
> What's your chip version? maybe some mis-probe it seems to be probed
> at 4KiB pagesize OneNAND.
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,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
>
> Thank you,
> Kyungmin Park
>
> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
> <eballetbo@gmail.com> wrote:
>> Hi,
>>
>> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>>> Hi,
>>>
>>> Can you add this statement at below the code?
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>> this->page_mask);
>>
>> Yes,
>>
>> With this code nandtest fails:
>>
>> onenand_base.c
>>
>> 377: default:
>> block = onenand_block(this, addr);
>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>> page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift;
>>
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>> page, (int)
>> onenand_addr(this, block), ((int) addr >>
>> this->page_shift) &
>> this->page_mask);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> block &= ~1;
>> /* Is it the odd plane? */
>> if (addr & this->writesize)
>> block++;
>> page >>= 1;
>> }
>> page &= this->page_mask;
>> break;
>>
>>
>> --- start log nandtest fail ---
>> # nandtest -l 262144 /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> 00000000: writing...
>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>> (...)
>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>> (...)
>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>> 00000000: reading...
>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>> [ 243.505249] onenand_wait: ECC error = 0x8488
>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>> [ 243.514587] onenand_wait: ECC error = 0x8488
>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>> (...)
>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>> [ 244.094268] onenand_wait: ECC error = 0x8448
>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>> [ 244.103790] onenand_wait: ECC error = 0x8488
>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>> [ 244.114196] onenand_wait: ECC error = 0x8488
>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>> [ 244.123535] onenand_wait: ECC error = 0x8488
>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>> (...)
>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>> [ 244.703369] onenand_wait: ECC error = 0x8448
>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>
>> ECC failed at 00000000
>> 00000000: checking...
>> compare failed. seed 1804289383
>> Byte 0x1 is 5a should be da
>> Byte 0x3 is 82 should be 92
>> Byte 0x4 is 10 should be 1a
>> Byte 0x5 is 21 should be b7
>>
>> --- end log nandtest fail ---
>>
>>
>> With this other code nandtest pass
>>
>> onenand_base.c
>>
>> 377: default:
>> block = onenand_block(this, addr);
>> page = (int) (addr >> this->page_shift);
>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift; */
>>
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>> page, (int)
>> onenand_addr(this, block), ((int) addr >>
>> this->page_shift) &
>> this->page_mask);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> block &= ~1;
>> /* Is it the odd plane? */
>> if (addr & this->writesize)
>> block++;
>> page >>= 1;
>> }
>> page &= this->page_mask;
>> break;
>>
>> --- start log nandtest pass ---
>> # nandtest -l 262144 /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 33
>> Bad blocks : 0
>> BBT blocks : 0
>> 00000000: writing...
>> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
>> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
>> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
>> (...)
>> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
>> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
>> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
>> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
>> (...)
>> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
>> 00000000: reading...
>> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
>> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
>> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
>> (...)
>>
>> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
>> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
>> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
>> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
>> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
>> (...)
>> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
>> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
>> 00000000: checking...
>> Finished pass 1 successfully
>> --- end log nandtest pass ---
>>
>>>
>>> In my test environment, it displays the correct page number.
>>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>>> '(addr >> this->page_shift) & this->page_mask'.
>>>
>>
>> Looks like page number is wrong ?
>>
>> Cheers,
>>
>> Enric
>>
>>> Thank you,
>>> Kyungmin Park
>>>
>>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>>> <eballetbo@gmail.com> wrote:
>>>> Hello all,
>>>>
>>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>>
>>>> Before this commit when I run the nandtest program all is ok
>>>> ---
>>>> # nandtest /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 0
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 002c0000: checking...
>>>> Finished pass 1 successfully
>>>> --
>>>>
>>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>>> fails with:
>>>> ---
>>>> # nandtest /dev/mtd3
>>>> ECC corrections: 0
>>>> ECC failures : 0
>>>> Bad blocks : 0
>>>> BBT blocks : 0
>>>> 00000000: reading...
>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>> ( ... lots of ECC errors ... )
>>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>>> ECC failed at 00000000
>>>> 00000000: checking...
>>>> compare failed. seed 1804289383
>>>> Byte 0x1 is 5a should be da
>>>> Byte 0x3 is 82 should be 92
>>>> Byte 0x4 is 10 should be 1a
>>>> ( ... )
>>>> ---
>>>>
>>>> Investigating a little I see a significant difference introduced by
>>>> this patch. In line
>>>>
>>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>>> this->page_shift; (patch applied)
>>>>
>>>> instead of
>>>>
>>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>>
>>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>>> the proper solution (probably this breaks other onenands devices, I
>>>> can't test).
>>>>
>>>> I'm just introducing in OneNAND devices so anyone can help me to
>>>> understand and solve the problem ? Note that my device is a Numonyx
>>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>>> page )
>>>>
>>>> Thanks in advance,
>>>>
>>>> ///:~Enric
>>>>
>>>> ---
>>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>>> b/drivers/mtd/onenand/onenand_base.c
>>>> index 081f97d..b1d50a3 100644
>>>> --- a/drivers/mtd/onenand/onenand_base.c
>>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>>> int cmd, loff_t addr, size_t le
>>>>
>>>> default:
>>>> block = (int) onenand_block(this, addr);
>>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>>> + page = (int) (addr >> this->page_shift);
>>>>
>>>> if (ONENAND_IS_2PLANE(this)) {
>>>> /* Make the even block number */
>>>> ---
>>>>
>>>> ______________________________________________________
>>>> Linux MTD discussion mailing list
>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-05-06 11:22 ` Enric Balletbò i Serra
@ 2010-05-06 11:44 ` Kyungmin Park
-1 siblings, 0 replies; 32+ messages in thread
From: Kyungmin Park @ 2010-05-06 11:44 UTC (permalink / raw)
To: Enric Balletbò i Serra; +Cc: linux-omap, linux-mtd
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
<eballetbo@gmail.com> wrote:
> Hi,
>
> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>> Hi,
>>
>> Can you add this statement at below the code?
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>> this->page_mask);
>
> Yes,
>
> With this code nandtest fails:
>
> onenand_base.c
>
> 377: default:
> block = onenand_block(this, addr);
> /* (line disabled) page = (int) (addr >> this->page_shift); */
> page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift;
>
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
> page, (int)
> onenand_addr(this, block), ((int) addr >>
> this->page_shift) &
> this->page_mask);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> block &= ~1;
> /* Is it the odd plane? */
> if (addr & this->writesize)
> block++;
> page >>= 1;
> }
> page &= this->page_mask;
> break;
>
>
> --- start log nandtest fail ---
> # nandtest -l 262144 /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 00000000: writing...
> [ 243.144287] onenand_command[382] page 0, 2621440, 0
> [ 243.150787] onenand_command[382] page 2, 2621440, 2
> [ 243.156158] onenand_command[382] page 4, 2621440, 4
> (...)
> [ 243.310729] onenand_command[382] page 60, 2621440, 60
> [ 243.316223] onenand_command[382] page 62, 2621440, 62
> [ 243.322204] onenand_command[382] page 0, 2752512, 0
> [ 243.327636] onenand_command[382] page 2, 2752512, 2
> [ 243.332977] onenand_command[382] page 4, 2752512, 4
> (...)
> [ 243.487487] onenand_command[382] page 60, 2752512, 60
> [ 243.493041] onenand_command[382] page 62, 2752512, 62
> 00000000: reading...
> [ 243.498535] onenand_command[382] page 0, 2621440, 0
> [ 243.505249] onenand_wait: ECC error = 0x8488
> [ 243.509552] onenand_command[382] page 1, 2621440, 1
> [ 243.514587] onenand_wait: ECC error = 0x8488
> [ 243.518890] onenand_command[382] page 2, 2621440, 2
> (...)
> [ 244.089050] onenand_command[382] page 62, 2621440, 62
> [ 244.094268] onenand_wait: ECC error = 0x8448
> [ 244.098602] onenand_command[382] page 63, 2621440, 63
> [ 244.103790] onenand_wait: ECC error = 0x8488
> [ 244.109191] onenand_command[382] page 0, 2752512, 0
> [ 244.114196] onenand_wait: ECC error = 0x8488
> [ 244.118469] onenand_command[382] page 1, 2752512, 1
> [ 244.123535] onenand_wait: ECC error = 0x8488
> [ 244.127838] onenand_command[382] page 2, 2752512, 2
> (...)
> [ 244.698150] onenand_command[382] page 62, 2752512, 62
> [ 244.703369] onenand_wait: ECC error = 0x8448
> [ 244.707672] onenand_command[382] page 63, 2752512, 63
> [ 244.712890] onenand_wait: ECC error = 0x8488
>
> ECC failed at 00000000
> 00000000: checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> Byte 0x5 is 21 should be b7
>
> --- end log nandtest fail ---
>
>
> With this other code nandtest pass
>
> onenand_base.c
>
> 377: default:
> block = onenand_block(this, addr);
> page = (int) (addr >> this->page_shift);
> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; */
>
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
> page, (int)
> onenand_addr(this, block), ((int) addr >>
> this->page_shift) &
> this->page_mask);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> block &= ~1;
> /* Is it the odd plane? */
> if (addr & this->writesize)
> block++;
> page >>= 1;
> }
> page &= this->page_mask;
> break;
>
> --- start log nandtest pass ---
> # nandtest -l 262144 /dev/mtd3
> ECC corrections: 0
> ECC failures : 33
> Bad blocks : 0
> BBT blocks : 0
> 00000000: writing...
> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
> (...)
> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
> (...)
> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
> 00000000: reading...
> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
> (...)
>
> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
> (...)
> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
> 00000000: checking...
> Finished pass 1 successfully
> --- end log nandtest pass ---
>
>>
>> In my test environment, it displays the correct page number.
>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>> '(addr >> this->page_shift) & this->page_mask'.
>>
>
> Looks like page number is wrong ?
>
> Cheers,
>
> Enric
>
>> Thank you,
>> Kyungmin Park
>>
>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>> <eballetbo@gmail.com> wrote:
>>> Hello all,
>>>
>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>
>>> Before this commit when I run the nandtest program all is ok
>>> ---
>>> # nandtest /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 0
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 002c0000: checking...
>>> Finished pass 1 successfully
>>> --
>>>
>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>> fails with:
>>> ---
>>> # nandtest /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 0
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 00000000: reading...
>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>> ( ... lots of ECC errors ... )
>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>> ECC failed at 00000000
>>> 00000000: checking...
>>> compare failed. seed 1804289383
>>> Byte 0x1 is 5a should be da
>>> Byte 0x3 is 82 should be 92
>>> Byte 0x4 is 10 should be 1a
>>> ( ... )
>>> ---
>>>
>>> Investigating a little I see a significant difference introduced by
>>> this patch. In line
>>>
>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>> this->page_shift; (patch applied)
>>>
>>> instead of
>>>
>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>
>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>> the proper solution (probably this breaks other onenands devices, I
>>> can't test).
>>>
>>> I'm just introducing in OneNAND devices so anyone can help me to
>>> understand and solve the problem ? Note that my device is a Numonyx
>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>> page )
>>>
>>> Thanks in advance,
>>>
>>> ///:~Enric
>>>
>>> ---
>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>> b/drivers/mtd/onenand/onenand_base.c
>>> index 081f97d..b1d50a3 100644
>>> --- a/drivers/mtd/onenand/onenand_base.c
>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>> int cmd, loff_t addr, size_t le
>>>
>>> default:
>>> block = (int) onenand_block(this, addr);
>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>> + page = (int) (addr >> this->page_shift);
>>>
>>> if (ONENAND_IS_2PLANE(this)) {
>>> /* Make the even block number */
>>> ---
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-06 11:44 ` Kyungmin Park
0 siblings, 0 replies; 32+ messages in thread
From: Kyungmin Park @ 2010-05-06 11:44 UTC (permalink / raw)
To: Enric Balletbò i Serra; +Cc: linux-omap, linux-mtd
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
<eballetbo@gmail.com> wrote:
> Hi,
>
> 2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
>> Hi,
>>
>> Can you add this statement at below the code?
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>> this->page_mask);
>
> Yes,
>
> With this code nandtest fails:
>
> onenand_base.c
>
> 377: default:
> block = onenand_block(this, addr);
> /* (line disabled) page = (int) (addr >> this->page_shift); */
> page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift;
>
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
> page, (int)
> onenand_addr(this, block), ((int) addr >>
> this->page_shift) &
> this->page_mask);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> block &= ~1;
> /* Is it the odd plane? */
> if (addr & this->writesize)
> block++;
> page >>= 1;
> }
> page &= this->page_mask;
> break;
>
>
> --- start log nandtest fail ---
> # nandtest -l 262144 /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 00000000: writing...
> [ 243.144287] onenand_command[382] page 0, 2621440, 0
> [ 243.150787] onenand_command[382] page 2, 2621440, 2
> [ 243.156158] onenand_command[382] page 4, 2621440, 4
> (...)
> [ 243.310729] onenand_command[382] page 60, 2621440, 60
> [ 243.316223] onenand_command[382] page 62, 2621440, 62
> [ 243.322204] onenand_command[382] page 0, 2752512, 0
> [ 243.327636] onenand_command[382] page 2, 2752512, 2
> [ 243.332977] onenand_command[382] page 4, 2752512, 4
> (...)
> [ 243.487487] onenand_command[382] page 60, 2752512, 60
> [ 243.493041] onenand_command[382] page 62, 2752512, 62
> 00000000: reading...
> [ 243.498535] onenand_command[382] page 0, 2621440, 0
> [ 243.505249] onenand_wait: ECC error = 0x8488
> [ 243.509552] onenand_command[382] page 1, 2621440, 1
> [ 243.514587] onenand_wait: ECC error = 0x8488
> [ 243.518890] onenand_command[382] page 2, 2621440, 2
> (...)
> [ 244.089050] onenand_command[382] page 62, 2621440, 62
> [ 244.094268] onenand_wait: ECC error = 0x8448
> [ 244.098602] onenand_command[382] page 63, 2621440, 63
> [ 244.103790] onenand_wait: ECC error = 0x8488
> [ 244.109191] onenand_command[382] page 0, 2752512, 0
> [ 244.114196] onenand_wait: ECC error = 0x8488
> [ 244.118469] onenand_command[382] page 1, 2752512, 1
> [ 244.123535] onenand_wait: ECC error = 0x8488
> [ 244.127838] onenand_command[382] page 2, 2752512, 2
> (...)
> [ 244.698150] onenand_command[382] page 62, 2752512, 62
> [ 244.703369] onenand_wait: ECC error = 0x8448
> [ 244.707672] onenand_command[382] page 63, 2752512, 63
> [ 244.712890] onenand_wait: ECC error = 0x8488
>
> ECC failed at 00000000
> 00000000: checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> Byte 0x5 is 21 should be b7
>
> --- end log nandtest fail ---
>
>
> With this other code nandtest pass
>
> onenand_base.c
>
> 377: default:
> block = onenand_block(this, addr);
> page = (int) (addr >> this->page_shift);
> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; */
>
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
> page, (int)
> onenand_addr(this, block), ((int) addr >>
> this->page_shift) &
> this->page_mask);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> block &= ~1;
> /* Is it the odd plane? */
> if (addr & this->writesize)
> block++;
> page >>= 1;
> }
> page &= this->page_mask;
> break;
>
> --- start log nandtest pass ---
> # nandtest -l 262144 /dev/mtd3
> ECC corrections: 0
> ECC failures : 33
> Bad blocks : 0
> BBT blocks : 0
> 00000000: writing...
> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
> (...)
> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
> (...)
> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
> [ 2024.985351] onenand_command[382] page 1406, 2752512, 62
> 00000000: reading...
> [ 2024.990997] onenand_command[382] page 1280, 2621440, 0
> [ 2024.997985] onenand_command[382] page 1281, 2621440, 1
> [ 2025.003295] onenand_command[382] page 1282, 2621440, 2
> (...)
>
> [ 2025.326782] onenand_command[382] page 1342, 2621440, 62
> [ 2025.332214] onenand_command[382] page 1343, 2621440, 63
> [ 2025.338592] onenand_command[382] page 1344, 2752512, 0
> [ 2025.343811] onenand_command[382] page 1345, 2752512, 1
> [ 2025.349151] onenand_command[382] page 1346, 2752512, 2
> (...)
> [ 2025.672576] onenand_command[382] page 1406, 2752512, 62
> [ 2025.677978] onenand_command[382] page 1407, 2752512, 63
> 00000000: checking...
> Finished pass 1 successfully
> --- end log nandtest pass ---
>
>>
>> In my test environment, it displays the correct page number.
>> (addr - onenand_addr(this, block) >> this->page_shift is same as
>> '(addr >> this->page_shift) & this->page_mask'.
>>
>
> Looks like page number is wrong ?
>
> Cheers,
>
> Enric
>
>> Thank you,
>> Kyungmin Park
>>
>> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
>> <eballetbo@gmail.com> wrote:
>>> Hello all,
>>>
>>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>>> Flex-OneNAND support) the onenand support for my device is broken.
>>>
>>> Before this commit when I run the nandtest program all is ok
>>> ---
>>> # nandtest /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 0
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 002c0000: checking...
>>> Finished pass 1 successfully
>>> --
>>>
>>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>>> fails with:
>>> ---
>>> # nandtest /dev/mtd3
>>> ECC corrections: 0
>>> ECC failures : 0
>>> Bad blocks : 0
>>> BBT blocks : 0
>>> 00000000: reading...
>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>> ( ... lots of ECC errors ... )
>>> [ 299.092041] onenand_wait: ECC error = 0x8488
>>> ECC failed at 00000000
>>> 00000000: checking...
>>> compare failed. seed 1804289383
>>> Byte 0x1 is 5a should be da
>>> Byte 0x3 is 82 should be 92
>>> Byte 0x4 is 10 should be 1a
>>> ( ... )
>>> ---
>>>
>>> Investigating a little I see a significant difference introduced by
>>> this patch. In line
>>>
>>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>>> this->page_shift; (patch applied)
>>>
>>> instead of
>>>
>>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>>
>>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>>> the line 347 and now works again. Fantastic, but I suspect this is not
>>> the proper solution (probably this breaks other onenands devices, I
>>> can't test).
>>>
>>> I'm just introducing in OneNAND devices so anyone can help me to
>>> understand and solve the problem ? Note that my device is a Numonyx
>>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>>> page )
>>>
>>> Thanks in advance,
>>>
>>> ///:~Enric
>>>
>>> ---
>>> diff --git a/drivers/mtd/onenand/onenand_base.c
>>> b/drivers/mtd/onenand/onenand_base.c
>>> index 081f97d..b1d50a3 100644
>>> --- a/drivers/mtd/onenand/onenand_base.c
>>> +++ b/drivers/mtd/onenand/onenand_base.c
>>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>>> int cmd, loff_t addr, size_t le
>>>
>>> default:
>>> block = (int) onenand_block(this, addr);
>>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>>> + page = (int) (addr >> this->page_shift);
>>>
>>> if (ONENAND_IS_2PLANE(this)) {
>>> /* Make the even block number */
>>> ---
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-05-06 3:46 ` Kyungmin Park
@ 2010-05-06 11:22 ` Enric Balletbò i Serra
-1 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-06 11:22 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hi,
2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
> Hi,
>
> Can you add this statement at below the code?
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
> onenand_addr(this, block), ((int) addr >> this->page_shift) &
> this->page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr >> this->page_shift); */
page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift;
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr >>
this->page_shift) &
this->page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block &= ~1;
/* Is it the odd plane? */
if (addr & this->writesize)
block++;
page >>= 1;
}
page &= this->page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
00000000: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
00000000: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Byte 0x5 is 21 should be b7
--- end log nandtest fail ---
With this other code nandtest pass
onenand_base.c
377: default:
block = onenand_block(this, addr);
page = (int) (addr >> this->page_shift);
/* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift; */
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr >>
this->page_shift) &
this->page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block &= ~1;
/* Is it the odd plane? */
if (addr & this->writesize)
block++;
page >>= 1;
}
page &= this->page_mask;
break;
--- start log nandtest pass ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 33
Bad blocks : 0
BBT blocks : 0
00000000: writing...
[ 2024.624664] onenand_command[382] page 1280, 2621440, 0
[ 2024.631530] onenand_command[382] page 1282, 2621440, 2
[ 2024.637145] onenand_command[382] page 1284, 2621440, 4
(...)
[ 2024.796813] onenand_command[382] page 1340, 2621440, 60
[ 2024.802520] onenand_command[382] page 1342, 2621440, 62
[ 2024.808593] onenand_command[382] page 1344, 2752512, 0
[ 2024.814239] onenand_command[382] page 1346, 2752512, 2
(...)
[ 2024.979644] onenand_command[382] page 1404, 2752512, 60
[ 2024.985351] onenand_command[382] page 1406, 2752512, 62
00000000: reading...
[ 2024.990997] onenand_command[382] page 1280, 2621440, 0
[ 2024.997985] onenand_command[382] page 1281, 2621440, 1
[ 2025.003295] onenand_command[382] page 1282, 2621440, 2
(...)
[ 2025.326782] onenand_command[382] page 1342, 2621440, 62
[ 2025.332214] onenand_command[382] page 1343, 2621440, 63
[ 2025.338592] onenand_command[382] page 1344, 2752512, 0
[ 2025.343811] onenand_command[382] page 1345, 2752512, 1
[ 2025.349151] onenand_command[382] page 1346, 2752512, 2
(...)
[ 2025.672576] onenand_command[382] page 1406, 2752512, 62
[ 2025.677978] onenand_command[382] page 1407, 2752512, 63
00000000: checking...
Finished pass 1 successfully
--- end log nandtest pass ---
>
> In my test environment, it displays the correct page number.
> (addr - onenand_addr(this, block) >> this->page_shift is same as
> '(addr >> this->page_shift) & this->page_mask'.
>
Looks like page number is wrong ?
Cheers,
Enric
> Thank you,
> Kyungmin Park
>
> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
> <eballetbo@gmail.com> wrote:
>> Hello all,
>>
>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>> Flex-OneNAND support) the onenand support for my device is broken.
>>
>> Before this commit when I run the nandtest program all is ok
>> ---
>> # nandtest /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> 002c0000: checking...
>> Finished pass 1 successfully
>> --
>>
>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>> fails with:
>> ---
>> # nandtest /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> 00000000: reading...
>> [ 299.092041] onenand_wait: ECC error = 0x8488
>> ( ... lots of ECC errors ... )
>> [ 299.092041] onenand_wait: ECC error = 0x8488
>> ECC failed at 00000000
>> 00000000: checking...
>> compare failed. seed 1804289383
>> Byte 0x1 is 5a should be da
>> Byte 0x3 is 82 should be 92
>> Byte 0x4 is 10 should be 1a
>> ( ... )
>> ---
>>
>> Investigating a little I see a significant difference introduced by
>> this patch. In line
>>
>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift; (patch applied)
>>
>> instead of
>>
>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>
>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>> the line 347 and now works again. Fantastic, but I suspect this is not
>> the proper solution (probably this breaks other onenands devices, I
>> can't test).
>>
>> I'm just introducing in OneNAND devices so anyone can help me to
>> understand and solve the problem ? Note that my device is a Numonyx
>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>> page )
>>
>> Thanks in advance,
>>
>> ///:~Enric
>>
>> ---
>> diff --git a/drivers/mtd/onenand/onenand_base.c
>> b/drivers/mtd/onenand/onenand_base.c
>> index 081f97d..b1d50a3 100644
>> --- a/drivers/mtd/onenand/onenand_base.c
>> +++ b/drivers/mtd/onenand/onenand_base.c
>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>> int cmd, loff_t addr, size_t le
>>
>> default:
>> block = (int) onenand_block(this, addr);
>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>> + page = (int) (addr >> this->page_shift);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> ---
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-06 11:22 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-05-06 11:22 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-omap, linux-mtd
Hi,
2010/5/6 Kyungmin Park <kyungmin.park@samsung.com>:
> Hi,
>
> Can you add this statement at below the code?
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
> onenand_addr(this, block), ((int) addr >> this->page_shift) &
> this->page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr >> this->page_shift); */
page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift;
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr >>
this->page_shift) &
this->page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block &= ~1;
/* Is it the odd plane? */
if (addr & this->writesize)
block++;
page >>= 1;
}
page &= this->page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
00000000: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
00000000: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Byte 0x5 is 21 should be b7
--- end log nandtest fail ---
With this other code nandtest pass
onenand_base.c
377: default:
block = onenand_block(this, addr);
page = (int) (addr >> this->page_shift);
/* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift; */
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr >>
this->page_shift) &
this->page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block &= ~1;
/* Is it the odd plane? */
if (addr & this->writesize)
block++;
page >>= 1;
}
page &= this->page_mask;
break;
--- start log nandtest pass ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 33
Bad blocks : 0
BBT blocks : 0
00000000: writing...
[ 2024.624664] onenand_command[382] page 1280, 2621440, 0
[ 2024.631530] onenand_command[382] page 1282, 2621440, 2
[ 2024.637145] onenand_command[382] page 1284, 2621440, 4
(...)
[ 2024.796813] onenand_command[382] page 1340, 2621440, 60
[ 2024.802520] onenand_command[382] page 1342, 2621440, 62
[ 2024.808593] onenand_command[382] page 1344, 2752512, 0
[ 2024.814239] onenand_command[382] page 1346, 2752512, 2
(...)
[ 2024.979644] onenand_command[382] page 1404, 2752512, 60
[ 2024.985351] onenand_command[382] page 1406, 2752512, 62
00000000: reading...
[ 2024.990997] onenand_command[382] page 1280, 2621440, 0
[ 2024.997985] onenand_command[382] page 1281, 2621440, 1
[ 2025.003295] onenand_command[382] page 1282, 2621440, 2
(...)
[ 2025.326782] onenand_command[382] page 1342, 2621440, 62
[ 2025.332214] onenand_command[382] page 1343, 2621440, 63
[ 2025.338592] onenand_command[382] page 1344, 2752512, 0
[ 2025.343811] onenand_command[382] page 1345, 2752512, 1
[ 2025.349151] onenand_command[382] page 1346, 2752512, 2
(...)
[ 2025.672576] onenand_command[382] page 1406, 2752512, 62
[ 2025.677978] onenand_command[382] page 1407, 2752512, 63
00000000: checking...
Finished pass 1 successfully
--- end log nandtest pass ---
>
> In my test environment, it displays the correct page number.
> (addr - onenand_addr(this, block) >> this->page_shift is same as
> '(addr >> this->page_shift) & this->page_mask'.
>
Looks like page number is wrong ?
Cheers,
Enric
> Thank you,
> Kyungmin Park
>
> On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
> <eballetbo@gmail.com> wrote:
>> Hello all,
>>
>> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
>> Flex-OneNAND support) the onenand support for my device is broken.
>>
>> Before this commit when I run the nandtest program all is ok
>> ---
>> # nandtest /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> 002c0000: checking...
>> Finished pass 1 successfully
>> --
>>
>> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
>> fails with:
>> ---
>> # nandtest /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> 00000000: reading...
>> [ 299.092041] onenand_wait: ECC error = 0x8488
>> ( ... lots of ECC errors ... )
>> [ 299.092041] onenand_wait: ECC error = 0x8488
>> ECC failed at 00000000
>> 00000000: checking...
>> compare failed. seed 1804289383
>> Byte 0x1 is 5a should be da
>> Byte 0x3 is 82 should be 92
>> Byte 0x4 is 10 should be 1a
>> ( ... )
>> ---
>>
>> Investigating a little I see a significant difference introduced by
>> this patch. In line
>>
>> 347: page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift; (patch applied)
>>
>> instead of
>>
>> 347: page = (int) (addr >> this->page_shift); (without patch)
>>
>> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
>> the line 347 and now works again. Fantastic, but I suspect this is not
>> the proper solution (probably this breaks other onenands devices, I
>> can't test).
>>
>> I'm just introducing in OneNAND devices so anyone can help me to
>> understand and solve the problem ? Note that my device is a Numonyx
>> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
>> page )
>>
>> Thanks in advance,
>>
>> ///:~Enric
>>
>> ---
>> diff --git a/drivers/mtd/onenand/onenand_base.c
>> b/drivers/mtd/onenand/onenand_base.c
>> index 081f97d..b1d50a3 100644
>> --- a/drivers/mtd/onenand/onenand_base.c
>> +++ b/drivers/mtd/onenand/onenand_base.c
>> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
>> int cmd, loff_t addr, size_t le
>>
>> default:
>> block = (int) onenand_block(this, addr);
>> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
>> + page = (int) (addr >> this->page_shift);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> ---
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-04-30 10:05 ` Enric Balletbò i Serra
@ 2010-05-06 3:46 ` Kyungmin Park
-1 siblings, 0 replies; 32+ messages in thread
From: Kyungmin Park @ 2010-05-06 3:46 UTC (permalink / raw)
To: Enric Balletbò i Serra; +Cc: linux-omap, linux-mtd
Hi,
Can you add this statement at below the code?
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr >> this->page_shift) &
this->page_mask);
In my test environment, it displays the correct page number.
(addr - onenand_addr(this, block) >> this->page_shift is same as
'(addr >> this->page_shift) & this->page_mask'.
Thank you,
Kyungmin Park
On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
<eballetbo@gmail.com> wrote:
> Hello all,
>
> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
> Flex-OneNAND support) the onenand support for my device is broken.
>
> Before this commit when I run the nandtest program all is ok
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 002c0000: checking...
> Finished pass 1 successfully
> --
>
> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
> fails with:
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 00000000: reading...
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ( ... lots of ECC errors ... )
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ECC failed at 00000000
> 00000000: checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> ( ... )
> ---
>
> Investigating a little I see a significant difference introduced by
> this patch. In line
>
> 347: page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; (patch applied)
>
> instead of
>
> 347: page = (int) (addr >> this->page_shift); (without patch)
>
> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
> the line 347 and now works again. Fantastic, but I suspect this is not
> the proper solution (probably this breaks other onenands devices, I
> can't test).
>
> I'm just introducing in OneNAND devices so anyone can help me to
> understand and solve the problem ? Note that my device is a Numonyx
> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
> page )
>
> Thanks in advance,
>
> ///:~Enric
>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index 081f97d..b1d50a3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
> int cmd, loff_t addr, size_t le
>
> default:
> block = (int) onenand_block(this, addr);
> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
> + page = (int) (addr >> this->page_shift);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> ---
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-06 3:46 ` Kyungmin Park
0 siblings, 0 replies; 32+ messages in thread
From: Kyungmin Park @ 2010-05-06 3:46 UTC (permalink / raw)
To: Enric Balletbò i Serra; +Cc: linux-omap, linux-mtd
Hi,
Can you add this statement at below the code?
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr >> this->page_shift) &
this->page_mask);
In my test environment, it displays the correct page number.
(addr - onenand_addr(this, block) >> this->page_shift is same as
'(addr >> this->page_shift) & this->page_mask'.
Thank you,
Kyungmin Park
On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
<eballetbo@gmail.com> wrote:
> Hello all,
>
> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
> Flex-OneNAND support) the onenand support for my device is broken.
>
> Before this commit when I run the nandtest program all is ok
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 002c0000: checking...
> Finished pass 1 successfully
> --
>
> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
> fails with:
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 00000000: reading...
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ( ... lots of ECC errors ... )
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ECC failed at 00000000
> 00000000: checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> ( ... )
> ---
>
> Investigating a little I see a significant difference introduced by
> this patch. In line
>
> 347: page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; (patch applied)
>
> instead of
>
> 347: page = (int) (addr >> this->page_shift); (without patch)
>
> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
> the line 347 and now works again. Fantastic, but I suspect this is not
> the proper solution (probably this breaks other onenands devices, I
> can't test).
>
> I'm just introducing in OneNAND devices so anyone can help me to
> understand and solve the problem ? Note that my device is a Numonyx
> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
> page )
>
> Thanks in advance,
>
> ///:~Enric
>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index 081f97d..b1d50a3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
> int cmd, loff_t addr, size_t le
>
> default:
> block = (int) onenand_block(this, addr);
> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
> + page = (int) (addr >> this->page_shift);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> ---
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
2010-04-30 10:05 ` Enric Balletbò i Serra
@ 2010-05-05 5:56 ` Artem Bityutskiy
-1 siblings, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-05-05 5:56 UTC (permalink / raw)
To: Enric Balletbò i Serra
Cc: linux-omap, linux-mtd, kyungmin.park, Hunter Adrian (Nokia-D/Helsinki)
Probably Adrian could comment on this?
On Fri, 2010-04-30 at 12:05 +0200, Enric Balletbò i Serra wrote:
> Hello all,
>
> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
> Flex-OneNAND support) the onenand support for my device is broken.
>
> Before this commit when I run the nandtest program all is ok
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 002c0000: checking...
> Finished pass 1 successfully
> --
>
> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
> fails with:
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 00000000: reading...
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ( ... lots of ECC errors ... )
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ECC failed at 00000000
> 00000000: checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> ( ... )
> ---
>
> Investigating a little I see a significant difference introduced by
> this patch. In line
>
> 347: page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; (patch applied)
>
> instead of
>
> 347: page = (int) (addr >> this->page_shift); (without patch)
>
> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
> the line 347 and now works again. Fantastic, but I suspect this is not
> the proper solution (probably this breaks other onenands devices, I
> can't test).
>
> I'm just introducing in OneNAND devices so anyone can help me to
> understand and solve the problem ? Note that my device is a Numonyx
> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
> page )
>
> Thanks in advance,
>
> ///:~Enric
>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index 081f97d..b1d50a3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
> int cmd, loff_t addr, size_t le
>
> default:
> block = (int) onenand_block(this, addr);
> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
> + page = (int) (addr >> this->page_shift);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> ---
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Possible bug in onenand_base ?
@ 2010-05-05 5:56 ` Artem Bityutskiy
0 siblings, 0 replies; 32+ messages in thread
From: Artem Bityutskiy @ 2010-05-05 5:56 UTC (permalink / raw)
To: Enric Balletbò i Serra
Cc: kyungmin.park, linux-omap, linux-mtd, Hunter Adrian (Nokia-D/Helsinki)
Probably Adrian could comment on this?
On Fri, 2010-04-30 at 12:05 +0200, Enric Balletbò i Serra wrote:
> Hello all,
>
> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
> Flex-OneNAND support) the onenand support for my device is broken.
>
> Before this commit when I run the nandtest program all is ok
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 002c0000: checking...
> Finished pass 1 successfully
> --
>
> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
> fails with:
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 00000000: reading...
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ( ... lots of ECC errors ... )
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ECC failed at 00000000
> 00000000: checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> ( ... )
> ---
>
> Investigating a little I see a significant difference introduced by
> this patch. In line
>
> 347: page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; (patch applied)
>
> instead of
>
> 347: page = (int) (addr >> this->page_shift); (without patch)
>
> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
> the line 347 and now works again. Fantastic, but I suspect this is not
> the proper solution (probably this breaks other onenands devices, I
> can't test).
>
> I'm just introducing in OneNAND devices so anyone can help me to
> understand and solve the problem ? Note that my device is a Numonyx
> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
> page )
>
> Thanks in advance,
>
> ///:~Enric
>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index 081f97d..b1d50a3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
> int cmd, loff_t addr, size_t le
>
> default:
> block = (int) onenand_block(this, addr);
> - page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
> + page = (int) (addr >> this->page_shift);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> ---
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Possible bug in onenand_base ?
@ 2010-04-30 10:05 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-04-30 10:05 UTC (permalink / raw)
To: linux-omap, linux-mtd, kyungmin.park
Hello all,
After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
Flex-OneNAND support) the onenand support for my device is broken.
Before this commit when I run the nandtest program all is ok
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
002c0000: checking...
Finished pass 1 successfully
--
Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
fails with:
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
00000000: reading...
[ 299.092041] onenand_wait: ECC error = 0x8488
( ... lots of ECC errors ... )
[ 299.092041] onenand_wait: ECC error = 0x8488
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
( ... )
---
Investigating a little I see a significant difference introduced by
this patch. In line
347: page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift; (patch applied)
instead of
347: page = (int) (addr >> this->page_shift); (without patch)
I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
the line 347 and now works again. Fantastic, but I suspect this is not
the proper solution (probably this breaks other onenands devices, I
can't test).
I'm just introducing in OneNAND devices so anyone can help me to
understand and solve the problem ? Note that my device is a Numonyx
4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
page )
Thanks in advance,
///:~Enric
---
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 081f97d..b1d50a3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = (int) onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
+ page = (int) (addr >> this->page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
---
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Possible bug in onenand_base ?
@ 2010-04-30 10:05 ` Enric Balletbò i Serra
0 siblings, 0 replies; 32+ messages in thread
From: Enric Balletbò i Serra @ 2010-04-30 10:05 UTC (permalink / raw)
To: linux-omap, linux-mtd, kyungmin.park
Hello all,
After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
Flex-OneNAND support) the onenand support for my device is broken.
Before this commit when I run the nandtest program all is ok
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
002c0000: checking...
Finished pass 1 successfully
--
Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
fails with:
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
00000000: reading...
[ 299.092041] onenand_wait: ECC error = 0x8488
( ... lots of ECC errors ... )
[ 299.092041] onenand_wait: ECC error = 0x8488
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
( ... )
---
Investigating a little I see a significant difference introduced by
this patch. In line
347: page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift; (patch applied)
instead of
347: page = (int) (addr >> this->page_shift); (without patch)
I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
the line 347 and now works again. Fantastic, but I suspect this is not
the proper solution (probably this breaks other onenands devices, I
can't test).
I'm just introducing in OneNAND devices so anyone can help me to
understand and solve the problem ? Note that my device is a Numonyx
4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
page )
Thanks in advance,
///:~Enric
---
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 081f97d..b1d50a3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = (int) onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block)) >> this->page_shift;
+ page = (int) (addr >> this->page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
---
^ permalink raw reply related [flat|nested] 32+ messages in thread
end of thread, other threads:[~2010-07-18 16:47 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-14 8:52 Possible bug in onenand_base ? ROHIT H.S
2010-07-14 14:37 ` Enric Balletbò i Serra
2010-07-15 9:25 ` Rohit Hassan Sathyanarayan
2010-07-15 11:19 ` Enric Balletbò i Serra
2010-07-16 12:04 ` Rohit Hassan Sathyanarayan
2010-07-18 16:47 ` Artem Bityutskiy
-- strict thread matches above, loose matches on Subject: below --
2010-04-30 10:05 Enric Balletbò i Serra
2010-04-30 10:05 ` Enric Balletbò i Serra
2010-05-05 5:56 ` Artem Bityutskiy
2010-05-05 5:56 ` Artem Bityutskiy
2010-05-06 3:46 ` Kyungmin Park
2010-05-06 3:46 ` Kyungmin Park
2010-05-06 11:22 ` Enric Balletbò i Serra
2010-05-06 11:22 ` Enric Balletbò i Serra
2010-05-06 11:44 ` Kyungmin Park
2010-05-06 11:44 ` Kyungmin Park
2010-05-06 13:02 ` Enric Balletbò i Serra
2010-05-06 13:02 ` Enric Balletbò i Serra
2010-05-12 10:29 ` Enric Balletbò i Serra
2010-05-12 10:29 ` Enric Balletbò i Serra
2010-05-12 13:16 ` Enric Balletbò i Serra
2010-05-12 13:16 ` Enric Balletbò i Serra
2010-07-08 9:55 ` Enric Balletbò i Serra
2010-07-08 9:55 ` Enric Balletbò i Serra
2010-07-08 9:58 ` Artem Bityutskiy
2010-07-08 9:58 ` Artem Bityutskiy
2010-07-08 10:11 ` Enric Balletbò i Serra
2010-07-08 10:11 ` Enric Balletbò i Serra
2010-07-08 10:22 ` Artem Bityutskiy
2010-07-08 10:22 ` Artem Bityutskiy
2010-07-12 14:59 ` Enric Balletbò i Serra
2010-07-12 14:59 ` Enric Balletbò i Serra
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.