SCO OpenServer

init(D2mdi)

init -- initialize an MDI version 1 device during system initialization

Synopsis (Not in SVR5 version)

See init(D2oddi) for syntax, arguments, return values, and context information.

Usage

The init( ) routine of all MDI drivers must check that the adapters at the configured I/O Base Addresses (or Slot numbers for EISA and MCA adapters, or Bus, Function, and Device numbers for PCI adapters) are present when the kernel is booted. If an adapter dos not exist, call the printcfg(D3oddi) function to display a message such as the following:

   %smc 0x240-0x25f -     -     ADAPTER NOT FOUND

If the adapter is present and the card found is one that has jumper or switch settings that can neither be read nor written by the UNIX kernel (as is the case with most older ISA cards), then the driver should read the configuration from the UNIX kernel and hope that it is the same as the adapter hardware setup. The driver should then print a successful boot message as described below.

If the adapter found is one that has write-only attributes (that is, ones that have no meaningful value when read or cannot be read at all) from the network adapter hardware, then the driver should read the configuration from the UNIX kernel and configure the adapter appropriately. An example of this is the 3Com Etherlink II Adapter's IRQ and transceiver type settings; they must be initialized by the driver at boot time. Success or failure of this operation should be reported as described below.

If the adapter found as either read-only or read/write configuration settings, then the driver should read its configuration (for example, the IRQ, DMA, ROM Address/Size, RAM Address/Size) from the hardware and configure the kernel to match the hardware setup. Settings obtained from the hardware override any corresponding attributes that may be stored in the link it. The kernel is configured using the functions listed below:

IRQ: add_intr_handler(D3oddi)
idistributed(D3oddi)
DMA channel: dma_alloc(D3oddi)
Shared memory or memory-mapped ROM: sptalloc(D3oddi)

If these functions cannot allocate kernel resources to the driver, use the printcfg( ) function to display a message such as the following:

     %smc 0x240-0x25f    -     -    UNABLE TO ADD INTR HANDLER (9)
     %smc 0x240-0x25f    -     -    UNABLE TO ALLOC DMA CHANNEL (3)
     %smc 0x240-0x25f    -     -    UNABLE TO ALLOC RAM (d0000-d8000)

Ideally, the presence test for the driver will verify that there are no conflicts with other devices. For example, when the shared memory configuration has been read from the adapter and sptalloc(D3oddi) has successfully been called, the driver should read and write every location in the shared memory region before initializing the adapter, to check that the shared memory region does not conflict with another device on the bus.

Microchannel and EISA network adapters are examples of cards that, at least from the view of the operating system, have read-only attributes because these settings can be modified only by the machine's Microchannel or EISA setup program. Some ISA adapters with jumpered settings that can be ready by the driver are also considered to have read-only settings.

ISA cards that are software-configurable are adapters with read/write settings. Most newer ISA cards fall into this category. Note that the settings for cards with read/write attributes are only modified by a network adapter-specific setup program that runs under the operating system; these settings should never be modified by the driver.

If the adapter does exist and the kernel is configured successfully, use the printcfg(D3oddi) function to issue a message in the following format:

     %drv 0xstart-0xstop ivec   dma    type=cardname addr=xx:xx:xx:xx:xx:xx

drv is the driver prefix(D1) used in the mdevice(F) file. For example:

     %smc 0x240-0x25f    9     -    type=8013EWC addr=00:00:c0:91:f5:5a

All network drivers that run on SCO systems should conform to this boot-time processing as much as possible.

Version applicability

mdi: 1

Differences between versions

MDI version 2 drivers must never call the init( ) entry point routine; all initialization for MDI version 2 drivers must be done in the _load(D2mdi) entry point routine.

However, if you have an existing init( ) routine (for example, from an SCO OpenServer driver), you can retain it in your MDI 2 driver as long as it is called from the _load( ) entry point routine. This ensures that dynamic loading will function properly. Note that there is a corresponding _unload(D2mdi) entry point routine for MDI 2 drivers, so to maintain this convention, you should write a corresponding uninit( ) routine.

References

init(D2oddi)

add_intr_handler(D3oddi), cdistributed(D3oddi), idistributed(D3oddi), printcfg(D3oddi), sdistributed(D3oddi), start(D2oddi)

``ODDI driver interface version for SCO OpenServer 5'' in HDK Technical Reference