From owner-freebsd-alpha Sun Nov 21 5:53:28 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 2E9A7157BB; Sun, 21 Nov 1999 05:53:03 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id OAA24865; Sun, 21 Nov 1999 14:28:52 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id NAA37853; Sun, 21 Nov 1999 13:28:18 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911211228.NAA37853@yedi.iaf.nl> Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: from Matthew Jacob at "Nov 20, 1999 2:46:47 pm" To: mjacob@feral.com Date: Sun, 21 Nov 1999 13:28:18 +0100 (CET) Cc: gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > > I have an excellent case that (copyrights aside) this should be possible > > (putting the f/w in the driver): > > > > my machine is an Aspen Alpine, which has EB64+ firmware running. It runs > > the latest SRM available (which is ancient) and to add to the problem it > > has the SRM in EPROM, not in flash. > > Tsk. Right, tsk. ;-) > > > the driver supports multiple cards with multiple f/w sets, the f/w was > > > beggining to add 100KB to the driver.... completely outta hand...). > > > > Big, I agree. But I rather have a bigger kernel than a panic :-( > > We're talking 192KB big. I know... :-( > > > > recent version. Modern revs of the srm console tend to load 5.x of > > > > the qlogic firmware which might help you. I'm running with 5.54.1 on > > > > a number of machines here & have not seen problems. I think 5.57 is the current f/w for KZPBA (aka isp1040) > > Isn't it possible to flash the f/w onto the isp card itself? Or does the > > Alpha always use the f/w contained in the SRM? The same cards also run > > in a PC, so without the notion of SRM... > > It's not quite clear what the SRM does or does not do. It may or may not > download from the card. Likely not. It also probably depends on the SRM > version and the platform. Well, Tru64 5.0 tells me: Alpha 21064A Evaluation Board 274 MHz DECchip 21072 pci0 (primary bus:0) at nexus Loading SIOP: script c0000000, reg 81051000, data 410dc000 scsi0 at psiop0 slot 0 isp0 at pci0 slot 6 isp0: QLOGIC ISP1040B/V2 isp0: Firmware revision 2.10 (loaded by console) isp0: Failed to enable fast RAM timing. scsi1 at isp0 slot 0 So, in this case the SRM has loaded the f/w onto the isp card. But on the same Tru64 5.0: # strings isp.mod | grep load isp_unload DMA map_unload failed (sg_loop) DMA map unload failed isp_segment_load Bad header/payload flags set in status entry: 0x%x Fatal Error - No firmware image is present to load Error detected in isp_chip_init, firmware load failure likely RAM load failure (loaded from root filesystem) !!!!! (loaded by console) !!!!! isp_load_ram It appears the Tru64 driver can also load f/w onto the isp. > Insofar as updating the cards themselves- this is a pretty much > undocumented procedure that I would rather not become responsible for. > There are tools available from the Qlogic website which allow you to do > this (on a PC executing from DOS), but it's not really clear whether the > SRM will pull this out of the BIOS flashrom and then download it to the > SRAM on the card and set that running- I believe that SRM just downloads > the code *it* has. This is what I think happens, judging from the experiment above. > The reason the f/w will be going back in the tree is to provide a > *selection* of features such as Fabric or Target Mode support. The INSTALL > kernel should not have any of this compiled in because it makes things > probably too big to fit on floppies. Well, it's there for Alpha because > there are so few other boards supported that there is room for it. Hell, :-) I agree that this is a kind of a mess. SRM can only handle ncr and isp (for PCI machines) IIRC. > It's a hard problem to get right solution for, sorry. I'll have a little discussion with one of my colleagues to see if one can merge new isp f/w into the EB64+ SRM console binary. This guy used to write repair diagnostics etc for Alpha so he knows a lot of the console bit banging stuff. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message