public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Husam <husamsenussi@gmail.com>
To: linux-mtd@lists.infradead.org
Subject: Re: DiskOn Chip Millennium Plus 32MB + INFTL
Date: Fri, 9 Jun 2006 01:04:37 +0100	[thread overview]
Message-ID: <200606090104.37756.husamsenussi@gmail.com> (raw)
In-Reply-To: <1149794376.18635.2.camel@shinybook.infradead.org>

I have device with  DiskOnChip Millennium Plus 64M "2x 32M", so I start making 
changes to nand based driver using the old one but I found the following 
problems:

1. The NAND layer use lookup table to set the size of the page, erase block ..  
etc, but this does work will 32/64M because of interleave.
2. When I set bus width to 16 in diskonchip level nand_scan return an error 
because that doesn't match with table.
3. Reading and writing has to be done in 16 bit otherwise you lose data, 
because MDOC+ 32/64M moves the pointer 2 bytes even if you read one byte.
4. I found that read_buff terminate the read each time, and because of that 
nand_read_ecc skip bytes when read across sections.
5. Layout of the data on the page is different form 16M, but I'm not sure if 
this is specific  to INTFL.  


I had look at the changes you guys made recently and I found that some of 
these change would fix some of the above problems but not all of them,.

My question will be would someboday be able to sumbit patch to you guys to fix 
the above problem.



On Thursday 08 June 2006 20:19, David Woodhouse wrote:
> On Thu, 2006-06-08 at 13:03 -0500, Jeff Kalikstein wrote:
> > and the MTD NAND based driver complains that "DiskOnChip Millennium
> > Plus 32MB is not supported, ignoring.".
>
> This is fixable. The 32MiB unit is just the same as the 16MiB unit
> except that it works in 16-bit mode instead of 8-bit mode, and by
> default does some bizarre interleaving of the data.
>
> Just look for 'interleave' in drivers/mtd/devices/doc2001plus.c and see
> how many places there are where we treat the 16MiB and 32MiB units
> differently -- there aren't that many. Getting this to work in the
> NAND-based driver should be relatively simple.

  reply	other threads:[~2006-06-09  0:04 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 [this message]
2006-06-09  0:18     ` David Woodhouse
2006-06-10 12:21       ` Husam
2006-06-10 22:05         ` David Woodhouse
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=200606090104.37756.husamsenussi@gmail.com \
    --to=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