DiskOnChip 2000/Millennium driver merge.
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 [email protected]
Quoted 3 lines · [email protected] said:
If anyone else with Millennium hardware could take a look at the
differences betweendoc2000.canddoc2001.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 [email protected]
Quoted 3 lines · [email protected] 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 [email protected]
Quoted 16 lines · 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_DRIVERin 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_DRIVERindocprobe.cand continue to use the doc2001 module.
Quoted 9 lines
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.canddoc2001.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 ofdoc2000.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 [email protected]
Quoted 7 lines · Ollie Lho
David,
I just tried the updated CVS version. The Millennium part ofdoc2000.cworks 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?
Signature · 6 lines
dwmw2 To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 16 lines · David Woodhouse
Quoted 7 lines · Ollie Lho
David,
I just tried the updated CVS version. The Millennium part ofdoc2000.cworks 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.csince the Millennium support was merged intodoc2000.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?
Quoted 5 lines
I note you changed
DoC_Command()so it no longer finishes withDoC_WaitReady(). Is there a situation in whichDoC_Commandshouldn't wait forFR_Bafter 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 [email protected]