From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nigel Roles" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: RE: [9fans] Writing device drivers Date: Mon, 17 Apr 2006 11:01:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <82b49c6d64ed36c95aa6ee896541f1f5@swtch.com> Topicbox-Message-UUID: 37d5b8ec-ead1-11e9-9d60-3106f5b1d025 9fans-bounces+ngr=9fs.org@cse.psu.edu wrote: >> it looks like all the code for aic-7xxx is in the linux kernel tree, >> including an assembler. >> >> does anybody know what processor it uses? > > it probably doesn't matter. it's unlikely that the > microcode is written in a real processor's assembly > language. usually it is a virtual processor defined > by the card. Originally Adaptec has an on-board 8035 which presented a mailbox (aka scb (aka Scsi Command Block)) interface to the host. You load up the command block, enable it, and wait for an interrupt. The firmware was fixed in an EPROM next door. This conforms to Russ'es idea that it is a virtual processor. Later, the firmware became downloadable to local ram in a cpu which implemented the scbs directly, plus enough flow control to allow the controller to manage many concurrent transfers without host intervention. So, the aic-7xxx series are real processors (at least a real as they ever get given that Intel processors still have microcode engines are therefore in some senses virtual). The story for the NCR/Symbios/LSI Logic controllers is similar; at first they were hard-wired and the CPU did all the sequencing, then a SCSI specific CPU was added (silicon designers would call it a programmable sequencer) which read its instructions over the bus and gave it more offload capability. Finally, the firmware got stored in local RAM because it ran too slowly when competeing with the data transfers over the same bus. SCSI processors are highly specialised, being excellent at DMA and able to guarantee the tight bus timings, but struggling to add two numbers together. They are a nightmare to debug because debugging usually results in the SCSI bus timing being violated and the targets take their bats home. None of the current cards will use general purpose processors. It may well be practical to borrow the Linux aic firmware, but the result will be ugly as the match between a Linux scsi driver and a Plan 9 scsi driver is not strong. It's the usual argument I see around here; compare the Symbios driver in Linux with that in Plan 9. If you want 90% of the functionality for 10% of the code, learn the firmware assembler and do something that fits the scale of Plan 9. If you just want a aic driver in the shortest possible time, then using known good firmware will no doubt help. I did make a start on an aic driver with the intention of doing Plan 9 specific firmware. I ported the Linux assembler but the effort is lost in the mists of time. It turned out that after doing the Symbios driver, I really couldn't be arsed to fight a firmware processor again. You really have to understand SCSI at the bus level, and to be honest having a bus analyser to hand would be a good idea.