Sbc qemu emulation

De The Linux Craftsman
Aller à la navigation Aller à la recherche

Introduction

Lorsque l'on n'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 vont influer sur les performances, la 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 utilisent 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 est 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èdent 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émarrage pas le biais de son CPU mais de son GPU !

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

Raspberry Les autres
  1. 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
  2. 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
  3. 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)
  4. 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.

Img sd card content rpi.png
  1. 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)
  2. eGON.BRM cherchera le noyau Linux (vmlinuz et initrd) sur les périphériques 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 secteurs multiplié par la taille d'un secteur (ici 8192*512)
  • lister les fichiers grâce à ll
Img list file armbian.png

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 !

Utilisation de Qemu

Tout d'abord assurez-vous d'avoir téléchargé l'émulateur pour votre OS et modifié votre variable PATH pour y ajouter le répertoire d'installation de Qemu. Une fois installé, on peut mesurer le nombre d'architectures supportées par Qemu !

Qemu listing emulator exe.png

Ceux qui vont nous intéresser sont :

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

Qemu s'utilise en ligne de commande avec certains paramètres dont voici les principaux:

  • -M: pour spécifier le type de machine émulée;
  • -m : pour spécifier la quantité de RAM
  • -cpu : pour spécifier le type de CPU
  • -nic : pour paramétrer la carte réseau
  • -drive : pour spécifier un disque système
  • -dtb : pour préciser l'arbre matériel (DeviceTree Binary)
  • -kernel : pour préciser le noyau utilisé
  • -initrd : pour spécifier le schéma de la RAM (initram FS)

Démarche pour émuler

Les SoC AllWinner

Imaginons que nous voulions émuler un SoC AllWinner H2+.

Orange pi zero.jpg

Cette carte utilise un SoC AllWinner H2+ et d'après la documentation de AllWinner le CPU est un ARM Cortex-A7 (32 bits):

Allwinner h2 documentation.png

Il ne nous reste plus qu'a trouver un SBC avec le même jeu d'instruction (ARMv7) équivalent dans Qemu:

# qemu-system-arm -M help
Supported machines are:
akita                Sharp SL-C1000 (Akita) PDA (PXA270)
ast2500-evb          Aspeed AST2500 EVB (ARM1176)
ast2600-evb          Aspeed AST2600 EVB (Cortex A7)
bast                 Simtec Electronics BAST (S3C2410A, ARM920T)
borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
canon-a1100          Canon PowerShot A1100 IS
cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
collie               Sharp SL-5500 (Collie) PDA (SA-1110)
connex               Gumstix Connex (PXA255)
cubieboard           cubietech cubieboard (Cortex-A9)
emcraft-sf2          SmartFusion2 SOM kit from Emcraft (M2S010)
highbank             Calxeda Highbank (ECX-1000)
imx25-pdk            ARM i.MX25 PDK board (ARM926)
integratorcp         ARM Integrator/CP (ARM926EJ-S)
kzm                  ARM KZM Emulation Baseboard (ARM1136)
lm3s6965evb          Stellaris LM3S6965EVB
...

On remarque que que des SBCs utilisent un CPU Cortex-A (cubieboard, ast2600-evb, ...) de la même famille que le Cortex-A7 et son donc 100% compatible (The ARM Cortex-A7 MPCore processor is fully compatible with other Cortex-A family of processors).

Il ne reste plus qu'a télécharger l'image d'Armbian sur le site d'OrangePi et de la décompresser pour regarder le répertoire boot et notamment la partie dtd:

Armbian dtd pi zero.png

On remarque qu'une dtd existe pour le SBC cubieboard, c'est donc celui-ci que nous allons utiliser avec les fichiers vmlinuz et initrd qui vont avec !

Dans un répertoire décompressez les fichiers initrd, vmlinuz et dtd correspondant (grâce à 7zip si vous êtes sous Windows)

Folder initrd vmlinuz dtd armbian.png

Vous pouvez créez un script bat avec le contenu suivant:

