• Aucun résultat trouvé

Informatique embarqu´ee 12/16

N/A
N/A
Protected

Academic year: 2022

Partager "Informatique embarqu´ee 12/16"

Copied!
11
0
0

Texte intégral

(1)

embarqu´ee 12/16 J.-M Friedt

Introduction

Informatique embarqu´ ee 12/16

J.-M Friedt

FEMTO-ST/d´epartement temps-fr´equence jmfriedt@femto-st.fr

transparents `ajmfriedt.free.fr

18 mars 2018

1 / 11

(2)

embarqu´ee 12/16 J.-M Friedt Introduction

Introduction

• D´eveloppeur⇒s’int´eresser `a l’interface mat´eriel-utilisateur

• Seul le noyau a acc`es `a toutes les ressources de la machine

• Distribuer les ressources et s’assurer de la coh´erence des acc`es

• Ajout de fonctionnalit´es au noyau Linux : les modules

(3)

embarqu´ee 12/16 J.-M Friedt Introduction

Porter GNU/Linux ` a une nouvelle architecture

• une chaˆıne de compilation

• tenir compte de l’architecture m´emoire de la cible (option -T deld)

• d´evelopper un bootloader (initialisation des p´eriph´eriques et chargement du noyau en m´emoire)1

• d´evelopper les modules noyau pour supporter le mat´eriel sp´ecifique

`

a la nouvelle architecture2.

0 20 40 60 80 100 120 140 160

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

tar.gz archive size (MB)

days since 1/1/1994 v10.dat

v11.dat v12.dat v13.dat v20.dat v21.dat v22.dat v23.dat v24.dat v25.dat v26.dat v30.dat v3x.dat v4x.dat

´Evolution de la taille de l’archive.tar.gz du noyau linux (www.kernel.org) 1. S. Guinot, J.-M Friedt,GNU/Linux sur Playstation Portable, GNU/Linux Magazine France114, Mars 2009, pp.30-40

2. J. Corbet, A. Rubini & G. Kroah-Hartman,Linux Device Drivers, 3rd Edition, O’Reilly (2005), disponible `ahttp://lwn.net/Kernel/LDD3/ 3 / 11

(4)

embarqu´ee 12/16 J.-M Friedt Introduction

Architecture d’un OS

Module 1

(USB) (port parallèle)

Module 2 Module 3 (fs)

/dev/ttyUSB /dev/partport0

(scheduler, interruptions, timers ...) Noyau monolithique

fonctions système, réseau, gestion processus et mémoire, vfs

Espace utilisateur

applications

(libc)

(5)

embarqu´ee 12/16 J.-M Friedt Introduction

Le r´ epertoire /dev

• contient des pseudo-fichiers faisant le lien entre un module noyau et l’espace utilisateur

• chaquedeviceest d´efini par unmajor number et, dans sa classe, un minor number

• du cˆot´e du noyau, un pilote (driver) s’est li´e au mˆeme major number et fournit des m´ethodes standard

• open()

• close()

• write()

• read()

• ioctl()

static struct file_operations qadc_fops = {

owner: THIS_MODULE,

read: qadc_read,

open: qadc_open,

ioctl: qadc_ioctl,

release: qadc_release, };

static int __init qadc_init (void) {...

register_chrdev (qadc_major, "ppp", &qadc_fops);

...}

module_init (qadc_init);

module_exit (qadc_exit);

5 / 11

(6)

embarqu´ee 12/16 J.-M Friedt Introduction

Structure de base

• deux points d’entr´ee et de sortie : module init (fonction debut);et module exit (fonction fin);

• initialisation du point de liaison avec l’espace utilisateur register chrdev (90 , "jmf" ,&fops );

attention au message d’erreur si le major est d´ej`a occup´e : cf/proc/devices

• des affichages au travers de/var/log/syslogpar

printk (KERN ALERT "message format´e");(sans virgule !)

• possibilit´e de cr´eation dynamique de l’entr´eedev int hello_start() // init_module(void)

{jmfdev.name = "jmf"; // /dev/jmf: major = classe misc jmfdev.minor = MISC_DYNAMIC_MINOR;

jmfdev.fops = &fops;

misc_register(&jmfdev); // creation dynamique /dev/jmf }

(7)

embarqu´ee 12/16 J.-M Friedt Introduction

Fonctions de base

• printf(char *)(stdio)→printk(level char*) (linux/kern levels.h)

• malloc→kalloc()

• MMU :copy from user&copy to userpour des blocs,

• MMU :put user& get user pour des scalaires

• Calculs flottantsinterdits:

• pas d’affichage parprintk(%f),

• probl`eme de sauvegarde du contexte du FPU,

