Lab 5

Purpose: Introduction to Device Drivers in Linux

•     The sonar device
•     How to make and install a Linux Device Driver (We will leave a good book on this in the Lab, and provide you with templates/instructions)
•     How to program the StrongARM processor in Kernel Space for device I/O (see CerfBoard specs, and SA1110 Specs above)

Install your sonar onto the CerfBoard System. The CerfBoard has its own power supply, but MAKE SURE TO CONNECT THE SONAR AND CERF GROUNDS TOGETHER BEFORE TURNING ON POWER!! Refer to the CerfBoard hardware documentation and to the StrongARM documentation.  Pick two pins that are available on Port0 or Port1 of the Cerf break-out-board that correspond to GPIO pins on the sa1100. Connect INIT to one of these pins and connect ECHO to the other. Make sure to check the output enable and port direction settings of the DIP switch on the Intrinsyc break-out-board.

• Create and install the device driver for your sonar device. It should be interrupt driven. 
• Here is the interface requirement

  1. It should allow any number of processes to open the same sonar device

  2. Write is unsupported (return -1)
  3. Read() will
      - cause a sonar measurement to begin if one is not already in progress
      - return the result of the next sonar measurement
      if several processes call read during a measurement, then they should all get the same return result.
   
  Measurements should only be taken in response to reads. So the sonar should not be going all of the time.
• It is probably a good idea  to get things working with a  busy-wait based driver, then move to an interrupt driven driver.
• Write a user program that "forks"(sample code a la 451) into at least two user processes, both of which attempt to open and continuously read the device. Make sure to print out a message about the distance measurement each time a successful read is performed. The printed message should include the process ID of the user process.
• Turn in the code for your driver, your user application, and screen shot of the output
• Demonstrate your system for Larry or a TA.

1. ssh from your desktop machine to rocket.cs.washington.edu, with your group's username (should look like cse466_<letter>) and password.
2. Grab a copy of the template file. This can be found at /home/cse466/template.c, or here. An example command would be cp /home/cse466/template.c ~/template.c. If you name the file something besides template.c, use that name in the steps below (instead of template.*).
       The kernel source is a slightly patched version of the 2.4.1 kernel. It can be found at /home/cse466/linux on rocket.
3. Compile your driver module using arm-linux-gcc -Wall -O2 -c template.c

1. Log in to the Cerfboard as described above
2. Create the device file for your device driver, using the command mknod /dev/sonar0 c major_version_number 0.

   mknod creates a special file, in this case a character special file (that's the c option). We don't care about the minor version number, so arbitrarily choose 0.
   major_version_number is the number in the #define directive in your driver module. The major version number in Linux is essentially an index by which the operating system can refer to drivers. It does not have anything to do with the particular release version of the driver. Indeed major version numbers can be assigned dynamically (thus avoiding conflicts) but we are not going to take this approach.
   
   

3. FTP your driver module template.o from rocket to the cerfboard.
4. Load the driver by running insmod template.o.
5. Make sure the driver is loaded by running lsmod.
6. Test the driver's read function by executing cat /dev/sonar0
7. Test the driver's write function by executing echo Test Message > /dev/sonar0
8. Unload your driver by running rmmod template
9. Repeat steps 3-8 as necessary.

1. User space applications are compiled with arm-linux-gcc -o <output-file> <input-file>
2. Move user space applications to the CerfBoard using FTP as above.
3. The CerfBoards are running a web server. Your files go in /root/html and /root/cgi-bin. CGI support is pretty much limited to shell scripts and compiled C programs. You can find your IP address by running ifconfig.
   

GPIO Hints

• GPDR: a 1 in a bit means the pin is configured for output
• GPLR: Read to get the current status of the pins
• GPSR: Write to a bit in this register to set a pin to 1
• GPCR: Write to a bit in this register to set a pin to 0

The kernel defines macros to make GPIO programming easier:

• GPIO_GPIOx: This can be used ot access bits like:
• GPDR|=GPIO_GPIO10; //set #10 for output

Edge triggering:

• set_GPIO_IRQ_edge(GPIO_GPIO4, GPIO_RISING_EDGE);
• Also available are GPIO_FALLING_EDGE and GPIO_BOTH_EDGES

IRQs:

• Each GPIO pin has an associated interrupt:
• IRQ_GPIO4 is the interrupt number for pin #4
• Look /home/cse466/linux/include/asm/SA-1100.h for more info

Breakout Board:

• The two switches labled OE (#2,#4) should be set to enabled.
• Set the direction switches as you need to. Each block of pins are either all in or all out.
• The two banks of switches in front of the connectors should all be open.

Device Driver Code

• Add unregister_chrdev(SONAR_DEV_MAJOR, SONAR); to cleanup_module(void).