 |
Home page |
|
Documentation top level |
srm_fw file?It also means you can boot any system, even ones that have display hardware that we don't support. And in fact, NetBSD/alpha development funding has placed emphasis on running general servers and X clients, but not on running X servers and other desktop boxes, so sometimes the only way to boot is to use a serial console. On a few older systems, the graphics hardware is completely undocumented, so serial consoles save the day there, too.
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 in the back that determines the console mode. I believe 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 just like the Pee Cee, 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 PeeCee 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.
...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 /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).
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:
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.
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.
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.
Examples:
srm_fw file?
(top)
Be sure to read the upgrade advice posted to the tru64-unix-managers mailing list.
foo.c:91: cast from pointer to integer of different size.An alpha is a 64bit native machine. Unlike a pentium or mac, which are 32 bit machines. 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.
foo.c:192: initializer element for `foo' is not computable at load timeis 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.
/usr/local/lib/gcc-lib/alpha-unknown-netbsd1.3/2.7.2.2/cpp
However, NetBSD 1.3.2 and the most recent binary snapshot of the development branch (NetBSD-current) install the toolchain elements into the usual places. If you see this problem and you are not running the 1.3.3 release or a snapshot from June 1998 or later, then just upgrade! (It's free.)
/*
* 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
/*
* 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
Both the communicator and navigator packages will run faster and provide more features than mozilla, but they require OSF1/Digital Unix/Tru64 libraries in /emul/osf1.
| Bus | Driver | Card | Product Code | Memory | Max Resolution | Depth |
|---|---|---|---|---|---|---|
| PCI | tga | ZLXp-E1 | PBXGA-AA | 2 | 1280x1024 | 8 |
| PCI | tga | ZLXp-E2 | PBXGA-BA | 8 | 1280x1024 | 32 |
| PCI | tga | ZLXp-E3 | PBXGA-CA | 16 | 1280x1024 | 32 |
| PCI | tga | PowerStorm 3d30 | PBXGB-AA | 2 | 1280x1024 | 8 |
| PCI | tga | PowerStorm 4d20 | PBXGB-BA | 16 | 1600x1200 | 32 |
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 = makeThis 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. A large number of programs that work on the PeeCee have internal LP64 bugs that become apparent only when they are compiled for a 64-bit architecture. (Well, sometimes: ``when compiled for any other architecture'', but that's a different story.)
Ignore these errors unless you feel like debugging the problem. If it happens in a program distributed as a part of NetBSD, we may need to hear about it.
If your machine halts or panics on a machine check ... thats a different story.
We only have code to decode this on a couple of the server systems in NetBSD 1.4. 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 port-alpha@NetBSD.org, and ask the friendly people there what to do.
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=0An unaligned access performed by the kernel will always cause a panic.
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.
In NetBSD 1.4 and later, there is a different primary bootstrap program for each different root-capable filesystem; this program automatically finds and loads /boot.
Using sd1 as an example:
# mount the file system
mount /dev/sd1a /mnt
# install the bootstrap programs
cd /usr/mdec
cp boot /mnt
sync
sync
./installboot /mnt/boot /usr/mdec/bootxx /dev/rsd1c
# 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.
For those of you wanting to create a NetBSD/Alpha bootable CD
from the cdhdtape image file and with access to only a Windows
based CD writer, here's one way to do it.
Get the free "Nero" demo (v4.0) from
AHEAD Software and
simply go in File/Burn Image, choose the cdhdtape
file.
Click OK to set options when asked and use:
Type of image: data mode 1 Block size: 2048 Image header (bytes): 0 Image trailer (bytes): 0and leave the "Raw Data", "Scrambled" and "Swapped" checkboxes unchecked.
That will do it.
I noticed that when booting from the CD I got a few "dka400.4.0.6.0 is not ready" right after "NetBSD/Alpha 1.4 Primary Boot +" but the boot process continued without problems. (I'm running on DEC Alpha Server 400 4/166)
Alpha firmware updates are available from http://ftp.digital.com/pub/DEC/Alpha/firmware/.
pid prog CALL [-10] pid prog PSIG SIGSYS SIG_DFL pid prog NAMI "prog.core"Then it is trying to make a Mach system call. The file /sys/compat/osf1/README.mach-traps spells out the problem.
In general, apps which are linked to libpthreads.so or libpthread.so tend to use mach system calls. Luckily, not many interesting apps are. Acroread is the only productivity app found so far.
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.
|
|