Re: DiskOnChip 2000/Millennium driver merge.

Re: DiskOnChip 2000/Millennium driver merge.

[Miguel Freitas]

Ollie Lho wrote:

> > I note you changed DoC_Command() so it no longer finishes with
> > DoC_WaitReady(). Is there a situation in which DoC_Command shouldn't
> > wait for FR_B after sending the command? Does it do any harm to do
> > so, or is the removal just an optimisation?
> >
> 
> The reason that I removed DoC_WaitReady() for DoC_Command() is you are
> using DoC_Command to find how many flash chip on a single DoC. If
> there is no more chip, the ready bit will never get high. And the
> driver hangs.
> 
> Ollie

   Hummm, this is a little off-topic, but you have just explained me 
why my PIC routines to access DOC2000 were hanging!!! I saw 
exactly this with a logic analiser, but when using the same DOC on a 
PC it worked, don't ask me why...(and it never left the WaitReady by 
timeout)


Miguel Freitas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: DiskOnChip 2000/Millennium driver merge.

[David Woodhouse]

miguel@cetuc.puc-rio.br said:
> 
>    Hummm, this is a little off-topic, but you have just explained me
> why my PIC routines to access DOC2000 were hanging!!! I saw  exactly
> this with a logic analiser, but when using the same DOC on a  PC it
> worked, don't ask me why...(and it never left the WaitReady by
> timeout) 

On a reasonably fast PC, the WaitReady will timeout and you won't lock 
forever. I think we could just change the timeout to something more 
appropriate - rather than a fixed number of loops, repeat until jiffies has 
increased by a certain number of ticks.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: DiskOnChip 2000/Millennium driver merge.

[Vadim Khamlinsky]

>Of course it works if I turn off CONFIG_MTD_DOCPROBE_55AA

Diskonchip 2000  always has 55aa signature at the beginning of 
the DiskOnChip window . DiskOnChip Millennium does not .
I'm not going to get into the hardware differences between these two
products . From the software point of view it depends on the DiskOnChip
Millennium low-level format .
If it was formatted with the following command :
  dformat /win:d000 /s:docxxx.exb  , then you should find 55AA signature .
If it was formatted as follows :
   dformat /win:d000 /s:docxxx.exb 

or docxxx.exb was somehow removed from the DiskOnChip Millennium
you will not see 55AA .
In short, don't depend on the 55aa probe when you work with
DiskOnChip-Millennium .

Regards,
Vadim  
 
  


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

DiskOnChip 2000/Millennium driver merge.

[David Woodhouse]

I've now cleaned up some of the differences between the new combined 
doc200[01] driver and the doc2001-only driver, and enabled 
DOC_SINGLE_DRIVER in the docprobe code.

I haven't removed the conditional stuff for two reasons -
	1. Ollie wants to keep the separate doc2001 driver for easier
		development and testing
	2. The doc2000 driver doesn't actually _work_ for writing. It
		exhibits the same behaviour with both types of device -
		writes to NFTL just don't appear to _stay_ written.

If you need write support for the Millennium right now, just comment out
the definition of DOC_SINGLE_DRIVER in docprobe.c and continue to use 
the doc2001 module.

As the doc2001 driver is working fine, I'm fairly sure it's a hardware
driver problem, not an NFTL code problem. Writes to the main body of the
flash appear to work too, so I currently suspect that it's an OOB data write
problem. 

If anyone else with Millennium hardware could take a look at the 
differences between doc2000.c and doc2001.c, especially Ollie who actually 
knows what he's doing, that'd be very much appreciated.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: DiskOnChip 2000/Millennium driver merge.

[David Woodhouse]

dwmw2@infradead.org said:
>  If anyone else with Millennium hardware could take a look at the
> differences between doc2000.c and doc2001.c, especially Ollie who
> actually  knows what he's doing, that'd be very much appreciated.

I think it's fixed. It now works on the DiskOnChip2000 - the culprit was 
the change to make doc_write_ecc() actually write the ECC data rather than 
just putting it into a buffer for the caller to subsequently write out.

Just continuing to write bytes to the IO register got it working on the 
Millennium. Not on the 2000, though. I had to change it to store the data 
and call doc_write_oob() at the end of doc_write_ecc() in order to make it 
work on the 2000.

I expect that to continue to work on the Millennium, but unfortunately I 
seem to have blown mine up - docprobe can't even see it any more :(

