From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 31 May 1997 11:57:30 +1000 From: David Hogan dhog@lore.plan9.cs.su.oz.au Subject: Adaptec 2940 (buy NCR/Symbios) [long] Topicbox-Message-UUID: 5b83d520-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19970531015730.j7KUW3dNWtmX-ZVd2Yh0wFH4LiSZ-SqjCu83XcZ8h5s@z> > Before I talk about the Adaptec AIC7xxx series, I would like to back up > forsyth's kind comments about the Symbios/NCR driver. If you don't have > an explicit need for an Adaptec controller, then the Symbios/NCR route > is cheaper, and higher performance. The Symbios 8751 Ultra Wide > controller now costs 110 quid here, whilst Adaptec is pushing 200 quid > for equivalents. I can't make comparisons under Plan 9, but under NT > commerical projects here have found 30% throughput, and better > reliability by switching to Symbios cards. Well, it looks like I should have done some research before I forked out the cash :-) > So why would I want to do an Adaptec driver? It's all Uncle Bill's > fault. Under Win95, the only well documented generic SCSI layer is the > ASPI layer which was invented by Adaptec (though they claim the A stands > for Advanced). It is possible to use the miniport layer (and hence drive > any controller) but few applications do (Seagate Backup for WIn95 is an > example) and the documentation seems to be designed to convince you that > it only works under NT so it's difficult to believe any part of it. As a > result, anyone writing software for SCSI will support one proprietary > controller directly, and then ASPI. This is the case with TWAIN drivers > for scanners. Since scanners tend to have manufacturer specific > extensions, each model has it's own TWAIN driver to do the twiddly bits. > These drivers talk to either the crappy card shipped with the scanner, > or ASPI. Easy solution -- don't use Win95! :-) > I've been in touch with the Linux/FreeBSD guys who were great. I have a > full reading list for Adaptec. You think you only need one manual. It > looked like about 10. I've only ordered 2... Of course, I'm only interested in the 7880 chip, perhaps you need more if you're supporting all the other variants as well. > The AIC chip runs microcode much like the NCR, except that there is an > on-board copy which can be replaced by download. Apparently, Adaptec > will not document the microcode except under NDA, so Linux/FreeBSD has > it's own. The microcode sequencer is better than NCRs (it avoids several > big mistakes). The microcode reproduces the control block concept that > is used by the unreplaceable (should that be irreplaceable) 8085 machine > code on the 1540 ISA cards. This suggests to me that we could borrow the > FreeBSD sequencer, and 'adapt' (ha ha ha) the existing Plan9 aha154x > driver. Yep, that's one way of doing it. This would get us up and running the fastest. I wonder though whether further performance gains might not be achieveable through the use of microcode which is tailored toward use with Plan 9. There are probably some "dirty tricks" with the buffer management which would work here. I need those docs :-) Another question I've been thinking about is whether it is better to compile the microcode at kernel compile time (like the FreeBSD driver does) or at device initialization time. In the later case, the microcode could be tuned for the specific type of card (ie leave out support for features it doesn't have, etc). The driver could also wire static addresses of command queues into the microcode, etc. > There's the usual load of crud to identify the card, download code, read > and write a microwire EEPROM, patch up for the fact that some wide > controllers actually are two AIC controllers bolted together, etc etc I have some code for identifying my card :-) I'm rewriting the PCI support, I will try to make it available when I've finished. Bolting two controllers together sounds like a complete nightmare! How do they maintain synchronization? Won't the data need to be split/interleaved (depending whether you are writing or reading)? Yuck yuck yuck...