The following new DDIs have been added:
The flash control DDI provides a basic interface by abstracting board-specific operations for flash device write enabling and disabling management. The driver implements routines that allow the device driver client to enable and disable the write access on a flash device.
For more information on the Flash Control DDI, refer to "Driver Framework APIs" in the ChorusOS 5.0 BSP Developer's Guide and to the flashCtl(9DDI) man page.
The new watchdog timer is essentially a counter driven by a clock signal. The watchdog timer DDI provides a countdown register, which is the main timer. This register is decremented at each clock tick. Its initial value is set through the limit register, either at initialization time, or at pat time.
If the countdown register reaches zero, a signal is alerted to produce a specified effect (hard reset, soft reset or interrupt). Depending on the type of watchdog device, it is possible to "pat" the timer to avoid this effect. This "patting" of the timer must occur at regular intervals.
The watchdog timer device may operate in two separate modes:
reset mode
interrupt mode
When operating in the reset mode, the watchdog device asserts a board reset signal if a watchdog timeout occurs. When operating in interrupt mode, the watchdog device asserts an interrupt line if a watchdog timeout occurs. The watchdog timer driver interface allows the watchdog device to operate in any mode.
For more information on how the watchdog timer is implemented in ChorusOS 5.0, refer to "Analyzing System Failure: Black Boxes, Watchdog Timers and Logging" in the ChorusOS 5.0 Application Developer's Guide and to the wdtimer(9DDI) man page.
A new architecture has been implemented to provide support for IDE disks and CompactFlash devices. The new architecture includes new Disk and ATA DDIs.
The new Disk DDI is a general purpose DDI, supporting all disks. The ATA DDI provides an API for the employment of ATA device drivers. For more information, see the ata(9DDI) and disk(9DDI) man pages.
To provide communication protocols over an I/O bus, the ChorusOS operating system implements a layered architecture composed of the following:
A physical (low) layer which includes the bus control DDI, the local bus communication DDI and the remote bus communication DDI.
A logical (middle) layer which includes the bus multiplexor DDI.
A protocol (high) layer which includes the ethernet driver (using the multiplexor DDI) and the TCP/IP stack.
The physical layer abstracts the bus architecture, enabling the portability of all upper layers. The main task of the physical communication driver is to make shared memory resources accessible from any board within the communication domain.
Typically, among all physical drivers running on a given CPU board, there is one driver that provides access to the board local memory (exported to the bus). All other physical drivers provide access to the remote memory (imported from the bus). Thus, the total number of physical drivers on a CPU board (visible for the multiplexer) is always equal to the number of CPU boards communicating over the bus (or buses). Another task of the physical layer is to provide interrupt services allowing a cross interrupt to be sent from one CPU board to another.
The logical communication driver (multiplexer) uses services provided by the physical drivers (shared memory and cross interrupts) to implement a low-level communication protocol over the bus. While various implementations of such a communication layer are possible, the ChorusOS operating system implements a basic communication protocol providing simplex (unidirectional) communication channels over the bus.
For more information on these DDI's refer to the buscom(9DDI) and busmux(9DDI) man pages.
The new PCI Resource Manager DDI is used internally by PCI bus drivers to manage PCI bus resources dynamically. This avoids code duplication in all PCI bus drivers as they can rely on a single, generic PCI resource manager driver for the dynamic resource allocation services defined by the PCI DDI. For more information, see the pcimngr(9DDI) man page.
The keyboard DDI (asynchronous mode) defines the upper interface for keyboard device drivers. For more information, see the keyboard(9DDI) man page.
The mouse DDI defines the upper interface for mouse device drivers. For more information, see the mouse(9DDI) man page.
The PCMCIA bus driver provides an API for PCMCIA development. This PCMCIA bus API is an abstraction of the low-level PCMCIA bus services and covers the following PCMCIA functional modules
PCMCIA interrupt management
Access to the I/O device registers
Access to the memory of the PCMCIA device
Power management of the PCMCIA device
Generation of PCMCIA device events
For more information, refer to the pcmcia(9DDI) man page.
The General Purpose I/O (GPIO) DDI provides an interface for device driver development. This DDI abstracts operations for a general purpose I/O port device. For more information, refer to the gpio(9DDI) man page.
This DDI provides a generic interface for handling the ENUM# signal on system CompactPCI boards. For more information, see the hsc(9DDI) man page.
The PCI Swap DDI provides a generic interface to access the Hot Swap control and status register. For more information, refer to the pciswap(9DDI) man page.
The MII DDI provides MII bus driver interface services. The MII bus is a generic bus that connects different types of network physical transceivers (PHYs) to the same network controller. For more information, see the mii(9DDI) man page.
The ethernet PHY transceiver DDI provides PHY device driver services. For more information, see the phy(9DDI) man page.
The management DDI provides services allowing a client to manage device and driver pairs as components. This interface is the same for all classes of bus and device drivers. For more information, see the mngt(9DDI) man page.
The diagnostic DDI allows a client to perform off-line tests on devices. This interface is typically provided by special diagnostic drivers to be started on inactive device nodes (failed or backup devices). For more information, see the diag(9DDI) man page.
The fault injection bus drivers verify that a device driver is resilient to hardware faults. They help to build and validate hardened device drivers. Three new fault injection DDIs are provided:
Bus fault injection driver
PCI fault injection driver
ISA fault injection driver
For more information, see the busFi(9DDI), pciFi(9DDI), and isaFi(9DDI) man pages.
The statistic DDIs are structure definitions used by the management DDI. They enable a client of a driver that exports the management DDI, to retrieve on demand raw I/O statistics since the driver last started. The following new statistics DDIs are provided:
DiskStat
EtherStat
FlashStat
UartStat
For more information, refer to the diskStat(9DDI), etherStat(9DDI), flashStat(9DDI), and uartStat(9DDI) man pages.