Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Dec 1999 19:47:18 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        Jason Thorpe <thorpej@nas.nasa.gov>
Cc:        Wilko Bulte <wilko@yedi.iaf.nl>, gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG
Subject:   Re: ISP firmware compiled in as a default.... 
Message-ID:  <Pine.BSF.4.05.9912041938020.368-100000@semuta.feral.com>
In-Reply-To: <199912050332.TAA16773@lestat.nas.nasa.gov>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sat, 4 Dec 1999, Jason Thorpe wrote:

> On Sat, 4 Dec 1999 11:43:39 -0800 (PST) 
>  Matthew Jacob <mjacob@feral.com> wrote:
> 
>  > Jason (bless his heart) Thorpe kept on claiming that NetBSD-alpha was
>  > completely broken without the f/w- I never saw such breakage at all and
>  > real active details were not provided, and in fact *you* (Wilko) are the
>  > only one who I know was completely blocked w/o the f/w.
> 
> Oh, c'mon.  The whole reason you started always downloading the firmware
> into the ISP is because cgd reported to you that the SRM's ISP firmware
> on his AlphaStation 500 didn't play nice with the NetBSD driver.  I'm
> pretty sure I have an archive of the e-mail conversation (which was all
> CC'd to me).

Nope, I don't think so. I pretty much always had been downloading f/w.
There was a hop skip and dance with some f/w and Chris's machine and some
stupid ass bugs in 7.55 f/w where you'd tell it to renegotiate and then
ask it what it had done and it lied and gave back random values.

> 
> And, I'm pretty sure there's actually a PR in the database about a
> PC164 user having to back-rev his machine to before the firmware was
> yanked because his ISP no longer worked after a *power-cycle* (i.e. the
> RAM on the card lost power, and the SRM-loaded firmware was not functional
> with the NetBSD driver).

Yep. But I've concluded that this wasn't a Digital supplied board (and
closed the PR) so the SRM wasn't starting it.

> 
> Not only that, but users of CATS boards (arm32) were completely left out
> in the cold; the firmware on those machines doesn't run the ISP BIOS, and
> thus had no way of loading in the firmware into the card.  The portmaster
> went as far as to yank the "isp" driver out of the example kernel config
> files in that port.

So I saw. I never claimed it was not completely broken in some cases.
For example, if there was a sparc64/PCI port going, it'd be mostly broken
there because only PTI PCI cards have fcode that gets the f/w started.

Read what I wrote above. You claimed NetBSD-alpha was completely broken.
But neglected to provide details. It wasn't completely broken, but it's
been problematic in a number of cases.


> ...or don't you read the `source-changes' mailing list?

Nope- the netbsd changes list is too hard to read.

> 
> Anyhow, the arm32 case will happen on *ANY* platform who's firmware
> doesn't natively understand the ISP.  So, not loading the firmware by
> default screws over anyone who tries to put it in an arm32, macppc,
> Atari Hades, etc.

Yup. Such is life and too bad. It is now corrected by being able to have
the f/w back in. I've also said that if I can get more information out of
Qlogic I can figure out how to extract the onboard firmware in flashram
down into sram on the card and get it going if the BIOS hasn't.

> 
> Now, you could do something like have #ifdefs for each firmware,
> i.e.
> 
> #ifdef ISP_1020_FIRMWARE
> 
> ...
> 
> #ifdef ISP_1080_FIRMWARE
> 
> ...
> 
> #ifdef ISP_2100_FIRMWARE
> 
> ...actually, I just noticed... there's already ISP_DISABLE_..._SUPPORT
> #ifdefs in there.  Why not key on those?

I do have "compile in these" f/w selectors, and an overall "compile in all
f/w" selectors. The NetBSD integration, respecting your unexplained
concerns, wraps *around* this by defining ISP_COMPILE_FW in isp_netbsd.h.

If I had time to blow on it, it would be a lot better. The subject under
discussion *here* is whether to have freebsd follow the settings for
NetBSD and compile/load it by default.


-matt




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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9912041938020.368-100000>