From owner-freebsd-alpha Sat Jun 19 20:35:44 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from callisto.fortean.com (callisto.fortean.com [209.42.229.241]) by hub.freebsd.org (Postfix) with ESMTP id DE9AF14E3E for ; Sat, 19 Jun 1999 20:35:38 -0700 (PDT) (envelope-from walter@fortean.com) Received: from localhost (walter@localhost) by callisto.fortean.com (8.9.3/8.9.3) with SMTP id XAA02024 for ; Sat, 19 Jun 1999 23:35:38 -0400 (EDT) (envelope-from walter@fortean.com) X-Authentication-Warning: callisto.fortean.com: walter owned process doing -bs Date: Sat, 19 Jun 1999 23:35:38 -0400 (EDT) From: Bruce Walter Reply-To: Bruce Walter To: alpha@freebsd.org Subject: Anyone up for an exorcism? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey, all! I just picked up an AXPPCI33/Noname for myself so I can do a little porting. When it arrived, I found the previous owner had blown MILO into the SROM :( Since this thing has the smallest SROM ever, MILO has displaced all vestiges of Digital firmware including the debug monitor. (if there even was one, but the 'boot Service Console' jumper options don't work, at least) Does anyone have any ideas on how to get the good old SRM back in there? So far the following have failed: 1) Sliding the jumper over to failsafe mode and inserting an SRM complient boot block diskette with the firmware update utility. This actually loads, displays the BIOS emulation message, then sits at the blue SRM/ARC screen with no output. Happens with both the SRM and the ARC firmware update disks. My guess is that DEC uses the PALcode from the existing SROM and never dreamed of a third party invading that space. MILO's PALcode apparently can't support the DEC update utility. 2) Burning incense and praying to the BSD gods to remove this blight from my machine. At least the room smells nice now. I've been poking around in the MILO fmu code, trying to see if it could be modified to carry an SRM image instead of the milo image. Unfortunately, it's complex enough that if I took the time to do that, it'd be easier to just hack MILO to load FreeBSD. Along those lines, am I correct in my understanding that the only reason MILO cannot be hacked to load our kernel is that the PALcode it uses is so blasted old? Thanks, - Bruce ______________________ Bruce M. Walter, Principal NIXdesign Group Inc. 426 S. Dawson Street Raleigh NC 27601 USA 919.829.4901 Tel (ext 11) 919.829.4993 Fax http://www.nixdesign.com Visual communications | concept + code To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message