NetBSD/alpha Frequently Asked Questions
- 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 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?
- 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:
Connect the MMJ “TX+” to the serial port's “RXD”.
Connect the MMJ “RX+” to the serial port's “TXD”.
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.
It is possible to run on the bare hardware. But there are some things that the PALcode does that are quite model-specific:
various cache issues
various interrupt issues (e.g. issuing EOIs, interrupt routing, etc.)
machine checks generated by the core logic
machine checks generated by the I/O processors
...and the list goes on.
This doesn't include the processor-model specific stuff:
- TLB differences
- cache differences
- trap differences
..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
--disassemble, and grep for the
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).
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:
It's very geared to NT's kernel model
Memory management is essentially MIPS-like, and also limits the virtual address space to 32-bit (except for some virtual address extension hack used to get at the hardware in the kernel)
It's ... amazingly large and complex. The number of NT PALcode calls is simply mind boggling.
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:
Based on very old Digital Unix PALcode (from the DEC EBSDK).
Missing various features needed by NetBSD.
Known to have a number of serious bugs.
Worked-over to be built with a totally different toolchain than the PALcode in production SRM.
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.
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.
There are two non-volatile SRM environment variables that affect the automatically initiated console actions.
If set to
a, NetBSD will automatically proceed from single-user to multi-user state. This can be overwritten with the
-floption to the console boot command. This is for compatibility with Digital Unix.
- This tells SRM what to do when it gets control.
Your choices here are BOOT or HALT. The HALT case gets
- This tells SRM which device to boot from. show config can show you what your choices are. To tell it to boot from floppy, for example, you would say set bootdef_dev dva0.
>>> set boot_osflags a >>> set auto_action boot >>> set bootdef_dev dka0 >>> boot -fl a
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
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.
Compiling and Programming
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.
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:
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
long, or to use
char * instead.
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
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
At this time, the following graphics cards are supported:
Table 1. Supported graphics cards
|Bus||Driver||Card||Product Code||Memory||Max Resolution||Depentry|
Note that this applies only to the server; the X client programs run just fine.
> 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.
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.
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 port-alpha@NetBSD.org, and ask the friendly people there what to do.
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:
- Overhead of taking an unaligned access fault.
- Overhead of fixup.
- Additional overhead for (2) because access must be across a protection boundary.
Using sysctl(8), the action can be tuned to one of:
- Silently fixup the unaligned access.
- Print out a message and fixup the unaligned access.
- Silently send the process a SIGBUS.
- Print out a message and send the process a SIGBUS.
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.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.
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.
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/.
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.
Back to NetBSD/alpha ports page