AlphaStation 255 quirks

Just a few short notes on issues with the AlphaStation 255 that took a while to figure out due to the answers being tucked away in obscure corners of the Internet. For the most part, this machine installs Debian pretty easily.

aboot.conf gotcha (more of a software issue)

If you install a separate /boot/ partition, then as expected, aboot.conf has to be on that partition. The way the Debian installer handles this is a bit confusing. Aboot will use /boot/etc/aboot.conf, but the Debian installer leaves a second /etc/aboot.conf in the main filesystem. Your best course of action is to remove this duplicate file and symlink it to /boot/etc/aboot.conf, lest you forget and accidentally edit the wrong one.

Serial SRM

Just booting without keyboard and monitor is not enough to send the SRM to a serial port. You unfortunately have to use the video/keyboard and issue a "set console serial". And then, sometime later, when the system feels like it, or when you do something which I haven't quite figured out yet, SRM will start appearing on the serial port. It will be on serial now whether or not the keyboard is connected (you'll get nothing but a blue screen with a blinking cursor on the video.) Unless it has been fiddled with, the console output will be on the first serial port at 9600n81. You still use "CTRL-C" to abort boot; I haven't found that rs232 "break" does anything. So make sure you have a com program that doesn't have ctrl-c defined as a hotkey. Maybe there is a default setting that will sanely choose serial when the keyboard isn't plugged in, but mine started with "console graphics" and that prevented the serial from displaying anything but the initial two lines of codes.

Getting onboard sound working

Before you pull your hair out over this, you should get access to your SRM console and make sure the line "No sound device in ISA table. Skipping sound init." does not appear when the machine is booting. If it does, then you need to execute the following SRM command, because your ISA bus is likely not correctly initialized. This happens after firmware upgrades, apparently, according to this post here and this here:

isacfg -init
add_sound
init

Now make sure that that error message doesn't reappear, and stop SRM again and issue "isacnf -all" and verify you have the following entry:

=============================================================
handle: PCXBJ 
etyp: 1 
slot: 2 
dev: 0 
enadev: 1 
totdev: 1 
iobase0: 530   iobase1: 388 
iobase2: 8000000000000000   iobase3: 8000000000000000 
iobase4: 8000000000000000   iobase5: 8000000000000000 
membase0: 8000000000000000   memlen0: 8000000000000000 
membase1: 8000000000000000   memlen1: 8000000000000000 
membase2: 8000000000000000   memlen2: 8000000000000000 
rombase: 8000000000000000   romlen:   8000000000000000 
dma0: 0         irq0: 9 +
dma1: 1         irq1: 80000000 +
dma2: 80000000          irq2: 80000000 +
dma3: 80000000          irq3: 80000000 +
=============================================================

Note the iobase0, irq0 and dma0 lines for future reference.

The driver for the onboard PCXBJ sound is ad1848. Once I cleared up the above SRM problem, I was able to insert the ALSA module into 2.6.10 and it worked (caveat: I haven't checked playback. I was only interested in using the input line to monitor my household power consumption.) Unfortunately I was forced to use the modules because I have a sneaking suspicion that all the stub documentation that suggests you can pass parameters to a builtin version of the driver via a lilo commandline of snd-ad1848=, whose format is not documented but whose existance is in places like the BootPrompt HOWTO and kernel-parameters.txt, is in fact false. I can't say for sure because stuff changes so fast in the kernel tree that it is possible that the MODULE_PARM lines somehow now magically work, but I don't see any code in ad1848.c that handles options for the compiled-in case. My guess is not, because my attempts to do so failed. Anyway for use as a module in more recent kernels, the options to pass are "port=0x534 irq=9 dma1=0" (based on the above SRM info) though many report using dma1=3. I don't know why you have to add 4 to the port value, though a wild guess would be differences in the ad1845 in the as255 and the ad1848 spec, or granularity issues in the SRM ISA bios.

Note that ALSA is a tad broken, or was when I tried it -- alsamixer does not allow you to choose an input from the multiplexor other than the loopback. The input sets itself to a strange initial value, taking one channel from one port and another from a different port. To change the values, use the amixer raw console command to cget/cset with chipset index numid=8. The line-in jacks are "AUX" in ALSA, which could probably be patched up with special support in the as1848 driver. Example to select line-in jacks on both channels:

amixer cset numid=8 1 1

If you want a look at the signal routing layout or other details on the ad1845, try here.