Skip to contentSkip to conversation

DiskOnChip 2000/Millennium driver merge.

DISCUSSION David Woodhouse 2 participants 6 messages Dec 1, 2000 – Dec 4, 2000 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

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]

#1 lore raw
Quoted 3 lines · [email protected] 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 [email protected]

#2 lore raw
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]

#3 lore raw
In reply to David Woodhouse
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_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.

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.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 [email protected]

#4 lore raw
Quoted 7 lines · Ollie Lho

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?

Signature · 6 lines
dwmw2




To unsubscribe, send "unsubscribe mtd" to [email protected]
#5 lore raw
Quoted 16 lines · David Woodhouse
Quoted 7 lines · Ollie Lho

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?

Quoted 5 lines

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 [email protected]