This directory contains boot blocks and related things: bb is boot blocks other directories are support specific to some particular VAX: naut for Nautilus (8550 et al), uvax for MicroVAX (II and III). How booting works, and how the pieces fit in: The scheme is stolen from the VAX-11/750 (comet) hardware. Some boot code (call it a ROM, as it is in the comet) is copied into a standard place in memory. The ROM is chosen according to boot device; it contains a subroutine to read a block from the device, and code to initialize the device and read the first 512 bytes off that device into the bottom of memory. The ROM then branches to the code it read in, with a pointer to the device driver and the parameters it needs left in registers. Hence the boot block (the code read into low memory) can be device- and processor-independent; it need only know about the filesystem it wants to read. The boot block reads in /unix directly, or prompts for a name and reads that file. There is no intermediate program like the old /boot; the boot block does it all. (It wasn't easy fitting it into 512 bytes.) /unix must be in the filesystem beginning at the front of the boot device, and must be no more than singly indirect. On some VAXes, like the 11/750, 8200, and 6200, the hardware provides ROMs that work exactly as above. On other known real (not Micro) VAXes, there's no convenient ROM, but there is a separate console computer with its own disk, and booting is controlled by a command file. The command file just copies code that does what the ROM should do into the proper place in memory, sets registers, and starts it. MicroVAXes are rather different. The only way to boot involves the standard DEC VMB boot program, which has device drivers for everything in the world but won't let the boot block use them. It also understands FILES-11 filesystems, which is of course useless for Unix. Fortunately it also understands a somewhat complicated boot block scheme. Hence the following subterfuge: For the MicroVAX, booting involves the first 1024 bytes of the boot device, not just the first 512. Sector 0 contains a header that VMB understands, with various magic numbers and checksums; there's also enough space left over for code that does what the ROM is meant to do, and a prologue that copies it to the right place in memory and starts it. Sector 1 contains the same boot block used by real VAXes. The VMB header causes sector 0 to be loaded and the prologue code started; the pseudo-ROM code loads sector 1 instead of sector 0; thereafter things work exactly as for real VAXes. For real VAXes, pick a boot block from bb according to filesystem type. You may also need to get stuff from some other directory to stuff in the console. For MicroVAXes, pick a boot block from uvax according to boot device and filesystem type. Here are some magic numbers. For more details, look in the chapter on the VAX-11/750 console subsystem in the VAX Hardware Handbook. The ROM is expected to occupy physical addresses 0xfa00-0xfdff while booting happens. The important point is that the boot block doesn't overwrite that part of memory until it's all done, and that the MicroVAX hack code and the console command files load the pseudo-ROM there. When the ROM is started, the registers should contain: R3 == device unit number R5 == boot flags, to be preserved SP == address of useable memory + 0x200 The ROM sets up the device, reads the first 512-byte block into the bottom of memory, and branches to address 0xC. The registers contain: R1 R2 == device address stuff for driver R3 == device unit number R5 == boot flags R6 == addr of device driver SP == addr of useful memory + 0x200 The boot flags in R5 are passed to Unix. They are copied into R11 as well, for compatibility with broken code from the past. The following flags are interesting: 01 makes the boot block ask for a filename, rather than assuming `unix'. The prompt is `*'. There are no erase and kill, but a nonexistent file makes it prompt again. 02 makes Unix come up single-user rather than multi-user. The device driver reads one 512-byte block into memory. It expects the registers to contain R1 R2 == address stuff as above R3 == device unit number R5 == where in memory to put data 4(SP) == where in memory to put data R8 == block number R0 is returned with an odd value iff things worked. The memory address will probably work only if <64K. The driver is allowed to scribble on R0 R7 R8 R9 FP.