Haute

1
Haute École de la Province de Liège

• Catégorie Technique
• Bachelier en Informatique et Systèmes
• ? Finalité Informatique Industrielle

2
Construction, chargement et mise au point
dimages systèmes sous QNX

• David Bourlard et Nicolas Dumont

3
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

4
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

5
Finalité Industrielle

• Informaticien
• Spécialiste des systèmes informatiques
• Supervision
• Programmation des interfaçages
• Systèmes embarqués
• Compétent dans le domaine du contrôle temps réel
  de dispositifs extérieurs à lordinateur.

6
Objectifs L.I.I.

• Systèmes temps réels
• Supervision
• Systèmes embarqués
• Traitements dimages

7
Cours de Systèmes Embarqués

• 3ème année.
• Techniques informatiques vues dans les autres
  cours
• ? Cours spécifique aux systèmes embarqués

8
Objectifs du cours

• Objectif principal
• Constructions dimages systèmes
• Objectif complémentaire
• Mise en œuvre dun microcontrôleur sans O.S.

9
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

10
Système QNX  Neutrino  (6.3.2)

• API POSIX 1003.1-2001
• 1003.1c (threads),
• 1003.1b, 1003.1d et 1003.1j (extensions
  temps réel)
• Hard Realtime lt 10µs
• ARM, MIPS, PowerPC, Hitachi SH-4, x86.

11
Système QNX  Neutrino 

• Module dexécution de base  procnto 
• µnoyau (gestion message-passing et
  signaux)
• process manager (gestion processus,
  IPC, mémoire et noms de répertoires)
• ? 45Ko
• Processus ajoutés au besoin
• Débogage standard avec gdb
• Compilateur gcc

procnto
12
Système QNX  Neutrino 

• Message-Passing Interface primitive de
  communication interprocessus (IPC) fondamentale
• Mécanisme synchrone
• (messages)
• ou non (événements)

13
Système QNX  Neutrino 

• support de la MMU (Memory Management Unit)
  espace mémoire de chaque processus isolé

14
Système pré-emptif QNX  Neutrino 

• Pré-emption et interruptions supportées jusque
  dans les appels systèmes

PREEMPT
PREEMPT
15
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

16
Création dune image système

17
Composition dun fichier .bld
18
Fichier .bld

• virtualx86,bios compress .bootstrap
• keeplinked
• startup-bios -s 64k -A
• PATH/proc/boot LD_LIBRARY_PATH/proc/boot/dev/s
  hmem/usr/lib/lib procnto
• script .script
• procmgr_symlink ../../proc/boot/libc.so
  /usr/lib/ldqnx.so.2
•  
• devc-pty
• devc-con -n2
•  
• reopen /dev/con1
•   
• session TERMqansi uesh
•  
•  

• libc.so
• /lib/libm.so.2
• /lib/libsocket.so.2
•  
• codeuip datacopy permsr,x
• /x86/usr/bin/gdb
• ls
• echo
• pdebug
• devc-pty
•  
• elem
• raw/home/testrt/BM/Prog
•  
• devc-con
• uesh

19
Tailles dimages Simples

• Images minimales
• De lordre de 200 Ko pour limage la plus simple.
• Images créées au laboratoire
• Jusquà 1,3 Mo pour limage contenant le débugger
  gdb.
• 600Ko 1 Mo pour limage permettant le débugging
  via la ligne série ou le réseau.

20
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

21
Debugging local sous QNX

• Débogage de processus local avec gdb, sur
  systèmes PC et embarqué
• Programme compilé avec option -g
• (taille passe de 7,5 à 25Ko).

22
Debugging distant sous QNX

• Informations de débogage et code source restent
  sur le système hôte.
• Exécutable à analyser téléchargé vers le système
  cible.

23
Debugging distant sous QNX

• 1) ligne série
• 2) réseau ethernet en ligne de commande
• 3) réseau ethernet dans lIDE QNX Momentics

24
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

25
Images système sur mémoire flash

• DiskOnChip (EEPROM XIP bootable apparaissant
  comme disque dur grâce au pilote TrueFFS)
• DiskOnModule (EEPROM reconnue nativement comme
  disque dur IDE/SATA)
• Clé USB

26
Images système sur mémoire flash

• Méthode en utilisant lutilitaire fdisk
• 0) pour le DiskOnChip, charger le pilote
  TrueFFS
• Créer une partition QNX
• Positionner le boot flag
• Initialiser la partition
• Ecrire le chargeur de démarrage QNX
• Monter la partition
• Copier limage système préalablement créée, sous
  le nom .boot

27
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

28
Démarrage via réseau BOOTP

• Bootstrap Protocol la machine qui démarre
  découvre
• son adresse IP
• adresse IP serveur
• adresse IP passerelle
• nom d'un fichier à
• charger en mémoire
• pour exécution.

29
Server
Client
30
Démarrage via réseau bootp

• Disquette Etherboot (boot loader
• open-source palliant à labsence de
• ROM PXE de certaines cartes réseau)
• BIOS de PC et de système embarqué
• -gterreur TFTP si image gt512Ko
• 3) pxegrub petite image pour démarrage sur le
  réseau

31
pxegrub
BOOTP requests
BOOTP replies
ARP requests
Server
Client
32
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

33
Développement croisé

• Création dune image pour une cible ARM depuis
  lIDE QNX sur un PC x86.

34
Caractéristiques désirées

• Taille 100x100 mm
• Connectique
• Ethernet 10/100MBit
• RS232
• USB
• Supporte QNX

35
Caractéristiques de la carte

• Module Colibri PXA270 de Toradex
• Processeur Marvell Xscale PXA2700 312 MHz
• 64 Mo de RAM
• 32 Mo de mémoire flash
• Carte support avec connecteurs souhaités
  (Série,USB, Ethernet)

36
Choix de la carte ARM

• Petite carte
• BSP disponible sous QNX et gratuit

37
Board Support Package

• Un BSP (de QNX)
• pour la carte est
• téléchargé.
• Il contient
• Certains drivers de la carte ARM.
• un fichier de build (.bld).
• ce qui est nécessaire pour démarrer une image sur
  la carte.

38
Création de limage sous lIDE

• Création de limage simple et intuitive via
  lIDE.
• Seules quelques modifications à faire au niveau
  du fichier directeur.
• IDE QNX disponible sous windows/linux également.

39
(No Transcript)
40
Environnement de travail

41
Plan

• Situation des activités.
• QNX.
• Construction dune image système.
• Debugging.
• Démarrage de la cible sur Flash.
• Démarrage sur le réseau.
• Développement Croisé.
• Conclusions

42
QNX points forts

• Entièrement conforme à POSIX 1003.1-2001
• Processus hors espace noyau, y compris les
  drivers -gt gdb utilisable
• Documentation claire et unifiée
• Support payant très efficace
• QNX gratuit pour enseignement / recherche

43
QNX points faibles

• Indisponibilité de pilotes pour hôtes de
  développement et de BSP pour les cibles
• Interface graphique propriétaire spécifique, mais
  légère et temps réel.

44
Pourquoi avoir choisi QNX

• RTOS (Real Time Operating System) de type
• Temps Réel Dur
• Système modulaire convenant à la fois pour une
  machine standard et une utilisation embarquée

45

• Questions ?

46
Aspects techniques

• Empreinte mémoire minimale 200ko
• XIP (eXecute In Place), exécution de code sans
  copie préalable en mémoire centrale

47
Perspectives

• Micro serveur WEB
• Ecrans tactiles (QNX / linux)

48
Système embarqué cible
PC104