Return to README CVS log

Up to [Research Unix] / researchv10dc / sys / boot

Annotation of researchv10dc/sys/boot/README, revision 1.1.1.1

1.1       root        1: This directory contains boot blocks and related things:
                      2: bb is boot blocks
                      3: other directories are support specific to some particular VAX:
                      4: naut for Nautilus (8550 et al), uvax for MicroVAX (II and III).
                      5: 
                      6: How booting works, and how the pieces fit in:
                      7: The scheme is stolen from the VAX-11/750 (comet) hardware.
                      8: Some boot code (call it a ROM, as it is in the comet) is copied into
                      9: a standard place in memory.  The ROM is chosen according to boot device;
                     10: it contains a subroutine to read a block from the device, and code to
                     11: initialize the device and read the first 512 bytes off that device into
                     12: the bottom of memory.  The ROM then branches to the code it read in,
                     13: with a pointer to the device driver and the parameters it needs left in
                     14: registers.  Hence the boot block (the code read into low memory) can be
                     15: device- and processor-independent; it need only know about the filesystem
                     16: it wants to read.
                     17: 
                     18: The boot block reads in /unix directly, or prompts for a name and reads
                     19: that file.  There is no intermediate program like the old /boot; the boot
                     20: block does it all.  (It wasn't easy fitting it into 512 bytes.)  /unix must
                     21: be in the filesystem beginning at the front of the boot device, and must
                     22: be no more than singly indirect.
                     23: 
                     24: On some VAXes, like the 11/750, 8200, and 6200, the hardware provides ROMs
                     25: that work exactly as above.  On other known real (not Micro) VAXes, there's
                     26: no convenient ROM, but there is a separate console computer with its own
                     27: disk, and booting is controlled by a command file.  The command file just
                     28: copies code that does what the ROM should do into the proper place in memory,
                     29: sets registers, and starts it.
                     30: 
                     31: MicroVAXes are rather different.  The only way to boot involves the standard
                     32: DEC VMB boot program, which has device drivers for everything in the world
                     33: but won't let the boot block use them.  It also understands FILES-11 filesystems,
                     34: which is of course useless for Unix.  Fortunately it also understands a somewhat
                     35: complicated boot block scheme.  Hence the following subterfuge:
                     36: For the MicroVAX, booting involves the first 1024 bytes of the boot device,
                     37: not just the first 512.  Sector 0 contains a header that VMB understands,
                     38: with various magic numbers and checksums; there's also enough space left over
                     39: for code that does what the ROM is meant to do, and a prologue that copies it
                     40: to the right place in memory and starts it.  Sector 1 contains the same boot
                     41: block used by real VAXes.  The VMB header causes sector 0 to be loaded and
                     42: the prologue code started; the pseudo-ROM code loads sector 1 instead of sector
                     43: 0; thereafter things work exactly as for real VAXes.
                     44: 
                     45: For real VAXes, pick a boot block from bb according to filesystem type.
                     46: You may also need to get stuff from some other directory to stuff in the console.
                     47: For MicroVAXes, pick a boot block from uvax according to boot device and
                     48: filesystem type.
                     49: 
                     50: Here are some magic numbers.  For more details, look in the chapter on the
                     51: VAX-11/750 console subsystem in the VAX Hardware Handbook.
                     52: 
                     53: The ROM is expected to occupy physical addresses 0xfa00-0xfdff while booting
                     54: happens.  The important point is that the boot block doesn't overwrite that
                     55: part of memory until it's all done, and that the MicroVAX hack code and the
                     56: console command files load the pseudo-ROM there.
                     57: 
                     58: When the ROM is started, the registers should contain:
                     59:        R3 == device unit number
                     60:        R5 == boot flags, to be preserved
                     61:        SP == address of useable memory + 0x200
                     62: The ROM sets up the device, reads the first 512-byte block into the bottom
                     63: of memory, and branches to address 0xC.  The registers contain:
                     64:        R1 R2 == device address stuff for driver
                     65:        R3 == device unit number
                     66:        R5 == boot flags
                     67:        R6 == addr of device driver
                     68:        SP == addr of useful memory + 0x200
                     69: The boot flags in R5 are passed to Unix.  They are copied into R11 as well,
                     70: for compatibility with broken code from the past.  The following flags are
                     71: interesting:
                     72:        01      makes the boot block ask for a filename, rather than assuming
                     73:                `unix'.  The prompt is `*'.  There are no erase and kill, but
                     74:                a nonexistent file makes it prompt again.
                     75:        02      makes Unix come up single-user rather than multi-user.
                     76: 
                     77: The device driver reads one 512-byte block into memory.  It expects
                     78: the registers to contain
                     79:        R1 R2 == address stuff as above
                     80:        R3 == device unit number
                     81:        R5 == where in memory to put data
                     82:        4(SP) == where in memory to put data
                     83:        R8 == block number
                     84: R0 is returned with an odd value iff things worked.
                     85: The memory address will probably work only if <64K.
                     86: The driver is allowed to scribble on R0 R7 R8 R9 FP.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.