Hello fellow 2.11BSD'ers: This is part 0 of 22 - the "README" file. There will follow (probably not in order) 22 additional patch files for 2.11BSD (NOT 2.10 or 2.10.1!!) Collect all parts before commencing to patch the sources. It might also be worth the time to read/scan the changes to get an idea what is being done. Some of the parts are almost trivial in size while others are quite large. Thought was given to batching the smaller ones but in the end it was decided to leave the patches as individual files. Save this 'README'/note - it will not be repeated in subsequent postings. While numerous (and large), the changes should slip into a stock 2.11BSD system with very little trouble. The diffs which will follow are based on the files present in the USENIX distribution. When the time comes to install the new /boot program remember to also install a new bootblock from /mdec on the drive(s) used for booting. The new boot program relies on the information passed to it from the bootblock (major device number, unit number and controller csr). NOTE: The new boot program relies on information passed by the new bootblocks. A brief summary before the detailed explanation of the what/why/etc: (order not necessarily the same as the detailed description) 1) TMSCP and MSCP drivers have extensive mods for bug fixes, space reduction and capabilities added. 2) the boot code (bootblocks and standalone programs) rewritten to be able to load from any controller/unit. 3) fixes for Fuji160 discs 4) GENERIC kernel support for the RL02 on UNIBUS systems 5) the testing of the "switch register" is gone - the reasons are described in the source file, it was mainly a space constraint. 6) the standalone utilities required some changes to fit in the 48kb limit. 7) the "return" protocol of the standalone utilities was changed, this allows slightly oversized programs to still 'return' to 'boot'. 8) there is now a SINGLE UNIVERSAL TAPEBOOT! this will be described in more detail later, but suffice it to say that ALL 4 tape types can be booted from a SINGLE 512 byte bootblock. (and they said it couldn't be done... :-) 9) 'checksys' had yet another bug in estimating system size. 10) updated documentation for the 'setup' portion of the documents. The following files/directories have undergone extensive modifications to add the following capabilities: 1) the MSCP (ra.c) and TMSCP (tmscp.c) drivers now have their command packet areas external to the kernel. This was done because each TMSCP controller consumed 1900+ bytes of kernel D space and each MSCP controller 1000+ bytes. Having one of each controller put a severe constraint on the kernel D space and having two of each was impossible in a reasonably configured kernel (there simply wasn't 6kb of kernel D space to spare). The external region is allocated in machdep2.c at system startup time (only if MSCP or TMSCP devices are configured in the kernel) and contains space enough for 2 each MSCP and TMSCP controllers. For UNIBUS systems the external region is mapped ONCE in machdep2.c with sufficient UMRs to cover the entire region. NO FURTHER UMRs are allocated by ra.c or tmscp.c to map command packets. If multiple controllers are present this conserves UMRs. All I-O to/from the command packets is handled by computing a virtual address relative to the first UMR mapping the external region. For Q22 (Q-bus) systems the physical address within the external region is calculated. NOTE: This has been *extensively* tested on a Q-BUS system, but i do not have access to a UNIBUS system with MSCP peripherals. IT should work (the method used was copied from the DEUNA driver which DOES work) - but back up your system before trying this. If it does work or you have problems let me know, please. The method used to allocate memory from the external region is the same as m_ioget() in the networking code. No 'free' capability is present, but that shouldn't be a problem - how often does a controller go away while the system is running? ;-) The command packet region is allocated at 'attach' time (when called from iinit() for 'root' fs capable devices) or at autoconfig time. The TMSCP driver has been extensively modified to support multiple controllers (the comment in the earlier version about multi- controller support was erroneous) AS WELL AS multiple drives per controller. The multiple controller capability has been tested, the multiple unit capability has not (but it *should* work ;-) been tested yet [offers of a SCSI interfaced tape drive accepted;-)]. In addition, there were numerous bugs (notably in the Get Unit Status handling) fixed in the TMSCP driver. Bugs in the MSCP driver were also fixed, it is now possible to remove and reinsert RX50s and not get an error. Both the TMSCP and MSCP drivers underwent a bit of a diet and are now noticeably smaller than before. 2) /sys/pdpstand, /sys/mdec The STANDALONE programs and bootblocks were essentially rewritten. It is now possible to load /boot from any controller/drive combination! The bootblocks (/sys/mdec, /mdec) were rewritten to use the R0 and R1 values passed by the boot roms as the booting unit and controller csr respectively. Using those values allows the bootblocks to load /boot from other than drive 0 on controller 0. *extremely* useful in case /boot or the bootblock on the system disc becomes corrupted or missing. THERE IS NOW A UNIVERSAL TAPEBOOT block! There is no longer a separate 'tmscp' bootblock file. ALL 4 (TM/HT/TS/TMSCP) tape types are now supported in a single 512 byte (actually i have 26 bytes free) boot block. If you like tight/lean/mean pdp-11 assembly code then take a look at 'mtboot.s'! Some of the retry/error handling had to be sacrificed to make things fit. 'mtboot' now pays attention to the device it was booted from by the roms! no more assuming that because a HT exists that it must be the load device (a situation i encountered where a HT and a TS were present on the system, the boot roms would load mtboot but then mtboot would test for the presence of HT first and fail). NOTE: Remove 'tmscpboot.s' and 'tmscptape.data' from /sys/pdpstand, they are no longer needed. NOTE: all of the tape types have been tested. (thanks Terry for the help!) All of the standalone programs (boot, mkfs, restor, icheck) have dual controller support added for all devices. This is extendable to additional controllers on a per device basis if desired. The first controller MUST be at the *standard* CSR address and is always known as controller 0. The controller number is encoded in bits 6 and 7 of the unit number, so to refer to controller 1 drive 0 the unit number 64 would be used. Example: after booting the tape/disc you wish to load a program from the second TMSCP controller unit 0 73boot: tms(64,3) would load the 'restor' program from the second controller. IF you have booted from a secondary controller (most boot roms do not support this) the CSR of that controller is placed in the second CSR slot for the device booted from, thus it is automatically controller #1 (the standard CSR is #0). IF you have booted from the standard (#0) controller and attempt to access higher numbered controllers the 'boot' program will prompt you for the CSR. The number you enter MUST be OCTAL. A MAXIMUM of 4 controllers of any type are permitted (only 2 bits to hold the controller number). 'boot' prints out the CSR of the controller booted from now. The bootblocks now pass the major device number to 'boot'. 'boot' in turn passes this information thru to each program loaded including the kernel. 'boot' also passes thru to the unix kernel the bootcsr and unit number. The kernel saves this information (mch_start.s) but at present does little else with it except to pass it on in the event of an [auto]reboot (conf/boot/*). More on this later. NOTE: Unix must still be booted from unit 0 controller 0. It is possible to custom build a kernel which can boot from alternate units but it is NOT possible to boot from alternate controllers. This is a consequence of the way autoconfigure and "root"/'swap' attachment/allocation is done. I doubt the project of allowing the kernel to boot from alternate controllers/units automatically will ever be completed due to the need to rewrite the autoconfigure process. At present the ability to load 'boot' and the standalone utilities from alternate controllers/units will have to suffice. The 'return' protocol used by the standalone programs (icheck, restor, mkfs) has changed because 'icheck' was too large and was overwriting the saved 'rtt' info needed to return to 'boot'. 'icheck' was later modified to be smaller, but the protocol changes were retained so that slightly oversized programs (>48kb) could be used if necessary (this will apply to 'restor' if any changes result in his growing in size). 3) /sys/pdpuba/rl.c In a GENERIC kernel the rl02 driver would crash on a UNIBUS system due to trying to access a register used by QBUS systems. The fix was to test in a nonfaulting manner for the register. Normally a UNIBUS system would not have Q22 defined. The rlreg.h file was updated to not conditionally define the extra register. 4) Misc other changes. 'ubmap' is a short now instead of a 'char/bool' - even alignment was required in the networking code. (/sys/h/uba.h) the check in the network startup code for being on a UNIBUS system (sys_net.c) was corrected, previously it didn't check 'ubmap' just in case UNIBUS_MAP was turned on for a QBUS system. 'mt' was using a default tape device which would rewind on close. this was kinda silly since most operations using 'mt' want to position the tape and leave it positioned - not rewound! two minor (one line changes) to mt.c and mtio.h were made (thanks Paul!). 'newfs' has a new entry for the 'extended RM02' drive type. this is a Fuji160 (Emulex SC01 or SC03 controller) doing a pseudo RM80 emulation (or double sized RM02, whichever you prefer). /etc/disktab was updated with the additional new name for this drive/controller configuration and /sys/pdpuba/xp.c modified to reflect new partitions for this (RM2X) drive type. NOTE: the Fuji160/rm2x partitions have changed because there was not enough room on the 'd' partition to hold the 2.11BSD distribution. IF you are using this drive/controller combination a dump and reload (i'm sorry) is necessary if you're presently using the 'd' partition. If the 'c' partition is being used as /usr then there is no problem. /usr/src/etc/icheck.c was modified to fit as a standalone program. The modification was a simple #ifdef STANDALONE to reduce the number of inodes read in at a time. /usr/src/etc/restor.c was modified for standalone space constraint reasons. many more register variables were added to reduce the size of the code, some error messages were reduced in verbosity and so on. Just space saving measures were taken (i.e verbosity reduction without loss of meaning). a minor typo in config.c (a NOP of a program) was fixed. 4.3+ style kernel configuration is still a pipedream, so why not update the version of the system which doesn't support 'config' ;-) #0 This file (README) #1 /usr/src/sys/GENERIC/Makefile #2 /usr/src/sys/conf/boot #3 /usr/src/sys/h/uba.h #4 /usr/src/sys/mdec #5 /usr/src/sys/pdp/machdep2.c #6 /usr/src/sys/pdp/mch_start.s #7 /usr/src/sys/pdpstand #8 /usr/src/sys/pdpuba/ra.c #9 /usr/src/sys/pdpuba/rl.c #10 /usr/src/sys/pdpuba/rlreg.h #11 /usr/src/sys/pdpuba/tmscp.c #12 /usr/src/sys/pdpuba/xp.c #13 /usr/src/sys/sys/sys_net.c #14 /usr/src/sys/conf/checksys.c #15 /usr/doc/2.10/setup.2.11/2.t #16 /etc/disktab #17 /usr/src/sys/h/mtio.h #18 /usr/src/bin/mt.c #19 /usr/src/etc/restor/restor.c #20 /usr/src/etc/icheck.c #21 /usr/src/etc/newfs.c #22 /usr/src/etc/config/config.c