question: Why the nand_wait() wait for 20ms for nand program.

DISCUSSION Huang Shijie 4 participants 13 messages Jan 18, 2013 – Feb 4, 2013 2 messages not in the archive Memory technology devices (MTD)

lore

Share & tools

lore

Huang Shijie

author

2013-01-18 08:05 UTC #0 lore raw

Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.

thanks
Huang Shijie

Matthieu CASTET

2013-01-18 12:26 UTC #1 lore raw

Quoted 7 lines · Huang Shijie

Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.

Don't you have an hardware problem (missing pullup/down on ready busy pin) ?

If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.

Matthieu

Huang Shijie

author

2013-01-21 03:35 UTC #2 lore raw

Quoted 11 lines · Matthieu CASTET

Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.

I finally found the root cause.

I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start -----------------------------------------------------------------------

+static struct timeval start, finish;
+static int my_nand_wait(struct mtd_info *mtd, struct nand_chip *chip)
+{
+
+ unsigned long timeo = jiffies;
+ int status, state = chip->state;
+ int check = 0;
+
+ if (state == FL_ERASING)
+ timeo += (HZ * 400) / 1000;
+ else
+ timeo += (HZ * 20) / 1000;
+
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
+ /*
+ * Apply this short delay always to ensure that we do wait tWB in any
+ * case on any machine.
+ */
+ ndelay(100);
+
+ if ((state == FL_ERASING) && (chip->options & NAND_IS_AND))
+ chip->cmdfunc(mtd, NAND_CMD_STATUS_MULTI, -1, -1);
+ else
+ chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+
+ do_gettimeofday(&start);
+
+ if (in_interrupt() || oops_in_progress)
+ panic_nand_wait(mtd, chip, timeo);
+ else {
+ while (time_before(jiffies, timeo)) {
+ if (chip->dev_ready) {
+ if (chip->dev_ready(mtd)) {
+ do_gettimeofday(&finish);
+ check = 1;
+ break;
+ }
+ } else {
+ if (chip->read_byte(mtd) & NAND_STATUS_READY)
+ break;
+ }
+ cond_resched();
+ }
+ }
+ led_trigger_event(nand_led_trigger, LED_OFF);
+
+ status = (int)chip->read_byte(mtd);
+ if (check == 0) {
+ long ms, us;
+
+ /* get it here. */
+ do_gettimeofday(&finish);
+
+ us = (finish.tv_sec * USEC_PER_SEC + finish.tv_usec)
+ - (start.tv_sec * USEC_PER_SEC + start.tv_usec);
+ ms = us / USEC_PER_MSEC;
+
+ printk("[ %s : ], status : %x, <%lu, %lu>, < %lu, %lu>, <%lu, %lu>, Js <%lu, %lu>\n",
+ __func__, status, finish.tv_sec, start.tv_sec,
+ finish.tv_usec, start.tv_usec, ms, us);
+
+ }
+ start = finish = (struct timeval) {0, 0};
+ return status;
+}

