128MB DOC2000 with 2.4.X kernel

128MB DOC2000 with 2.4.X kernel

[Brendan J Simon]

I've just been reading the archives about 128MB DOCs looking like a 
Millenium device and the soltion being to do 4 reads, etc.
The 2.4.26 kernel doesn't support this device but I see that the 2.6.X 
kernels do.

If I modify docprobe.c to detect the 128MB DOC2000 correctly, will the 
rest of the MTD code work correctly with it ???
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 ?

To summarise, I have an embedded board with a 64MB DOC2000 and a 2.4.18 
kernel.  I need to have a 128MB DOC2000 working on it pretty quickly and 
am considering the options of making a few source code changes to the 
2.4.18 kernel or porting a newer 2.6.x kernel to the embedded board.  
I'm looking for the quickest solution.  Any ideas, comments or 
suggestions would be greatly appreciated.

Is INTFL needed for the 128MB DOC2000 or can I use the NFTL code that I 
am currently using on the 64MB doc?

Many thanks,
Brendan Simon.

Re: 128MB DOC2000 with 2.4.X kernel

[Dan Brown]

----- 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

Re: 128MB DOC2000 with 2.4.X kernel

[Brendan Simon]

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
>
>  
>

Re: 128MB DOC2000 with 2.4.X kernel

[Dan Brown]

----- Original Message ----- 
From: "Brendan Simon" <BrendanSimon@fastmail.fm>
Sent: Tuesday, August 10, 2004 9:11 PM


> Summary regarding the 128MB DOC2000:
>     1) Cannot use NTFL.  I *must* use INFTL

Or a filesystem that runs directly on flash, such as jffs2 or yaffs.

>     2) 128MB DOC2000 is more like a MilleniumPlus device than a DOC2000
> device.

I think you mean Millennium.  Millennium Plus is another beast entirely :)

>     3) Recommend using 2.6 kernel and latest MTD tree.

This would still be my recommendation, however, there has been some effort
in the last few days to allow the latest MTD code to compile under the 2.4
series.  If you're dead-set against switching to 2.6, it might be worth your
time to grab the latest MTD snapshot, patch your 2.4 kernel using the
included script, and see what happens.  No promises.

> 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.

Take a look at the file "DiskOnChip Software Utilities.pdf", distributed by
M-Systems as part of their free DOS driver download.  Table 1 (on page 4)
discusses which parts use NFTL and which use INFTL.  Quoted below:

NFTL [NAND Flash Translation Layer] M-Systems' patented algorithm, used by
the TrueFFS driver for the following devices:

- Most models of DiskOnChip 2000 (see excluded models below).

- DiskOnChip Millennium 8Mbytes.

INFTL [Inverse NAND Flash Translation Layer] M-Systems' latest flash
management algorithm, used by the TrueFFS driver for the following devices:

- DiskOnChip Millennium Plus

- Mobile DiskOnChip Plus

- DiskOnChip 2000 DIP (high), 384Mbytes and higher.

- DiskOnChip 2000 DIP (low), 192Mbytes and higher.


If I had reviewed this table before I responded to your email, I would have
noticed that the 128M DOC ought to use NFTL.  Are you sure you have a part
that "looks like a Millennium"?  (All DOC2000 parts that use the Millennium
hardware interface also use INFTL, and vice versa.)  I'm willing to believe
the MSYS docs I have might be out of date (I'm pretty sure the
low-profile/high-profile boundary has changed), but it would be good to
confirm this.


    -Dan

Re: 128MB DOC2000 with 2.4.X kernel

[Brendan Simon]

Dan Brown wrote:

>>    3) Recommend using 2.6 kernel and latest MTD tree.
>>    
>>
>This would still be my recommendation, however, there has been some effort
>in the last few days to allow the latest MTD code to compile under the 2.4
>series.  If you're dead-set against switching to 2.6, it might be worth your
>time to grab the latest MTD snapshot, patch your 2.4 kernel using the
>included script, and see what happens.  No promises.
>  
>
Depends whether it would patch to 2.4.18 sucessfully or whether it is 
designed to patch to 2.4.26 or 2.4.27.  If I have to do work to get it 
to patch, then the time might be better spent porting 2.6.x to my board :)

