Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

Embedded Linux – GSE5

LAB2 – Character driver

BARRIGA Ponce de Leon Ricardo

GUO Ran
GSE5 LAB2 Embedded Linux BARRIGA_GUO

Objectives:
Development of a character driver and device file example
Test on a ZedBoard/Linux platform

Lab preparation:
• Develop a preliminary version of a Linux module
We created a new file named leds.c, with the functions init, exit, open, release, read and write.

• Does the major number 60 match the requirements? why? if not, propose an other major number.
To use the device file from the driver, a specific mechanism based on a major number and a
minor number is used. These two numbers associate the device file and device driver.
To see the usage situation, we use the command in the terminal: $ ls -l /dev and we get the major
number on the left and the minor number on the right. If there is no other device that uses 60 as a
major number, so major number 60 meets the need. If the number 60 exists, we must create
another number.

• Which command allows creating the device file?


We create a new device file called leds by using $ mknod /dev/leds c 255 0.
c specifes a character device where 255 is the major number, 0 is the minor number.

1.1 LED driver:


We want to write a character driver that can be used to control LEDs from a user application.
First, from Device Tree we stated before, we know that the physical base address of the
aix_gpio_0 device is 0x41200000. So we declare parameters in the leds.h file:

Creation of a share file in /dev/leds, with a major number different from the existing ones. We
have listed the card drivers to see the major number already taken with the command: $ ls -l /dev.
We then chose the 255.
1
GSE5 LAB2 Embedded Linux BARRIGA_GUO

We have the file_operations structure, which is the mechanisms for the user space to exchange
data at the kernel space. For example the function for the user is read and it can call the function
in the leds_read kernel space. The LED driver allows the user to interact with LEDs using the
following access functions:

We add a request_mem_region function to the initialization function to allocate memories with


the specific length. The length of memory allocation required is defined in leds.h which is 8. This
function allocates a memory region of 8 bytes, starting at physical base address 0x41200000.

Memory regions should be freed when no longer needed, so we add the function which release
the memory release_mem_region at module exit.

2
GSE5 LAB2 Embedded Linux BARRIGA_GUO
Then we should to do is ensuring that this I/O memory has been made accessible to the kernel.
On many systems, I/O memory is not directly accessible, so a mapping must be set up first.
Linux works with virtual addresses, we have to translate the physical address of the GPIO into a
virtual address via the ioremap function:

virtual_address = ioremap (physic_base_address, length_of_memory_allocation )

We add ioremap function in leds_open. we have declared a global variable named


start_vir_add_map to store the virtual address.

For the disconnection of the virtual address and physical address, we use the function iounmap.

function write: change the value of the register. In this function, we use kernel function kstrtol to
convert a string to an integer number.

function read: read and returns the value of the GPIO register.

1.2 Development of a userspace test application

3
GSE5 LAB2 Embedded Linux BARRIGA_GUO
Then we compile with Makefile and run the script test.

We change the state of the LEDs by writing to the device file /dev/ leds. However, the dev folder
is a system folder, so write only as superuser using the sudo keyword. Here is the result:

The LED will change state according to the received number.

0xff 0x01

Conclusion:
In this lab, we managed to write our first character driver. From this driver, we were able to
create an executable program in user space which allows to manage the LEDs by making calls to
the functions of this driver.

You might also like