1. Computer System Laboratory
Lab7 - Driver
/ 19

2. Experimental Goal
Understand the architecture of Linux device driver and kernel module.
/ 19

3. Environment Host Machine Target Machine Build Machine OS: Windows
Raspberry Pi (2 or 3)
Build Machine
A computer with a SD card slot
OS: Ubuntu (or above) 64-bit
/ 19

4. Software Required Host Machine Build Machine
PL2303 Driver
PuTTY
Build Machine
A built kernel with its configuration and header files
GCC Cross-Compiler targeting ARM
DHT11 sensor driver sample code
You may find all software on the CSL Course Software.
/ 19

5. Hardware Checklist Raspberry Pi Power supply
Micro SD card and card reader
USB-TTL cable / Network cable
DHT11 sendor and 3 wires
/ 19

6. Introduction to Device Drivers
What are device drivers?
Make a particular piece of hardware respond to a well-defined internal programming interface.
Hide completely the details of how the device works.
User activities are performed by means of a set of standardized calls that are independent of the specific driver.
Mapping those calls to device-specific operations that act on real hardware is then the role of a device driver.
/ 19

7. Device Driver Architecture
user program
/dev/XXX
device driver
physical device
/ 19

8. Physical vs. Logical
A physical device usually has a corresponding logical device file (e.g. /dev/XXX).
User programs operate the logical device file via system calls such as open(), read(), write(), and close().
Operations to the logical device file will cause a set of corresponding handlers (e.g. fops.open(), fops.read(), fops.write(), fops.release()) provided by the device driver being invoked to perform real operations to the physical device.
A device driver has two layers: physical device driver (PDD) and logical device driver (LDD). PDD performs real operations to physical devices, and LDD implements the set of handlers using PDD.
/ 19

9. Writing a Logical Device Driver (fops)
Define file_operations and implement handlers of system calls.
#include <linux/fs.h>
struct file_operations dev_fops = {
.open = dev_open,
.read = dev_read,
.write = dev_write,
.release = dev_close, };
Implement these functions
/ 19

10. Writing a Logical Device Driver (device)
Define miscdevice and register a device file.
#include <linux/miscdevice.h>
struct miscdevice dev = {
.minor = MISC_DYNAMIC_MINOR,
.name = "dht11",
.fops = &dev_fops,
.mode = S_IRUGO | S_IWUGO, };
misc_register(&dev);
Name of your device file
System call handlers
Permission of your device file
/ 19

11. Writing a Physical Device Driver
This part of work depends on the specification of the physical device you are targeting to. Typically you need the datasheet of the physical device to learn how to interact with it via low level I/O operations. If some people already implement that PDD, usually you would like to copy-and- paste their work rather than reading the datasheet and implementing the PDD by yourself.
At the lowest software layer, there are only two ways to perform I/O: port I/O and memory mapped I/O.
Port I/O: Use special CPU instructions to access I/O ports, which are not memory address.
Memory mapped I/O: Access special memory addresses, which are associated with I/O system rather than real RAM.
/ 19

12. Data Transfer between Kernel and User
Arguments passing
read(fd, buf, size);
dev_read(file, buf, size, pos);
Your dev_read() has to fetch data from physical device, and write the fetched data to user buffer “buf”.
The fetched data exists in kernel space since the driver is in kernel space, but “buf” is a pointer points to user space. As the result, we need copy_to_user() to transfer data between kernel and user.
#include <linux/uaccess.h>
copy_to_user(user_pointer, kernel_pointer, size_to_copy);
/ 19

13. Introduction to Kernel Module
A kernel module contains code that runs in kernel mode to extend the running kernel. It can be loaded/unloaded during runtime of the kernel.
Most Linux drivers are implemented as kernel modules.
/ 19

14. Related Commands Load/unload a kernel module module.ko
$ sudo insmod module.ko
$ sudo rmmod module.ko
Dump the message from kernel’s printk()
$ dmesg
/ 19

15. Write a Kernel Module Called after insmod Called after rmmod
#include <linux/init.h> #include <linux/kernel.h> #include <linux/module.h>
static int init_demo(void) { printk("Hello World!\n"); return 0; }
static void cleanup_demo(void) { printk("Goodbye World!\n"); }
module_init(init_demo);
module_exit(cleanup_demo);
MODULE_LICENSE("GPL");
Called after insmod
Called after rmmod
/ 19

16. Build a Kernel Module
We cross compile kernel modules in the build machine. A built kernel with its configuration and header files is required. In the sample Makefile, set the KDIR variable to the path of your built kernel.
After the above steps, you can compile you kernel module. For more information of building kernel modules, see kbuild in the reference page.
% # in the kernel module directory
% export ARCH=arm
% export CROSS_COMPILE=arm-linux-gnueabihf-
% make
/ 19

17. DHT11 sensor
DHT11 sensor is a combined humidity and temperature sensor. We will write a device driver that requests humidity and temperature from DHT11.
Connect DHT11 pins and RPi GPIO pins.
DHT11 DATA  GPIO GPIO02
DHT11 VCC  GPIO 3.3V
DHT11 GND  GPIO GND
/ 19

18. Lab Requirement
The physical part of the DHT11 sensor driver is already contained in the sample code. After inserting the module built from the sample code, the humidity and temperature sensed by DHT11 will be displayed in dmesg.
Your job is to complete the logical part of the driver, and write a user space program to read humidity and temperature from the logical device.
/ 19

19. Reference The Linux Kernel Module Programming Guide
Linux/Documentation/kbuild/modules.txt
DHT11 Datasheet
/ 19