>>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.
>>    
>>
>INFTL [Inverse NAND Flash Translation Layer] M-Systems' latest flash
>management algorithm, used by the TrueFFS driver for the following devices:
>
>- DiskOnChip Millennium Plus
>- Mobile DiskOnChip Plus
>- DiskOnChip 2000 DIP (high), 384Mbytes and higher.
>- DiskOnChip 2000 DIP (low), 192Mbytes and higher.
>
>If I had reviewed this table before I responded to your email, I would have
>noticed that the 128M DOC ought to use NFTL.  Are you sure you have a part
>that "looks like a Millennium"?  (All DOC2000 parts that use the Millennium
>hardware interface also use INFTL, and vice versa.)  I'm willing to believe
>the MSYS docs I have might be out of date (I'm pretty sure the
>low-profile/high-profile boundary has changed), but it would be good to
>confirm this.
>  
>
I can confirm that the 128MB DOC I received in Australia definately DOES 
NOT work.  i.e. it looks like it has the new ASIC embedded in it.  A 
friend of mine in the USA also sees the same thing on his newly received 
128MB DOC.  Therefore I think the M-System docs are wrong.

Anyone know about the 96MB DOC2000 ????
Is it an old style or new style DOC2000 ????

Cheers,
Brendan Simon.

Re: 96MB/128MB DOC2000 with 2.4.X kernel

[Brendan Simon]

Brendan Simon wrote:

>
>>> 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.
>>>   
>>
>> INFTL [Inverse NAND Flash Translation Layer] M-Systems' latest flash
>> management algorithm, used by the TrueFFS driver for the following 
>> devices:
>>
>> - DiskOnChip Millennium Plus
>> - Mobile DiskOnChip Plus
>> - DiskOnChip 2000 DIP (high), 384Mbytes and higher.
>> - DiskOnChip 2000 DIP (low), 192Mbytes and higher.
>>
>> If I had reviewed this table before I responded to your email, I 
>> would have
>> noticed that the 128M DOC ought to use NFTL.  Are you sure you have a 
>> part
>> that "looks like a Millennium"?  (All DOC2000 parts that use the 
>> Millennium
>> hardware interface also use INFTL, and vice versa.)  I'm willing to 
>> believe
>> the MSYS docs I have might be out of date (I'm pretty sure the
>> low-profile/high-profile boundary has changed), but it would be good to
>> confirm this.
>>  
>
> I can confirm that the 128MB DOC I received in Australia definately 
> DOES NOT work.  i.e. it looks like it has the new ASIC embedded in 
> it.  A friend of mine in the USA also sees the same thing on his newly 
> received 128MB DOC.  Therefore I think the M-System docs are wrong.
>
> Anyone know about the 96MB DOC2000 ????
> Is it an old style or new style DOC2000 ????


A colleague of mine just tested a 96MB DOC and he says that it works 
perfectly with the 2.4 kernel.
i.e. it is correctly detected as a DOC2000 device.

Brendan Simon.

Re: 96MB/128MB DOC2000 with 2.4.X kernel

[Kurt A. Freiberger]

Brendan Simon wrote:
> Brendan Simon wrote:
> 
>>
>>>> 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.
>>>>   
>>>
>>>
>>> INFTL [Inverse NAND Flash Translation Layer] M-Systems' latest flash
>>> management algorithm, used by the TrueFFS driver for the following 
>>> devices:
>>>
>>> - DiskOnChip Millennium Plus
>>> - Mobile DiskOnChip Plus
>>> - DiskOnChip 2000 DIP (high), 384Mbytes and higher.
>>> - DiskOnChip 2000 DIP (low), 192Mbytes and higher.
>>>
>>> If I had reviewed this table before I responded to your email, I 
>>> would have
>>> noticed that the 128M DOC ought to use NFTL.  Are you sure you have a 
>>> part
>>> that "looks like a Millennium"?  (All DOC2000 parts that use the 
>>> Millennium
>>> hardware interface also use INFTL, and vice versa.)  I'm willing to 
>>> believe
>>> the MSYS docs I have might be out of date (I'm pretty sure the
>>> low-profile/high-profile boundary has changed), but it would be good to
>>> confirm this.
>>>  
>>
>>
>> I can confirm that the 128MB DOC I received in Australia definately 
>> DOES NOT work.  i.e. it looks like it has the new ASIC embedded in 
>> it.  A friend of mine in the USA also sees the same thing on his newly 
>> received 128MB DOC.  Therefore I think the M-System docs are wrong.
>>
>> Anyone know about the 96MB DOC2000 ????
>> Is it an old style or new style DOC2000 ????
> 
> 
> 
> A colleague of mine just tested a 96MB DOC and he says that it works 
> perfectly with the 2.4 kernel.
> i.e. it is correctly detected as a DOC2000 device.
> 
> Brendan Simon.

I have trie the DOC2000 with both 2.4 and 2.6 kernels.  It seems to be 
detected correctly, but I get a message about it being "temporarily 
unavailable".  What gives?

Thanks,
Kurt

-- 
Kurt A. Freiberger     Austin, TX	kurt@badgers-hill.net
Amateur Radio Callsign WB5BBW  		AIM Handle: WB5BBW
"Some people are like Slinkys - Generally considered useless, but
  you can't help smiling when you see them falling down the stairs."