1 / 23

Device Drivers

Device Drivers. EE138 – SJSU Christopher Pham. Objectives. Defining device drivers Discussing the difference between architecture-specific and board-specific drivers Providing several examples of different types of device drivers . Introduction.

mirari
Download Presentation

Device Drivers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Device Drivers EE138 – SJSU Christopher Pham

  2. Objectives • Defining device drivers • 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. 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.

  7. 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

  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. 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.

  10. 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.

  11. Examples

  12. Example of Interrupt Table

  13. 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.

  14. 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

  15. 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

  16. 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).

  17. 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.

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

  19. Cont. Code example: Text Section 8.2.1

  20. 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

  21. 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.

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

  23. 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

More Related