• Aucun résultat trouvé

2 – Character driver

N/A
N/A
Protected

Academic year: 2022

Partager "2 – Character driver"

Copied!
3
0
0

Texte intégral

(1)

Embedded Linux – GSE5

2 – Character driver

Objectives

 Development of a character driver and device file example

 Test on a ZedBoard/Linux platform Lab preparation

 Read carefully the following problem statement.

 Develop a preliminary version of a Linux module for question 1.1.

 Does the major number 60 match the requirements? why? if not, propose an other major number.

 Which command allows creating the device file?

Achievement

 A demonstration showing LEDs control and interaction from a user space test application.

Host configuration for ARM cross compilation

$ xilinx_env_vivado18.2

$ export CROSS_COMPILE=arm-linux-gnueabihf-

$ export ARCH=arm

1.1 LED driver

From the « memory » driver example detailed in Ch6 – Device driver development, write a character driver that can let the control of LEDs from a user application. For instance, writing

0x1 to the device file will switch on LED1, writing 0x2 will switch on LED2 etc.

A character driver template is given for help at http://users.polytech.unice.fr/~bilavarn/

(Example 1 – Character driver).

The following standalone code is also provided to show GPIO register usage to blink the eight LEDs.

#define XPAR_LEDS_8BIT_BASEADDR 0x41200000

#define GPIO_DATA (*((unsigned int*)(XPAR_LEDS_8BIT_BASEADDR + 0x00)))

#define GPIO_TRI (*((unsigned int*)(XPAR_LEDS_8BIT_BASEADDR + 0x04))) main() {

int i;

// Initialize

GPIO_TRI = 0x00; // output // blink

xil_printf(“Blinking leds!\n\r”);

for(i=0; i<10; i++) { GPIO_DATA = 0xff;

sleep(1);

GPIO_DATA = 0x00;

sleep(1);

}

xil_printf(“Stop blinking!\n\r”);

}

The LED driver allows the user to interact with LEDs using the following access functions:

Struct file_operations leds_fops = { .read = leds_read,

- 1 -

(2)

Embedded Linux – GSE5

.write = leds_write, .open = leds_open, .release = leds_release };

The Character driver example has to be completed with the following steps in order to access GPIO registers properly:

 I/O memory allocation and mapping:

 I/O memory regions must be allocated prior to use, at module initialization, to reserve I/O address ranges (other drivers will not be able to reserve already reserved ranges).

The interface for allocation of memory regions (defined in <linux/ioport.h>) is:

struct resource *request_mem_region(unsigned long start, unsigned long len, char *name);

start: base address

len: length of memory allocation required

name: name of peripheral device

This function allocates a memory region of len bytes, starting at start. If all goes well, a non- NULL pointer is returned; otherwise the return value is NULL. All I/O memory allocations are listed in /proc/iomem.

Memory regions should be freed when no longer needed (at module exit):

void release_mem_region(unsigned long start, unsigned long len);

start: base address

len: length of memory allocation required

 Allocation of I/O memory is not the only required step before that memory may be accessed. You must also ensure that this I/O memory has been made accessible to the kernel. Getting at I/O memory is not just a matter of dereferencing a pointer; on many systems, I/O memory is not directly accessible in this way at all. So a mapping must be set up first. This is the role of the ioremap function (defined in <asm/io.h>). The function is designed specifically to assign virtual addresses to I/O memory regions:

void * ioremap(unsigned long addr, unsigned long size) addr : base address

size : size of physical address mapping

return : pointer to the start of virtual address map

void iounmap(void *addr) addr : virtual address

 Accessing IO/ memory: The addresses returned from ioremap should not be dereferenced directly (using pointers). Such use is not portable, and, increasingly, the kernel developers have been working to eliminate any such use. The proper way of getting at I/O memory is via a set of functions (defined in <asm/io.h>) provided for that purpose:

int ioread8(void __iomem *addr) int ioread16(void __iomem *addr) int ioread32(void __iomem *addr)

addr: pointer to the concerned memory address

- 2 -

(3)

Embedded Linux – GSE5

void iowrite8(u8 val, void __iomem *addr) void iowrite16(u16 val, void __iomem *addr) void iowrite32(u32 val, void __iomem *addr)

val: value to be copied to memory address addr addr: pointer to the concerned memory address

You must firstly modify functions led_init, led_exit accordingly.

Then complete functions led_open, led_release, leds_read and led_write of the character driver template.

Compile and test the driver module on the ZedBoad/Linux platform. Explain your test method.

Note : use kernel function kstrtol to convert a string to an integer number.

1.2 Development of a userspace test application

The objective now is to write a userspace application that can let let us control LED states (on/off).

Write a userspace program which interacts with previous LED driver using the associated device file /dev/led and file access functions (open, close, read, write). A model is available for help in Example 1 – Character driver.

Explain your code, testing strategy and results.

- 3 -

Références

Documents relatifs

Device drivers User / device interaction Example 1: basic module Example 2: character driver Example 3: « ioctl » method Example 4: the « mmap » method... Linux

With these two cards, netconfig checks the information stored via your ma- chine's EISA configuration utility and, assuming the parameters don't conflict with those of any

provides general information on data transfer methods between the kernel and devices, and between user space and the kernel; detailed information on block data transfer methods,

Thus, while using a mobile phone for conversation may have a less detrimental impact on driving behaviour (i.e. may be a less risky driving behaviour) than text messaging, some

Public health research – generating evidence for policies that drive health equity Committing to the SDGs and ratifying human rights treaties means that the progress of WHO European

The promotion of social participation is a key driver of health equity because it supports governance mechanisms that provide opportunities for greater health equality:

These applications collectively provide a &#34;collaboratory&#34; environment (Lederberg and Uncapher, 1989; Cerf et al., 1993) that couples tools to support communication

I f we look at the history of lighting, antiquity offers important events that moved the technology of fire- light forward, such as the oil lamp circa 4500BC, or the candle