Subject: Re: Shark flashing (oops!)
To: Chris G. Demetriou <cgd@netbsd.org>
From: Hans Ridder <hans.ridder@veritas.com>
List: port-arm32
Date: 06/14/1999 16:04:11
"Chris G. Demetriou" wrote:
> [Blowing your flash away with your DHCP server] is a 'known
> issue' that I probably should have warned you about.  Sorry.  (In my
> defense, for some reason I thought that the DHCP server that was known
> to have this problem was fixed...)

Not a problem. It's all in a day's learning. It's hard to complain since
you've made the firmware available. We should probably get some basic
(and safe) flashing instructions into the FAQ though. I think I can
write the part about what *not* to do and hopefully soon, how to fix it!

> What's happening is that the firmware is asking for the ROM image file
> name, and instead of replying with that filename (as is reasonable
> and, IIRC, specified by the RFC), your DHCP server is returning the
> filename that it likes.

Ummm, handy. It has a couple other annoying features I'd like to fix.

> In a nutshell, the DHCP server is broken.  If it's the ISC DHCP server
> shipped with 1.3.x, yes, this is a known problem.  (I thought it was
> fixed in the one in 1.4, but obviously i could be mistaken.)

The server system is a RedHat 5.2 system. The DHCP server says:

    Internet Software Consortium DHCPD $Name: V2-BETA-1-PATCHLEVEL-6 $

> A
> workaround is to remove the 'filename' specifier from the Shark's
> entry in the dhcpd.conf, while upgrading flash images.

A good idea. I'll add it to my list for the FAQ entry.
 
> There's a quick hack (which might have shown up in the latest FW
> image) to sanity check the image before it's burned into the EEPROM.
> If the firmware doesn't have it, it can be placed into the nvramrc...

And the quick hack is???

> There's no failsafe loader built in, but the flash EEPROM is a
> standard and socketed part, so you can yank it out and pop it into an
> EEPROM burner if you have or have access to one.
> 
> If you neither have nor have access to one, well, i'm sure somebody on
> this list might be able to help you out.  (Unfortunately, I don't have
> or currently have access to one.)

I don't have access to one. I have an offer from a couple of states
away. I'd like something more local (I'm located in the Seattle, WA
area,) but it isn't that hard to drop the chip in the mail.
 
> You'd be surprised to know how many times
> we made this same mistake ourselves.  8-)

Well, it's nice to be in good company! ;-)

This probably isn't the right thread to mention it in, but it would have
been nice if the CS8900 driver could've been made to look at the
firmware date (i.e. the built-on property of the /openprom node) and
work around this broken firmware version.... It could have avoided the
whole firmware license/upgrade/etc. issue. It probably isn't worth the
trouble now. Since 1.4 is already released everyone will probably
upgrade (thus upgrading their firmware) before another release.

Thanks (to Mark H. and Mark B. too) for the support.

> chris

-hans
--
Hans-Gabriel Ridder <Hans.Ridder@veritas.com>
VERITAS Software, Bellevue, WA USA