/*
* Copyright (c) 1995 Charles D. Cranor
* 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.
*
* 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.
*/
/*
* Converted to SUN ie driver by Charles D. Cranor,
* October 1994, January 1995.
*/
/*
* The i82586 is a very painful chip, found in sun3's, sun-4/100's
* sun-4/200's, and VME based suns. The byte order is all wrong for a
* SUN, making life difficult. Programming this chip is mostly the same,
* but certain details differ from system to system. This driver is
* written so that different "ie" interfaces can be controlled by the same
* driver.
*/
/*
* 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 has 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 alignment). 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
*
* The page map to control where ram appears in the address space.
* We choose to have RAM start at 0 in the 24 bit address space.
*
* to get the physical address of the board's RAM you must take the
* top 12 bits of the physical address of the register address and
* or in the 4 bits from the status word as bits 17-20 (remember that
* the board ignores the chip's top 4 address lines). For example:
* if the register is @ 0xffe88000, then the top 12 bits are 0xffe00000.
* to get the 4 bits from the status word just do status & IEVME_HADDR.
* suppose the value is "4". Then just shift it left 16 bits to get
* it into bits 17-20 (e.g. 0x40000). Then or it to get the
* address of RAM (in our example: 0xffe40000). see the attach routine!
*
*
* on-board interface:
*
* on the onboard ie interface the 24 bit address space is hardwired
* to be 0xff000000 -> 0xffffffff of KVA. this means that sc_iobase
* will be 0xff000000. sc_maddr will be where ever we allocate RAM
* in KVA. note that since the SCP is at a fixed address it means
* that we have to allocate a fixed KVA for the SCP.
* <fill in useful info later>
*
*
* VME3E interface:
*
* <fill in useful info later>
*
*/
/*
* VME/multibus definitions
*/
#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 order */
#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 {
uint16_t pgmap[IEVME_MAPSZ];
uint16_t xxx[32]; /* prom */
uint16_t status; /* see below for bits */
uint16_t xxx2; /* filler */
uint16_t pectrl; /* parity control (see below) */
uint16_t 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 */
/* Supported media */
static int media[] = {
IFM_ETHER | IFM_10_2,
};
#define NMEDIA __arraycount(media)
/* read a 16-bit value at BH offset */
uint16_t ie_vme_read16(struct ie_softc *, int offset);
/* write a 16-bit value at BH offset */
void ie_vme_write16(struct ie_softc *, int offset, uint16_t value);
void ie_vme_write24(struct ie_softc *, int offset, int addr);
uint16_t
ie_vme_read16(struct ie_softc *sc, int offset)
{
uint16_t v;
v = bus_space_read_2(sc->bt, sc->bh, offset);
return (((v&0xff)<<8) | ((v>>8)&0xff));
}
void
ie_vme_write16(struct ie_softc *sc, int offset, uint16_t v)
{
int v0 = ((((v)&0xff)<<8) | (((v)>>8)&0xff));
bus_space_write_2(sc->bt, sc->bh, offset, v0);
}
void
ie_vme_write24(struct ie_softc *sc, int offset, int addr)
{
u_char *f = (u_char *)&addr;
uint16_t v0, v1;
u_char *t;
/*
* *note*: We don't detect the difference between a VME3E and a
* multibus/vme card. If you want to use a 3E you'll have to fix this.
*/
mod = 0x3d; /* VME_AM_A24|VME_AM_MBO|VME_AM_SUPER|VME_AM_DATA */
if (vme_space_alloc(va->va_vct, va->r[0].offset,
sizeof(struct ievme), mod) ||
vme_space_alloc(va->va_vct, va->r[1].offset,
va->r[1].size, mod))
panic("if_ie: vme alloc");
/*
* Set up mappings, direct map except for last page
* which is mapped at zero and at high address (for scp)
*/
for (lcv = 0; lcv < IEVME_MAPSZ - 1; lcv++)
write_iev(vsc, pgmap[lcv], IEVME_SBORDR | IEVME_OBMEM | lcv);
write_iev(vsc, pgmap[IEVME_MAPSZ - 1], IEVME_SBORDR | IEVME_OBMEM | 0);
/* Clear all ram */
bus_space_set_region_2(sc->bt, sc->bh, 0, 0, memsize/2);
/*
* We use the first page to set up SCP, ICSP and SCB data
* structures. The remaining pages become the buffer area
* (managed in i82586.c).
* SCP is in double-mapped page, so the 586 can see it at
* the mandatory magic address (IE_SCP_ADDR).
*/
sc->scp = (IE_SCP_ADDR & (IEVME_PAGESIZE - 1));
