[9fans] running alphas
Geoff Collyer
cheaply than I could buy a bitsy) on ebay, primarily to add a little
diversity to my pool of machines, as a way to exercise new code
routinely to ensure at least a little portability. I had to load SRM
firmware (available from
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/archive/alphapc164lx
) over its NT firmware, but once I managed to build a kernel without
realtime and edf code in it, it just runs. Thank you, dhog.
So here's what I did wrong and what I learned from it.
• I typed "set auto_action BOOT" without first reading the entire
SRM console firmware manual. This is apparently a common and
well-known gaffe, but for some odd reason Alphas don't come with a big
red warning label advising against doing it. It makes the Alpha
immediately boot at power on and at any attempt to halt the machine
(but see below), so access to the SRM command set is gone forever.
Having loaded the SRM firmware once, I can't get the machine to accept
any further loads of firmware (even via the Fail-Safe Booter), so the
obvious solution doesn't work. There is a well-marked place on the
motherboard to hook up wires to a Halt button, which is claimed to be
the only other means of escape and seems to be standard equipment only
on more expensive Alphas. I haven't gone that far yet.
• I initially built kernels with
realtime edf
in their config files. This caused all sorts of odd effects: the
system couldn't get very far because '#l0/ether0' was empty; when it
got past that, something printed "utype" at random intervals on the
console, the system (at 533MHz) felt sluggish, and rob's mips program
claimed 523 MIPS (which rises to 526 without realtime in the kernel).
Removing realtime and rebuilding cured all the problems I'd been
having.
But before I realised that that was the root cause, I tried debugging
and in the course tried minimising differences with the PC port, on
the assumption that some of the Alpha port code might be out of date,
thus causing the odd behaviour actually caused by realtime. I can
make the resulting code available to anybody who is interested.
bootalphapc is mysteriously quite a bit slower than bootp/tftp loading
on a PC. I don't yet know if this is due to running the 2114x
ethernet at 10Mb/s, or if there's some other cause (like the SRM
firmware being really slow). Not a big deal, I only noticed it
because I was booting so much. I did modify bootalphapc to ignore "#"
comments in /alpha/conf files (the Alpha version of plan9.ini). I
also added enums for some more firmware operators and SRM environment
variable indices for future use.
In the kernel, I've imported into exit() some of the code from the PC
port's exit() and fleshed out reboot, which now does warm reboots
(triggered by writing "reboot" to /dev/reboot) but doesn't yet attempt
to implement the new "reboot kernel" message. More reading and
experimentation is needed here; there seem to be a lot of possible
settings of bits in cpu->state that affect halt and reboot behaviour.
I think alphapc/devether.c can be nearly identical to pc/devether.c;
one odd difference is:
: alpha; diff -w alphapc/devether.c pc/devether.c
384c396
< if(ether->irq == 2 && BUSTYPE(ether->tbdf) != BusPCI)
---
> if(ether->irq == 2)
I made alphapc/random.c just include pc/random.c since this was the only
difference:
diff /n/dump/2002/1020/sys/src/9/alphapc ../pc/random.c|p
40c40
< void
---
> static void
I fleshed out the devarch.c tables more fully (now I see where the
mnemonic `7' comes from) and added enums for more cpu->state bits and
bitfields. 9/boot/bootip.c and cmd/ip/ipconfig.c needed some
werrstr("")s added to avoid printing spurious messages (I'd wondered
for some time why ipconfig's messages were sometimes so inscrutable;
``no free devices'' can be a dreg from a failed bind of #l3!).
I'd love to find some unused NVRAM somewhere in the machine. I can
run the machine diskless, booting via bootp and tftp from the boot ROM
(SRM), since it's a real computer, but I need somewhere to hold the
cpu server authentication data. I'm resorting to floppy for now. I
suppose I could burn the data onto a CD, which won't wear out with
repeated use.