NetBSD/alpha Frequently Asked Questions

Console and Console Firmware Issues

• Why does NetBSD/alpha need firmware?
• Can NetBSD/alpha run on systems with only NT (ARC) firmware?
• Can NetBSD/alpha use MILO to run on systems without SRM?
• Where do I get a copy of the SRM console for my machine?
• How do I get it to (not to) automatically boot multi-user?
• Why does my firmware not have the srm_fw file?
• Upgrading 3000/400 firmware

Compiling and Programming

• Compiling a program that works on i386 gives strange errors on alpha
• Error message initializer element... is not computable
• How do I write an assembly program?
• How do I write a really standalone assembly program?

Miscellaneous

• What video cards are supported by X11?
• I just got a kernel trap, but my machine is still running!!
• Help! My machine just panic'd with a machine check!
• Nasty message from the kernel saying something about unaligned accesses
• Can NetBSD/alpha boot diskless?
• How do I make a hard disk bootable?
• AlphaStation kernel panics
• Coexisting with Tru64 Unix (aka Digital Unix, aka OSF/1)
• Other sources of information

---

Console and Console Firmware Issues

What's the story on serial consoles? All versions of SRM do a good job with serial consoles. This is actually a Very Good Thing, because it means you can remotely administer systems, leave them locked up in nice cool machine rooms, keep big noisy boxes out of your work areas, etc...

It also means you can boot any system, even ones that have unsupported display hardware.

On almost all alpha systems, SRM switches into serial console mode if there is no keyboard when power is turned on. On some 3000 series machines, there is a switch on the back that determines the console mode. There is also an SRM non-volatile variable, but you probably don't want to set it, as it means you are then stuck in one mode and can't just plug or unplug a keyboard to switch.

Most alpha systems have com ports, so it should be fairly obvious how to hook these back to back with another computer acting as a terminal by running tip(1) in an xterm or some terminal emulator like HyperTerm.

If you are unlucky enough to have the technically nice but highly incompatible DEC MMJ ... say, on a 3000/400 ... you will need to buy or borrow the appropriate DEC MMJ adapters and line cord or make your own. To make one, see the NetBSD Hardware Documentation - Misc page, go to “Tommy's Pinout Collection”, and search for “MMJ”. There you will see documentation on the DEC MMJ pinout, and on the DB9 that PC and workstation com ports usually use. To build an adapter, you may want to cut the latch off an ordinary line cord, so it will fit in the MMJ socket, and then wire the cable as follows:

If you aren't sure which is “TX+” and which is “RX+”, but you have a voltmeter or LED, “TX+” is the one with the higher absolute voltage magnitude, and the one that can light up the LED. (Try the LED both ways; obviously it only lights up in one direction.) I'm not sure I agree with tying “TX-” and “RX-” together as implied by the pinout collection diagram; if you connect no signal ground at all, you will still get return current through the equipment protective ground, which will work fairly well if the terminal or terminal emulator shares a common power circuit with the 3000 and they are reasonably close together.

Another approach would be to connect the DEC MMJ to a Mac or Sun box which also has a differential serial interface.

Additionally, see the NetBSD Serial Port Primer.

Why does NetBSD/alpha need firmware?

It is possible to run on the bare hardware. But there are some things that the PALcode does that are quite model-specific:

...and the list goes on.

This doesn't include the processor-model specific stuff:

..and the list goes on here, too.

Basically, the PALcode provides a very nice abstraction to which the Operating System can be ported - running on the bare hardware would be a real pain.

Note, SRM isn't really required, per se. NetBSD/alpha does run on a platform that doesn't have SRM; it's a parallel multicomputer called the Avalon A12. It's not a DEC machine. It doesn't have DEC console software. The console software it does have, however, provides OSF/1 PALcode, and the A12 console software also complies with the Alpha Console Architecture as described in the architecture manual. SRM also complies with this (obviously). The AlphaBIOS console software complies with ARC (originally a console specification for MIPS systems), and not with Alpha Console Architecture.

