Too much dust on these files, it's time for them to leave the building.

6 files changed, 0 insertions, 575 deletions

diff --git a/sys/arch/hp300/DOC/Debug.tips b/sys/arch/hp300/DOC/Debug.tips
deleted file mode 100644
index 8a76bc98edf..00000000000
--- a/sys/arch/hp300/DOC/Debug.tips
+++ /dev/null
@@ -1,228 +0,0 @@
-$OpenBSD: Debug.tips,v 1.3 2002/02/10 23:15:05 deraadt Exp $
-$NetBSD: Debug.tips,v 1.2 1994/10/26 07:22:49 cgd Exp $
-
-NOTE: this description applies to the hp300 system with the old BSD
-virtual memory system.  It has not been updated to reflect the new,
-Mach-derived VM system, but should still be useful.
-The new system has no fixed-address "u.", but has a fixed mapping
-for the kernel stack at 0xfff00000.
-
---------------------------------------------------------------------------
-
-Some quick notes on the HPBSD VM layout and kernel debugging.
-
-Physical memory:
-
-Physical memory always ends at the top of the 32 bit address space; i.e. the
-last addressible byte is at 0xFFFFFFFF.  Hence, the start of physical memory
-varies depending on how much memory is installed.  The kernel variable "lowram"
-contains the starting locatation of memory as provided by the ROM.
-
-The low 128k (I think) of the physical address space is occupied by the ROM.
-This is accessible via /dev/mem *only* if the kernel is compiled with DEBUG.
-[ Maybe it should always be accessible? ]
-
-Virtual address spaces:
-
-The hardware page size is 4096 bytes.  The hardware uses a two-level lookup.
-At the highest level is a one page segment table which maps a page table which
-maps the address space.  Each 4 byte segment table entry (described in
-hp300/pte.h) contains the page number of a single page of 4 byte page table
-entries.  Each PTE maps a single page of address space.  Hence, each STE maps
-4Mb of address space and one page containing 1024 STEs is adequate to map the
-entire 4Gb address space.
-
-Both page and segment table entries look similar.  Both have the page frame
-in the upper part and control bits in the lower.  This is the opposite of
-the VAX.  It is easy to convert the page frame number in an STE/PTE to a
-physical address, simply mentally mask out the low 12 bits.  For example
-if a PTE contains 0xFF880019, the physical memory location mapped starts at
-0xFF880000.
-
-Kernel address space:
-
-The kernel resides in its own virtual address space independent of all user
-processes.  When the processor is in supervisor mode (i.e. interrupt or 
-exception handling) it uses the kernel virtual mapping.  The kernel segment
-table is called Sysseg and is allocated statically in hp300/locore.s.  The
-kernel page table is called Systab is also allocated statically in
-hp300/locore.s and consists of the usual assortment of SYSMAPs.
-The size of Systab (Syssize) depends on the configured size of the various
-maps but as currently configured is 9216 PTEs.  Both segment and page tables
-are initialized at bootup in hp300/locore.s.  The segment table never changes
-(except for bits maintained by the hardware).  Portions of the page table
-change as needed.  The kernel is mapped into the address space starting at 0.
-
-Theoretically, any address in the range 0 to Syssize * 4096 (0x2400000 as
-currently configured) is valid.  However, certain addresses are more common
-in dumps than others.  Those are (for the current configuration):
-
-	0         - 0x800000	kernel text and permanent data structures
-	0x917000  - 0x91a000	u-area; 1st page is user struct, last k-stack
-	0x1b1b000 - 0x2400000	user page tables, also kmem_alloc()ed data
-
-User address space:
-
-The user text and data are loaded starting at VA 0.  The user's stack starts
-at 0xFFF00000 and grows toward lower addresses.  The pages above the user
-stack are used by the kernel.  From 0xFFF00000 to 0xFFF03000 is the u-area.
-The 3 PTEs for this range map (read-only) the same memory as does 0x917000
-to 0x91a000 in the kernel address space.  This address range is never used
-by the kernel, but exists for utilities that assume that the u-area sits
-above the user stack.  The pages from FFF03000 up are not used.  They
-exist so that the user stack is in the same location as in HPUX.
-
-The user segment table is allocated along with the page tables from Usrptmap.
-They are contiguous in kernel VA space with the page tables coming before
-the segment table.  Hence, a process has p_szpt+1 pages allocated starting
-at kernel VA p_p0br.
-
-The user segment table is typically very sparse since each entry maps 4Mb.
-There are usually only two valid STEs, one at the start mapping the text/data
-potion of the page table, and one at the end mapping the stack/u-area.  For
-example if the segment table was at 0xFFFFA000 there would be valid entries
-at 0xFFFFA000 and 0xFFFFAFFC.
-
-Random notes:
-
-An important thing to note is that there are no hardware length registers
-on the HP.  This implies that we cannot "pack" data and stack PTEs into the
-same page table page.  Hence, every user page table has at least 2 pages
-(3 if you count the segment table).
-
-The HP maintains the p0br/p0lr and p1br/p1lr PCB fields the same as the
-VAX even though they have no meaning to the hardware.  This also keeps many
-utilities happy.
-
-There is no separate interrupt stack (right now) on the HPs.  Interrupt
-processing is handled on the kernel stack of the "current" process.
-
-Following is a list of things you might want to be able to do with a kernel
-core dump.  One thing you should always have is a ps listing from the core
-file.  Just do:
-
-	ps klaw vmunix.? vmcore.?
-
-Exception related panics (i.e. those detected in hp300/trap.c) will dump
-out various useful information before panicing.  If available, you should
-get this out of the /usr/adm/messages file.  Finally, you should be in adb:
-
-	adb -k vmunix.? vmcore.?
-
-Adb -k will allow you to examine the kernel address space more easily.
-It automatically maps kernel VAs in the range 0 to 0x2400000 to physical
-addresses.  Since the kernel and user address spaces overlap (i.e. both
-start at 0), adb can't let you examine the address space of the "current"
-process as it does on the VAX.
---------
-
-1. Find out what the current process was at the time of the crash:
-
-If you have the dump info from /usr/adm/messages, it should contain the
-PID of the active process.  If you don't have this info you can just look
-at location "Umap".  This is the PTE for the first page of the u-area; i.e.
-the user structure.  Forget about the last 3 hex digits and compare the top
-5 to the ADDR column in the ps listing.
-
-2. Locating a process' user structure:
-
-Get the ADDR field of the desired process from the ps listing.  This is the
-page frame number of the process' user structure.  Tack 3 zeros on to the
-end to get the physical address.  Note that this doesn't give you the kernel
-stack since it is in a different page than the user-structure and pages of
-the u-area are not physically contiguous.
-
-3. Locating a process' proc structure:
-
-First find the process' user structure as described above.  Find the u_procp
-field at offset 0x200 from the beginning.  This gives you the kernel VA of
-the proc structure.
-
-4. Locating a process' page table:
-
-First find the process' user structure as described above.  The first part
-of the user structure is the PCB.  The second longword (third field) of the
-PCB is pcb_ustp, a pointer to the user segment table.  This pointer is
-actually the page frame number.  Again adding 3 zeros yields the physical
-address.  You can now use the values in the segment table to locate the
-page tables.  For example, to locate the first page of the text/data part
-of the page table, use the first STE (longword) in the segment table.
-
-5. Locating a process' kernel stack:
-
-First find the process' page table as described above.  The kernel stack
-is near the end of the user address space.  So, locate the last entry in the
-user segment table (base+0xFFC) and use that entry to find the last page of
-the user page table.  Look at the last 256 entries of this page
-(pagebase+0xFE0)  The first is the PTE for the user-structure.  The second
-was intended to be a read-only page to protect the user structure from the
-kernel stack.  Currently it is read/write and actually allocated.  Hence
-it can wind up being a second page for the kernel stack.  The third is the
-kernel stack.  The last 253 should be zero.  Hence, indirecing through the
-third of these last 256 PTEs will give you the kernel stack page.
-
-An alternate way to do this is to use the p_addr field of the proc structure
-which is found as described above.  The p_addr field is at offset 0x10 in the
-proc structure and points to the first of the PTEs mentioned above (i.e. the
-user structure PTE).
-
-6. Interpreting the info in a "trap type N..." panic:
-
-As mentioned, when the kernel crashes out of hp300/trap.c it will dump some
-useful information.  This dates back to the days when I was debugging the
-exception handling code and had no kernel adb or even kernel crash dump code.
-"trap type" (decimal) is as defined in hp300/trap.h, it doesn't really
-correlate with anything useful.  "code" (hex) is only useful for MMU
-(trap type 8) errors.  It is the concatination of the MMU status register
-(see hp300/cpu.h) in the high 16 bits and the 68020 special status word
-(see the 020 manual page 6-17) in the low 16.  "v" (hex) is the virtual
-address which caused the fault.  "pid" (decimal) is the ID of the process
-running at the time of the exception.  Note that if we panic in an interrupt
-routine, this process may not be related to the panic.  "ps" (hex) is the
-value of the 68020 status register (see page 1-4 of 020 manual) at the time
-of the crash.  If the 0x2000 bit is on, we were in supervisor (kernel) mode
-at the time, otherwise we were in user mode.  "pc" (hex) is the value of the
-PC saved on the hardware exception frame.  It may *not* be the PC of the
-instruction causing the fault (see the 020 manual for details).  The 0x2000
-bit of "ps" dictates whether this is a kernel or user VA.  "sfc" and "dfc"
-are the 68020 source/destination function codes.  They should always be one.
-"p0" and "p1" are the VAX-like region registers.  They are of the form:
-
-	<length> '@' <kernel VA>
-
-where both are in hex.  Following these values are a dump of the processor
-registers (hex).  Check the address registers for values close to "v", the
-fault address.  Most faults are causes by dereferences of bogus pointers.
-Most such dereferences are the result of 020 instructions using the:
-
-	<address-register> '@' '(' offset ')'
-
-addressing mode.  This can help you track down the faulting instruction (since
-the PC may not point to it).  Note that the value of a7 (the stack pointer) is
-ALWAYS the user SP.  This is brain-dead I know.  Finally, is a dump of the
-stack (user/kernel) at the time of the offense.  Before kernel crash dumps,
-this was very useful.
-
-7. Converting kernel virtual address to a physical address.
-
-Adb -k already does this for you, but sometimes you want to know what the
-resulting physical address is rather than what is there.  Doing this is
-simply a matter of indexing into the kernel page table.  In theory we would
-first have to do a lookup in the kernel segment table, but we know that the
-kernel page table is physically contiguous so this isn't necessary.  The
-base of the system page table is "Sysmap", so to convert an address V just
-divide the address by 4096 to get the page number, multiply that by 4 (the
-size of a PTE in bytes) to get a byte offset, and add that to "Sysmap".
-This gives you the address of the PTE mapping V.  You can then get the
-physical address by masking out the low 12 bits of the contents of that PTE.
-To wit:
-
-	*(Sysmap+(VA%1000*4))&fffff000
-
-where VA is the virtual address in question.
-
-This technique should also work for user virtual addresses if you replace
-"Sysmap" with the value of the appropriate processes' P0BR.  This works
-because a user's page table is *virtually* contiguous in the kernel
-starting at P0BR, and adb will handle translating the kernel virtual addresses
-for you.
diff --git a/sys/arch/hp300/DOC/HPMMU.notes b/sys/arch/hp300/DOC/HPMMU.notes
deleted file mode 100644
index 0d525d2e076..00000000000
--- a/sys/arch/hp300/DOC/HPMMU.notes
+++ /dev/null
@@ -1,148 +0,0 @@
-$OpenBSD: HPMMU.notes,v 1.4 2002/02/10 23:15:05 deraadt Exp $
-$NetBSD: HPMMU.notes,v 1.2 1994/10/26 07:22:51 cgd Exp $
-
-Overview:
---------
-
-	(Some of this is gleaned from an article in the September 1986
-	Hewlett-Packard Journal and info in the July 1987 HP Communicator)
-
-	Page and segment table entries mimic the Motorola 68851 PMMU,
-	in an effort at upward compatibility.  The HP MMU uses a two
-	level translation scheme.  There are separate (but equal!)
-	translation tables for both supervisor and user modes.  At the
-	lowest level are page tables.  Each page table consists of one
-	or more 4k pages of 1024x4 byte page table entries.  Each PTE
-	maps one 4k page of VA space.  At the highest level is the
-	segment table.  The segment table is a single 4K page of 1024x4
-	byte entries.  Each entry points to a 4k page of PTEs.  Hence
-	one STE maps 4Mb of VA space and one page of STEs is sufficient
-	to map the entire 4Gb address space (what a coincidence!).  The
-	unused valid bit in page and segment table entries must be
-	zero.
-
-	There are separate translation lookaside buffers for the user
-	and supervisor modes, each containing 1024 entries.
-
-	To augment the 68020's instruction cache, the HP CPU has an
-	external cache.  A direct-mapped, virtual cache implementation
-	is used with 16 Kbytes of cache on 320 systems and 32 Kbytes on
-	350 systems.  Each cache entry can contain instructions or data,
-	from either user or supervisor space.  Separate valid bits are
-	kept for user and supervisor entries, allowing for descriminatory
-	flushing of the cache.
-
-	MMU translation and cache-miss detection are done in parallel.
-
-
-Segment table entries:
-------- ----- -------
-
-	bits 31-12:	Physical page frame number of PT page
-	bits 11-4:	Reserved at zero
-			(can software use them?)
-	bit 3:		Reserved at one
-	bit 2:		Set to 1 if segment is read-only, ow read-write
-	bits 1-0:	Valid bits
-			(hardware uses bit 1)
-
-
-Page table entries:
----- ----- -------
-
-	bits 31-12:	Physical page frame number of page
-	bits 11-7:	Available for software use
-	bit 6:		If 1, inhibits caching of data in this page.
-			(both instruction and external cache)
-	bit 5:		Reserved at zero
-	bit 4:		Hardware modify bit
-	bit 3:		Hardware reference bit
-	bit 2:		Set to 1 if page is read-only, ow read-write
-	bits 1-0:	Valid bits
-			(hardware uses bit 0)
-
-
-Hardware registers:
--------- ---------
-
-	The hardware has four longword registers controlling the MMU.
-	The registers can be accessed as shortwords also (remember to
-	add 2 to addresses given below).
-
-	5F4000:	Supervisor mode segment table pointer.  Loaded (as longword)
-		with page frame number (i.e. Physaddr >> 12) of the segment
-		table mapping supervisor space.
-	5F4004: User mode segment table pointer.  Loaded (as longword) with
-		page frame number of the segment table mapping user space.
-	5F4008: TLB control register.  Used to invalid large sections of the
-		TLB.  More info below.
-	5F400C:	MMU command/status register.  Defined as follows:
-
-		bit 15:	If 1, indicates a page table fault occurred
-		bit 14:	If 1, indicates a page fault occurred
-		bit 13: If 1, indicates a protection fault (write to RO page)
-		bit 6:	MC68881 enable.  Tied to chip enable line.
-			(set this bit to enable)
-		bit 5:	MC68020 instruction cache enable.  Tied to Insruction
-			cache disable line.  (set this bit to enable)
-		bit 3:	If 1, indicates an MMU related bus error occurred.
-			Bits 13-15 are now valid.
-		bit 2:	External cache enable.  (set this bit to enable)
-		bit 1:	Supervisor mapping enable.  Enables translation of
-			supervisor space VAs.
-		bit 0:	User mapping enable.  Enables translation of user
-			space VAs.
-
-
-	Any bits set by the hardware are cleared only by software.
-	(i.e. bits 3,13,14,15)
-
-Invalidating TLB:
------------- ---
-
-	All translations:
-		Read the TLB control register (5F4008) as a longword.
-
-	User translations only:
-		Write a longword 0 to TLB register or set the user
-		segment table pointer.
-
-	Supervisor translations only:
-		Write a longword 0x8000 to TLB register or set the
-		supervisor segment table pointer.
-
-	A particular VA translation:
-		Set destination function code to 3 ("purge" space),
-		write a longword 0 to the VA whose translation we are to
-		invalidate, and restore function code.  This apparently
-		invalidates any translation for that VA in both the user
-		and supervisor LB.  Here is what I did:
-
-		#define FC_PURGE 3
-		#define FC_USERD 1
-		_TBIS:
-			movl	sp@(4),a0	| VA to invalidate
-			moveq	#FC_PURGE,d0	| change address space
-			movc	d0,dfc		|   for destination
-			moveq	#0,d0		| zero to invalidate?
-			movsl	d0,a0@		| hit it
-			moveq	#FC_USERD,d0	| back to old
-			movc	d0,dfc		|   address space
-			rts			| done
-
-
-Invalidating the external cache:
------------- --- -------- -----
-
-	Everything:
-		Toggle the cache enable bit (bit 2) in the MMU control
-		register (5F400C).  Can be done by ANDing and ORing the
-		register location.
-
-	User:
-		Change the user segment table pointer register (5F4004),
-		i.e. read the current value and write it back.
-
-	Supervisor:
-		Change the supervisor segment table pointer register
-		(5F4000), i.e. read the current value and write it back.
diff --git a/sys/arch/hp300/DOC/Options b/sys/arch/hp300/DOC/Options
deleted file mode 100644
index 6e4d08dbe81..00000000000
--- a/sys/arch/hp300/DOC/Options
+++ /dev/null
@@ -1,66 +0,0 @@
-$OpenBSD: Options,v 1.10 2001/12/06 01:02:50 miod Exp $
-$NetBSD: Options,v 1.7 1997/09/12 08:04:12 mycroft Exp $
-
-Here is a list of HP300 specific kernel compilation options and what they
-mean:
-
-HP320
-	Support for HP320 machines: 16MHz 68020, HP MMU, 16MHz 68881 and VAC.
-	Compiles in support for a VAC, HP MMU, and the 98620A 16-bit DMA
-	channel.
-
-HP350
-	Support for HP350 machines: 25MHz 68020, HP MMU, 20MHz 68881 and VAC.
-	Compiles in support for a VAC and the HP MMU.  Differs from HP320 in
-	that it has no support for 16-bit DMA controller.
-
-HP330
-	Support for HP330 (and 318, 319) machines: 16MHz 68020, 68851 PMMU
-	and 16MHz 68881.  Compiles in support for PMMU.
-
-HP340
-	Support for HP340 machines: 25MHz 68030+MMU and 25MHz 68882.  Compiles
-	in support for PMMU and 68030.  Differs from HP330 in support for
-	68030 on-chip data cache.
-
-HP345
-HP360
-HP370
-HP375
-HP400
-	Support for HP345, 360, 370, 375 and 400 machines: 33 (or 50) MHz
-	68030+MMU and 33 (or 50) MHz 68882.  Compiles in support for PMMU,
-	68030 and off-chip physically addressed cache.  Differs from 340
-	in only one place, in dealing with flushing the external cache.
-
-HP380
-HP385
-HP425
-HP433
-	Support for HP380, 385, 425 and 433 machines: 25 (or 33) MHz 68040
-	with MMU/FPU.  Compiles in support for 68040.
-
-USELEDS
-	Twinkle the HP4xx front panel (or HP3xx internal) LEDs in the HP
-	designated way.  Somewhat frivolous, but the heartbeat LED is
-	useful to see if your machine is alive.
-
-DEBUG
-	Compiles in a variety of consistency checks and debug printfs
-	throughout the hp300 MD code and device drivers.
-
-COMPAT_HPUX
-	Enables HP-UX binary compatibility mode.  Allows a variety of
-	"recent" HP-UX m68k binaries to be run unchanged.  Due to the
-	evolutionary and "as-needed" nature of this code, "recent" is
-	anywhere from release 6.2 to 8.0 of HP-UX.  It will run 8.0
-	shared-library binaries (assuming all the necessary shared-libraries
-	are installed in the filesystem).
-
-DCMSTATS
-	Compile in code to collect a variety of transmit/receive statistics
-	for the 98642 4-port MUX.
-
-WAITHIST
-	Compile in code to collect statistics about the distribution of
-	wait-times for various busy waits in the SCSI host-adaptor driver.
diff --git a/sys/arch/hp300/DOC/README b/sys/arch/hp300/DOC/README
deleted file mode 100644
index 33c94691754..00000000000
--- a/sys/arch/hp300/DOC/README
+++ /dev/null
@@ -1,25 +0,0 @@
-$OpenBSD: README,v 1.3 2001/12/06 01:02:50 miod Exp $
-$NetBSD: README,v 1.2 1994/10/26 07:22:55 cgd Exp $
-
-This directory contains random snippets related to various hp300 issues.
-
-Debug.tips	Some tips for debugging kernel problems.  Out of date but
-		may contains some useful info.
-
-HPMMU.notes	Most of this information was collected by David Davis in
-		1987 or so while he was working on hp200/300 BSD.
-
-Options		Kernel configuration options that are either defined in
-		the prototype makefile or that can be specified in a config
-		file.
-
-README		This.
-
-TODO.dev	A fairly ancient list of projects related to IO devices.
-
-TODO.hp300	A much more up do date list of general hp300 projects.
-
-Mike Hibler (mike@cs.utah.edu)
-Center for Software Science
-University of Utah
-February, 1993.
diff --git a/sys/arch/hp300/DOC/TODO.dev b/sys/arch/hp300/DOC/TODO.dev
deleted file mode 100644
index acd5b490e81..00000000000
--- a/sys/arch/hp300/DOC/TODO.dev
+++ /dev/null
@@ -1,20 +0,0 @@
-$OpenBSD: TODO.dev,v 1.2 1997/01/12 15:12:11 downsj Exp $
-$NetBSD: TODO.dev,v 1.2 1994/10/26 07:22:57 cgd Exp $
-
-[ this is old -- mike ]
-
-Oh, where do I begin...
-
-1. Integrate 98628A (single port buffered RS232) driver.
-2. Integrate 1/2" 9-track reel tape driver (from Mt Xinu).
-3. SCSI: sync support and connect/disconnect.
-4. VME/EISA adaptor drivers needed.
-5. Centronics driver for 345/375.
-6. HP-IB (SCSI?) improvement: attempt to get more activity on a single
-   bus (e.g. overlap seeks with transfers).
-7. Support for more modern (post-DaVinci) displays.
-
-----
-Mike Hibler
-University of Utah CSS group
-mike@cs.utah.edu
diff --git a/sys/arch/hp300/DOC/TODO.hp300 b/sys/arch/hp300/DOC/TODO.hp300
deleted file mode 100644
index 7c5ea196302..00000000000
--- a/sys/arch/hp300/DOC/TODO.hp300
+++ /dev/null
@@ -1,88 +0,0 @@
-$OpenBSD: TODO.hp300,v 1.2 1997/01/12 15:12:12 downsj Exp $
-$NetBSD: TODO.hp300,v 1.2 1994/10/26 07:22:59 cgd Exp $
-
-1. Create and use an interrupt stack.
-   Well actually, use the master SP for kernel stacks instead of
-   the interrupt SP.  Right now we use the interrupt stack for
-   everything.  Allows for more accurate accounting of systime.
-   In theory, could also allow for smaller kernel stacks but we
-   only use one page anyway.
-
-2. Copy/clear primitives could be tuned.
-   What is best is highly CPU and cache dependent.  One thing to look
-   at are the copyin/copyout primitives.  Rather than looping using
-   MOVS instructions, you could map an entire page at a time and use
-   bcopy, MOVE16, or whatever.  This would lose big on the VAC models
-   however.
-
-3. Sendsig/sigreturn are pretty bogus.
-   Currently we can call a signal handler even if an excpetion
-   occurs in the middle of an instruction.  This causes the handler
-   to return right back to the middle of the offending instruction
-   which will most likely lead to another exception/signal.
-   Technically, I feel this is the correct behavior but it requires
-   saving a lot of state on the user's stack, state that we don't
-   really want the user messing with.  Other 68k implementations
-   (e.g. Sun) will delay signals or abort execution of the current
-   instruction to reduce saved state.  Even if we stick with the
-   current philosophy, the code could be cleaned up.
-
-4. Ditto for AST and software interrupt emulation.
-   Both are possibly over-elaborate and inefficiently implemented.
-   We could possibly handle them by using an appropriately planted
-   PS trace bit.
-
-5. Make use of transparent translation registers on 030/040 MMU.
-   With a little rearranging of the KVA space we could use one to
-   map the entire external IO space [ 600000 - 20000000 ).  Since
-   the translation must be 1-1, this would limit the kernel to 6mb
-   (some would say that is hardly a limit) or divide it into two
-   pieces.  Another promising use would be to map physical memory
-   within the kernel.  This allows a much simpler and more efficient
-   implementation of /dev/mem, pmap_zero_page, pmap_copy_page and
-   possible even kernel-user cross address space copies.  However,
-   it does eat up a significant piece of kernel address space.
-
-6. Create a 32-bit timer.
-   Timers 2 and 3 on the MC6840 clock chip can be concatonated together to
-   get a 32-bit countdown timer.  There are at least three uses for this:
-   1. Monitoring the interval timer ("clock") to detect lost "ticks".
-      (Idea from Scott Marovich)
-   2. Implement the DELAY macro properly instead of approximating with
-      the current "while (--count);" loop.  Because of caches, the current
-      method is potentially way off.
-   3. Export as a user-mappable timer for high-precision (4us) timing.
-   Note that by doing this we can no longer use timer 3 as a separate
-   statistics/profiling timer.  Should be able to compile-time (runtime?)
-   select between the two.
-
-7. Conditional MMU code sould be restructured.
-   Right now it reflects the evolutionary path of the code: 320/350 MMU
-   was supported and PMMU support was glued on.  The latter can be ifdef'ed
-   out when not needed, but not all of the former (e.g. ``mmutype'' tests).
-   Also, PMMU is made to look like the HP MMU somewhat ham-stringing it.
-   Since HP MMU models are dead, the excess baggage should be there (though
-   it could be argued that they benefit more from the minor performance
-   impact).  MMU code should probably not be ifdef'ed on model type, but
-   rather on more relevant tags (e.g. MMU_HP, MMU_MOTO).
-
-8. Redo cache handling.
-   There are way too many routines which are specific to particular
-   cache types.  We should be able to come up with a more coherent
-   scheme (though HP 68k boxes have just about every caching scheme
-   imaginable: internal/external, physical/virtual, writeback/writethrough)
-   See, for example, Wheeler and Bershad in ASPLOS 92.
-
-9. Sort the free page list.
-   The DMA hardware on the 300 cannot do scatter/gather IO.  For example,
-   if an 8k system buffer consists of two non-contiguous physical pages
-   it will require two DMA transfers (and hence two interrupts) to do the
-   operation.  It would take only one transfer if they were physically
-   contiguous.  By keeping the free list ordered we could potentially
-   allocate contiguous pages and reduce the number of interrupts.  We can
-   consider doing this since pages in the free list are not reclaimed and
-   thus we don't have to worry about distorting any LRU behavior.
-----
-Mike Hibler
-University of Utah CSS group
-mike@cs.utah.edu