Introduction

My problems with this date back to when I had an Etherlink-II adapter (the beloved 3c503). This card sort of managed, but among its many shortcomings, its only configuration that would be recognized by the generic NetBSD kernel was the ed2 setting with iobase 0x300, irq 10, rambase 0xcc000. This card is not software configurable, so the kernel did not trash it. But later when I moved up to a WD8013 (an excellent move all told, but an 8216 is better yet), I jumpered it to be an ed2 like the old 3c503, and then when I upgraded to NetBSD 1.1, I got bit, and again on my upgrade to 1.2 (some people never learn). What can be done? Well, the obvious thing is to jumper or configure the card someplace other than 0x300. Another option would be to beg or borrow some other kind of ethernet board (like a 3com or some such), for the duration of the install procedure. Perhaps you could convince the NetBSD kernel folks to either remove the driver that does the nasty probing from the generic kernel, or to fix the driver so it probes in a less damaging way. However, this problem has been around for what seems like years, so there is perhaps no chance of relief from that quarter. Another option is to build a custom kernel and put it onto the boot floppy, but if you are doing a first time install this will be out of the question.

What are the symptoms? Well, you get to the point in the install process where you are going to boot the kernel off the hard disk. As the device probe messages go by, you notice that there is no mention of "ed0" (it has already been roached by a preceding probe). When you try to ifconfig to, lets say mount an NFS partition and load the rest of the distribution, you get some kind of error about no such device being configured. You then go scrounge up some DOS diskettes and run the EZSETUP utility from SMC and it reports that it cannot find an ethernet board. Too much fun, eh?

Last night I managed to fix a WD8013 board that had been screwed up in this fashion. It involves using DOS debug and poking around with some of the registers on the board. Port 0x301 is the ICR register, bit 0x80 is the bit that tells the board to store information into NVRAM. Ports 0x308 thru 0x30d hold the 6-byte hardware ethernet address, Port 0x30e holds a product ID (see table below), and Port 0x30f holds a checksum. Your challenge is to restore the contents of these 8 bytes to their proper values. If you are lucky (as I was) the 6-byte ethernet address is on a sticker on your card, or you can find a record of it somewhere. You could really use anything, but you would be advised to use the "offical" value to avoid having the same address as some other node in the world. The product ID is easy if you know what kind of card you have. Look in /dev/isa/if_edreg.h for a more complete list. The checksum is whatever it takes for the sum of the 8 bytes (modulo 256) to be 0xff. Easy to work out with a hex calculator.

In my case, the first byte of the ethernet address had been overwritten by an 0x05, and the card type was zeroed. The checksum needed to be recalculated after these were corrected, then things were fine. In a case prior to NetBSD 1.2, just powering the system off would allow the EZSETUP utility to recognize them later, but not so last night.

Here is a cookbook procedure:

• Put your ailing board back in your computer, still jumpered at 0x300 just as it was when it got shot in the head.
• Boot from a floppy with DOS and DOS debug.
• Run DEBUG (it should give a "-" prompt).
• Use i 308 to examine port 0x308.
• Repeat this for ports 0x308 thru 0x30f.
• Use o 308 xx to store into port 0x308.
• use the o command to fix up the 8 values.
• Use i 301 to read the ICR port.
• Add 0x80 to this value and use o 301 xx to write this.
• Use o 301 xx to write the original value back.

Here is a list of product ID's for port 0x30e:

0x26

8013W

0x27

8013EP

0x28

8013WC

0x29

8013EPC

0x2a

8216T

0x2b

8216C

0x2c

8216EBP