Device Drivers

1. Device Drivers EE138 – SJSU

2. Objectives • Defining device drivers Each piece of hardware that is connected to a computer requires software to control it. This software is known as a device driver. • Discussing the difference between architecture-specific and board-specific drivers • Providing several examples of different types of device drivers

3. Introduction • Most embedded hardware requires some type of software initialization and management. • The software that directly interfaces with and controls this hardware is called a device driver. • Device drivers are the software libraries that initialize the hardware, and manage access to the hardware by higher layers of software. • Device drivers are the liaison between the hardware and the operating system, middleware, and application layers.

4. Types of Device Driver • Device drivers are typically considered either architecture-specific or generic. • Architecture-specific device driver manages the hardware that is integrated into the master processor (the architecture) • initialize and enable components within a master processor include on-chip memory, integrated memory managers (MMUs), and floating point hardware • Generic device driver manages hardware that is located on the board and not integrated onto the master processor. • There are typically architecture-specific portions of source code, because the master processor is the central control unit and to gain access to anything on the board usually means going through the master processor. • The generic driver also manages board hardware that is not specific to that particular processor • Generic drivers include code that initializes and manages access to the remaining major components of the board, including board buses (I2C, PCI, PCMCIA, etc.), off-chip memory (controllers, level-2+ cache, Flash, etc.), and off-chip I/O (Ethernet, RS-232, display, mouse, etc.)

5. Example

6. Typical Device Driver Functions Regardless of the type of device driver or the hardware it manages, all device drivers are generally made up of all or some combination of the following functions: • Hardware Startup, initialization of the hardware upon power-on or reset. • Hardware Shutdown, configuring hardware into its power-off state. • Hardware Disable, allowing other software to disable hardware on-the-fly. • Hardware Enable, allowing other software to enable hardware on-the-fly. • Hardware Acquire, allowing other software to gain singular (locking) access to hardware. • Hardware Release, allowing other software to free (unlock) hardware. • Hardware Read, allowing other software to read data from hardware. • Hardware Write, allowing other software to write data to hardware. • Hardware Install, allowing other software to install new hardware on-the-fly. • Hardware Uninstall, allowing other software to remove installed hardware on-the-fly. • Plus other functions

7. Hardware States • Hardware in the inactive state is interpreted as being either disconnected (thus the need for an install function), without power (hence the need for an initialization routine) or disabled (thus the need for an enable routine). • Hardware that is in a busy state is actively processing some type of data and is not idle, and thus may require some type of release mechanism. • Hardware that is in the finished state is in an idle state, which then allows for acquisition, read, or write requests, for example. These aforementioned functions are based upon the software’s implicit perception of hardware, which is that hardware is in one of three states at any given time—inactive, busy, or finished.

8. Modes of Device Driver • Depending on the master processor, different types of software can execute in different modes, the most common being supervisory and user modes • Software running in supervisory mode having more access (privileges) than software running in user mode • Device driver code typically runs in supervisory mode.

9. Example 1: Device Drivers for Interrupt-Handling • Interrupts are signals triggered by some event during the execution of an instruction stream by the master processor Asynchronously or Synchronously • Asynchronous: external hardware devices, resets, power failures, etc. • Synchronous: for instruction-related activities such as system calls or illegal instructions. These signals cause the master processor to stop executing the current instruction stream and start the process of handling (processing) the interrupt.

10. Interrupt-Handling Device Drivers • Interrupt-Handling Startup, initialization of the interrupt hardware (i.e., interrupt controller, activating interrupts, etc.) upon power-on or reset. • Interrupt-Handling Shutdown, configuring interrupt hardware (i.e., interrupt con- troller, deactivating interrupts, etc.) into its power-off state. • Interrupt-Handling Disable, allowing other software to disable active interrupts on- the-fly (not allowed for Non-Maskable Interrupts (NMIs), which are interrupts that cannot be disabled). • Interrupt-Handling Enable, allowing other software to enable inactive interrupts on-the-fly. • and one additional function unique to interrupt-handling: • Interrupt-Handler Servicing, the interrupt-handling code itself, which is executed after the interruption of the main execution stream (this can range in complexity from a simple non-nested routine to nested and/or reentrant routines). The three main types of interrupts are software, internal hardware, and external hardware.