qemu-system-arm.exe ^
-M cubieboard -m 512 -cpu cortex-a7 ^
-dtb .\sun4i-a10-cubieboard.dtb ^
-kernel .\vmlinuz-5.4.20-sunxi ^
-initrd .\initrd.img-5.4.20-sunxi ^
-drive file=.\Armbian_20.02.1_Orangepizero_buster_current_5.4.20.img,format=raw,if=none,id=d1 ^
-device ide-hd,drive=d1 ^
-append "nosmp earlyprintk loglevel=8 earlycon=uart8250,mmio32,0x1c28000,115200n8 console=ttyS0 root=/dev/sda1" ^
-nographic -serial stdio -monitor none ^
-nic user,model=allwinner-emac,hostfwd=tcp::2222-:22

Reprenons dans l'ordre:

Option Signification

-M cubieboard

AllWinner H2+ / H3

-cpu cortex-a7

Cortex-a7

-m 512

512MB de RAM

-dtb

indique le fichier datatree

-kernel

indique le noyau Linux

-initrd

indique le fichier initram fs

-drive

indique le fichier image

-append

indique les paramètres du noyau

-nographic -serial stdio -monitor none

pas de sortie graphique mais plutôt série sur la sortie standard

-nic user,model=allwinner-emac,hostfwd=tcp::5022-:22

carte réseau allwinner-emac avec redirection du port tcp 2222 local sur le port 22 de la machine émulée

Cela permet, après le temps à l'émulateur de démarrer le système, de pouvoir se logger.

Qemu orange pi zero logging.png

Le Raspberry Pi

Pour le Raspberry Pi les choses ne sont pas aussi simple, comme le code du SoC Broadcom BCM28XX est propriétaire il faut donc trouver un équivalent libre qui va émuler le même comportement que le VideoCore OS. Heureusement que le modèle raspi3 sur Qemu fait cela !

Il ne reste plus qu'à récupérer le fichier kernel et DTD présent sur la première partition fat du fichier img

Raspi fat partition content.png

Une fois l'image du système d'exploitation téléchargée (ici Debian Buster) on peut créer un répertoire avec les fichiers suivants :

  • le fichier du noyau qui vient du projet qemu-rpi-kernel (kernel8.img')
  • le fichier DTD qui vient du projet qemu-rpi-kernel (bcm2710-rpi-3-b.dtb)
  • le fichier img (2020-02-13-raspbian-buster-lite.img)

Folder rpi emulation content.png

Enfin, on peut créer le fichier bat suivant:

qemu-system-aarch64 ^
-M raspi3 ^
-m 1024 ^
-dtb .\bcm2710-rpi-3-b.dtb ^
-kernel .\kernel8.img ^
-drive file=.\2020-02-13-raspbian-buster-lite.img,format=raw,if=sd ^
-append "rw console=ttyAMA0 loglevel=8 root=/dev/mmcblk0p2 rootwait" ^
-serial stdio ^
-net user,hostfwd=tcp::2222-:22
pause

Reprenons dans l'ordre:

Option Signification

-M raspi3

SoC BCM28XX

-m 1024

1024MB de RAM

-dtb

indique le fichier datatree

-kernel

indique le noyau Linux

-drive

indique le fichier image

-append

indique les paramètres du noyau

-nographic -serial stdio -monitor none

pas de sortie graphique mais plutôt série sur la sortie standard

-net user,hostfwd=tcp::2222-:22

carte réseau avec redirection du port tcp 2222 local sur le port 22 de la machine émulée

Une fois l'émulateur démarré (avec quelques erreurs...) et que l'on s'est connecté (pi/raspberry) on découvre que l'on a pas de carte réseau !

Le modèle de SBC raspi3 de Qemu n'intègre pas la partie réseau (chip LAN9514) mais il est toutefois possible de récupérer la partie réseau en utilisant le SBC générique de Qemu (virt). Vous devrez cependant recompiler le noyau et régénérer le DTD pour les adapter au virt comme montré ici.

Raspbian GNU/Linux 10 raspberrypi ttyAMA0

raspberrypi login: pi
Password:
Last login: Wed May 13 08:18:53 BST 2020 on ttyAMA0
Linux raspberrypi 4.19.97-v8+ #1294 SMP PREEMPT Thu Jan 30 13:27:08 GMT 2020 aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pi@raspberrypi:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
pi@raspberrypi:~$