From 49235ceee0c25492d4ca35194d7c72838a9ec284 Mon Sep 17 00:00:00 2001
From: Theo de Raadt <deraadt@cvs.openbsd.org>
Date: Wed, 18 Oct 1995 10:44:53 +0000
Subject: mvme68k port by me. some parts by dale rahn.

---
 sys/arch/mvme68k/dev/if_ie.h | 191 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 191 insertions(+)
 create mode 100644 sys/arch/mvme68k/dev/if_ie.h

(limited to 'sys/arch/mvme68k/dev/if_ie.h')

diff --git a/sys/arch/mvme68k/dev/if_ie.h b/sys/arch/mvme68k/dev/if_ie.h
new file mode 100644
index 00000000000..a17de666905
--- /dev/null
+++ b/sys/arch/mvme68k/dev/if_ie.h
@@ -0,0 +1,191 @@
+/*	$NetBSD$ */
+
+/*
+ * Copyright (c) 1995 Theo de Raadt
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ *      This product includes software developed by Theo de Raadt
+ * 4. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * XXX where else is this from?
+ * if_sunie.h
+ *
+ * sun's ie interface
+ */
+
+/*
+ * programming notes:
+ *
+ * the ie chip operates in a 24 bit address space.
+ *
+ * most ie interfaces appear to be divided into two parts:
+ *	 - generic 586 stuff
+ *	 - board specific
+ *
+ * generic:
+ *	the generic stuff of the ie chip is all done with data structures
+ * 	that live in the chip's memory address space.   the chip expects
+ * 	its main data structure (the sys conf ptr -- SCP) to be at a fixed
+ * 	address in its 24 bit space: 0xfffff4
+ *
+ *      the SCP points to another structure called the ISCP.
+ *      the ISCP points to another structure called the SCB.
+ * 	the SCB has a status field, a linked list of "commands", and
+ * 	a linked list of "receive buffers".   these are data structures that
+ * 	live in memory, not registers.
+ *
+ * board:
+ * 	to get the chip to do anything, you first put a command in the
+ * 	command data structure list.   then you have to signal "attention"
+ * 	to the chip to get it to look at the command.   how you
+ * 	signal attention depends on what board you have... on PC's
+ * 	there is an i/o port number to do this, on sun's there is a
+ * 	register bit you toggle.
+ *
+ * 	to get data from the chip you program it to interrupt...
+ *
+ *
+ * sun issues:
+ *
+ *      there are 3 kinds of sun "ie" interfaces:
+ *        1 - a VME/multibus card
+ *        2 - an on-board interface (sun3's, sun-4/100's, and sun-4/200's)
+ *        3 - another VME board called the 3E
+ *
+ * 	the VME boards lives in vme16 space.   only 16 and 8 bit accesses
+ * 	are allowed, so functions that copy data must be aware of this.
+ *
+ * 	the chip is an intel chip.  this means that the byte order
+ * 	on all the "short"s in the chip's data structures is wrong.
+ * 	so, constants described in the intel docs are swapped for the sun.
+ * 	that means that any buffer pointers you give the chip must be
+ * 	swapped to intel format.   yuck.
+ *
+ *   VME/multibus interface:
+ * 	for the multibus interface the board ignores the top 4 bits
+ * 	of the chip address.   the multibus interface seems to have its
+ * 	own MMU like page map (without protections or valid bits, etc).
+ * 	there are 256 pages of physical memory on the board (each page
+ * 	is 1024 bytes).   there are 1024 slots in the page map.  so,
+ * 	a 1024 byte page takes up 10 bits of address for the offset,
+ * 	and if there are 1024 slots in the page that is another 10 bits
+ * 	of the address.   that makes a 20 bit address, and as stated
+ * 	earlier the board ignores the top 4 bits, so that accounts
+ * 	for all 24 bits of address.
+ *
+ * 	note that the last entry of the page map maps the top of the
+ * 	24 bit address space and that the SCP is supposed to be at
+ * 	0xfffff4 (taking into account allignment).   so,
+ *	for multibus, that entry in the page map has to be used for the SCP.
+ *
+ * 	the page map effects BOTH how the ie chip sees the
+ * 	memory, and how the host sees it.
+ *
+ * 	the page map is part of the "register" area of the board
+ *
+ *   on-board interface:
+ *
+ *	<fill in useful info later>
+ *
+ *
+ *   VME3E interface:
+ *
+ *	<fill in useful info later>
+ *
+ */
+
+/*
+ * PART 1: VME/multibus defs
+ */
+#define IEVME_PAGESIZE 1024	/* bytes */
+#define IEVME_PAGSHIFT 10	/* bits */
+#define IEVME_NPAGES   256	/* number of pages on chip */
+#define IEVME_MAPSZ    1024	/* number of entries in the map */
+
+/*
+ * PTE for the page map
+ */
+#define IEVME_SBORDR 0x8000	/* sun byte order */
+#define IEVME_IBORDR 0x0000	/* intel byte ordr */
+
+#define IEVME_P2MEM  0x2000	/* memory is on P2 */
+#define IEVME_OBMEM  0x0000	/* memory is on board */
+
+#define IEVME_PGMASK 0x0fff	/* gives the physical page frame number */
+
+struct ievme {
+	u_short pgmap[IEVME_MAPSZ];
+	u_short xxx[32];	/* prom */
+	u_short status;		/* see below for bits */
+	u_short xxx2;		/* filler */
+	u_short pectrl;		/* parity control (see below) */
+	u_short peaddr;		/* low 16 bits of address */
+};
+
+/*
+ * status bits
+ */
+#define IEVME_RESET 0x8000	/* reset board */
+#define IEVME_ONAIR 0x4000	/* go out of loopback 'on-air' */
+#define IEVME_ATTEN 0x2000	/* attention */
+#define IEVME_IENAB 0x1000	/* interrupt enable */
+#define IEVME_PEINT 0x0800	/* parity error interrupt enable */
+#define IEVME_PERR  0x0200	/* parity error flag */
+#define IEVME_INT   0x0100	/* interrupt flag */
+#define IEVME_P2EN  0x0020	/* enable p2 bus */
+#define IEVME_256K  0x0010	/* 256kb rams */
+#define IEVME_HADDR 0x000f	/* mask for bits 17-20 of address */
+
+/*
+ * parity control
+ */
+#define IEVME_PARACK 0x0100	/* parity error ack */
+#define IEVME_PARSRC 0x0080	/* parity error source */
+#define IEVME_PAREND 0x0040	/* which end of the data got the error */
+#define IEVME_PARADR 0x000f	/* mask to get bits 17-20 of parity address */
+
+
+/*
+ * PART 2: the on-board interface
+ */
+struct ieob {
+	u_short	porthigh;
+	u_short	portlow;
+	u_long	attn;
+};
+#define IE_PORT_NEWSCPADDR	0x00000002
+#define	IE_PORT_RESET		0x00000000
+
+#define IEOB_ADBASE 0xff000000  /* KVA base addr of 24 bit address space */
+
+/*
+ * PART 3: the 3E board
+ */
+
+/*
+ * not supported (yet?)
+ */
-- 
cgit v1.2.3