Unit IV Device Driver Basics Contents Bootloaders Device
Unit - IV Device Driver Basics
Contents : • • • Bootloaders Device Driver File Systems Device Tree MTD System Embedded Development Environment
Bootloaders :
Bootloaders : • • • Processor and Board specific Usually starts from ROM Moves itself to RAM for actual work Minimum peripheral initialization Decide which OS image to start Get the kernel Prepare parameters for OS loading Transfer control to OS kernel in RAM Example – UBoot, GRUB, LILO
U-Boot : • Can be configured at compile time • include/config : • • CPU type Peripheral configurations Memory Mapping options Features enabled/selected for compilation • configuring U-Boot for specific platform: • $ make <boardname>_config • name of supported board listed in boards. cfg file. • Specify cross compiling toolchain • $ make CROSS_COMPILE = arm-linux
Commands : • • boot : default boot mode bootm <address> : Boots kernel image @ address (SDRAM) <File_System>load : loading file from file system to SDRAM <File_System>ls : list out files in FS <File_System>info : Print FS information <File_System> = ext 2, FAT, etc. tftp : loading img/files from remote location • tftp <load_address> <image_source> • Nand : IO operations on NAND • md : Display Memory contents • mm : Modify Memory contents
LILO : • No specified file system i. e. can be booted from CD, floppy etc. • Primary Loader : • First Sector of boot device • 512 bytes • Locates the Secondary Loader • Secondary Loader : • Locates the OS kernel • Multiple Sectors on Hard Disk • Multiple OS Boot Support
Files : • lilo. conf : LILO configuration file • File Options: • boot : Specified MBR • timeout : time before it selects default boot option • Image : kernel image path
GRUB • GRand Unified Bootloader • Boot loader from GNU project • Loads on startup and allows boot time changes • Graphical option to select one of installed OS i. e. kernel configuration • Allows network booting, highly portable(FAT/NTFS) • Can be loaded from external devices. • GRUB-I, GRUB-II
Files : • /boot/grub. cfg • Actual grub file • Needs to be updates as per user requirement • /etc/grub. d/ • Contains grub scripts used to generate grub. cfg • /etc/default/grub • Grub menu setting • Accessed by grub script • Grub update command to make changes in grub. cfg
IO Architecture : • To facilitate data flow between CPU memory and IO devices, data paths must be specified • Data paths are called Buses – Primary communication channel inside computer • Internal H/W devices are connected by System Buses • PCI Bus is a typical system bus. Others are: ISA, EISA, MCA, SCSI and USB • Same computer may include several buses, linked by hardware called Bridge
IO Architecture • Two high-speed buses are dedicated to the data transfers to and from the memory chips: • • Front-side bus: connects the CPUs to the RAM controller, Back-side bus: connects the CPUs directly to the external hardware cache. • Host bridge links together the system bus and the front-side bus
IO Architecture • Any hardware device is hosted by one and only one bus. • The bus type affects the internal design of IO device. (PCI Bus – PCI Device), as well how the kernel will handle the device.
IO architecture • Data Paths that connects CPU and IO device is called IO Bus • The I/O bus, in turn, is connected to each I/O device by means of a hierarchy of hardware components including up to three elements: I/O ports, interfaces, and device controllers
IO Architecture: I/O ports, interfaces, and device controllers
IO Ports • Each device connected to the I/O bus has its own set of I/O addresses, which are usually called I/O ports. • In the IBM PC architecture, the I/O address space provides up to 65, 536 8 -bit I/O ports. • Two consecutive 8 -bit ports may be regarded as a single 16 -bit port. • Similarly, two consecutive 16 - bit ports may be regarded as a single 32 -bit port. • Four special assembly language instructions called in, ins and out, outs allow the CPU to read from and write into an I/O port.
Specialized IO ports
IO ports • I/O ports of each device are structured into a set of specialized registers. • CPU writes the commands to be sent to the device into the device control register • CPU reads a value that represents the internal state of the device from the device status register. • The CPU also fetches data from the device by reading bytes from the device input register • Pushes data to the device by writing bytes into the device output register.
IO Interfaces • An I/O interface is a hardware circuit inserted between a group of I/O ports and the corresponding device controller. • It acts as an interpreter that translates the values in the I/O ports into commands and data for the device. • In the opposite direction, it detects changes in the device state and correspondingly updates the I/O port that plays the role of status register. • This circuit can also be connected through an IRQ line to a Programmable Interrupt Controller, so that it issues interrupt requests on behalf of the device.
IO Interfaces 1. Custom I/O interfaces • Devoted to one specific hardware device. • In some cases, the device controller is located in the same card (pluggable to bus slot) that contains the I/O interface. • The devices attached to a custom I/O interface can be either internal devices (devices located inside the PC’s cabinet) or external devices (devices located outside the PC’s cabinet). 2. General-purpose I/O interfaces Used to connect several different hardware devices. Devices attached to a general-purpose I/O interface are usually external devices.
Custom IO Interfaces • Keyboard Interface : • Connected to a keyboard controller that includes a dedicated microprocessor. • This microprocessor decodes the combination of pressed keys, generates an interrupt, and puts the corresponding scan code in an input register.
Custom IO Interfaces Graphic interface Packed together with the corresponding controller in a graphic card that has its own frame buffer, as well as a specialized processor and some code stored in a Read-Only Memory chip (ROM) Disk interface Connected by a cable to the disk controller, which is usually integrated with the disk.
Custom IO Interfaces Bus mouse interface Connected by a cable to the corresponding controller, which is included in the mouse. Network interface Packed together with the corresponding controller in a network card used to receive or transmit network packets.
General-purpose I/O interfaces • Modern PCs include several general-purpose I/O interfaces, which connect a wide range of external devices. The most common interfaces are: • Parallel port : Used to connect printers, removable disks, scanners, backup units, and other computers. The data is transferred 1 byte (8 bits) at a time. • Serial port : Data is transferred 1 bit at a time. It includes a Universal Asynchronous Receiver and Transmitter (UART) chip to string out the bytes to be sent into a sequence of bits and to reassemble the received bits into bytes.
Device Controller • Device Controllers A complex device may require a device controller to drive it. Essentially, the controller plays two important roles: • High level commands to electrical signals • It interprets the high-level commands received from the I/O interface and forces the device to execute specific actions by sending proper sequences of electrical signals to it. • Electrical signals to commands • It converts and properly interprets the electrical signals received from the device and modifies (through the I/O interface) the value of the status register.
Device Controller: The Disk Controller • A typical device controller is the disk controller • It receives high-level commands such as “write this block of data” from the microprocessor (through the I/O interface) converts them into low-level disk operations such as • • “position the disk head on the right track” “write the data inside the track. ”
Device Driver :
Device Driver Basics • Device driver is a software interface for operating system and other programs to deal IO devices and operations. • Kernel components which can be loaded as module. • Device Driver Types : • Block devices • Character devices • Network Device
Device Driver : Application Kernel Layer Device Driver Hardware Layer Hardware
Device Driver : Application Kernel Layer IO Subsystem Device Driver Hardware Layer H/W Controller Hardware
Flow for printf() :
Flow to Device Driver :
Device Driver Interaction : • • Boot Time Application requesting IO operations Hardware interrupts Bus reset operation
Printer Device Driver :
Printer Device Driver : • Initialization • Initializes the printer • Interrupts • Set offset and segment address • Set position to print • Set number of bytes to print • Write • INT 17 H • 00 Printing • 01 Initialization
Device Driver Module : • #include <linux/module. h> • #include <linux/init. h> • #include <linux/kernel. h> • static int my_init(void) • //Code while loading the module • static void my_exit(void) • //Code while removing the module • module_init(my_init); • module_exit(my_exit); • MODULE_AUTHOR(“XYZ”); • MODULE_DESCRIPTION(“TEST DD”); • MODULE_LICENSE(“GPL”);
Building a Loadable Kernel Module : • Create directory of driver module @. . . /dev/char • Specify New. Driver as LKM in kernel configuration • Specify New. Driver subdirectory entry @. . . /dev/char/Make. File • Create Make. File for New. Driver subdirectory • Configuration utility for ARM • $ make ARCH=arm CROSS_COMPILE=xscale_be- gconfig • Build the module • $ make ARCH=arm CROSS_COMPILE=xscale_be- modules • Install Module • $ make ARCH=arm CROSS_COMPILE=xscale_be- INSTALL_MOD_PATH=<Installation Path> modules_install
Module Utilities : • modinfo • Shows module information • insmod • $insmod <Module_Path> • lsmod • List out all the modules along with size & processes using it • depmod • Creates dependency file modules. dp containing dependency information of the module on other modules • modprobe • Uses modules. dp file • #modprobe New. Driver • #modprobe –r New. Driver • rmmod – Remove Module from Kernel
Driver Methods : • In Linux, devices are accessed from user space in exactly the same way as files are accessed. • Linking normal file with kernel module • mknod <name> <type> <major_no> <minor_no> • mknod /dev/hello 1 c 234 0 • <major_no> : Associates device to device node • <minor_no> : Handeling multiple devices with single device driver
Driver Methods : • Initialization : • moule_init(): • Registering Device: • register_chrdev(<major_no>, <module_name>, <&memory_file_operations>); • register_chrdev(234, “hello 1”, &hello_fops); • module_exit(): • unregister_chrdev(<major_no>, <module_name>);
Driver Methods : • Memory anagement/ File Handeling : • int memory_open(struct inode *inode, struct file *filp); • int memory_release(struct inode *inode, struct file *filp); • ssize_t memory_read(struct file *filp, char *buf, size_t count, loff_t *f_pos); • ssize_t memory_write(struct file *filp, char *buf, size_t count, loff_t *f_pos); • void memory_exit(void); • int memory_init(void);
Device Driver Flow as a File : • Explain flow of device driver as a file once it is created, in the following format • Events User Function Kernel Function
Device Driver Flow as a File :
PCI Device Drivers : • Peripheral Component Interconnect • Standard that defines how component should interact • Advancement over ISA • Faster transfer • Uniform layout of interconnection across various architectures • Simplified standard for adding and removing peripheral devices • Features • • • 32 bit data bus Supports various arch like: Power PC, IA-64, SPARC-64, etc. Automatically configures @ boot time Auto detection of interface boards. Minimizes processor specific interfacing standards. No need for jumpers or dip switches.
PCI System Layout: • Bus Number • Device Number • Function Number • PCI standard supports : 256 Buses • 32 devices for each bus • 8 functions for each device
Bus connections:
Device Tree :
Device Tree : • Flat device tree or device tree binary • A device tree is a tree data structure with nodes that describe the physical devices in a system. • board-specific information that the kernel requires in order to boot the board. • CPUs, memory size, clock speeds, onboard devices, buses, and Flash layout
Device Tree :
Device Tree Node Properties: • String data representation • a-string-property = "Demo String"; • List representation • a-string-list-property = "Demo String 1", "Demo String 2"; • Cells data representation • Generally 32 bit data • a-cell-property = <9 8 7 6>; • Byte data representation • a-byte-data-property = [0 x 02 0 x 22 0 x 33 0 x 55];
Device Tree for imx 28 • arch/arm/boot/dts/imx 28. dtsi
Device Tree Binary: • Device Tree Source les (DTS) • arch/arm/boot/dts • . dts files for board-level definitions (main file) • . dtsi files for So. C-level information (library files) • Device Tree Compiler • scripts/dtc • Device Tree Blob • the binary that gets loaded by the bootloader and parsed by the kernel at boot time. • . dtb files
Device Tree :
Commands : • dtc [options] [<input_filename>] • <input_filenames> : . dts files • bootm $loadaddr - $fdtaddr • <load_addr> : Address of Kernel Image • <fdt_addr> : Address of DTB
Device Node : • Required properties: • compatible : Should be "fsl, <soc>-auart". The supported So. Cs include imx 23 and imx 28. • reg : Address and length of the register set for the device • interrupts : Should contain the auart interrupt numbers
Device Node : auart 0: serial@8006 a 000 { compatible = "fsl, imx 28 -auart", "fsl, imx 23 -auart"; reg = <0 x 8006 a 000 0 x 2000>; interrupts = <112>; };
AUART Device Tree Node :
File Systems : • File System • Partition • Journaling
File Systems : • Linux has a single global hierarchy of files and directories. This hierarchy can be composed of many file systems. • File systems are mounted on specific locations in directory hierarchy. This specific location is called the mount point. • Partition : logical division of the physical device.
File Systems : • Journaling : • • • Maintains important data about file systems. Logs changes before they are committed to the filesystem. Ordered-mode journaling : logs meta-data. Data-mode journaling : logs meta-data and data. Eg : ext 3 and ext 4
Ext 2 File System • fdisk utility can be used to create the partition. Another utility called mkfs. ext 2 is used to format the partition and create file system of type ext 2. • Use the following command to format the partition with ext 2. • mkfs. ext 2 /dev/sdb 1 -L My. Flash
Ext 2 file system raghib@ubuntu: $ sudo mkfs. ext 2 /dev/sdb 1 -L My. Flash mke 2 fs 1. 42. 9 (4 -Feb-2014) Filesystem label=My. Flash OS type : Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 977280 inodes, 3908344 blocks 195417 blocks (5. 00%) reserved for the super user First data block = 0 Maximum filesystem blocks=4005560320 120 block groups 32768 blocks per group, 32768 fragments per group 8144 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 919200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Writing superblocks and filesystem accounting information: done
Ext 2 file system • After creating file system, it can be mounted at desired location using the following mount command. • Before running the command, create the directory My. Flash. Drive that will serve as mount point. • # mount /dev/sdb 1 /mnt/My. Flash. Drive
Ext 3 file system • Ext 3 file system more efficient and powerful journaling file system. • Ext 3 is an extension of Ext 2. It adds journaling capability. • Journaling is a special feature of file recovery where every change is logged in a separate file and later can be recovered if needed. • The separate special file holds all information about the file (file metadata), included every change that takes place in a file. This file is often called the Journal. • So whenever there is change in file system, the changes are logged in Journal
Ext 3 file system • Consistency check for the files are needed after an unexpected shutdown (sudden power failure) in Ext 2 file system. It takes significant amount of time. • In Ext 3, consistency check is not needed as journaling system ensures the file system consistency. Journal is referred to recover from an inconsistent state of file system.
Ext 4 • Ext 4 is an advancement of Ext 3. • A journaling file system. It removes certain limitations of Ext 3 file system. It includes scalability and reliability enhancements. • Latest Linux distribution is now adopting the ext 4 as their default. The maximum file system limit is extended to 1 exbibyte. Individual file size can be 1024 GB. • Used at large database servers.
Reiser. FS • This file system has journaling capability like Ext 3 and Ext 4. • Reiser. FS guarantees atomicity in file system transaction. It means all the operation should completer entire or none of them, ensuring the consistency of file data • It is also default file system for Xandros, Linspire, Gobo. Linux.
Reiser. FS • Reiser. FS had some features that was not seen by Linux community earlier at that time: • 1. Metadata Only Journaling (Block Journaling) : Reiser. FS stores metadata, directory entry, inode lists etc in a combined B+ tree data structure • 2. Online Resizing of File system : Logical volume manager(LVM) can be used for support of online growth of the file system (LVM not necessarily required) • 3. Tail Packing : Reiser. FS uses the method called tail packing to minimize internal fragmentation. Performance however decreases with tail packing.
JFFS 2 (Journaling Flash File System) • Embedded systems have flash devices for storing their files. • Flash memory has quite different characteristics then hard drives. • Write times are larger and to update a single file, entire block is rewritten. • Considering all these issues JSSF 2 is designed for flash devices.
JFFS 2 • Flash devices have limited life time due to limited number of write cycles (1, 000 write cycles in general). • Writing at same block many times will decrease the overall life. • JSSF 2 is also designed to ensure that write operations are spread evenly across all blocks. • mkfs. jffs 2 utility in Linux is used to build JFFS 2 image.
File Systems :
MTD Subsystem • MTD (Memory technology device) Subsystem provides a separation layer between low level device complexities and high level data organization in flash devices. • The MTD subsystem consists of device drivers for flash devices and offers a uniform interface (API) to interact with storage device. • Though MTD is not a block device, it supports data units of erasable blocks. These erasable blocks can be of different sizes. • Comparing to block devices, MTD has three operations: read, write and erase. (Block devices has only two : read and write)
MTD Subsystem • Flash devices has limited write life cycle. MTD subsystem works together with JSSF 2 to evenly distribute all write operations on entire flash blocks, increasing overall life time of flash devices. The process is called wear levelling.
MTD Subsystem
Embedded Development Environment : • tftp • DHCP
Cross Development Environment Setup
DHCP • Ethernet interface configuration is required for remote booting or accessing the remote files. • DHCP server has the responsibility of assigning the IP addresses for IP subnets. Client is then configured to request the DHCP server for an IP address at boot time. • Hard coding of the Ethernet interface parameter of target board (Eg. BBB) on Linux command line or in default static configuration.
- Slides: 77