11. Types of Interrupts • Softwareinterrupts are explicitly triggered internally by some instruction within the current instruction stream being executed by the master processor. • Internal hardware interrupts are initiated by an event that is a result of a problem with the current instruction stream that is being executed by the master processor because of the features (or limitations) of the hardware, such as illegal math operations (overflow, divide-by-zero), debugging (single-stepping, breakpoints), invalid instructions (opcodes), and so on. • External hardware interrupts are interrupts initiated by hardware other than the master CPU—board buses and I/O for instance. Interrupts that are raised (requested) by some internal event to the master processor—basically software and internal hardware interrupts—are also commonly referred to as exceptions or traps.

12. Interrupt Controller • Architectures that include an interrupt controller within their interrupt-handling schemes include the 268/386 (x86) architectures, which use two PICs (Intel’s Programmable Interrupt Controller) • MIPS32 relies on an external interrupt controller • MPC860 integrates two interrupt controllers, one in the CPM and one in its SIU • For systems with no interrupt controller, such as the Mitsubishi M37267M8 TV microcontroller, the interrupt request lines are connected directly to the master processor, and interrupt transactions are controlled via software and some internal circuitry, such as registers and/or counters. interrupt controller can be integrated onto a board, or within a processor, to mediate interrupt transactions in conjunction with software.

13. Examples MPC860 (shown in Figure 8-7a), which integrates two interrupt controllers, one in the CPM and one in its SIU. No interrupt controller, the interrupt request lines are connected directly to the master processor, and interrupt transactions are controlled via software and some internal circuitry, such as registers and/or counters.

14. Interrupt Priorities • Interrupts with higher levels have precedence over any instruction stream being executed by the master processor, meaning that interrupts have precedence over the main program and have priority over interrupts with lower priorities as well. When an interrupt is triggered, lower priority interrupts are typically masked, meaning they are not allowed to trigger when the system is handling a higher-priority interrupt. • Components are prioritized depends on the IRQ line they are connected to, in the case of external devices, or what has been assigned by the processor design. • Several different priority schemes are implemented in the various architectures. These schemes commonly fall under one of three models: the equal single level, where the latest interrupt to be triggered gets the CPU; the static multilevel, where priorities are assigned by a priority encoder, and the interrupt with the highest priority gets the CPU; and the dynamic multilevel, where a priority encoder assigns priorities, and the priorities are reassigned when a new interrupt is triggered. • The interrupt with the highest priority is usually called a non-maskable interrupt (NMI). When multiple components on an embedded board that need to request interrupts, the scheme that manages all of the different types of interrupts is priority-based. This means that all available interrupts within a processor have an associated interrupt level, which is the priority of that interrupt within the system.

15. Example of Interrupt Table The M37267M8 architecture, shown in Figure 8-10a, allows for interrupts to be caused by 16 events (13 internal, two external, and one software) whose priorities and usages are summarized in Figure 8-10b.

16. Context Switching • After the hardware mechanisms have determined which interrupt to handle and have acknowledged the interrupt, the current instruction stream is halted and a context switch is performed • Context Switching is a process in which the master processor switches from executing the current instruction stream to another set of instructions.

17. Interrupt Device Driver Pseudocode Examples Interrupt-Handling Startup (Initialization) MPC860 • Overview of initializing interrupts on MPC860 (in both CPM and SIU) • 1. Initializing CPM Interrupts in MPC860 Example • 1.1  Setting Interrupt Priorities via CICR • 1.2  Setting individual enable bit for interrupts via CIMR • 1.3  Initializing SIU Interrupts via SIU Mask Register including setting the SIU bit associated with the level that the CPM uses to assert an interrupt. • 1.4 Set Master Enable bit for all CPM interrupts 2. Initializing SIU Interrupts on MPC860 Example • 2.1  Initializing the SIEL Register to select the edge-triggered or level-triggered interrupt-handling for external interrupts and whether processor can exit/wakeup from low power mode. • 2.2  If not done, initializing SIU Interrupts via SIU Mask Register including setting • the SIU bit associated with the level that the CPM uses to assert an interrupt. • ** Enabling all interrupts via MPC860 “mtspr” instruction next step see Interrupt-Han- dling Enable ** Code example: use Text, section 8.1.3 The following pseudocode examples demonstrate the implementation of various interrupt-handling routines on the MPC860, specifically startup, shutdown, disable, enable, and interrupt servicing functions in reference to this architecture. These examples show how interrupt-handling can be implemented on a more complex architecture like the MPC860, and this in turn can be used as a guide to understand how to write interrupt-handling drivers on other processors that are as complex or less complex than this one

