Sbc qemu emulation

Introduction

Lorsque l'on a pas de SBC physique on peut se tourner vers l'émulation pour faire des tests ! Attention cependant, les performances seront médiocres comme souvent avec l'émulation.

Nous allons utiliser l'émulateur Qemu pour émuler une architecture ARM et pouvoir exécuter une image de PI.

SBC et SoC

Les composants qui forment chacun des SBC va influer sur les performances, capacité, etc... et sont généralement rassemblés sous le nom de SoC. Le Raspberry PI utilise un SoC Broadcom BCM28XX alors que les autres SBC utilise un SoC AllWinner (H2, H3, A10, A20, etc...).

Le SoC peut être vu comme la compression de la carte mère, du CPU, de la RAM et du GPU. Le SBC et l'ajout, autour du SoC, des ports d'extension (USB, Ethernet, SD, etc...)

N'hésitez pas à lire le cours sur le matériel pour des explications plus poussées !

Le Raspberry... et les autres

Le Raspberry PI (et donc le SoC Broadcom BCM28XX) possède en plus du CPU ARM un GPU VideoCore alors que les SoC AllWinner possède un GPU Mali400 et jusque là pas de grosses différences sauf dans la phase de démarrage...

Le Raspberry PI, à l'inverse des autres SBC, n'amorce pas sa phase de démarre pas le biais de son CPU mais de son GPU !

Ci-dessous sont détaillés les phases de démarrage des différents SBC

Raspberry

Les autres

exécution du premier chargeur d'amorçage situé dans une ROM programmée en usine ce code s'exécute sur un petit processeur RISC du GPU ce code monte une partition FAT32 située sur la carte SD ce code n'initialise PAS le CPU ARM qui reste dans l'état RESET exécution du second chargeur d'amorçage situé sur la carte SD: bootcode.bin ce code s'exécute sur un petit processeur RISC du GPU il est chargé dans les 128Ko de cache L2 du GPU il initialise la RAM exécution du troisième chargeur d'amorçage situé sur la carte SD: start.elf ce code est le firmware du GPU il prend ses paramètres dans le fichier config.txt (arm_freq, gpu_freq, etc...) il sépare la RAM en deux parties distinctes (GPU et CPU) exécution du quatrième chargeur d'amorçage kernel.img le kernel démarre avec les paramètres du fichier cmdline.txt il relâche le RESET du CPU ce qui a pour effet de démarrer le système d'exploitation Après le démarrage du système d'exploitation, le code du GPU n'est pas déchargé de la RAM. En effet, start.elf n'est pas juste un firmware pour le GPU mais un système d'exploitation propriétaire appelé VideoCore OS (VCOS). Lorsque Linux nécessite un élément du GPU (caméra, 3D, etc...) il communique avec VCOS au travers du système de mail.

exécution du premier chargeur d'amorçage situé sur une ROM programmée en usine de 32 KiB appelée BROM (Boot ROM) la première partie de la BROM (0xffff0000) est le FEL (pour la programmation de la flash) la seconde partie de la BROM (0xffff4000) est le eGON.BRM (pour le boot de l'OS) eGON.BRM cherchera le noyau Linux (vmlinuz et initrd) sur les périphérique dans cet ordre: SD1 NAND (mémoire eMMC) SD2 SPI USB On peut observer le répertoire boot à partir d'une image et pour cela il faut: déterminer le début de la partition grâce à la commande fdisk monter la partition grâce à mount, l'offset est égale au nombre de secteur multiplié par la taille d'un secteur (ici 8192*512) lister les fichier grâce à ll

Pour émuler un Raspberry PI l'émulateur va devoir jouer le rôle du CPU ARM et du GPU alors que dans les autres cas, seulement le CPU sera nécessaire !

Émulation

Tout d'abord assurez-vous d'avoir téléchargé l'émulateur pour votre OS. Une fois installé, on peut mesurer le nombre d'architecture supportée par Qemu !

Ceux qui vont nous intéresser sont :

• qemu-system-arm pour les processeur ARM jusqu'à la V7 (32bits)
• qemu-system-aarch64 pour les processeur ARM V8+ (64bits)