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" 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 649