18. Interrupt-Handling and Performance • The performance of an embedded design is affected by the latencies (delays) involved with the interrupt-handling scheme. • The interrupt latency is essentially the time from when an interrupt is triggered until its ISR starts executing

19. Example 2: Memory Device Drivers • Memory Map: The software must provide the processors in the system with the ability to access various portions of the memory map. • Common MemDev Driver functionality: • Memory Subsystem Startup, initialization of the hardware upon power-on or reset (initialize TLBs for MMU, initialize/configure MMU). • Memory Subsystem Shutdown, configuring hardware into its power-off state. Note: under the MPC860, there is no necessary shutdown sequence for the memory subsystem, so • pseudocode examples are not shown. • Memory Subsystem Disable, allowing other software to disable hardware on-the-fly (disabling cache). • Memory Subsystem Enable, allowing other software to enable hardware on-the-fly (enable cache). • Memory Subsystem Write, storing in memory a byte or set of bytes (i.e., in cache, ROM, and main memory). • Memory Subsystem Read, retrieving from memory a “copy” of the data in the form of a byte or set of bytes (i.e., in cache, ROM, and main memory).

20. Byte ordering • In little endian mode, bytes (or “bits” with 1 byte (8-bit) schemes) are retrieved and stored in the order of the lowest byte first, meaning the lowest byte is furthest to the left. • In big endian mode bytes are accessed in the order of the highest byte first, meaning that the lowest byte is furthest to the right • Performance can be greatly impacted if data requested isn’t aligned in memory according to the byte ordering scheme defined by the architecture.

21. Memory Management Device Driver Pseudocode Examples • Ex: Memory Subsystem Startup (Initialization) on MPC860

22. Cont. Code example: Text Section 8.2.1

23. Example 3: On-board Bus Device Drivers Bus protocol is supported by the bus device drivers, including: • Bus Startup, initialization of the bus upon power-on or reset. • Bus Shutdown, configuring bus into its power-off state. • Bus Disable, allowing other software to disable bus on-the-fly. • Bus Enable, allowing other software to enable bus on-the-fly. • Bus Acquire, allowing other software to gain singular (locking) access to bus. • Bus Release, allowing other software to free (unlock) bus. • Bus Read, allowing other software to read data from bus. • Bus Write, allowing other software to write data to bus. • Bus Install, allowing other software to install new bus device on-the-fly for expand- able buses. • Bus Uninstall, allowing other software to remove installed bus device on-the-fly for expandable buses. Code example: text section 8.3.1

24. Board I/O Driver Examples Depending on the I/O subsystem, common Functionality includes: • I/O Startup, initialization of the I/O upon power-on or reset. • I/O Shutdown, configuring I/O into its power-off state. • I/O Disable, allowing other software to disable I/O on-the-fly. • I/O Enable, allowing other software to enable I/O on-the-fly. • I/O Acquire, allowing other software gain singular (locking) access to I/O. • I/O Release, allowing other software to free (unlock) I/O. • I/O Read, allowing other software to read data from I/O. • I/O Write, allowing other software to write data to I/O. • I/O Install, allowing other software to install new I/O on-the-fly. • I/O Uninstall, allowing other software to remove installed I/O on-the-fly.

25. Example 4: Initializing an Ethernet Driver Code example: Text Section 8.4.1

26. Summary • This chapter discussed device drivers, the type of software needed to manage the hardware in an embedded system. • This chapter also introduced a general set of device driver routines, which make up most device drivers. • Interrupt-handling (on the PowerPC platform), memory management (on the PowerPC platform), I2C bus (on a PowerPC-based platform), and I/O (Ethernet and RS-232 on PowerPC and ARM-based platforms) were real-world examples