If someone were to write some free console software, please pay careful attention to the Green and or Red Book's description of the Console Architecture. The Console Architecture doesn't suck.

Now, strictly speaking, the console software and the PALcode are distinct entities. When NetBSD calls the PALcode, it's not calling the console software, really. It's calling the PALcode. There is a standard PALcode operations called `swppal' which enables you do switch to a different PALcode image on the fly (the NetBSD/alpha boot loader does this; SRM comes up in the OpenVMS PALcode by default).

However, the PALcode is called literally all the time. Take a NetBSD kernel image sometime, pump it though objdump --disassemble, and grep for the call_pal instruction:

bishop:thorpej 53$ pwd
/usr/src/sys/arch/alpha/compile/GENERIC
bishop:thorpej 54$ objdump --disassemble netbsd | grep -c call_pal
4807
bishop:thorpej 55$ 

Some of those are in key places, like, for example, all traps (syscalls, interrupts, page faults, etc.). The C library uses it, too. It's how system calls are made (the `callsys' PALcode operation).

Can NetBSD/alpha run on systems with only NT (ARC) firmware?

Not currently. NetBSD/alpha requires the SRM Console firmware (used by OSF/1 and OpenVMS) to function. There are two main reasons for this: the console software is what's responsible for loading the operating system's primary bootstrap program, and the firmware provides the PALcode for the system, which handles low-level memory management and interrupt handling details on a system-specific basis. (NetBSD uses the Digital Unix PALcode.)

The NT PALcode is documented pretty well in the Green Book, and probably even better in the Red Book. It might not be totally unreasonable to think about a NetBSD/arcalpha ... however, the NT PALcode comes with some caveats:

Can NetBSD/alpha use MILO to run on systems without SRM?

The Alpha port of Linux can boot on systems with NT firmware not because they can use the NT PALcode, but because MILO, the Alpha Linux loader, includes its own PALcode. (This of course means you need a different loader for each system type.) The MILO PALcode is:

Ross Harvey was on the verge of fixing some of the more obnoxious bugs in it once but managed to obtain the real SRM PALcode for the project on which he was working, so he didn't. It is probably more productive to spend time persuading DEC to release SRM for more platforms, or to release the unmodified source code to a current SRM, including the PALcode, than fix the MILO PALcode for NetBSD, particularly as Linux also uses SRM for more modern systems.

Where do I get a copy of the SRM console for my machine?

For those who own AlphaStation, AlphaServer, AlphaPC164, Multia or AXPpci boxen, the SRM console can be obtained through either the “Alpha Systems Firmware Update CD” (part number QZ-003AA-E8) or from http://ftp.digital.com/pub/DEC/Alpha/firmware/.

Owners of older Alpha Evaluation Boards and older AlphaPC motherboards should peruse the “Alpha EBSDK and Firmware Update Kit” (part number QR-21B02-03). This can be obtained from DEC Direct for $75 + S&H.

How do I get it to (not to) automatically boot multi-user?

There are two non-volatile SRM environment variables that affect the automatically initiated console actions.

Examples:

        >>> set boot_osflags a
	>>> set auto_action boot
	>>> set bootdef_dev dka0
	>>> boot -fl a

Why does my firmware not have the srm_fw file?

For at least the AlphaServer1000, when booting an Alpha Firmware cdrom when attached to a network, the update program is unable to find the srm_fw file and thus can not update it. This is remedied by unplugging the network.

Upgrading 3000/400 firmware

Upgrading the firmware on a 3000/400 can be a dangerous operation, as it needs to have a sufficiently new SROM chip or else an upgrade from an old version of the firmware to a fairly new one will trash the system and cause it to machine-check at power-on.

Be sure to read the upgrade advice posted to the tru64-unix-managers mailing list.

---

Compiling and Programming

Compiling a program that works on i386 gives strange errors on alpha

Errors such as:

foo.c:91: cast from pointer to integer of different size.

