Getting Linux to Run on an Alpha CPU

I purchased a remaindered Digital Equipment Corporation VX40A-F2 Universal Desktop Box (UDB) from Starship/Computer Guys. I did this via an on-line auction run by www.onsale.com. Although I received the goods I paid for, I'm not sure I can recommend onsale.com. I have already gotten several email spams because either Starship or Onsale.com gave out their list of email addresses to unscrupulous scumbag email advertisers.

This UDB was strictly barebones. It had no memory, no disk, no monitor or keyboard. It did come with a mouse, a Red Hat Linux/Alpha 4.0 CD-ROM set, and some minimalistic instructions, however.

After the UDB arrived, I proceeded to purchase the other pieces I needed to make it into a useful computer. The first episode involved memory.

I called several used and do-it-yourself type computer shops in the Denver metro area to find 36-pin, 70 nanosecond or better, "true parity" SIMMs. All of them quoted me a price. One Saturday, I drove over to purchase some. In 3 of the stores, I got exactly the same treatment: I asked for the memory, they looked up the price, then told me to bring my PC to their shop to let them install the SIMMs. I waved the DEC documentation at them, told them I just want to buy it, and I'll sign away my right to return ruined memory. Reluctantly, each counter jockey went to the back rooms, only to discover that they had no SIMMs like the UDB needs in stock.

I eventually purchased the SIMMs I needed from a mail-order concern, Memory Shippers of San Francisco, California. I was able to install it without ruining it, despite the fears of the used computer shops in Denver.

I went to the local Computer City mass-market personal computer store to purchase a "PS/2 compatible" keyboard. The used computer stores, was reluctant not only to sell me SIMMs, but also didn't want to sell me a keyboard. There was a dazzling array of keyboards at Computer City, each clearly marked with some set of buzzwords. I was able to spot two signs saying "PS/2 compatible", but the only boxes behind those signs had labels on them saying "Not PS/2 Compatible". I was eventually able to find a keyboard that was "PS/2 compatible", in spite of some non-help from Computer City sales people. Apparently putting on a pastel-yellow Computer City polo shirt causes the IQ to drop about 20 points. The keyboard I purchased was one of the middle-priced ones. The cheapest ones are still only "AT Compatible".

I discovered that the UDB must have a "multi-synch" SVGA monitor because of its built-in video capability. None of my other monitors are "multi-synch". During my search for memory and keyboard, I had also noted prices and availability of monitors.

During 1996, I had purchased a 19-inch genuine Sun Microsystems monitor via a usenet newsgroup for $350, so I was shocked to see used 17-inch multi-synch monitors going for $450 and up. New monitors at the mass-market PC stores were quite pricey.

I finally decided that I'd buy a 14 or 15 inch monitor. I got the same run around on monitors as I did during my memory acquisition. After looking in the back room, one used computer store would sell me the monitor the repairman was using. Another used computer store only dealt in 17-inch and larger monitors. The third store had only one monitor for sale by itself (outside of the full systems they sold) a Compaq "Presario 1410". This monitor is apparently something of a white elephant, since the speakers only work with Compaq computers or some such excuse. As a long-time NeXT owner and user, I am familiar with the lack of benefits of sound, so this wasn't a real factor in my decision. 

Digital Equipment Corporation stopped manufacturing the UDB (a.k.a. "Multia") product line sometime in 1996, but they've put the hardware service manual out for ftp. This isn't quite as gracious as it sounds, since it contained no diagrams that showed the position of the various jumpers that control aspects of the UDB's behavior. Fortunately, Red Hat has made its mailing list archive public and searchable.

Armed with the oddly-typeset documentation from "Starship Computer", (the company I bought the UDB from) and numerous chunks of documents from the Digital service manual, the Red Hat mailing list and other web pages, I was able to get the UDB to boot the MILO mini-loader. The "SRM" boot PROM doesn't synch with the monitor, so part of the boot is blind. After that, I was able to install Red Hat Linux for Alpha, 4.0 on a Fujitsu model M1606SAU SCSI disk. I had a Toshiba XM-3301TA CD-ROM drive that I had previously hacked to work with the Sun SPARC boot PROM, which requires 512 byte disk sectors. I used this CD-ROM drive to install Linux from the Red Hat CDs. I find it remarkable that the hardware and software worked with a modified, 5-year-old CD-ROM drive.

One difficulty I encountered was having to use "fdisk" to build a cheesy MS-DOS partition table. It strains credibility to believe that Digital makes boot PROMs that require a "FAT" filesystem to boot from, but it is so. I also found out that the various partitions have to start on a divisible-by-4 number of cylinders.

A second difficulty I encountered was that the fool-proof instructions from Starship/Computer Guys implicitly assumed that the hard disk is at SCSI Target 0. Experience with Sun's boot PROM over the years allowed me to spot where the UDB boot PROM code assumed Target 0. 

It took me two complete install cycles to get a satisfactorily working Linux. I made an incorrect choice of packages to install the first time around. I thought that getting a system up and running was paramount. Getting that installation to start networking would be easy. Getting IP networking to start when the whole system isn't configured to start is quite difficult. I ended up re-installing as a "networked workstation".

There may be something wrong with the Linux networking code. The default installation causes the boot process to hang, but there's a deeper flaw: every 3.5 seconds, the Linux/alpha kernel fires off a 46-byte packet to itself. The ethernet frame has the machine's own MAC address as both source and destination. Maybe this is a heartbeat or a way of checking that the network wiring is intact, but it's very puzzling.

After getting the system to boot from the hard disk, the rest of the set up was moderately difficult. I had to scour the Red Hat mailing list archives for hints about how to keep the boot process from hanging, and I had to fiddle with the XFree86 configuration file. Having purchased a cheesy 14-inch monitor was a mistake: everything is really tiny.

I quickly encountered a bug related to the 64-bit Alpha CPU. I wanted to keep all my machine's clocks synchronized, and `rdate' seemed like a cheap and easy way. I was already using it on two other machines, and it seemed like it would be easier to compile and use than alternatives like NTP (I've set up and administered NTP in the past).

Compiling 'rdate' from the NetBSD 1.1 sources was pretty easy. It insisted on telling me that the time on my other machines (SPARC IPC and M68040 NeXT) was sometime in 1861. It turned out to be a sign extension "feature" of the Alpha CPU: the `rdate' protocol is supposed to give out a 32-bit, "network" byte order, 2's complement number of seconds since 12:00 AM Jan 1, 1900. The `rdate' code uses the library routine ntohl() to get back to its own byte order. This ended up setting the 32nd bit of the numerical representation of the date to a `1'. This 32-bit value gets sign-extended when loaded in the Alpha CPU's 64-bit wide registers. The `1' bit in position 32 made the number in the register negative.