public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Husam <husamsenussi@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: DiskOn Chip Millennium Plus 32MB + INFTL
Date: Sat, 10 Jun 2006 23:05:14 +0100	[thread overview]
Message-ID: <1149977115.18635.158.camel@shinybook.infradead.org> (raw)
In-Reply-To: <200606101321.37502.husamsenussi@gmail.com>

On Sat, 2006-06-10 at 13:21 +0100, Husam wrote:
> Yes thats correct but the 32MiB consist of two "NAND 16MiB, 8-bit" Chip, 
> providing 16 bit access using interleave, and that double size the page "Page 
> = 1024 + 32 OOB".
> 
> But does NAND layer need to be abee to handle Multi floor device?

Hm, no -- it's two separate device, isn't it? So don't we just have to
probe them separately and then perhaps use something like mtdconcat?

> > > 2. When I set bus width to 16 in diskonchip level nand_scan return an
> > > error because that doesn't match with table.
> >
> > Doesn't match with which table? What chip ID is detected?
> >
> Yes the ID exist on the table "mfr = 0x98 (Toshiba) , id = 0x75" which match 
> the id I get from trueffs driver for wince, so I would expect "NAND 16MiB, 
> 8-bit". However as I said before the driver should double the size of the 
> page because of interleave.

Hm, is it actually two 8-bit chips, rather than a single 16-bit chip?

In that case, we might have to do a bit more to make it work.

> > > 4. I found that read_buff terminate the read each time, and because of
> > > that nand_read_ecc skip bytes when read across sections.
> >
> > I think the new code probably fixed this, didn't it? If not, we can make
> > sure it does.
> No  you are still terminating the read at the end of read_buf function, you 
> wold need to
> 
> 1. Send READ command
> 2. Read date "e.g. 512 bytes" 
> 3. Read ECC 6 bytes
> 4. terminate read stream
> 
> My be diskonchip layer should implement read_page !!!

Yeah, I think that's probably a sane plan.

> >
> > > 5. Layout of the data on the page is different form 16M, but I'm not sure
> > > if this is specific  to INTFL.
> >
> > I _think_ it's specific to INFTL -- it's weird, though. I don't actually
> > know why M-Systems did that interleaving. There are guys from M-Systems
> > on the list though -- perhaps they can enlighten us?
> >
> But would be able to use the same layout with jffs?

I see no reason why not.

> > Now is a good time to get the remaining issues fixed. I'd very much like
> > to have the 32MiB and 64MiB DiskOnChip Millennium Plus devices working.
> 
> Thats good ... because from what I see 64MiB is not even supported by INTFL 
> layer, in 64MiB each device has separate boot records but information for 
> some of the partitions into the two boot records.

Hm, OK -- we'll need to work on that too.

Let's forget INFTL for now -- can we work on getting basic read/write
operations on the 32MiB unit working first? We can do 64MiB next, then
INFTL (for 32MiB and then 64MiB).

-- 
dwmw2

  reply	other threads:[~2006-06-10 22:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-08 18:03 DiskOn Chip Millennium Plus 32MB + INFTL Jeff Kalikstein
2006-06-08 18:59 ` Thomas Gleixner
2006-06-08 19:19 ` David Woodhouse
2006-06-09  0:04   ` Husam
2006-06-09  0:18     ` David Woodhouse
2006-06-10 12:21       ` Husam
2006-06-10 22:05         ` David Woodhouse [this message]
2006-06-13 19:42           ` Husam
2006-06-13 19:56             ` David Woodhouse
2006-06-13 20:20               ` Husam
2006-06-13 20:59                 ` Thomas Gleixner
2006-06-20  0:21                   ` Husam
2006-06-20  0:31                   ` Husam
2006-06-26 18:17           ` Husam
2006-06-27 13:41             ` David Woodhouse
2006-08-29 12:20             ` Kalev Lember
2006-08-30  7:12               ` Rüdiger Härtel

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=1149977115.18635.158.camel@shinybook.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=husamsenussi@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