The combined 2000/Millennium driver now ought to be completely working.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: DiskOnChip 2000/Millennium driver merge.

[David Woodhouse]

dwmw2@infradead.org said:
>  I expect that to continue to work on the Millennium, but
> unfortunately I  seem to have blown mine up - docprobe can't even see
> it any more :(

OK, I hereby declare myself to by Today's Official Mr F*** All Good.

Of course it works if I turn off CONFIG_MTD_DOCPROBE_55AA

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: DiskOnChip 2000/Millennium driver merge.

[Ollie Lho]

David Woodhouse wrote:
> 
> I've now cleaned up some of the differences between the new combined
> doc200[01] driver and the doc2001-only driver, and enabled
> DOC_SINGLE_DRIVER in the docprobe code.
> 
> I haven't removed the conditional stuff for two reasons -
>         1. Ollie wants to keep the separate doc2001 driver for easier
>                 development and testing
>         2. The doc2000 driver doesn't actually _work_ for writing. It
>                 exhibits the same behaviour with both types of device -
>                 writes to NFTL just don't appear to _stay_ written.
> 
> If you need write support for the Millennium right now, just comment out
> the definition of DOC_SINGLE_DRIVER in docprobe.c and continue to use
> the doc2001 module.
> 
> As the doc2001 driver is working fine, I'm fairly sure it's a hardware
> driver problem, not an NFTL code problem. Writes to the main body of the
> flash appear to work too, so I currently suspect that it's an OOB data write
> problem.
> 
> If anyone else with Millennium hardware could take a look at the
> differences between doc2000.c and doc2001.c, especially Ollie who actually
> knows what he's doing, that'd be very much appreciated.
> 

David,
	I just tried the updated CVS version. The Millennium part of 
doc2000.c works for some extend. It has some bugs which will offset/lost
1 or 2 bytes at begin/end of each 512byte page. It is a common problem if
you are not programming the chip fully comply to M-Systems Spec (actually
you have to do some "undocumented" tricks too). I will review the new code
next week possiblly after you get the SiS 630 LinuxBIOS demo/devel platform.

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: DiskOnChip 2000/Millennium driver merge.

[David Woodhouse]

On Sat, 2 Dec 2000, Ollie Lho wrote:

> David,
> 	I just tried the updated CVS version. The Millennium part of
> doc2000.c works for some extend. It has some bugs which will offset/lost
> 1 or 2 bytes at begin/end of each 512byte page. It is a common problem if
> you are not programming the chip fully comply to M-Systems Spec (actually
> you have to do some "undocumented" tricks too). I will review the new code
> next week possiblly after you get the SiS 630 LinuxBIOS demo/devel platform.

Thanks. I'll go through the driver and look for the remaining differences.
Were these changes made in doc2001.c since the Millennium support was
merged into doc2000.c, or did they get lost in the merge? If the former,
do you remember the entry in the CVS log that I should be looking for?

I note you changed DoC_Command() so it no longer finishes with
DoC_WaitReady(). Is there a situation in which DoC_Command shouldn't wait
for FR_B after sending the command? Does it do any harm to do so, or is
the removal just an optimisation?

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: DiskOnChip 2000/Millennium driver merge.

[Ollie Lho]

David Woodhouse wrote:
> 
> On Sat, 2 Dec 2000, Ollie Lho wrote:
> 
> > David,
> >       I just tried the updated CVS version. The Millennium part of
> > doc2000.c works for some extend. It has some bugs which will offset/lost
> > 1 or 2 bytes at begin/end of each 512byte page. It is a common problem if
> > you are not programming the chip fully comply to M-Systems Spec (actually
> > you have to do some "undocumented" tricks too). I will review the new code
> > next week possiblly after you get the SiS 630 LinuxBIOS demo/devel platform.
> 
> Thanks. I'll go through the driver and look for the remaining differences.
> Were these changes made in doc2001.c since the Millennium support was
> merged into doc2000.c, or did they get lost in the merge? If the former,
> do you remember the entry in the CVS log that I should be looking for?
> 
> I note you changed DoC_Command() so it no longer finishes with
> DoC_WaitReady(). Is there a situation in which DoC_Command shouldn't wait
> for FR_B after sending the command? Does it do any harm to do so, or is
> the removal just an optimisation?
> 

The reason that I removed DoC_WaitReady() for DoC_Command() is you are using
DoC_Command to find how many flash chip on a single DoC. If there is no more
chip, the ready bit will never get high. And the driver hangs.

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org