Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Apr 1998 17:38:27 -0600 (MDT)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        schofiel@xs4all.nl
Cc:        hardware@FreeBSD.ORG
Subject:   Re: Ooops - sorry
Message-ID:  <199804292338.RAA28319@narnia.plutotech.com>
In-Reply-To: <3547389F.121E@xs4all.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <3547389F.121E@xs4all.nl> you wrote:
> The chipsets Adaptec sell/use have got the capability to operate either
> as SCSI Host or SCSI Target, and carry out a lot of the bus bit bashing
> previously done in software using a hardware state machine. The mode is
> not hard-coded by a jumper, but determined by the software driving the
> chip. This you will know from writing a SCSI subsystem; I have a dead
> Seagate and an HP drive in front of me with ADAPTEC writ large across
> many of the chips on the PCB of the disk controller.

The parts Adaptec sells to device vendors are designed for target
applications only.  They are rarely the same parts that are developed
for HBAs.  Adaptec has a long history of "providing" for target mode
in their HBA chips, but never testing it.  My understanding is that
they did develop target mode drivers for the aic7880 internally and
they sell them to certain third party integrators, but other than
this development and the support for target mode in the 1542B (result
of a NASA contract I believe), Adaptec has rarely supported target
mode for their HBAs.  Even today I received some mail from a fellow
who developed a target mode driver for the 2944 (differential 2940) and
found out that there was a bug in this card that caused problems for
target mode that Adaptec was unwilling to fix.  He did get a "cut this
line, insert jumper here" kind of solution from them, but it was fairly
obvious that they never tested the target mode features of their
differential products.

> Ah, now I can correct you here; I have successfully worked on two
> PC-based projects where a 1510 and a 1740 were used in target mode, so
> the *hardware at least* does. Whether, as you rightly say, the PC- based
> BIOS provided with these cards actually implements this mode or not (and
> for any other SCSI device class other than Disk, at that) is another
> question; we didn't use it - simply disabled the BIOS, got a register
> map and the right data sheet for the chips on the cards, and wrote our
> own drivers, which were then successfully tested under the operating
> system we were using (OS-9000).

You were very lucky that the hardware worked as specified.

> I have no idea what implementation method you were using for this, but
> it would still boil down to getting a register address map for the
> chipset, an address map for the host card from the manufacturer (Adaptec
> were quite happy to let us have the developer docs when we asked) and
> getting down to it. Whether the host adapter circuitry is designed to
> allow full use of the chipset's capabilities is a different matter, and
> I can't comment for the 1542; however, the ISA part (the bus interface)
> of this card had some definite limitations, which you may have hit
> against. If I hear another anguished story about "ISA Bus Mastering" I
> will scream - that was why EISA appeared...

For many applications, doing all of the protocol management from
the kernel is simply too slow.  Luckily many of the newer chips
allow you to write and download your own firmware so you can provide
target mode yourself if the vendor doesn't support.  I need to be
able to saturate a wide Ultra2 connection (80MB/s) for the target
mode applications I'm interrested in.

>>we are NOT using it as they won't give source..
> 
> No defintiely, they won't *give* you the ASPI sources for their
> commercially available, main income source. Would you? ;^) However, if
> you asked them for the developer's packages and ASPI specs, well,
> they'll let you have that. Maybe I was just lucky when I asked, I got
> all my stuff for free in '95....

ASPI is too inflexible.  That is why it was not chosen as the spec for
the new FreeBSD SCSI layer.  We're implementing CAM instead.

> Tell me, why use the firmware? I thought this was U**X? Why on earth do
> you need to use the card firmware? 

If you don't perform some onboard processing, you will never achieve the
maximum performance that adapter can provide.  Remember also that
Firmware != BIOS.

--
Justin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804292338.RAA28319>