/**
* __nand_unlock - [REPLACEABLE] unlocks specified locked blocks
* @mtd: mtd info
@@ -2180,7 +2247,8 @@ static int nand_write_page(struct mtd_info *mtd, struct nand_chip *chip, if (!cached || !(chip->options & NAND_CACHEPRG)) {

chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
- status = chip->waitfunc(mtd, chip);
+ status = my_nand_wait(mtd, chip);
+
/*
* See if operation failed and additional status checks are
* available.

Signature · 10 lines

------------------------------------------------------------------------code end here.----------------------------------------------------------------------------


The code tells me that it will wait for 20ms, but in actually, the kernel may breaks the while loop in JUST 1ms.
My CONFIG_HZ is 100.

Any idea about this?

thanks.
Huang Shijie

Quoted 3 lines

Matthieu

Matthieu CASTET

2013-01-21 08:57 UTC #3 lore raw

Quoted 11 lines · Huang Shijie

Quoted 10 lines · Matthieu CASTET
Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?

Quoted 8 lines

Quoted 1 line
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
I finally found the root cause.
I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start

Could you dump jiffies and timeo in your code ?

A message that is not in the archive (sent off-list or not yet received): [email protected]

Matthieu CASTET

2013-01-21 09:16 UTC #5 lore raw

Quoted 23 lines · Huang Shijie

Quoted 12 lines · Matthieu CASTET
Quoted 11 lines · Huang Shijie
Quoted 10 lines · Matthieu CASTET
Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
I finally found the root cause.
I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start
Could you dump jiffies and timeo in your code ?
The following just shows some part of the log:

Quoted 8 lines

[my_nand_wait]status : 80, <21480, 21480>, < 665911, 664170>, <1, 1741> [my_nand_wait]status : 80, <21480, 21480>, < 735989, 734626>, <1, 1363> [my_nand_wait]status : 80, <21480, 21480>, < 805693, 804825>, <0, 868>
From the log, we can see that the kernel just waits for 1741us to break the while loop,
not 20ms.

Yes but you should display jiffies and timeo value to understand why the kernel thinks 2 jiffies elapsed.

Matthieu

Huang Shijie

author

2013-01-21 09:25 UTC #6 lore raw

Quoted 28 lines · Matthieu CASTET

Quoted 27 lines · Huang Shijie
Quoted 12 lines · Matthieu CASTET
Quoted 11 lines · Huang Shijie
Quoted 10 lines · Matthieu CASTET
Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
I finally found the root cause.
I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start
Could you dump jiffies and timeo in your code ?
The following just shows some part of the log:
[my_nand_wait]status : 80,<21480, 21480>,<  665911, 664170>,<1, 1741>
[my_nand_wait]status : 80,<21480, 21480>,<  735989, 734626>,<1, 1363>
[my_nand_wait]status : 80,<21480, 21480>,<  805693, 804825>,<0, 868>

Quoted 6 lines

Quoted 4 lines
From the log, we can see that the kernel just waits for 1741us to break
the while loop,
not 20ms.
Yes but you should display jiffies and timeo value to understand why the kernel thinks 2 jiffies elapsed.

I dumpped the jiffies and timeo too. The jiffies is really _equal_ to the timeo, and then the while loop breaks.

thanks for your comments.

I think there is something wrong with the timer.

Huang Shijie

Quoted 3 lines

Matthieu

Matthieu CASTET

2013-01-21 09:33 UTC #7 lore raw

Quoted 33 lines · Huang Shijie

Quoted 32 lines · Matthieu CASTET
Quoted 31 lines · Huang Shijie
Quoted 12 lines · Matthieu CASTET
Quoted 11 lines · Huang Shijie
Quoted 10 lines · Matthieu CASTET
Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
I finally found the root cause.
I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start
Could you dump jiffies and timeo in your code ?
The following just shows some part of the log:
[my_nand_wait]status : 80,<21480, 21480>,<  665911, 664170>,<1, 1741>
[my_nand_wait]status : 80,<21480, 21480>,<  735989, 734626>,<1, 1363>
[my_nand_wait]status : 80,<21480, 21480>,<  805693, 804825>,<0, 868>
From the log, we can see that the kernel just waits for 1741us to break
the while loop,
not 20ms.

Quoted 9 lines

Quoted 2 lines
Yes but you should display jiffies and timeo value to understand why the kernel thinks 2 jiffies elapsed.
I dumpped the jiffies and timeo too. The jiffies is really _equal_ to the timeo, and then the while loop breaks.
thanks for your comments.
I think there is something wrong with the timer.

timeo += (HZ * 20) / 1000;

So what is the value of HZ ?

In order (HZ * 20) / 1000 is 0 HZ should be < 50.

Matthieu

Huang Shijie

author

2013-01-21 09:36 UTC #8 lore raw

Quoted 39 lines · Matthieu CASTET

Quoted 38 lines · Huang Shijie
Quoted 28 lines · Matthieu CASTET
Quoted 27 lines · Huang Shijie
   于 2013年01月21日 16:57, Matthieu CASTET 写道:
Quoted 12 lines
Quoted 11 lines · Huang Shijie
Quoted 10 lines · Matthieu CASTET
Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
I finally found the root cause.
I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start
Could you dump jiffies and timeo in your code ?
The following just shows some part of the log:
[my_nand_wait]status : 80,<21480, 21480>,<   665911, 664170>,<1, 1741>
[my_nand_wait]status : 80,<21480, 21480>,<   735989, 734626>,<1, 1363>
[my_nand_wait]status : 80,<21480, 21480>,<   805693, 804825>,<0, 868>
Quoted 6 lines
Quoted 4 lines
From the log, we can see that the kernel just waits for 1741us to break
the while loop,
not 20ms.
Yes but you should display jiffies and timeo value to understand why the kernel thinks 2 jiffies elapsed.
I dumpped the jiffies and timeo too. The jiffies is really _equal_ to the timeo, and then the while loop breaks.

Quoted 7 lines

Quoted 4 lines
thanks for your comments.
I think there is something wrong with the timer.
timeo += (HZ * 20) / 1000;
So what is the value of HZ ?

my CONFIG_HZ is 100.

thanks
Huang Shijie

Quoted 5 lines

In order (HZ * 20) / 1000 is 0 HZ should be< 50.
Matthieu

A message that is not in the archive (sent off-list or not yet received): [email protected]

Artem Bityutskiy

2013-02-01 16:56 UTC #10 lore raw

Re: question about mtd_torturetest.c

Quoted 4 lines · Huang Shijie

Hi all:
The mtd_torturetest.c uses the 55/AA patterns to torture the nand block.
Are the 55/AA patterns more tougher then the random data?

Probably not, please, improve the test.

Signature · 2 lines

Best Regards,
Artem Bityutskiy

Gupta, Pekon

2013-02-04 05:19 UTC #11 lore raw

RE: question about mtd_torturetest.c

Quoted 9 lines · Huang Shijie

Quoted 3 lines
Hi all:
The mtd_torturetest.c uses the 55/AA patterns to torture the nand
block.
Quoted 1 line
Are the 55/AA patterns more tougher then the random data?
Probably not, please, improve the test.

(0x55/0xAA/0x55) pattern ensures that _all_ bits in the byte transition from 0-> 1, and 1->0,
Whereas, a random pattern may miss a bit-cell or miss transition sequence, of an bad bit-cell.
Exercising each bit both ways is important so as to differentiate a bad bit-cell (permanent error) from read-disturb errors (temporary error).

For read-disturb: http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf

with regards, pekon

Artem Bityutskiy

2013-02-04 06:57 UTC #12 lore raw

Re: question about mtd_torturetest.c

Quoted 7 lines · Pekon

Quoted 7 lines · Huang Shijie
Quoted 3 lines
Hi all:
The mtd_torturetest.c uses the 55/AA patterns to torture the nand
block.
Quoted 1 line
Are the 55/AA patterns more tougher then the random data?

Quoted 8 lines

Quoted 2 lines
Probably not, please, improve the test.
(0x55/0xAA/0x55) pattern ensures that _all_ bits in the byte transition from 0-> 1, and 1->0,
Whereas, a random pattern may miss a bit-cell or miss transition sequence, of an bad bit-cell.
Exercising each bit both ways is important so as to differentiate a bad bit-cell (permanent error) from read-disturb errors (temporary error).
For read-disturb: http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf

Sure, I did not mean remove those, I meant that random data test can also be added and that would be an improvement.

Signature · 2 lines

Best Regards,
Artem Bityutskiy

Huang Shijie

author

2013-02-04 07:32 UTC #13 lore raw

Re: question about mtd_torturetest.c

Quoted 9 lines · Artem Bityutskiy

Quoted 8 lines · Pekon
Quoted 8 lines · Huang Shijie
Quoted 3 lines
Hi all:
The mtd_torturetest.c uses the 55/AA patterns to torture the nand
block.
Quoted 1 line
Are the 55/AA patterns more tougher then the random data?
Probably not, please, improve the test.

Quoted 8 lines

Quoted 5 lines
(0x55/0xAA/0x55) pattern ensures that _all_ bits in the byte transition from 0-> 1, and 1->0,
Whereas, a random pattern may miss a bit-cell or miss transition sequence, of an bad bit-cell.
Exercising each bit both ways is important so as to differentiate a bad bit-cell (permanent error) from read-disturb errors (temporary error).
For read-disturb: http://download.micron.com/pdf/presentations/events/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf
Sure, I did not mean remove those, I meant that random data test can also be added and that would be an improvement.

I think the random data test is much like the simulation of the nand real use, such as the nand is used in the filesystem.

thank
Huang Shijie

Huang Shijie

author

2013-01-22 02:46 UTC #14 lore raw

In reply to Matthieu CASTET

Quoted 41 lines · Matthieu CASTET

Quoted 40 lines · Huang Shijie
Quoted 28 lines · Matthieu CASTET
Quoted 27 lines · Huang Shijie
   于 2013年01月21日 16:57, Matthieu CASTET 写道:
Quoted 12 lines
Quoted 11 lines · Huang Shijie
Quoted 10 lines · Matthieu CASTET
Quoted 7 lines · Huang Shijie
Hi all:
Why the nand_wait() wait for 20ms for nand program. could we expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP. The chip's BUSY/READY pin may needs more then 20ms to become ready, though its
datasheet tells me the tPROG's max value is 2.5ms.
Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
I finally found the root cause.
I added the do_gettimeofday() in the nand_wait() to measure the READY/BUSY time. The code is like this:
---------------------------------------------------- code start
Could you dump jiffies and timeo in your code ?
The following just shows some part of the log:
[my_nand_wait]status : 80,<21480, 21480>,<   665911, 664170>,<1, 1741>
[my_nand_wait]status : 80,<21480, 21480>,<   735989, 734626>,<1, 1363>
[my_nand_wait]status : 80,<21480, 21480>,<   805693, 804825>,<0, 868>
Quoted 6 lines
Quoted 4 lines
From the log, we can see that the kernel just waits for 1741us to break
the while loop,
not 20ms.
Yes but you should display jiffies and timeo value to understand why the kernel thinks 2 jiffies elapsed.
I dumpped the jiffies and timeo too. The jiffies is really _equal_ to the timeo, and then the while loop breaks.
thanks for your comments.

Quoted 7 lines

Quoted 2 lines
I think there is something wrong with the timer.
timeo += (HZ * 20) / 1000;
So what is the value of HZ ?
In order (HZ * 20) / 1000 is 0 HZ should be< 50.

thanks for your help.

I really appreciate it.

this bug is caused by our unstable kernel.
I tried with some other stable code, the issue never occurs.

thanks
Huang shijie

Quoted 3 lines

Matthieu