All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan Simon <BrendanSimon@fastmail.fm>
To: linux-mtd@lists.infradead.org
Cc: Dan Brown <brown@osdsun1.nrl.navy.mil>
Subject: Re: 128MB DOC2000 with 2.4.X kernel
Date: Wed, 11 Aug 2004 11:11:26 +1000	[thread overview]
Message-ID: <4119723E.8050205@fastmail.fm> (raw)
In-Reply-To: <003f01c47aeb$706113d0$0100a8c0@superfortress>

Dear MTD gurus.

Thanks for your feedback Dan.
Summary regarding the 128MB DOC2000:
    1) Cannot use NTFL.  I *must* use INFTL
    2) 128MB DOC2000 is more like a MilleniumPlus device than a DOC2000 
device.
    3) Recommend using 2.6 kernel and latest MTD tree.

Is the 96MB DOC2000 more like the 64MB model or the 128MB model?
i.e. can I use a 96MB DOC2000 with my existing 2.4.18 kernel or will I 
have the same problems as the 128MB DOC.

Many thanks,
Brendan Simon.


Dan Brown wrote:

>----- Original Message ----- 
>From: "Brendan J Simon" <BrendanSimon@fastmail.fm>
>Sent: Wednesday, August 04, 2004 11:51 PM
>
>
>  
>
>>I've just been reading the archives about 128MB DOCs looking like a
>>Millenium device and the soltion being to do 4 reads, etc.
>>    
>>
>
>Just to be absolutely clear:  The reason it looks like a Millennium device
>is that it is (in almost every respect) a Millennium device, from a hardware
>access perspective.  The "solution" you describe allows you to properly
>detect the fact that it is a larger DOC2000, rather than a true Millennium,
>but you still have to talk to it as if it were a Millennium.
>
>  
>
>>If I modify docprobe.c to detect the 128MB DOC2000 correctly, will the
>>rest of the MTD code work correctly with it ???
>>    
>>
>
>Depends on your definition of "correctly".  You may be able to get the stock
>2.4.18 MTD code to read and write your device with the modification you
>describe (or you may not -- I haven't tried it).  However, you'll be missing
>a lot of critical functionality that has been added to the 2.6.8-rc2 kernel
>(and the MTD CVS repository, which is even more up-to-date).
>
>In particular, you won't get proper bad block handling, because your device
>uses INFTL (rather than NFTL), and the 2.4 series do not properly parse
>INFTL bad block tables.  Bad block detection becomes particularly critical
>for larger devices.
>
>  
>
>>I hope so as this would be a quick fix, however I do recall seeing
>>something about 3 and 4 byte addresses.  Is this relevant to getting
>>128MB DOC working with 2.4.X kernels ?
>>    
>>
>
>Not sure.  I doubt the 128MB DOC is big enough to require 4-byte addresses.
>(It depends on whether it's organized as one very large flash chip or
>several -- does anyone know?)
>
>  
>
>>I'm looking for the quickest solution.  Any ideas, comments or
>>suggestions would be greatly appreciated.
>>    
>>
>
>I strongly suggest you put in the effort to switch to the latest kernel
>(2.6.8-rc2 or later).  I'm not certain that your quick fix to 2.4.18 will
>work.  You will certainly not have full functionality -- in addition to
>proper bad block handling, the new DOC drivers under the NAND subsystem
>allow you to use jffs2 cleanly on DOC devices, which you may be interested
>in.
>
>Perhaps most importantly, you'll find people on this list to be much more
>supportive and helpful to someone who is using the latest code.  There's not
>a whole lot of interest in helping people deal with problems that have
>already been fixed in the newer code.
>
>Your best bet may be to grab the latest 2.6 kernel and patch it with the
>latest MTD snapshot; others may disagree.
>
>  
>
>>Is INTFL needed for the 128MB DOC2000 or can I use the NFTL code that I
>>am currently using on the 64MB doc?
>>    
>>
>
>You can't use NFTL.  If you want to use an arbitrary filesystem (such as
>ext2) on your device, you'll have to use INFTL.  Another (better, in my
>opinion) option is to switch to a filesystem that runs directly over the
>flash device, such as JFFS2.  The latest DOC drivers (the NAND subsytem
>reimplementation, not the original stand-alone drivers) finally support this
>cleanly.
>
>Good luck!
>
>    -Dan Brown
>
>  
>

  reply	other threads:[~2004-08-11  1:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05  3:51 128MB DOC2000 with 2.4.X kernel Brendan J Simon
2004-08-05 12:55 ` Dan Brown
2004-08-11  1:11   ` Brendan Simon [this message]
2004-08-11 12:49     ` Dan Brown
2004-08-12  5:27       ` Brendan Simon
2004-09-09  3:16         ` 96MB/128MB " Brendan Simon
2004-09-09 22:44           ` Kurt A. Freiberger

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=4119723E.8050205@fastmail.fm \
    --to=brendansimon@fastmail.fm \
    --cc=brown@osdsun1.nrl.navy.mil \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.