An alpha is a 64bit native machine. A lot of programmers assume things like pointers are 32 bits. So when you compile them on alphas, they suddenly emit tons of warnings. Generally speaking you can get away with ignoring these, and NetBSD is smart enough to fix them up for you and do the right thing with them (it will *not* do this for kernel code!). If your program exhibits strange behavior, you will need to sit down and examine the code, and attempt to sort out all the 64bit uncleanliness.

Error message “initializer element... is not computable”

An error message

foo.c:192: initializer element for `foo' is not computable at load time

is given, and the compile stops. The code in question basicly attempts to do: int foo=(int)"string";

This is almost certainly due to foo being 32 bits and the address of "string" being 64 bits. So you're telling the compiler to store the lower part of the address and there isn't a mechanism in ELF to do that. The fix is sometimes to set the int to long, or to use char * instead.

How do I write an assembly program?

Below is Hello, world. Caution: like other RISC architectures, the alpha can't necessarily load an address or an arbitrarily large constant in a single instruction; the examples below use a couple of build-in assembler macros that are expanded as needed.

/*
 *      hw.S
 *
 *      cc hw.S
 *      ./a.out
 */

#include <machine/asm.h>
#include <sys/syscall.h>

.text
.globl  main
main:
        ldgp    gp,0(pv)
        ldi     a0, 1
        lda     a1, hwstring
        ldi     a2, hwlen
        ldi     v0, SYS_write
        call_pal 0x83
        addq    zero, zero, a0
        ldi     v0, SYS_exit
        call_pal 0x83
1:      br      1b

hwstring:
        .ascii  "Hello, world\n"
        hwlen = . - hwstring

How do I write a really standalone assembly program?

Using standalone to mean a program that doesn't require the C runtime support mechanism, here is one that can be just run through the linker without any startup or library code at all:

/*
 *      Completely standalone assembly Hello, world demo. Has the magic
 *      NetBSD .note section which tells our ELF from generic ELF.
 *
 *      hwsa.S
 *
 *      cc -c hw.S
 *      ld hw.o
 *      ./a.out
 */

#include <machine/asm.h>
#include <sys/syscall.h>

        .set noat
        .set noreorder

        .section ".note.netbsd.ident", "a"
        .long   2f-1f
        .long   4f-3f
        .long   1
1:      .asciz "NetBSD"
2:      .p2align 2
3:      .long   199905
4:      .p2align 2

.text
.globl  __start
__start:
        ldgp    gp,0(pv)
        ldi     a0, 1
        lda     a1, hwstring
        ldi     a2, hwlen
        ldi     v0, SYS_write
        call_pal 0x83
        addq    zero, zero, a0
        ldi     v0, SYS_exit
        call_pal 0x83
1:      br      1b

hwstring:
        .ascii  "Hello, world\n"
        hwlen = . - hwstring

---

Miscellaneous

What video cards are supported by X11?

At this time, the following graphics cards are supported:

Note that this applies only to the server; the X client programs run just fine.

I just got a kernel trap, but my machine is still running!!

 > fatal user trap:
 >
 >     trap entry = 0x2 (memory management fault)
 >     a0         = 0xffffffffc8000004
 >     a1         = 0x1
 >     a2         = 0x1
 >     pc         = 0x1200205b0
 >     ra         = 0x12001a8d4
 >     curproc    = 0xfffffe0000229c00
 >         pid = 22188, comm = make

This means you (or someone) compiled a DEBUG kernel, and some user or system program hit a bug and got a core dump. NetBSD/alpha prints these on the console to help developers debug program errors. Some programs have internal LP64 bugs that become apparent only when they are compiled for a 64-bit architecture.

Ignore these errors unless you feel like debugging the problem. If it happens in a program distributed as a part of NetBSD, please send a problem report about it.

If your machine halts or panics on a machine check ... that's a different story.

Help! My machine just panic'd with a machine check!

The PALcode has sent the machine check interrupt to the kernel, which panic'd. There is a "logout frame" (machine check information) set up by the PALcode which must be decoded to determine what happened. This is both CPU (ev4, ev5, etc.) and core-logic (ALCOR, Pyxis, APECS, etc) specific.

We only have code to decode this on a couple of the server systems. DEC doesn't document what the codes mean, though we can sometimes piece it together using various header files and source code that have been made redistributable.

A '660' vector usually means “memory ECC error”.

A good percentage of the time a machine check could mean bad hardware. The scope of this FAQ is too broad to tell you exactly what to do if you see one of these. Your best bet would be to carefully copy it down, or cut and paste it, and send it to [email protected], and ask the friendly people there what to do.

Nasty message from the kernel saying something about unaligned accesses

Nothing is wrong with the machine. This happens when programs illegally cast types or make various other type-unsafe assumptions. Unlike the x86 and vax, risc processors require data items to be aligned. The compilers do this automatically, but some programs are so badly written that they override the compiler's choices and force the compiler to accept type-unsafe constructs.

The NetBSD kernel will fix these up on the fly, though it may slow your application down. To fix each unaligned access fault requires:

Using sysctl(8), the action can be tuned to one of:

The default action is equivalent to:

	# sysctl -w machdep.unaligned_print=1
	# sysctl -w machdep.unaligned_fix=1
	# sysctl -w machdep.unaligned_sigbus=0

An unaligned access performed by the kernel will always cause a panic.

Can NetBSD/alpha boot diskless?

Yes. NetBSD/alpha supports diskless booting with BOOTP. You must have a recent version of the SRM console firmware for this to work. For more complete documentation see Netbooting NetBSD/alpha.

If you try to set up a Digital UNIX 3.x (formerly DEC OSF/1) system as an NFS server containing NetBSD diskless root partitions, you'll run into a problem: Digital UNIX 3.x does not properly handle NetBSD device nodes. Apparently, to ease the transition from 16-bit to 32-bit device nodes, Digital added run-time conversion code to convert from the old device node format to the new format. Unfortunately, this causes the device nodes as seen by a diskless NetBSD to be garbage. The only solutions to this are binary or source modifications to the Digital UNIX kernel, so, for most users, the easiest solution is to simply not use a Digital UNIX system as the server for NetBSD diskless clients. Rumor has it that Digital Unix 4.x does not suffer from this problem.

How do I make a hard disk bootable?

To make a hard disk bootable, you have to copy the NetBSD/alpha second-stage bootstrap, /usr/mdec/boot, to the root directory of the file system on the disk's a partition and use the installboot(8) program to install the first-stage bootstrap.

Using sd1 as an example:

    # mount the file system
    mount /dev/sd1a /mnt

    # install the bootstrap programs
    cd /usr/mdec
    cp boot /mnt
    ./installboot /dev/rsd1c bootxx_ffs

This example (even adjusted to use the correct path names and disk device names for your system) might not work in all situations. You should read the installboot(8) manual page for more details about using installboot.

In addition to working for hard disks, this procedure also works for SCSI removable-media devices (such as Zip and Jaz drives) that contain BSD disklabels.

AlphaStation kernel panics

If you experience kernel panics at boot after upgrading from NetBSD 1.3.3 to a newer version (e.g. NetBSD 1.4), consider upgrading your SRM firmware. There were at least 2 reports that on AlphaStation 200 4/100 upgrading the firmware to version 6.9 made the newer kernel boot correctly.

Alpha firmware updates are available from http://ftp.digital.com/pub/DEC/Alpha/firmware/.

Coexisting with Tru64 Unix (aka Digital Unix, aka OSF/1)

It appears that Tru64 Unix uses filesystems which look like what NetBSD calls “old-style ffs”. So, you should be able to mount a Tru64 filesystem under NetBSD; it will be recognized by NetBSD's compatibility code. Mounting a NetBSD filesystem under Tru64 Unix is dangerous; a Tru64 fsck will destroy the fs. There is a possibility that a fs created using NetBSD's newfs -O would work interchangeably between the two.

We have one report that a filesystem with too many files in it will appear to be empty.

Whatever you try, we recommend that you try it first with data that's not important to you, and we ask that you let us know if you learn anything new, so that we can update this page.

Other sources of information

---

Back to  NetBSD/alpha ports page