public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Kyungmin Park <kyungmin.park@samsung.com>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Adrian Hunter <hunter.programmer@gmail.com>
Subject: OneNAND: read-while-load (known problem)
Date: Mon, 08 Jan 2007 03:37:23 +0000 (GMT)	[thread overview]
Message-ID: <7302633.455711168227442976.JavaMail.weblogic@ep_ml21> (raw)

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 (Битюцкий Артём)




             reply	other threads:[~2007-01-08  3:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-08  3:37 Kyungmin Park [this message]
2007-01-08  7:47 ` OneNAND: read-while-load (known problem) 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7302633.455711168227442976.JavaMail.weblogic@ep_ml21 \
    --to=kyungmin.park@samsung.com \
    --cc=dedekind@infradead.org \
    --cc=hunter.programmer@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox