1 |
1275 |
phoenix |
/*******************************************************************************
|
2 |
|
|
*
|
3 |
|
|
* (c) 1999 by Computone Corporation
|
4 |
|
|
*
|
5 |
|
|
********************************************************************************
|
6 |
|
|
*
|
7 |
|
|
*
|
8 |
|
|
* PACKAGE: Linux tty Device Driver for IntelliPort II family of multiport
|
9 |
|
|
* serial I/O controllers.
|
10 |
|
|
*
|
11 |
|
|
* DESCRIPTION: Definitions limited to properties of the hardware or the
|
12 |
|
|
* bootstrap firmware. As such, they are applicable regardless of
|
13 |
|
|
* operating system or loadware (standard or diagnostic).
|
14 |
|
|
*
|
15 |
|
|
*******************************************************************************/
|
16 |
|
|
#ifndef I2HW_H
|
17 |
|
|
#define I2HW_H 1
|
18 |
|
|
//------------------------------------------------------------------------------
|
19 |
|
|
// Revision History:
|
20 |
|
|
//
|
21 |
|
|
// 23 September 1991 MAG First Draft Started...through...
|
22 |
|
|
// 11 October 1991 ... Continuing development...
|
23 |
|
|
// 6 August 1993 Added support for ISA-4 (asic) which is architected
|
24 |
|
|
// as an ISA-CEX with a single 4-port box.
|
25 |
|
|
//
|
26 |
|
|
// 20 December 1996 AKM Version for Linux
|
27 |
|
|
//
|
28 |
|
|
//------------------------------------------------------------------------------
|
29 |
|
|
/*------------------------------------------------------------------------------
|
30 |
|
|
|
31 |
|
|
HARDWARE DESCRIPTION:
|
32 |
|
|
|
33 |
|
|
Introduction:
|
34 |
|
|
|
35 |
|
|
The IntelliPort-II and IntelliPort-IIEX products occupy a block of eight (8)
|
36 |
|
|
addresses in the host's I/O space.
|
37 |
|
|
|
38 |
|
|
Some addresses are used to transfer data to/from the board, some to transfer
|
39 |
|
|
so-called "mailbox" messages, and some to read bit-mapped status information.
|
40 |
|
|
While all the products in the line are functionally similar, some use a 16-bit
|
41 |
|
|
data path to transfer data while others use an 8-bit path. Also, the use of
|
42 |
|
|
command /status/mailbox registers differs slightly between the II and IIEX
|
43 |
|
|
branches of the family.
|
44 |
|
|
|
45 |
|
|
The host determines what type of board it is dealing with by reading a string of
|
46 |
|
|
sixteen characters from the board. These characters are always placed in the
|
47 |
|
|
fifo by the board's local processor whenever the board is reset (either from
|
48 |
|
|
power-on or under software control) and are known as the "Power-on Reset
|
49 |
|
|
Message." In order that this message can be read from either type of board, the
|
50 |
|
|
hardware registers used in reading this message are the same. Once this message
|
51 |
|
|
has been read by the host, then it has the information required to operate.
|
52 |
|
|
|
53 |
|
|
General Differences between boards:
|
54 |
|
|
|
55 |
|
|
The greatest structural difference is between the -II and -IIEX families of
|
56 |
|
|
product. The -II boards use the Am4701 dual 512x8 bidirectional fifo to support
|
57 |
|
|
the data path, mailbox registers, and status registers. This chip contains some
|
58 |
|
|
features which are not used in the IntelliPort-II products; a description of
|
59 |
|
|
these is omitted here. Because of these many features, it contains many
|
60 |
|
|
registers, too many to access directly within a small address space. They are
|
61 |
|
|
accessed by first writing a value to a "pointer" register. This value selects
|
62 |
|
|
the register to be accessed. The next read or write to that address accesses
|
63 |
|
|
the selected register rather than the pointer register.
|
64 |
|
|
|
65 |
|
|
The -IIEX boards use a proprietary design similar to the Am4701 in function. But
|
66 |
|
|
because of a simpler, more streamlined design it doesn't require so many
|
67 |
|
|
registers. This means they can be accessed directly in single operations rather
|
68 |
|
|
than through a pointer register.
|
69 |
|
|
|
70 |
|
|
Besides these differences, there are differences in whether 8-bit or 16-bit
|
71 |
|
|
transfers are used to move data to the board.
|
72 |
|
|
|
73 |
|
|
The -II boards are capable only of 8-bit data transfers, while the -IIEX boards
|
74 |
|
|
may be configured for either 8-bit or 16-bit data transfers. If the on-board DIP
|
75 |
|
|
switch #8 is ON, and the card has been installed in a 16-bit slot, 16-bit
|
76 |
|
|
transfers are supported (and will be expected by the standard loadware). The
|
77 |
|
|
on-board firmware can determine the position of the switch, and whether the
|
78 |
|
|
board is installed in a 16-bit slot; it supplies this information to the host as
|
79 |
|
|
part of the power-up reset message.
|
80 |
|
|
|
81 |
|
|
The configuration switch (#8) and slot selection do not directly configure the
|
82 |
|
|
hardware. It is up to the on-board loadware and host-based drivers to act
|
83 |
|
|
according to the selected options. That is, loadware and drivers could be
|
84 |
|
|
written to perform 8-bit transfers regardless of the state of the DIP switch or
|
85 |
|
|
slot (and in a diagnostic environment might well do so). Likewise, 16-bit
|
86 |
|
|
transfers could be performed as long as the card is in a 16-bit slot.
|
87 |
|
|
|
88 |
|
|
Note the slot selection and DIP switch selection are provided separately: a
|
89 |
|
|
board running in 8-bit mode in a 16-bit slot has a greater range of possible
|
90 |
|
|
interrupts to choose from; information of potential use to the host.
|
91 |
|
|
|
92 |
|
|
All 8-bit data transfers are done in the same way, regardless of whether on a
|
93 |
|
|
-II board or a -IIEX board.
|
94 |
|
|
|
95 |
|
|
The host must consider two things then: 1) whether a -II or -IIEX product is
|
96 |
|
|
being used, and 2) whether an 8-bit or 16-bit data path is used.
|
97 |
|
|
|
98 |
|
|
A further difference is that -II boards always have a 512-byte fifo operating in
|
99 |
|
|
each direction. -IIEX boards may use fifos of varying size; this size is
|
100 |
|
|
reported as part of the power-up message.
|
101 |
|
|
|
102 |
|
|
I/O Map Of IntelliPort-II and IntelliPort-IIEX boards:
|
103 |
|
|
(Relative to the chosen base address)
|
104 |
|
|
|
105 |
|
|
Addr R/W IntelliPort-II IntelliPort-IIEX
|
106 |
|
|
---- --- -------------- ----------------
|
107 |
|
|
|
108 |
|
|
1 R/W (Not used) (MSB of word-wide data written to Data Port)
|
109 |
|
|
2 R Status Register Status Register
|
110 |
|
|
2 W Pointer Register Interrupt Mask Register
|
111 |
|
|
3 R/W (Not used) Mailbox Registers (6 bits: 11111100)
|
112 |
|
|
4,5 -- Reserved for future products
|
113 |
|
|
6 -- Reserved for future products
|
114 |
|
|
7 R Guaranteed to have no effect
|
115 |
|
|
7 W Hardware reset of board.
|
116 |
|
|
|
117 |
|
|
|
118 |
|
|
Rules:
|
119 |
|
|
All data transfers are performed using the even i/o address. If byte-wide data
|
120 |
|
|
transfers are being used, do INB/OUTB operations on the data port. If word-wide
|
121 |
|
|
transfers are used, do INW/OUTW operations. In some circumstances (such as
|
122 |
|
|
reading the power-up message) you will do INB from the data port, but in this
|
123 |
|
|
case the MSB of each word read is lost. When accessing all other unreserved
|
124 |
|
|
registers, use byte operations only.
|
125 |
|
|
------------------------------------------------------------------------------*/
|
126 |
|
|
|
127 |
|
|
//------------------------------------------------
|
128 |
|
|
// Mandatory Includes:
|
129 |
|
|
//------------------------------------------------
|
130 |
|
|
//
|
131 |
|
|
#include "ip2types.h"
|
132 |
|
|
#include "i2os.h" /* For any o.s., compiler, or host-related issues */
|
133 |
|
|
|
134 |
|
|
//-------------------------------------------------------------------------
|
135 |
|
|
// Manifests for the I/O map:
|
136 |
|
|
//-------------------------------------------------------------------------
|
137 |
|
|
// R/W: Data port (byte) for IntelliPort-II,
|
138 |
|
|
// R/W: Data port (byte or word) for IntelliPort-IIEX
|
139 |
|
|
// Incoming or outgoing data passes through a FIFO, the status of which is
|
140 |
|
|
// available in some of the bits in FIFO_STATUS. This (bidirectional) FIFO is
|
141 |
|
|
// the primary means of transferring data, commands, flow-control, and status
|
142 |
|
|
// information between the host and board.
|
143 |
|
|
//
|
144 |
|
|
#define FIFO_DATA 0
|
145 |
|
|
|
146 |
|
|
// Another way of passing information between the board and the host is
|
147 |
|
|
// through "mailboxes". Unlike a FIFO, a mailbox holds only a single byte of
|
148 |
|
|
// data. Writing data to the mailbox causes a status bit to be set, and
|
149 |
|
|
// potentially interrupting the intended receiver. The sender has some way to
|
150 |
|
|
// determine whether the data has been read yet; as soon as it has, it may send
|
151 |
|
|
// more. The mailboxes are handled differently on -II and -IIEX products, as
|
152 |
|
|
// suggested below.
|
153 |
|
|
//------------------------------------------------------------------------------
|
154 |
|
|
// Read: Status Register for IntelliPort-II or -IIEX
|
155 |
|
|
// The presence of any bit set here will cause an interrupt to the host,
|
156 |
|
|
// provided the corresponding bit has been unmasked in the interrupt mask
|
157 |
|
|
// register. Furthermore, interrupts to the host are disabled globally until the
|
158 |
|
|
// loadware selects the irq line to use. With the exception of STN_MR, the bits
|
159 |
|
|
// remain set so long as the associated condition is true.
|
160 |
|
|
//
|
161 |
|
|
#define FIFO_STATUS 2
|
162 |
|
|
|
163 |
|
|
// Bit map of status bits which are identical for -II and -IIEX
|
164 |
|
|
//
|
165 |
|
|
#define ST_OUT_FULL 0x40 // Outbound FIFO full
|
166 |
|
|
#define ST_IN_EMPTY 0x20 // Inbound FIFO empty
|
167 |
|
|
#define ST_IN_MAIL 0x04 // Inbound Mailbox full
|
168 |
|
|
|
169 |
|
|
// The following exists only on the Intelliport-IIEX, and indicates that the
|
170 |
|
|
// board has not read the last outgoing mailbox data yet. In the IntelliPort-II,
|
171 |
|
|
// the outgoing mailbox may be read back: a zero indicates the board has read
|
172 |
|
|
// the data.
|
173 |
|
|
//
|
174 |
|
|
#define STE_OUT_MAIL 0x80 // Outbound mailbox full (!)
|
175 |
|
|
|
176 |
|
|
// The following bits are defined differently for -II and -IIEX boards. Code
|
177 |
|
|
// which relies on these bits will need to be functionally different for the two
|
178 |
|
|
// types of boards and should be generally avoided because of the additional
|
179 |
|
|
// complexity this creates:
|
180 |
|
|
|
181 |
|
|
// Bit map of status bits only on -II
|
182 |
|
|
|
183 |
|
|
// Fifo has been RESET (cleared when the status register is read). Note that
|
184 |
|
|
// this condition cannot be masked and would always interrupt the host, except
|
185 |
|
|
// that the hardware reset also disables interrupts globally from the board
|
186 |
|
|
// until re-enabled by loadware. This could also arise from the
|
187 |
|
|
// Am4701-supported command to reset the chip, but this command is generally not
|
188 |
|
|
// used here.
|
189 |
|
|
//
|
190 |
|
|
#define STN_MR 0x80
|
191 |
|
|
|
192 |
|
|
// See the AMD Am4701 data sheet for details on the following four bits. They
|
193 |
|
|
// are not presently used by Computone drivers.
|
194 |
|
|
//
|
195 |
|
|
#define STN_OUT_AF 0x10 // Outbound FIFO almost full (programmable)
|
196 |
|
|
#define STN_IN_AE 0x08 // Inbound FIFO almost empty (programmable)
|
197 |
|
|
#define STN_BD 0x02 // Inbound byte detected
|
198 |
|
|
#define STN_PE 0x01 // Parity/Framing condition detected
|
199 |
|
|
|
200 |
|
|
// Bit-map of status bits only on -IIEX
|
201 |
|
|
//
|
202 |
|
|
#define STE_OUT_HF 0x10 // Outbound FIFO half full
|
203 |
|
|
#define STE_IN_HF 0x08 // Inbound FIFO half full
|
204 |
|
|
#define STE_IN_FULL 0x02 // Inbound FIFO full
|
205 |
|
|
#define STE_OUT_MT 0x01 // Outbound FIFO empty
|
206 |
|
|
|
207 |
|
|
//------------------------------------------------------------------------------
|
208 |
|
|
|
209 |
|
|
// Intelliport-II -- Write Only: the pointer register.
|
210 |
|
|
// Values are written to this register to select the Am4701 internal register to
|
211 |
|
|
// be accessed on the next operation.
|
212 |
|
|
//
|
213 |
|
|
#define FIFO_PTR 0x02
|
214 |
|
|
|
215 |
|
|
// Values for the pointer register
|
216 |
|
|
//
|
217 |
|
|
#define SEL_COMMAND 0x1 // Selects the Am4701 command register
|
218 |
|
|
|
219 |
|
|
// Some possible commands:
|
220 |
|
|
//
|
221 |
|
|
#define SEL_CMD_MR 0x80 // Am4701 command to reset the chip
|
222 |
|
|
#define SEL_CMD_SH 0x40 // Am4701 command to map the "other" port into the
|
223 |
|
|
// status register.
|
224 |
|
|
#define SEL_CMD_UNSH 0 // Am4701 command to "unshift": port maps into its
|
225 |
|
|
// own status register.
|
226 |
|
|
#define SEL_MASK 0x2 // Selects the Am4701 interrupt mask register. The
|
227 |
|
|
// interrupt mask register is bit-mapped to match
|
228 |
|
|
// the status register (FIFO_STATUS) except for
|
229 |
|
|
// STN_MR. (See above.)
|
230 |
|
|
#define SEL_BYTE_DET 0x3 // Selects the Am4701 byte-detect register. (Not
|
231 |
|
|
// normally used except in diagnostics.)
|
232 |
|
|
#define SEL_OUTMAIL 0x4 // Selects the outbound mailbox (R/W). Reading back
|
233 |
|
|
// a value of zero indicates that the mailbox has
|
234 |
|
|
// been read by the board and is available for more
|
235 |
|
|
// data./ Writing to the mailbox optionally
|
236 |
|
|
// interrupts the board, depending on the loadware's
|
237 |
|
|
// setting of its interrupt mask register.
|
238 |
|
|
#define SEL_AEAF 0x5 // Selects AE/AF threshold register.
|
239 |
|
|
#define SEL_INMAIL 0x6 // Selects the inbound mailbox (Read)
|
240 |
|
|
|
241 |
|
|
//------------------------------------------------------------------------------
|
242 |
|
|
// IntelliPort-IIEX -- Write Only: interrupt mask (and misc flags) register:
|
243 |
|
|
// Unlike IntelliPort-II, bit assignments do NOT match those of the status
|
244 |
|
|
// register.
|
245 |
|
|
//
|
246 |
|
|
#define FIFO_MASK 0x2
|
247 |
|
|
|
248 |
|
|
// Mailbox readback select:
|
249 |
|
|
// If set, reads to FIFO_MAIL will read the OUTBOUND mailbox (host to board). If
|
250 |
|
|
// clear (default on reset) reads to FIFO_MAIL will read the INBOUND mailbox.
|
251 |
|
|
// This is the normal situation. The clearing of a mailbox is determined on
|
252 |
|
|
// -IIEX boards by waiting for the STE_OUT_MAIL bit to clear. Readback
|
253 |
|
|
// capability is provided for diagnostic purposes only.
|
254 |
|
|
//
|
255 |
|
|
#define MX_OUTMAIL_RSEL 0x80
|
256 |
|
|
|
257 |
|
|
#define MX_IN_MAIL 0x40 // Enables interrupts when incoming mailbox goes
|
258 |
|
|
// full (ST_IN_MAIL set).
|
259 |
|
|
#define MX_IN_FULL 0x20 // Enables interrupts when incoming FIFO goes full
|
260 |
|
|
// (STE_IN_FULL).
|
261 |
|
|
#define MX_IN_MT 0x08 // Enables interrupts when incoming FIFO goes empty
|
262 |
|
|
// (ST_IN_MT).
|
263 |
|
|
#define MX_OUT_FULL 0x04 // Enables interrupts when outgoing FIFO goes full
|
264 |
|
|
// (ST_OUT_FULL).
|
265 |
|
|
#define MX_OUT_MT 0x01 // Enables interrupts when outgoing FIFO goes empty
|
266 |
|
|
// (STE_OUT_MT).
|
267 |
|
|
|
268 |
|
|
// Any remaining bits are reserved, and should be written to ZERO for
|
269 |
|
|
// compatibility with future Computone products.
|
270 |
|
|
|
271 |
|
|
//------------------------------------------------------------------------------
|
272 |
|
|
// IntelliPort-IIEX: -- These are only 6-bit mailboxes !!! -- 11111100 (low two
|
273 |
|
|
// bits always read back 0).
|
274 |
|
|
// Read: One of the mailboxes, usually Inbound.
|
275 |
|
|
// Inbound Mailbox (MX_OUTMAIL_RSEL = 0)
|
276 |
|
|
// Outbound Mailbox (MX_OUTMAIL_RSEL = 1)
|
277 |
|
|
// Write: Outbound Mailbox
|
278 |
|
|
// For the IntelliPort-II boards, the outbound mailbox is read back to determine
|
279 |
|
|
// whether the board has read the data (0 --> data has been read). For the
|
280 |
|
|
// IntelliPort-IIEX, this is done by reading a status register. To determine
|
281 |
|
|
// whether mailbox is available for more outbound data, use the STE_OUT_MAIL bit
|
282 |
|
|
// in FIFO_STATUS. Moreover, although the Outbound Mailbox can be read back by
|
283 |
|
|
// setting MX_OUTMAIL_RSEL, it is NOT cleared when the board reads it, as is the
|
284 |
|
|
// case with the -II boards. For this reason, FIFO_MAIL is normally used to read
|
285 |
|
|
// the inbound FIFO, and MX_OUTMAIL_RSEL kept clear. (See above for
|
286 |
|
|
// MX_OUTMAIL_RSEL description.)
|
287 |
|
|
//
|
288 |
|
|
#define FIFO_MAIL 0x3
|
289 |
|
|
|
290 |
|
|
//------------------------------------------------------------------------------
|
291 |
|
|
// WRITE ONLY: Resets the board. (Data doesn't matter).
|
292 |
|
|
//
|
293 |
|
|
#define FIFO_RESET 0x7
|
294 |
|
|
|
295 |
|
|
//------------------------------------------------------------------------------
|
296 |
|
|
// READ ONLY: Will have no effect. (Data is undefined.)
|
297 |
|
|
// Actually, there will be an effect, in that the operation is sure to generate
|
298 |
|
|
// a bus cycle: viz., an I/O byte Read. This fact can be used to enforce short
|
299 |
|
|
// delays when no comparable time constant is available.
|
300 |
|
|
//
|
301 |
|
|
#define FIFO_NOP 0x7
|
302 |
|
|
|
303 |
|
|
//------------------------------------------------------------------------------
|
304 |
|
|
// RESET & POWER-ON RESET MESSAGE
|
305 |
|
|
/*------------------------------------------------------------------------------
|
306 |
|
|
RESET:
|
307 |
|
|
|
308 |
|
|
The IntelliPort-II and -IIEX boards are reset in three ways: Power-up, channel
|
309 |
|
|
reset, and via a write to the reset register described above. For products using
|
310 |
|
|
the ISA bus, these three sources of reset are equvalent. For MCA and EISA buses,
|
311 |
|
|
the Power-up and channel reset sources cause additional hardware initialization
|
312 |
|
|
which should only occur at system startup time.
|
313 |
|
|
|
314 |
|
|
The third type of reset, called a "command reset", is done by writing any data
|
315 |
|
|
to the FIFO_RESET address described above. This resets the on-board processor,
|
316 |
|
|
FIFO, UARTS, and associated hardware.
|
317 |
|
|
|
318 |
|
|
This passes control of the board to the bootstrap firmware, which performs a
|
319 |
|
|
Power-On Self Test and which detects its current configuration. For example,
|
320 |
|
|
-IIEX products determine the size of FIFO which has been installed, and the
|
321 |
|
|
number and type of expansion boxes attached.
|
322 |
|
|
|
323 |
|
|
This and other information is then written to the FIFO in a 16-byte data block
|
324 |
|
|
to be read by the host. This block is guaranteed to be present within two (2)
|
325 |
|
|
seconds of having received the command reset. The firmware is now ready to
|
326 |
|
|
receive loadware from the host.
|
327 |
|
|
|
328 |
|
|
It is good practice to perform a command reset to the board explicitly as part
|
329 |
|
|
of your software initialization. This allows your code to properly restart from
|
330 |
|
|
a soft boot. (Many systems do not issue channel reset on soft boot).
|
331 |
|
|
|
332 |
|
|
Because of a hardware reset problem on some of the Cirrus Logic 1400's which are
|
333 |
|
|
used on the product, it is recommended that you reset the board twice, separated
|
334 |
|
|
by an approximately 50 milliseconds delay. (VERY approximately: probably ok to
|
335 |
|
|
be off by a factor of five. The important point is that the first command reset
|
336 |
|
|
in fact generates a reset pulse on the board. This pulse is guaranteed to last
|
337 |
|
|
less than 10 milliseconds. The additional delay ensures the 1400 has had the
|
338 |
|
|
chance to respond sufficiently to the first reset. Why not a longer delay? Much
|
339 |
|
|
more than 50 milliseconds gets to be noticable, but the board would still work.
|
340 |
|
|
|
341 |
|
|
Once all 16 bytes of the Power-on Reset Message have been read, the bootstrap
|
342 |
|
|
firmware is ready to receive loadware.
|
343 |
|
|
|
344 |
|
|
Note on Power-on Reset Message format:
|
345 |
|
|
The various fields have been designed with future expansion in view.
|
346 |
|
|
Combinations of bitfields and values have been defined which define products
|
347 |
|
|
which may not currently exist. This has been done to allow drivers to anticipate
|
348 |
|
|
the possible introduction of products in a systematic fashion. This is not
|
349 |
|
|
intended to suggest that each potential product is actually under consideration.
|
350 |
|
|
------------------------------------------------------------------------------*/
|
351 |
|
|
|
352 |
|
|
//----------------------------------------
|
353 |
|
|
// Format of Power-on Reset Message
|
354 |
|
|
//----------------------------------------
|
355 |
|
|
|
356 |
|
|
typedef union _porStr // "por" stands for Power On Reset
|
357 |
|
|
{
|
358 |
|
|
unsigned char c[16]; // array used when considering the message as a
|
359 |
|
|
// string of undifferentiated characters
|
360 |
|
|
|
361 |
|
|
struct // Elements used when considering values
|
362 |
|
|
{
|
363 |
|
|
// The first two bytes out of the FIFO are two magic numbers. These are
|
364 |
|
|
// intended to establish that there is indeed a member of the
|
365 |
|
|
// IntelliPort-II(EX) family present. The remaining bytes may be
|
366 |
|
|
// expected // to be valid. When reading the Power-on Reset message,
|
367 |
|
|
// if the magic numbers do not match it is probably best to stop
|
368 |
|
|
// reading immediately. You are certainly not reading our board (unless
|
369 |
|
|
// hardware is faulty), and may in fact be reading some other piece of
|
370 |
|
|
// hardware.
|
371 |
|
|
|
372 |
|
|
unsigned char porMagic1; // magic number: first byte == POR_MAGIC_1
|
373 |
|
|
unsigned char porMagic2; // magic number: second byte == POR_MAGIC_2
|
374 |
|
|
|
375 |
|
|
// The Version, Revision, and Subrevision are stored as absolute numbers
|
376 |
|
|
// and would normally be displayed in the format V.R.S (e.g. 1.0.2)
|
377 |
|
|
|
378 |
|
|
unsigned char porVersion; // Bootstrap firmware version number
|
379 |
|
|
unsigned char porRevision; // Bootstrap firmware revision number
|
380 |
|
|
unsigned char porSubRev; // Bootstrap firmware sub-revision number
|
381 |
|
|
|
382 |
|
|
unsigned char porID; // Product ID: Bit-mapped according to
|
383 |
|
|
// conventions described below. Among other
|
384 |
|
|
// things, this allows us to distinguish
|
385 |
|
|
// IntelliPort-II boards from IntelliPort-IIEX
|
386 |
|
|
// boards.
|
387 |
|
|
|
388 |
|
|
unsigned char porBus; // IntelliPort-II: Unused
|
389 |
|
|
// IntelliPort-IIEX: Bus Information:
|
390 |
|
|
// Bit-mapped below
|
391 |
|
|
|
392 |
|
|
unsigned char porMemory; // On-board DRAM size: in 32k blocks
|
393 |
|
|
|
394 |
|
|
// porPorts1 (and porPorts2) are used to determine the ports which are
|
395 |
|
|
// available to the board. For non-expandable product, a single number
|
396 |
|
|
// is sufficient. For expandable product, the board may be connected
|
397 |
|
|
// to as many as four boxes. Each box may be (so far) either a 16-port
|
398 |
|
|
// or an 8-port size. Whenever an 8-port box is used, the remaining 8
|
399 |
|
|
// ports leave gaps between existing channels. For that reason,
|
400 |
|
|
// expandable products must report a MAP of available channels. Since
|
401 |
|
|
// each UART supports four ports, we represent each UART found by a
|
402 |
|
|
// single bit. Using two bytes to supply the mapping information we
|
403 |
|
|
// report the presense or absense of up to 16 UARTS, or 64 ports in
|
404 |
|
|
// steps of 4 ports. For -IIEX products, the ports are numbered
|
405 |
|
|
// starting at the box closest to the controller in the "chain".
|
406 |
|
|
|
407 |
|
|
// Interpreted Differently for IntelliPort-II and -IIEX.
|
408 |
|
|
// -II: Number of ports (Derived actually from product ID). See
|
409 |
|
|
// Diag1&2 to indicate if uart was actually detected.
|
410 |
|
|
// -IIEX: Bit-map of UARTS found, LSB (see below for MSB of this). This
|
411 |
|
|
// bitmap is based on detecting the uarts themselves;
|
412 |
|
|
// see porFlags for information from the box i.d's.
|
413 |
|
|
unsigned char porPorts1;
|
414 |
|
|
|
415 |
|
|
unsigned char porDiag1; // Results of on-board P.O.S.T, 1st byte
|
416 |
|
|
unsigned char porDiag2; // Results of on-board P.O.S.T, 2nd byte
|
417 |
|
|
unsigned char porSpeed; // Speed of local CPU: given as MHz x10
|
418 |
|
|
// e.g., 16.0 MHz CPU is reported as 160
|
419 |
|
|
unsigned char porFlags; // Misc information (see manifests below)
|
420 |
|
|
// Bit-mapped: CPU type, UART's present
|
421 |
|
|
|
422 |
|
|
unsigned char porPorts2; // -II: Undefined
|
423 |
|
|
// -IIEX: Bit-map of UARTS found, MSB (see
|
424 |
|
|
// above for LSB)
|
425 |
|
|
|
426 |
|
|
// IntelliPort-II: undefined
|
427 |
|
|
// IntelliPort-IIEX: 1 << porFifoSize gives the size, in bytes, of the
|
428 |
|
|
// host interface FIFO, in each direction. When running the -IIEX in
|
429 |
|
|
// 8-bit mode, fifo capacity is halved. The bootstrap firmware will
|
430 |
|
|
// have already accounted for this fact in generating this number.
|
431 |
|
|
unsigned char porFifoSize;
|
432 |
|
|
|
433 |
|
|
// IntelliPort-II: undefined
|
434 |
|
|
// IntelliPort-IIEX: The number of boxes connected. (Presently 1-4)
|
435 |
|
|
unsigned char porNumBoxes;
|
436 |
|
|
} e;
|
437 |
|
|
} porStr, *porStrPtr;
|
438 |
|
|
|
439 |
|
|
//--------------------------
|
440 |
|
|
// Values for porStr fields
|
441 |
|
|
//--------------------------
|
442 |
|
|
|
443 |
|
|
//---------------------
|
444 |
|
|
// porMagic1, porMagic2
|
445 |
|
|
//----------------------
|
446 |
|
|
//
|
447 |
|
|
#define POR_MAGIC_1 0x96 // The only valid value for porMagic1
|
448 |
|
|
#define POR_MAGIC_2 0x35 // The only valid value for porMagic2
|
449 |
|
|
#define POR_1_INDEX 0 // Byte position of POR_MAGIC_1
|
450 |
|
|
#define POR_2_INDEX 1 // Ditto for POR_MAGIC_2
|
451 |
|
|
|
452 |
|
|
//----------------------
|
453 |
|
|
// porID
|
454 |
|
|
//----------------------
|
455 |
|
|
//
|
456 |
|
|
#define POR_ID_FAMILY 0xc0 // These bits indicate the general family of
|
457 |
|
|
// product.
|
458 |
|
|
#define POR_ID_FII 0x00 // Family is "IntelliPort-II"
|
459 |
|
|
#define POR_ID_FIIEX 0x40 // Family is "IntelliPort-IIEX"
|
460 |
|
|
|
461 |
|
|
// These bits are reserved, presently zero. May be used at a later date to
|
462 |
|
|
// convey other product information.
|
463 |
|
|
//
|
464 |
|
|
#define POR_ID_RESERVED 0x3c
|
465 |
|
|
|
466 |
|
|
#define POR_ID_SIZE 0x03 // Remaining bits indicate number of ports &
|
467 |
|
|
// Connector information.
|
468 |
|
|
#define POR_ID_II_8 0x00 // For IntelliPort-II, indicates 8-port using
|
469 |
|
|
// standard brick.
|
470 |
|
|
#define POR_ID_II_8R 0x01 // For IntelliPort-II, indicates 8-port using
|
471 |
|
|
// RJ11's (no CTS)
|
472 |
|
|
#define POR_ID_II_6 0x02 // For IntelliPort-II, indicates 6-port using
|
473 |
|
|
// RJ45's
|
474 |
|
|
#define POR_ID_II_4 0x03 // For IntelliPort-II, indicates 4-port using
|
475 |
|
|
// 4xRJ45 connectors
|
476 |
|
|
#define POR_ID_EX 0x00 // For IntelliPort-IIEX, indicates standard
|
477 |
|
|
// expandable controller (other values reserved)
|
478 |
|
|
|
479 |
|
|
//----------------------
|
480 |
|
|
// porBus
|
481 |
|
|
//----------------------
|
482 |
|
|
|
483 |
|
|
// IntelliPort-IIEX only: Board is installed in a 16-bit slot
|
484 |
|
|
//
|
485 |
|
|
#define POR_BUS_SLOT16 0x20
|
486 |
|
|
|
487 |
|
|
// IntelliPort-IIEX only: DIP switch #8 is on, selecting 16-bit host interface
|
488 |
|
|
// operation.
|
489 |
|
|
//
|
490 |
|
|
#define POR_BUS_DIP16 0x10
|
491 |
|
|
|
492 |
|
|
// Bits 0-2 indicate type of bus: This information is stored in the bootstrap
|
493 |
|
|
// loadware, different loadware being used on different products for different
|
494 |
|
|
// buses. For most situations, the drivers do not need this information; but it
|
495 |
|
|
// is handy in a diagnostic environment. For example, on microchannel boards,
|
496 |
|
|
// you would not want to try to test several interrupts, only the one for which
|
497 |
|
|
// you were configured.
|
498 |
|
|
//
|
499 |
|
|
#define POR_BUS_TYPE 0x07
|
500 |
|
|
|
501 |
|
|
// Unknown: this product doesn't know what bus it is running in. (e.g. if same
|
502 |
|
|
// bootstrap firmware were wanted for two different buses.)
|
503 |
|
|
//
|
504 |
|
|
#define POR_BUS_T_UNK 0
|
505 |
|
|
|
506 |
|
|
// Note: existing firmware for ISA-8 and MC-8 currently report the POR_BUS_T_UNK
|
507 |
|
|
// state, since the same bootstrap firmware is used for each.
|
508 |
|
|
|
509 |
|
|
#define POR_BUS_T_MCA 1 // MCA BUS */
|
510 |
|
|
#define POR_BUS_T_EISA 2 // EISA BUS */
|
511 |
|
|
#define POR_BUS_T_ISA 3 // ISA BUS */
|
512 |
|
|
|
513 |
|
|
// Values 4-7 Reserved
|
514 |
|
|
|
515 |
|
|
// Remaining bits are reserved
|
516 |
|
|
|
517 |
|
|
//----------------------
|
518 |
|
|
// porDiag1
|
519 |
|
|
//----------------------
|
520 |
|
|
|
521 |
|
|
#define POR_BAD_MAPPER 0x80 // HW failure on P.O.S.T: Chip mapper failed
|
522 |
|
|
|
523 |
|
|
// These two bits valid only for the IntelliPort-II
|
524 |
|
|
//
|
525 |
|
|
#define POR_BAD_UART1 0x01 // First 1400 bad
|
526 |
|
|
#define POR_BAD_UART2 0x02 // Second 1400 bad
|
527 |
|
|
|
528 |
|
|
//----------------------
|
529 |
|
|
// porDiag2
|
530 |
|
|
//----------------------
|
531 |
|
|
|
532 |
|
|
#define POR_DEBUG_PORT 0x80 // debug port was detected by the P.O.S.T
|
533 |
|
|
#define POR_DIAG_OK 0x00 // Indicates passage: Failure codes not yet
|
534 |
|
|
// available.
|
535 |
|
|
// Other bits undefined.
|
536 |
|
|
//----------------------
|
537 |
|
|
// porFlags
|
538 |
|
|
//----------------------
|
539 |
|
|
|
540 |
|
|
#define POR_CPU 0x03 // These bits indicate supposed CPU type
|
541 |
|
|
#define POR_CPU_8 0x01 // Board uses an 80188 (no such thing yet)
|
542 |
|
|
#define POR_CPU_6 0x02 // Board uses an 80186 (all existing products)
|
543 |
|
|
#define POR_CEX4 0x04 // If set, this is an ISA-CEX/4: An ISA-4 (asic)
|
544 |
|
|
// which is architected like an ISA-CEX connected
|
545 |
|
|
// to a (hitherto impossible) 4-port box.
|
546 |
|
|
#define POR_BOXES 0xf0 // Valid for IntelliPort-IIEX only: Map of Box
|
547 |
|
|
// sizes based on box I.D.
|
548 |
|
|
#define POR_BOX_16 0x10 // Set indicates 16-port, clear 8-port
|
549 |
|
|
|
550 |
|
|
//-------------------------------------
|
551 |
|
|
// LOADWARE and DOWNLOADING CODE
|
552 |
|
|
//-------------------------------------
|
553 |
|
|
|
554 |
|
|
/*
|
555 |
|
|
Loadware may be sent to the board in two ways:
|
556 |
|
|
1) It may be read from a (binary image) data file block by block as each block
|
557 |
|
|
is sent to the board. This is only possible when the initialization is
|
558 |
|
|
performed by code which can access your file system. This is most suitable
|
559 |
|
|
for diagnostics and appications which use the interface library directly.
|
560 |
|
|
|
561 |
|
|
2) It may be hard-coded into your source by including a .h file (typically
|
562 |
|
|
supplied by Computone), which declares a data array and initializes every
|
563 |
|
|
element. This acheives the same result as if an entire loadware file had
|
564 |
|
|
been read into the array.
|
565 |
|
|
|
566 |
|
|
This requires more data space in your program, but access to the file system
|
567 |
|
|
is not required. This method is more suited to driver code, which typically
|
568 |
|
|
is running at a level too low to access the file system directly.
|
569 |
|
|
|
570 |
|
|
At present, loadware can only be generated at Computone.
|
571 |
|
|
|
572 |
|
|
All Loadware begins with a header area which has a particular format. This
|
573 |
|
|
includes a magic number which identifies the file as being (purportedly)
|
574 |
|
|
loadware, CRC (for the loader), and version information.
|
575 |
|
|
*/
|
576 |
|
|
|
577 |
|
|
|
578 |
|
|
//-----------------------------------------------------------------------------
|
579 |
|
|
// Format of loadware block
|
580 |
|
|
//
|
581 |
|
|
// This is defined as a union so we can pass a pointer to one of these items
|
582 |
|
|
// and (if it is the first block) pick out the version information, etc.
|
583 |
|
|
//
|
584 |
|
|
// Otherwise, to deal with this as a simple character array
|
585 |
|
|
//------------------------------------------------------------------------------
|
586 |
|
|
|
587 |
|
|
#define LOADWARE_BLOCK_SIZE 512 // Number of bytes in each block of loadware
|
588 |
|
|
|
589 |
|
|
typedef union _loadHdrStr
|
590 |
|
|
{
|
591 |
|
|
unsigned char c[LOADWARE_BLOCK_SIZE]; // Valid for every block
|
592 |
|
|
|
593 |
|
|
struct // These fields are valid for only the first block of loadware.
|
594 |
|
|
{
|
595 |
|
|
unsigned char loadMagic; // Magic number: see below
|
596 |
|
|
unsigned char loadBlocksMore; // How many more blocks?
|
597 |
|
|
unsigned char loadCRC[2]; // Two CRC bytes: used by loader
|
598 |
|
|
unsigned char loadVersion; // Version number
|
599 |
|
|
unsigned char loadRevision; // Revision number
|
600 |
|
|
unsigned char loadSubRevision; // Sub-revision number
|
601 |
|
|
unsigned char loadSpares[9]; // Presently unused
|
602 |
|
|
unsigned char loadDates[32]; // Null-terminated string which can give
|
603 |
|
|
// date and time of compilation
|
604 |
|
|
} e;
|
605 |
|
|
} loadHdrStr, *loadHdrStrPtr;
|
606 |
|
|
|
607 |
|
|
//------------------------------------
|
608 |
|
|
// Defines for downloading code:
|
609 |
|
|
//------------------------------------
|
610 |
|
|
|
611 |
|
|
// The loadMagic field in the first block of the loadfile must be this, else the
|
612 |
|
|
// file is not valid.
|
613 |
|
|
//
|
614 |
|
|
#define MAGIC_LOADFILE 0x3c
|
615 |
|
|
|
616 |
|
|
// How do we know the load was successful? On completion of the load, the
|
617 |
|
|
// bootstrap firmware returns a code to indicate whether it thought the download
|
618 |
|
|
// was valid and intends to execute it. These are the only possible valid codes:
|
619 |
|
|
//
|
620 |
|
|
#define LOADWARE_OK 0xc3 // Download was ok
|
621 |
|
|
#define LOADWARE_BAD 0x5a // Download was bad (CRC error)
|
622 |
|
|
|
623 |
|
|
// Constants applicable to writing blocks of loadware:
|
624 |
|
|
// The first block of loadware might take 600 mS to load, in extreme cases.
|
625 |
|
|
// (Expandable board: worst case for sending startup messages to the LCD's).
|
626 |
|
|
// The 600mS figure is not really a calculation, but a conservative
|
627 |
|
|
// guess/guarantee. Usually this will be within 100 mS, like subsequent blocks.
|
628 |
|
|
//
|
629 |
|
|
#define MAX_DLOAD_START_TIME 1000 // 1000 mS
|
630 |
|
|
#define MAX_DLOAD_READ_TIME 100 // 100 mS
|
631 |
|
|
|
632 |
|
|
// Firmware should respond with status (see above) within this long of host
|
633 |
|
|
// having sent the final block.
|
634 |
|
|
//
|
635 |
|
|
#define MAX_DLOAD_ACK_TIME 100 // 100 mS, again!
|
636 |
|
|
|
637 |
|
|
//------------------------------------------------------
|
638 |
|
|
// MAXIMUM NUMBER OF PORTS PER BOARD:
|
639 |
|
|
// This is fixed for now (with the expandable), but may
|
640 |
|
|
// be expanding according to even newer products.
|
641 |
|
|
//------------------------------------------------------
|
642 |
|
|
//
|
643 |
|
|
#define ABS_MAX_BOXES 4 // Absolute most boxes per board
|
644 |
|
|
#define ABS_BIGGEST_BOX 16 // Absolute the most ports per box
|
645 |
|
|
#define ABS_MOST_PORTS (ABS_MAX_BOXES * ABS_BIGGEST_BOX)
|
646 |
|
|
|
647 |
|
|
#endif // I2HW_H
|
648 |
|
|
|