• inefficace en l’absence de FPU,

• absence demath.h(biblioth`eque en espace utilisateur)

7 / 11

(8)

embarqu´ee 12/16 J.-M Friedt Introduction

M´ ethodes fournies par le noyau

Nombreuses fonctionnalit´es fournies par le noyau pour la gestion des tˆaches (ordonnanceur),timerou communication avec l’espace utilisateur.

• concepts se rapprochant de la programmation microcontrˆoleur

init_timer_on_stack (&exp_timer );

exp_timer.expires = jiffies+delay*HZ ; exp_timer.data = 0;

exp_timer.function = do_something ; add_timer (&exp_timer);

• tˆaches (tasklet) : interruptions logicielles

char my_tasklet_data[]="my_tasklet_function was called";

void my_tasklet_function( unsigned long data ) { printk( "%s\n", (char *)data ); return; } DECLARE_TASKLET( my_tasklet, my_tasklet_function,

(unsigned long) &my_tasklet_data );

int init_module( void )

{ tasklet_schedule( &my_tasklet ); return 0; } void cleanup_module( void )

{ tasklet_kill( &my_tasklet ); return; }

(9)

embarqu´ee 12/16 J.-M Friedt Introduction

Compilation d’un module noyau

• N´ecessit´e de connaˆıtre la version et la configuration du noyau courant :uname -a

• N´ecessit´e de connaˆıtre l’emplacement des sources du noyau : /usr/src/linux-headers-ver-arch(Debian), ou

$BUILDROOT/output/build/linux*(ARM)

• Compilation du noyau Linux :make modulespour conclure

• Notre module (PC) :

obj-m +=0mymod.o 1mymod.o all:

make -C /usr/src/linux-headers-$(shell uname -r)/build \ M=$(PWD) modules

9 / 11

(10)

embarqu´ee 12/16 J.-M Friedt Introduction

Compilation d’un module noyau

• N´ecessit´e de connaˆıtre la version et la configuration du noyau courant :uname -a

• N´ecessit´e de connaˆıtre l’emplacement des sources du noyau : /usr/src/linux-headers-ver-arch(Debian), ou

$BUILDROOT/output/build/linux*(ARM)

• Compilation du noyau Linux :make modulespour conclure

• Notre module (Redpitaya) :

PATH:=$(PATH):$(HOME)/buildroot/output/host/usr/bin/

obj-m +=0mymod.o 1mymod.o all:

make ARCH=arm \

CROSS_COMPILE=arm-buildroot-linux-uclibcgnueabihf- \ -C $(HOME)/buildroot/output/build/linux-4.4.2/ \ M=$(PWD) modules

(11)

embarqu´ee 12/16 J.-M Friedt Introduction

Mise en pratique

1 Module noyau sous GNU/Linux

2 Portabilit´e du module noyau qui n’acc`ede pas au mat´eriel

3 Cr´eation dynamique du point d’entr´ee dans/dev

• Au lieu d’ex´ecuter le r´esultat de la compilation, nous le lions au noyau :

Code .c −→

|{z}

Makefile

module .ko

• [sudo] insmodmodule.ko

• rmmodmodule

• lsmod

11 / 11

Références

Documents relatifs

• summon-arm-toolchain fournit un script pour g´ en´ erer un ensemble “coh´ erent” d’outils – explication de sa compilation ` a http://jmfriedt.free.fr/summon_arm.pdf. •

• thread : occupe les mˆ emes ressources m´ emoire que le p` ere mais contient sa propre pile ⇒ partage de ressources mais ´ elimine les probl` emes de communication entre

2 un ´ emulateur permet de connaˆıtre l’´ etat interne du processeur et de pr´ evenir l’utilisateur d’erreurs ...

• Pourquoi un syst` eme d’exploitation : un scheduler, un gestionnaire de m´ emoire (multitˆ ache), une couche d’abstraction suppos´ ee cacher le mat´ eriel au programmeur,

• m´ emoire mat´ erielle : une adresse sur le bus d’adresse pour identifier un p´ eriph´ erique. • chaque p´ eriph´ erique d´ ecode le bus d’adresse pour savoir si le

Plusieurs tˆ aches g` erent une mˆ eme donn´ ee ⇒ risque d’incoh´ erence Trois m´ ethodes pour prot´ eger une donn´ ee :. • s´

Le comportement d’un appel syst` eme est similaire ` a celui que nous avons vu lorsqu’un appel POSIX est transmis ` a un pilote pour faire appel aux entr´ ees de la structure de

a une ´ epoque o` u aucun superviseur (noyau) n’impl´ ementait d’appels syst` emes logiciels – tandis que la seconde est utilis´ ee pour rediriger les appels syst` emes