i2hw.h

linux-2.6.15.6

receive loadware from the host.

It is good practice to perform a command reset to the board explicitly as part
of your software initialization.  This allows your code to properly restart from
a soft boot. (Many systems do not issue channel reset on soft boot).

Because of a hardware reset problem on some of the Cirrus Logic 1400's which are
used on the product, it is recommended that you reset the board twice, separated
by an approximately 50 milliseconds delay. (VERY approximately: probably ok to
be off by a factor of five. The important point is that the first command reset
in fact generates a reset pulse on the board. This pulse is guaranteed to last
less than 10 milliseconds. The additional delay ensures the 1400 has had the
chance to respond sufficiently to the first reset. Why not a longer delay? Much
more than 50 milliseconds gets to be noticable, but the board would still work.

Once all 16 bytes of the Power-on Reset Message have been read, the bootstrap
firmware is ready to receive loadware.

Note on Power-on Reset Message format:
The various fields have been designed with future expansion in view.
Combinations of bitfields and values have been defined which define products
which may not currently exist. This has been done to allow drivers to anticipate
the possible introduction of products in a systematic fashion. This is not
intended to suggest that each potential product is actually under consideration.
------------------------------------------------------------------------------*/

//----------------------------------------
// Format of Power-on Reset Message
//----------------------------------------

typedef union _porStr		// "por" stands for Power On Reset
{
	unsigned char  c[16];	// array used when considering the message as a
							// string of undifferentiated characters

	struct					// Elements used when considering values
	{
		// The first two bytes out of the FIFO are two magic numbers. These are
		// intended to establish that there is indeed a member of the
		// IntelliPort-II(EX) family present. The remaining bytes may be 
		// expected // to be valid. When reading the Power-on Reset message, 
		// if the magic numbers do not match it is probably best to stop
		// reading immediately. You are certainly not reading our board (unless
		// hardware is faulty), and may in fact be reading some other piece of
		// hardware.

		unsigned char porMagic1;   // magic number: first byte == POR_MAGIC_1 
		unsigned char porMagic2;   // magic number: second byte == POR_MAGIC_2 

		// The Version, Revision, and Subrevision are stored as absolute numbers
		// and would normally be displayed in the format V.R.S (e.g. 1.0.2)

		unsigned char porVersion;  // Bootstrap firmware version number
		unsigned char porRevision; // Bootstrap firmware revision number
		unsigned char porSubRev;   // Bootstrap firmware sub-revision number

		unsigned char porID;	// Product ID:  Bit-mapped according to
								// conventions described below. Among other
								// things, this allows us to distinguish
								// IntelliPort-II boards from IntelliPort-IIEX
								// boards.

		unsigned char porBus;	// IntelliPort-II: Unused
								// IntelliPort-IIEX: Bus Information:
								// Bit-mapped below

		unsigned char porMemory;	// On-board DRAM size: in 32k blocks

		// porPorts1 (and porPorts2) are used to determine the ports which are
		// available to the board. For non-expandable product, a single number 
		// is sufficient. For expandable product, the board may be connected
		// to as many as four boxes. Each box may be (so far) either a 16-port
		// or an 8-port size. Whenever an 8-port box is used, the remaining 8
		// ports leave gaps between existing channels. For that reason,
		// expandable products must report a MAP of available channels. Since 
		// each UART supports four ports, we represent each UART found by a
		// single bit. Using two bytes to supply the mapping information we
		// report the presense or absense of up to 16 UARTS, or 64 ports in
		// steps of 4 ports. For -IIEX products, the ports are numbered
		// starting at the box closest to the controller in the "chain".

		// Interpreted Differently for IntelliPort-II and -IIEX.
		// -II:   Number of ports (Derived actually from product ID). See
		// Diag1&2 to indicate if uart was actually detected.
		// -IIEX: Bit-map of UARTS found, LSB (see below for MSB of this). This
		//        bitmap is based on detecting the uarts themselves; 
		//        see porFlags for information from the box i.d's.
		unsigned char  porPorts1;

		unsigned char  porDiag1;	// Results of on-board P.O.S.T, 1st byte
		unsigned char  porDiag2;	// Results of on-board P.O.S.T, 2nd byte
		unsigned char  porSpeed;	// Speed of local CPU: given as MHz x10
									// e.g., 16.0 MHz CPU is reported as 160
		unsigned char  porFlags;	// Misc information (see manifests below)
									// Bit-mapped: CPU type, UART's present

		unsigned char  porPorts2;	// -II:  Undefined
									// -IIEX: Bit-map of UARTS found, MSB (see
									//        above for LSB)

		// IntelliPort-II: undefined
		// IntelliPort-IIEX: 1 << porFifoSize gives the size, in bytes, of the
		// host interface FIFO, in each direction. When running the -IIEX in
		// 8-bit mode, fifo capacity is halved. The bootstrap firmware will
		// have already accounted for this fact in generating this number.
		unsigned char  porFifoSize;

		// IntelliPort-II: undefined
		// IntelliPort-IIEX: The number of boxes connected. (Presently 1-4)
		unsigned char  porNumBoxes;
	} e;
} porStr, *porStrPtr;

//--------------------------
// Values for porStr fields
//--------------------------

//---------------------
// porMagic1, porMagic2
//----------------------
//
#define  POR_MAGIC_1    0x96  // The only valid value for porMagic1
#define  POR_MAGIC_2    0x35  // The only valid value for porMagic2
#define  POR_1_INDEX    0     // Byte position of POR_MAGIC_1
#define  POR_2_INDEX    1     // Ditto for POR_MAGIC_2

//----------------------
// porID
//----------------------
//
#define  POR_ID_FAMILY  0xc0	// These bits indicate the general family of
								// product.
#define  POR_ID_FII     0x00	// Family is "IntelliPort-II"
#define  POR_ID_FIIEX   0x40	// Family is "IntelliPort-IIEX"

// These bits are reserved, presently zero. May be used at a later date to
// convey other product information.
//
#define POR_ID_RESERVED 0x3c

#define POR_ID_SIZE     0x03	// Remaining bits indicate number of ports &
								// Connector information.
#define POR_ID_II_8     0x00	// For IntelliPort-II, indicates 8-port using
								// standard brick.
#define POR_ID_II_8R    0x01	// For IntelliPort-II, indicates 8-port using
								// RJ11's (no CTS)
#define POR_ID_II_6     0x02	// For IntelliPort-II, indicates 6-port using
								// RJ45's
#define POR_ID_II_4     0x03	// For IntelliPort-II, indicates 4-port using
								// 4xRJ45 connectors
#define POR_ID_EX       0x00	// For IntelliPort-IIEX, indicates standard
								// expandable controller (other values reserved)

//----------------------
// porBus
//----------------------

// IntelliPort-IIEX only: Board is installed in a 16-bit slot
//
#define POR_BUS_SLOT16  0x20

// IntelliPort-IIEX only: DIP switch #8 is on, selecting 16-bit host interface
// operation.
// 
#define POR_BUS_DIP16   0x10

// Bits 0-2 indicate type of bus: This information is stored in the bootstrap
// loadware, different loadware being used on different products for different
// buses. For most situations, the drivers do not need this information; but it
// is handy in a diagnostic environment. For example, on microchannel boards,
// you would not want to try to test several interrupts, only the one for which
// you were configured.
//
#define  POR_BUS_TYPE   0x07

// Unknown:  this product doesn't know what bus it is running in. (e.g. if same
// bootstrap firmware were wanted for two different buses.)
//
#define  POR_BUS_T_UNK  0

// Note: existing firmware for ISA-8 and MC-8 currently report the POR_BUS_T_UNK
// state, since the same bootstrap firmware is used for each.

#define  POR_BUS_T_MCA  1  // MCA BUS */
#define  POR_BUS_T_EISA 2  // EISA BUS */
#define  POR_BUS_T_ISA  3  // ISA BUS */

// Values 4-7 Reserved

// Remaining bits are reserved

//----------------------
// porDiag1
//----------------------

#define  POR_BAD_MAPPER 0x80	// HW failure on P.O.S.T: Chip mapper failed

// These two bits valid only for the IntelliPort-II
//
#define  POR_BAD_UART1  0x01	// First  1400 bad
#define  POR_BAD_UART2  0x02	// Second 1400 bad

//----------------------
// porDiag2
//----------------------

#define  POR_DEBUG_PORT 0x80	// debug port was detected by the P.O.S.T
#define  POR_DIAG_OK    0x00	// Indicates passage: Failure codes not yet
								// available.
								// Other bits undefined.
//----------------------
// porFlags
//----------------------

#define  POR_CPU     0x03	// These bits indicate supposed CPU type
#define  POR_CPU_8   0x01	// Board uses an 80188 (no such thing yet)
#define  POR_CPU_6   0x02	// Board uses an 80186 (all existing products)
#define  POR_CEX4    0x04	// If set, this is an ISA-CEX/4: An ISA-4 (asic)
							// which is architected like an ISA-CEX connected
							// to a (hitherto impossible) 4-port box.
#define POR_BOXES    0xf0	// Valid for IntelliPort-IIEX only: Map of Box
							// sizes based on box I.D.
#define POR_BOX_16   0x10	// Set indicates 16-port, clear 8-port

//-------------------------------------
// LOADWARE and DOWNLOADING CODE
//-------------------------------------

/*
Loadware may be sent to the board in two ways:
1) It may be read from a (binary image) data file block by block as each block
	is sent to the board. This is only possible when the initialization is
	performed by code which can access your file system. This is most suitable
	for diagnostics and appications which use the interface library directly.

2) It may be hard-coded into your source by including a .h file (typically
	supplied by Computone), which declares a data array and initializes every
	element. This acheives the same result as if an entire loadware file had 
	been read into the array.

	This requires more data space in your program, but access to the file system
	is not required. This method is more suited to driver code, which typically
	is running at a level too low to access the file system directly.

At present, loadware can only be generated at Computone.

All Loadware begins with a header area which has a particular format. This
includes a magic number which identifies the file as being (purportedly)
loadware, CRC (for the loader), and version information.
*/


//-----------------------------------------------------------------------------
// Format of loadware block
//
// This is defined as a union so we can pass a pointer to one of these items
// and (if it is the first block) pick out the version information, etc.
//
// Otherwise, to deal with this as a simple character array
//------------------------------------------------------------------------------

#define LOADWARE_BLOCK_SIZE   512   // Number of bytes in each block of loadware

typedef union _loadHdrStr
{
	unsigned char c[LOADWARE_BLOCK_SIZE];  // Valid for every block

	struct	// These fields are valid for only the first block of loadware.
	{
		unsigned char loadMagic;		// Magic number: see below
		unsigned char loadBlocksMore;	// How many more blocks?
		unsigned char loadCRC[2];		// Two CRC bytes: used by loader
		unsigned char loadVersion;		// Version number
		unsigned char loadRevision;		// Revision number
		unsigned char loadSubRevision;	// Sub-revision number
		unsigned char loadSpares[9];	// Presently unused
		unsigned char loadDates[32];	// Null-terminated string which can give
										// date and time of compilation
	} e;
} loadHdrStr, *loadHdrStrPtr;

//------------------------------------
// Defines for downloading code:
//------------------------------------

// The loadMagic field in the first block of the loadfile must be this, else the
// file is not valid.
//
#define  MAGIC_LOADFILE 0x3c

// How do we know the load was successful? On completion of the load, the
// bootstrap firmware returns a code to indicate whether it thought the download
// was valid and intends to execute it. These are the only possible valid codes:
//
#define  LOADWARE_OK    0xc3        // Download was ok
#define  LOADWARE_BAD   0x5a        // Download was bad (CRC error)

// Constants applicable to writing blocks of loadware:
// The first block of loadware might take 600 mS to load, in extreme cases.
// (Expandable board: worst case for sending startup messages to the LCD's).
// The 600mS figure is not really a calculation, but a conservative
// guess/guarantee. Usually this will be within 100 mS, like subsequent blocks.
//
#define  MAX_DLOAD_START_TIME 1000  // 1000 mS
#define  MAX_DLOAD_READ_TIME  100   // 100 mS

// Firmware should respond with status (see above) within this long of host
// having sent the final block.
//
#define  MAX_DLOAD_ACK_TIME   100   // 100 mS, again!

//------------------------------------------------------
// MAXIMUM NUMBER OF PORTS PER BOARD:
// This is fixed for now (with the expandable), but may
// be expanding according to even newer products.
//------------------------------------------------------
//
#define ABS_MAX_BOXES   4     // Absolute most boxes per board
#define ABS_BIGGEST_BOX 16    // Absolute the most ports per box
#define ABS_MOST_PORTS  (ABS_MAX_BOXES * ABS_BIGGEST_BOX)

#endif   // I2HW_H