RE: [9fans] Writing device drivers

["Nigel Roles" <nigel@9fs.org>]

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.