Date: Thu, 4 Nov 1999 17:21:18 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: wilko@yedi.iaf.nl, adsharma@home.com, Bulte@feral.com, current-users@netbsd.org, freebsd-hackers@FreeBSD.ORG, jmb@hub.freebsd.org, Wilko@feral.com Subject: Re: FreeBSD FibreChannel support Message-ID: <Pine.LNX.4.04.9911041709020.4987-100000@feral.com> In-Reply-To: <199911042201.OAA17952@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9911041709020.4987-100000>