* OneNAND: read-while-load (known problem)
@ 2007-01-08 3:37 Kyungmin Park
2007-01-08 7:47 ` Adrian Hunter
0 siblings, 1 reply; 6+ messages in thread
From: Kyungmin Park @ 2007-01-08 3:37 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-mtd@lists.infradead.org, Adrian Hunter
Hi,
FYI: read-while-load known problem in DDP.
Of course it's rare case in MTD. and please don't program like this in upper layer.
If you are using OneNAND DDP (Dual Densidy Package) and you want to read data between chip boundary. you maybe failed to read.
For example, 2Gbit OneNAND DDP has following address
Chip 0: 0x0000 0000 ~ 0x0800 0000 - 1
Chip 1: 0x0800 0000 ~ 0x1000 0000 - 1
If you want to read from 0x07ff f800 to 0x8000 0800 (4KB). it will be failed since each chip has its own bufferram
So it don't support read-while-loading between each chip.
[Chip 0] onenand_update_bufferram: 1 addr 0x7ffe000, valid = 1
[Chip 0] onenand_update_bufferram: 0 addr 0x7ffe800, valid = 1
[Chip 0] onenand_update_bufferram: 1 addr 0x7fff000, valid = 1
[Chip 0] onenand_update_bufferram: 0 addr 0x7fff800, valid = 1
-> Send next page read, but next page is in chip 1
[Chip 1] onenand_update_bufferram: 1 addr 0x8000000, valid = 1 => Actually it's invalid
[Chip 1] onenand_update_bufferram: 0 addr 0x8000800, valid = 1
[Chip 1] onenand_update_bufferram: 1 addr 0x8001000, valid = 1
Thank you,
Kyungmin Park
------- Original Message -------
Sender : Artem Bityutskiy<dedekind@infradead.org>
Date : Jan 05, 2007 19:54
Title : Re: OneNAND: read-while-load
On Fri, 2007-01-05 at 09:58 +0000, Kyungmin Park wrote:
> Yes, We already knew read-while-loading has better performance than normal read.
> Internally we called it 'MRead' (refer another OneNAND open source in samsung web site)
It is true that JFFS2 is currently the main user. But it may be changed
in the future. Also one day one can teach JFFS2 to maintain larger nodes
with, say 16K or more bytes of data. And BTW, UBI reads whole
eraseblocks when making wear-leveling, so it would also benefit.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OneNAND: read-while-load (known problem)
2007-01-08 3:37 OneNAND: read-while-load (known problem) Kyungmin Park
@ 2007-01-08 7:47 ` Adrian Hunter
0 siblings, 0 replies; 6+ messages in thread
From: Adrian Hunter @ 2007-01-08 7:47 UTC (permalink / raw)
To: kyungmin.park; +Cc: linux-mtd
On 1/8/07, Kyungmin Park <kyungmin.park@samsung.com> wrote:
> Hi,
>
> FYI: read-while-load known problem in DDP.
>
> Of course it's rare case in MTD. and please don't program like this in upper layer.
>
> If you are using OneNAND DDP (Dual Densidy Package) and you want to read data between chip boundary. you maybe failed to read.
>
> For example, 2Gbit OneNAND DDP has following address
>
> Chip 0: 0x0000 0000 ~ 0x0800 0000 - 1
> Chip 1: 0x0800 0000 ~ 0x1000 0000 - 1
>
> If you want to read from 0x07ff f800 to 0x8000 0800 (4KB). it will be failed since each chip has its own bufferram
> So it don't support read-while-loading between each chip.
>
> [Chip 0] onenand_update_bufferram: 1 addr 0x7ffe000, valid = 1
> [Chip 0] onenand_update_bufferram: 0 addr 0x7ffe800, valid = 1
> [Chip 0] onenand_update_bufferram: 1 addr 0x7fff000, valid = 1
> [Chip 0] onenand_update_bufferram: 0 addr 0x7fff800, valid = 1
> -> Send next page read, but next page is in chip 1
> [Chip 1] onenand_update_bufferram: 1 addr 0x8000000, valid = 1 => Actually it's invalid
> [Chip 1] onenand_update_bufferram: 0 addr 0x8000800, valid = 1
> [Chip 1] onenand_update_bufferram: 1 addr 0x8001000, valid = 1
>
> Thank you,
> Kyungmin Park
I think I see what you mean. It occurs to me that maybe
onenand_check_bufferram has the same problem i.e. a different chip is
selected to the one that we want to read from. Do you think there
could be a problem with onenand_check_bufferram also?
^ permalink raw reply [flat|nested] 6+ messages in thread
* OneNAND: read-while-load (known problem)
@ 2007-01-08 8:13 Kyungmin Park
2007-01-08 9:29 ` Adrian Hunter
0 siblings, 1 reply; 6+ messages in thread
From: Kyungmin Park @ 2007-01-08 8:13 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linux-mtd@lists.infradead.org
Hi Adrian,
> Do you think there could be a problem with onenand_check_bufferram also?
No, onenand_check_bufferram & onenand_update_bufferram is right.
In DDP, actually there's 4 bufferrams
Chip 0: 0, 1
Chip 1: 0, 1
In case read from chip 0 to chip 1, first send command at chip 0: 0 or 1, next we also send command at chip 1: 1 or 0, repectively,
in that case. second command will be failed.
To fix this problem, we add some code to check chip boundary condition in DDP. but it's overhead since there's no usage in current MTD
I think it is best way we send the read buffer with block aligned.
Thank you,
Kyungmin Park
------- Original Message -------
Sender : Adrian Hunter<hunter.programmer@gmail.com>
Date : Jan 08, 2007 16:47
Title : Re: OneNAND: read-while-load (known problem)
On 1/8/07, Kyungmin Park <kyungmin.park@samsung.com> wrote:
> Hi,
>
> FYI: read-while-load known problem in DDP.
>
> Of course it's rare case in MTD. and please don't program like this in upper layer.
>
> If you are using OneNAND DDP (Dual Densidy Package) and you want to read data between chip boundary. you maybe failed to read.
>
> For example, 2Gbit OneNAND DDP has following address
>
> Chip 0: 0x0000 0000 ~ 0x0800 0000 - 1
> Chip 1: 0x0800 0000 ~ 0x1000 0000 - 1
>
> If you want to read from 0x07ff f800 to 0x8000 0800 (4KB). it will be failed since each chip has its own bufferram
> So it don't support read-while-loading between each chip.
>
> [Chip 0] onenand_update_bufferram: 1 addr 0x7ffe000, valid = 1
> [Chip 0] onenand_update_bufferram: 0 addr 0x7ffe800, valid = 1
> [Chip 0] onenand_update_bufferram: 1 addr 0x7fff000, valid = 1
> [Chip 0] onenand_update_bufferram: 0 addr 0x7fff800, valid = 1
> -> Send next page read, but next page is in chip 1
> [Chip 1] onenand_update_bufferram: 1 addr 0x8000000, valid = 1 => Actually it's invalid
> [Chip 1] onenand_update_bufferram: 0 addr 0x8000800, valid = 1
> [Chip 1] onenand_update_bufferram: 1 addr 0x8001000, valid = 1
>
> Thank you,
> Kyungmin Park
I think I see what you mean. It occurs to me that maybe
onenand_check_bufferram has the same problem i.e. a different chip is
selected to the one that we want to read from. Do you think there
could be a problem with onenand_check_bufferram also?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OneNAND: read-while-load (known problem)
2007-01-08 8:13 Kyungmin Park
@ 2007-01-08 9:29 ` Adrian Hunter
2007-01-08 14:41 ` Adrian Hunter
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Hunter @ 2007-01-08 9:29 UTC (permalink / raw)
To: kyungmin.park; +Cc: linux-mtd
On 1/8/07, Kyungmin Park <kyungmin.park@samsung.com> wrote:
> Hi Adrian,
>
> > Do you think there could be a problem with onenand_check_bufferram also?
>
> No, onenand_check_bufferram & onenand_update_bufferram is right.
>
What I meant was this:
1. Read page x from chip 0. It goes to dataRAM 0 in chip 0
2. Read page y from chip 1. It goes to dataRAM 1 in chip 1
3. Read page x from chip 0. Now the read incorrectly comes from
dataRAM 0 in chip 1 because that was the last chip selected.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: OneNAND: read-while-load (known problem)
2007-01-08 9:29 ` Adrian Hunter
@ 2007-01-08 14:41 ` Adrian Hunter
0 siblings, 0 replies; 6+ messages in thread
From: Adrian Hunter @ 2007-01-08 14:41 UTC (permalink / raw)
To: kyungmin.park; +Cc: linux-mtd
On 1/8/07, Adrian Hunter <hunter.programmer@gmail.com> wrote:
> On 1/8/07, Kyungmin Park <kyungmin.park@samsung.com> wrote:
> > Hi Adrian,
> >
> > > Do you think there could be a problem with onenand_check_bufferram also?
> >
> > No, onenand_check_bufferram & onenand_update_bufferram is right.
> >
>
> What I meant was this:
>
> 1. Read page x from chip 0. It goes to dataRAM 0 in chip 0
> 2. Read page y from chip 1. It goes to dataRAM 1 in chip 1
> 3. Read page x from chip 0. Now the read incorrectly comes from
> dataRAM 0 in chip 1 because that was the last chip selected.
>
Ah, I see now, onenand_check_bufferram only checks the current dataRAM
so it won't have the wrong chip selected. Please disregard previous
email. Sorry.
^ permalink raw reply [flat|nested] 6+ messages in thread
* OneNAND: read-while-load (known problem)
@ 2007-01-09 1:14 Kyungmin Park
0 siblings, 0 replies; 6+ messages in thread
From: Kyungmin Park @ 2007-01-09 1:14 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linux-mtd@lists.infradead.org
Ah, I see
please try this patch. In my test program. It passed.
Thank you,
Kyungmin Park
--
@@ -747,6 +819,14 @@ static int onenand_read(struct mtd_info *mtd, loff_t from, size_t len,
from += thislen;
if (read + thislen < len) {
this->command(mtd, ONENAND_CMD_READ, from, mtd->writesize);
+ /*
+ * Chip boundary handling in DDP
+ * Now we issued chip 1 read and pointed chip 1
+ * bufferam so we have to point chip 0 bufferam.
+ */
+ if (this->device_id & ONENAND_DEVICE_IS_DDP &&
+ from == (this->chipsize >> 1))
+ this->write_word(0, this->base + ONENAND_REG_START_ADDRESS2);
ONENAND_SET_PREV_BUFFERRAM(this);
}
/* While load is going, read from last bufferRAM */
------- Original Message -------
Sender : Adrian Hunter<hunter.programmer@gmail.com>
Date : Jan 08, 2007 18:29
Title : Re: OneNAND: read-while-load (known problem)
On 1/8/07, Kyungmin Park <kyungmin.park@samsung.com> wrote:
> Hi Adrian,
>
> > Do you think there could be a problem with onenand_check_bufferram also?
>
> No, onenand_check_bufferram & onenand_update_bufferram is right.
>
What I meant was this:
1. Read page x from chip 0. It goes to dataRAM 0 in chip 0
2. Read page y from chip 1. It goes to dataRAM 1 in chip 1
3. Read page x from chip 0. Now the read incorrectly comes from
dataRAM 0 in chip 1 because that was the last chip selected.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-01-09 1:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-08 3:37 OneNAND: read-while-load (known problem) Kyungmin Park
2007-01-08 7:47 ` Adrian Hunter
-- strict thread matches above, loose matches on Subject: below --
2007-01-08 8:13 Kyungmin Park
2007-01-08 9:29 ` Adrian Hunter
2007-01-08 14:41 ` Adrian Hunter
2007-01-09 1:14 Kyungmin Park
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox