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”).


10 Responses to “Hardware hacks – DEGXA cards for OpenVMS

  • 1
    ldb
    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.

  • 2
    Terry Kennedy
    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 out
    
  • 3
    ldb
    June 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.

  • 4
    Terry Kennedy
    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.

  • 5
    ldb
    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

  • 6
    dunnett
    July 18th, 2008 10:55

    Hi Terry

    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

  • 7
    Terry Kennedy
    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.

  • 8
    roburban
    December 4th, 2012 15:16

    Hi Terry,

    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

  • 9
    roburban
    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

  • 10
    Terry Kennedy
    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.

Leave a Reply

You must be logged in to post a comment.