Hardware hacks – DEGXA cards for OpenVMS
As part of my project to upgrade my network to Gigabit Ethernet capability, I purchased a 3X-DEGXA-TA card for $469 from a vendor that shall remain nameless. Upon installing it in my DS10 system and booting, the system locked up after 10 minutes or so. Upon each reboot, the uptime was shorter and shorter, until finally the system wouldn’t boot at all.
When I contacted the vendor, their response was “well, it worked when you got it – call your service people”. As this is a hobby system, I am my service people.
I removed the card and studied it in detail, and as far as I could tell it was a generic BCM5703 card with a DEGXA bumper sticker on it. With the help of some resources on the net:
http://moon.hanya-n.org/comp/alpha/hct/GbE.html
http://www.techiegroups.com/archive/index.php/t-56718.html
I determined that it was likely that the only difference between a card that would work and one that wouldn’t was the PCI subvendor / subdevice data. While it was possible to have VMS recognize the card by editing a VMS configuration file (as shown in the second post above), that meant that the system couldn’t netboot from the card. It also struck me as a bit of a hack.
I thought about obtaining a new NC7771 card and unsoldering the SEEPROM from the dead DEGXA-TA and moving it to the new card, but that was a bit of a kludge and might not work, since the NC7771’s available these days are rev B0 cards, corresponding to the DEGXA-TB. Also, the burned-in MAC address wouldn’t match the sticker on the card, a minor annoyance.
Broadcom does a pretty good job of locking down the SEEPROM, but I felt that there must be a way to accomplish this with the tools available on the net. I searched for various items related to the BCM5703, such as utilities to change the MAC address. Finally, I had enough information to begin experimenting. After a day or so of fiddling around, I came up with a system that works.
IMPORTANT: Use the following information at your own risk. If you break your network card or computer(s), don’t blame me. I have tested the procedure here on multiple cards and they all work, but variations in cards may mean that this procedure won’t work for you.
First, you’ll need to download the latest HP Broadcom firmware update utility from: http://h18023.www1.hp.com/support/files/networking/us/download/24056.html
Next, you’ll need a copy of the OEM version of the Broadcom diagnostic utility from: http://portal.atcelestica.com/public/global/suppchman/alpha/alphadw.nsf/downloads/000031/$file/B57DIAG.EXE
You will also need a utility to modify binary files. This could be as simple as the MS-DOS “debug” utility – it really doesn’t matter. You’ll also need a bootable DOS floppy, and an Intel-architecture machine to install the network card into to perform the upgrade.
Unpack the SP31728.exe file somewhere on your hard disk and copy the file 7771v235.bin to degxa.bin. Copy 7782327B.BIN to degx2.bin.
Using a binary editor, edit the file degxa.bin and change the bytes starting at 0xA4 to the new subvendor and subdevice by replacing bytes 00 CA 0E 11 with 60 1B 0E 11.
Using a binary editor, edit the file degx2.bin and change the bytes starting at 0xA4 to the new subvendor and subdevice by replacing bytes 00 D0 0E 11 with 00 C9 0E 11.
Copy all of the files from your work directory to the bootable DOS floppy.
For a BCM5703-based card like the NC7771, boot the DOS floppy on a machine with the Broadcom card installed, and give the following command:
b57diag -e b57kia -c 0 -t a35b35cd -f degxa.bin
For a BCM5704-based card like the IBM 31P6401, boot the DOS floppy on a machine with the Broadcom card installed, and give the following command:
b57diag -e b57kia -c 0 -t a35b35cd -f degx2.bin
Note: these commands assume that this is the only 5703 card in this system. If there are other cards, you may need to change the value of -c (“card”).
June 14th, 2008 21:01
NC7771 seems to be a moving target?
it looks like, but has been hard to confirm, that HPQ has made
several variants of BCM5703 cards, since late 2006, and calls all of them NC7771.
even if I knew the exact rev card to look for, ordering from most
vendors is a crap-shoot, given that they’ll usually substitute a ‘generic’ NC7771.
I was able to get a few “NC7771” cards recognized/configured by VMS,
changing the subvendor/subdevice ids as described above, but the link
status would bounce up/down (per OPA0 and lancp; prob the link was never up)
with, or without jumbo frames.
the LANCP counters/stats for the device would look whacky also.
for addtl yucks, I tried a NC7770 card, (5701), id’s tweaked to look like
the (ds25) on-board BCM 5701 LOM. no luck. VMS seems to pause every 5s,
and the card ran way hot. (same whacky lancp stats/counters)
A shame, because I would like get about 3 DEGXA-TB’s, but at $150-600 each
it’s too much $$$ for what I want to use them for.
June 15th, 2008 04:07
Re: NC7771 seems to be a moving target?
That’s odd. I’ve never had any problems with these myself, and nobody else has reported this to me. All cards with the same main vendor / device ID should respond the same way to the VMS device driver (aside from any revision-specific quirks, which are usually dealt with by the device driver anyway). I’m running VMS 8.3 with SYS$EW5700DRIVER without any problems. Here’s the output from various VMS utilities as well as the corresponding port on my Cisco Catalyst 4948 switch:
$ ana/image sys$loadable_images:sys$ew5700.exe ...snip... Image Identification Information image name: "SYS$EW5700DRIVER" image file identification: "X-79" image file build identification: "XBCA-0080070019" link date/time: 11-JAN-2008 09:59:46.84 linker identification: "A13-03" Patch Information There are no patches at this time. ..snip... LANCP> sho dev/count ewc SERVER Device Counters EWC0 (15-JUN-2008 05:09:02.78): Value Counter ----- ------- 3838674 Seconds since last zeroed 234286518071 Bytes received 21602117780 Bytes sent 122354951 Packets received 101549119 Packets sent 205589226 Multicast bytes received 32781126 Multicast bytes sent 1666578 Multicast packets received 397326 Multicast packets sent 1 Unrecognized unicast destination packets 64039 Unrecognized multicast destination packets 0 Unavailable station buffers 0 Unavailable user buffers 0 Alignment errors 0 Frame check errors 0 Frame size errors 0 Frame status errors 0 Frame length errors 0 Frame too long errors 0 Data overruns 0 Send data length errors 0 Receive data length errors 0 Transmit underrun errors 0 Transmit failures 0 Carrier check failures 0 Station failures 0 Initially deferred packets sent 0 Single collision packets sent 0 Multiple collision packets sent 0 Excessive collisions 0 Late collisions 0 Collision detect check failures 1 Link up transitions (1-MAY-2008 17:54:33.05) 0 Link down transitions None Time of last generic transmit error None Time of last generic receive error LANCP> sho dev/inter ewc SERVER Device Internal Counters EWC0 (15-JUN-2008 05:06:50.35): Value Counter ----- ------- --- Internal Driver Counters --- "DEGXA-TB" Device name "Jan 11 2008 09:48:39" Driver timestamp 79 Driver version (X-n) 11000000 Device revision (Broadcom 5701,5703,5704,5715 chip) 198793936 Device interrupts 1 Link transitions 36 Link transitions avoided 4 Status block link state changes 3838825 Link checks 1 Device resets 1 Device initializations 19 User start/change/stop requests 353131 Jumbo transmits issued 16090740 Transmits issued (using map registers) 29379119 Jumbo receives issued 320 Standard receive buffers 128 Jumbo receive buffers (current) 128 Jumbo receive buffers (minimum) 1012 Jumbo receive buffer allocations 2158 Standard buffer size (bytes) 1518 Standard packet size (bytes)(device standard ring) 9658 Jumbo buffer size (bytes) 9018 Jumbo packet size (bytes)(device jumbo ring)) 000002A0 Requested link state <FlowControl, Fdx, 1000 mb> 000002A1 Current link state <FlowControl, Fdx, 1000 mb, Link up> 00000003 Remote flow capabilities <Transmit_Pause, Receive_Pause> 4 Current link up timer 0000844C Driver flags <Device_Link_Handling, Dynamic_Interrupt_Coalescing, 5703, Copper, Jumbo_Frames> 00000008 Driver state <RunUp> 00000040 LAN_FLAGS system parameter <Enable_GBE_Jumbo> 64 DMA width (bits) 33 BUS speed (mhz) PCI BUS type IOSAPIC Interrupt mode 00000086 MSI control (Alloc<6:4>,Req<3:1>,Enable<0>) 16 Transmit coalesce value 16 Receive coalesce value 50 Transmit interrupt delay (usec) 10 Receive interrupt delay (usec) 100 DIM (dynamic interrupt mitigation) tics 1 DIM receive interrupts 1 DIM receives done 1 DIM transmit interrupts 2 DIM transmits done 5920 Map registers allocated 0:00:03.00 Transmit time limit 0:00:01.00 Timer routine interval --- Registers (wrote/read) --- 110002B8 110000BA Misc Host Control 00E04F08 00E04F08 MAC Mode <Enable_FHDE, Enable_RDE, Enable_TDE, Enable_TX_Stats, Enable_RX_Stats, Link_Polarity, Max_Deferral, TX_Burst, PM1> 0F40141C 00000003 MAC Status <Signal_Detect, PCS_Synched> 00001006 00001006 RX Mode <ExtendedHash, FlowCtrl, Enable> FFFFFFFF 00000008 TX Status <LinkUP> --- Time Stamps --- 1067:12:24.31 Current uptime 0:00:03.80 Last reset 0:00:07.00 Last link up 1067:12:17.31 Total link uptime 0:00:07.00 Total link downtime --- Driver Auto-Negotiation Context (fiber) --- Not_Autoneg Current state --- Fork Delay (after scheduled) --- 189404 10..19 milliseconds --- Transmit Time --- 656470 10..19 milliseconds --- Receive completion time --- 120960 10..19 milliseconds --- Status Block --- 000000A2 Status tag value 00000001 Status <Updated> 47 Receive Jumbo Consumer index 4 Receive Standard Consumer index 51 Receive Ring 0 Producer index 31 Send Ring 0 Consumer index --- Statistics Block --- ----- Statistics - Receive MAC --- 234268414036 Bytes received 120683087 Unicast packets received 127662 Multicast packets received 1538868 Broadcast packets received 3635551 Packets (64 bytes) 26818091 Packets (65-127 bytes) 11302389 Packets (128-255 bytes) 159851 Packets (256-511 bytes) 63090 Packets (512-1023 bytes) 50991527 Packets (1024-1522 bytes) 1208 Packets (1523-2047 bytes) 14678684 Packets (2048-4095 bytes) 1705 Packets (4096-8191 bytes) 14697521 Packets (8192-9018 bytes) ----- Statistics - Transmit MAC --- 22010448047 Bytes sent 101146326 Unicast packets sent 332440 Multicast packets sent 64873 Broadcast packets sent ----- Statistics - Receive List Placement State Machine --- 122349617 Frames received onto return ring 1 164334 DMA write queue full ----- Statistics - Send Data Initiator State Machine --- 101543639 Frames sent from send ring 1 68 DMA Read Queue full ----- Statistics - Host Coalescing State Machine --- 101912514 Send producer index updates 204252832 Ring status updates 203976274 Interrupts generated 276558 Interrupts avoided 275 Send threshold hit --- Driver Messages --- 1-MAY-2008 17:51:07.53 Link up: 1000 mbit, full duplex, flow control (txrx) 1-MAY-2008 17:51:04.35 Device type is BCM5703C (UTP) Rev B0 (11000000) 1-MAY-2008 17:51:04.34 DEGXA-TB located in 64-bit, 33-mhz PCI slot 1-MAY-2008 17:51:04.34 Jumbo frames enabled per system parameter LAN_FLAGS bit 6 1-MAY-2008 17:51:04.34 1000mbps_full_duplex mode set by console (EGA0_MODE) tmk-gw>sh int gi1/36 GigabitEthernet1/36 is up, line protocol is up (connected) Hardware is Gigabit Ethernet Port, address is 0019.e8xx.xxxx (bia 0019.e8xx.xxxx) Description: server - HP DS10 MTU 9198 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX input flow-control is on, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 43000 bits/sec, 40 packets/sec 5 minute output rate 1106000 bits/sec, 40 packets/sec 158563697 packets input, 32994695197 bytes, 0 no buffer Received 672222 broadcasts (562471 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 196437230 packets output, 368328755355 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped outJune 16th, 2008 10:06
I suspect my problem is that I don’t have true-blue NC7771 cards at hand.
One vendor shipped me NC7770’s (the afore mentioned 5701 cards)
even while the invoice/web pages stated NC7771.
another vendor shipped me IBM NetXtreme cards labeled NC7771, but actually
IBM part 31P6309/fru 31P6319. And I have another card, I can’t say for sure is really a NC7771, although the vendor says it is. and so it goes.
thx for the followup. if you’ve heard of no other reports, I’m hoping that
one doesn’t need a very specific revision of the NC7771 card for this hack.
June 16th, 2008 12:02
NC7771 is just a sticker that HP puts on cards they buy from Broadcom. I’m looking at one here that has the HP sticker on the back. But the front has “BCM95703A30U” silk-screened on it, which is the Broadcom part number for the card. If you search for that, you’ll find the cards branded by quite a few OEMs.
While I don’t know about your specific IBM card, the IBM 31P6419 is similarly “badge-engineered” from a Broadcom BCM95704CA40 card.
June 30th, 2008 22:55
short story:
if you’re trying this in a 500/600au PWS, “this might not work”
longer story:
What I didn’t mention earlier, is that the system(s) I was
trying these modified NC7771’s in, were 600au Alpha PWS (Miata GL).
I found what I believe is a true-blue NC7771,
and did the same drill, with the firmware. same results.
these are the later Miatas (without the Pyxis/64bit slot bugs),
using the last f/w for this model, SRM 7.2-1,
as best I knew these systems pre-date the DEGXA-TA/-TB cards.
and these cards were never officially supported in the PWS.
(but for the price, I had to try anyway)
they’re not recognized under the 600au SRM (no surprise there, really)
Bus 00 Slot 11: Vendor: 14e4 Device: 16a7 Sub_id: 601b0e11
I’ve had working graphics (PBXGB-AA) and DEGPA-SA nic cards
in the two 64bit slots. so I know the slots were working.
My guess: a DEGPA-TA (twisted pair) would also work.
it seems likely that only a specific subset of digital-brand cards
will work in these 600au 64bit slots, under VMS.
later, as time allows, a few weeks from now, I’ll try
the modified NC7771 in some other Alpha systems
(eg DS10/20/25,ES45), and report back.
—– Statistics – Host Coalescing State Machine —
841813590240 Send producer index updates
274877907026 Ring status updates
747324309753 Interrupts generated
236223201385 Interrupts avoided
575525617881 Send threshold hit
— Driver Messages —
30-JUN-2008 19:48:48.81 Link up: 1000 mbit, full duplex, flow control (txrx)
30-JUN-2008 19:48:40.12 Device type is BCM5703C (UTP) Rev B0 (11000000)
30-JUN-2008 19:48:40.12 DEGXA-TB located in 64-bit, 33-mhz PCI slot
30-JUN-2008 19:48:40.11 Jumbo frames enabled per system parameter LAN_FLAGS bit 6
30-JUN-2008 19:48:40.11 Auto-negotiation mode assumed set by console
July 18th, 2008 10:55
Hi Terri
Just wanted to let you know HP has moved the firmware files. You can now find them at:
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=ca&prodTypeId=329290&prodSeriesId=406606&prodNameId=406608&swEnvOID=14&swLang=8&mode=2&taskId=135&swItem=MTX-UNITY-I24056
December 22nd, 2009 00:02
Nothing on the Internet is as permanent as we expect it to be. In addition to HP moving the SP31728 file as described above, the second link in my original article is now a dead link, though there is another copy of the comp.os.vms post at http://unix.derkeiler.com/Newsgroups/comp.os.vms/2005-04/1293.html
More importantly, the link for b57diag in my original article is now dead – that host seems to have disappeared. You can do a web search for b57diag.exe to locate another copy – be sure to get the b57diag (manufacturing) version and not the b57udiag (user) version of the utility. I suspect that one of the reasons it is hard to find is that it probably shouldn’t be included in driver downloads from various PC manufacturers, but gets included on occasion. One of the links (verified 12-21-2009) for it is http://driverscollection.com/?aid=32213 – however, that is a 15MB download which includes a lot of things not needed for this project. There is another copy of that file at http://www.msi.com/index.php?func=driverfile&dno=2413&i=4 also. You may find another site with a more compact download – I stopped looking as soon as I found a site that offered it, just to make sure this article is still relevant.
December 4th, 2012 15:16
Hi Terri,
I’ve just tried your procedure on a NC7771. The SRM console seems to recognize it, but Tru64 (V5.1B, with patches) reports the following while booting (from the generic kernel):
vmunix: Firmware revision: 7.3-1
vmunix: PALcode: UNIX version 1.92-73
vmunix: PCI device at bus 0, slot 17, function 0 could not be configured:
vmunix: Vendor ID 0x14e4, Device ID 0x16c7, Base class 0x2, Sub class 0x0 Sub-VID 0xe11 Sub-DID 0x601b
The silkscreen ID is “BCM95703A3OU”. The chip says:
BROADCOM
BCM5703CKHB
CS0508 P20
737602 CB
Any idea how I could get this card to be recognized by Tru64?
cheers,
Rob Urban
December 4th, 2012 18:59
addemdum: it seems I was mistaken. Tru64 was *not* patched. I’ve now patched it using the BB29 kit, and the NC7771 is recognized by the bcm driver. It seems not to matter to Tru64 if the subvendor/subdevice are hacked — it works in both cases. However, the SRM console of my DS10 shows a network device if the subvendor/subdevice are hacked.
Thanks for this great article.
cheers,
Rob Urban
December 4th, 2012 19:03
Yes, my testing was done entirely with the SRM console and VMS. It seems that Tru64 is more forgiving of “foreign” IDs.