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