On Thu, 4 Nov 1999, Jason Thorpe wrote:

> On Thu, 4 Nov 1999 13:57:24 -0800 
>  Matthew Jacob <mjacob@feral.com> wrote:
> 
>  > Because what I did was wrong. It should also be removed from OpenBSD.
>  > I've had extensive discussions with Theo about this, and the f/w will
>  > probably be removed from OpenBSD as soon as the tree unlocks post 2.6.
>  > Unless Qlogic agrees to a BSD style licence. So far, they've not been
>  > helpful at all.
> 
> So, OpenBSD is going to ship software with known bogus license terms?
> Someone should report this to Qlogic, Corp. so that they have a change
> to defend their intellectual property.

No- Actually Theo just got through making it clear that *all* of the ISP
driver support would be pulled from OpenBSD if they didn't quit farting
around. It appears based upon mail I just got from Qlogic that they have
agreed to allow the use of *BSD licences. That'd be good. If you see the
f/w go back into the trees in the next day or so, that'll mean all is well
again.

> 
>  > I think it's a huge pain, but it really should not have been handled
>  > the way I handled it so far.
> 
> ...especially considering that a fair number of previously happy
> Qlogic ISP users now have completely useless boards.

No, that's not correct either. Here's an editted copy of what I sent to
board@netbsd.org explaining what the ramifications of removing the
firmware were:

=============================================================================


What you'll get now for SBus and PCI versions is whatever is both resident
on the card *and has been set running by the firmware* (i.e., loaded
from (relatively undocumented) flashram to SRAM and the RISC processor
reset (no doubt with the same copyrights embedded in it, but distributed
with the h/w, not the s/w...:-().

-------
The implications of this are as follows:

+ SCCLUN/FABRIC Fibre Channel feature sets are not likely to be available,
as these are not resident on the 2100/2200 cards. It is possible to
programmatically determine whether fabric support exists by attempting to
get a port database entry for the fabric name server (if that fails,
you're either on a private loop or you don't have fabric support in the
firmware). As yet I have not figured out a way to programmatically
determine whether SCCLUN (65535 lun) is enabled or not.

+ Target mode support will be unavailable, as this is not likely to be in
the resident f/w.

+ It is unlike that any fibre channel cards will work on non-BIOS
platforms. The more recent Alpha SRMs claim to understand the 2100 (but
not the 2200)- but as best as I can tell, don't set the resident f/w
running.

+ All SBus cards will fall back to whatever is resident. This is now about
6 years old and buggy. It may or may be true that UltraSCSI SBus cards
will work. I don't know.

+ All the feature sets for newer Fibre Channel and parallel SCSI that are
available in newer firmware (fast posting interrupts, better port database
management, other things) will not be available. What this may or may not
mean practically, I don't know. I've always tried limit certain features
based upon firmware level, but that may be broken in subtle ways.

+ By the same token, I have never done much testing *w/o* loading f/w.
We'll have to see what transpires.

The net effect of all of this, in my opinion, is that the isp driver will
mostly work, but NetBSD will no longer be a candidate for any serious
development or leading edge work certainly in Fibre Channel until this is
somehow fixed. Certainly not for anything like working with target mode or
SAN development.

-----

The technical work I was planning was:

	+ Determination/Documentation of how to burn new f/w into the
	card using f/w and/or tools publicly available from Qlogic's
	website.

	I have the f/w on my ftp/website. *I'm* not worried about the
	legal folderol. Maybe foolishly, maybe not. Maybe I'll just
	docuemnt where it can all be found. Hell, some of it's on the
	Qlogic website under Beta drivers for linux (which I now cannot
	find again! I know it's there... somewhere...)

	+ Determination of how to get extract resident f/w from flashram
	and get it downloaded into SRAM so that cards not started by by
	OBP or SRM could still be made to work.

Ideally, the f/w should not have to be hauled along and downloaded each
reboot anyway as it's quite bulky. From a pragmatic and usage point of
view, any utility that you have to run out of band to perform brain
surgery on your hardware makes that hardware unattractive and you won't
use it unless you have to.
=============================================================================