Différences entre versions de « Sbc qemu emulation »
(15 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
= Introduction = | = Introduction = | ||
− | Lorsque l'on a pas de [https://fr.wikipedia.org/wiki/Ordinateur_%C3%A0_carte_unique SBC] physique on peut se tourner vers l'émulation pour faire des tests ! Attention cependant, les performances seront médiocres comme souvent avec [https://fr.wikipedia.org/wiki/%C3%89mulation l'émulation]. | + | Lorsque l'on n'a pas de [https://fr.wikipedia.org/wiki/Ordinateur_%C3%A0_carte_unique SBC] physique, on peut se tourner vers l'émulation pour faire des tests ! Attention cependant, les performances seront médiocres comme souvent avec [https://fr.wikipedia.org/wiki/%C3%89mulation l'émulation]. |
Nous allons utiliser l'émulateur [https://fr.wikipedia.org/wiki/QEMU Qemu] pour émuler une [https://fr.wikipedia.org/wiki/Architecture_ARM architecture ARM] et pouvoir exécuter une image de PI. | Nous allons utiliser l'émulateur [https://fr.wikipedia.org/wiki/QEMU Qemu] pour émuler une [https://fr.wikipedia.org/wiki/Architecture_ARM architecture ARM] et pouvoir exécuter une image de PI. | ||
== SBC et SoC == | == SBC et SoC == | ||
− | Les composants qui forment chacun des SBC | + | 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 [https://fr.wikipedia.org/wiki/Syst%C3%A8me_sur_une_puce SoC]. Le Raspberry PI utilise un SoC [https://fr.wikipedia.org/wiki/Broadcom Broadcom] BCM28XX alors que les autres SBC utilisent un SoC [https://fr.wikipedia.org/wiki/Allwinner_Technology AllWinner] (H2, H3, A10, A20, etc...). |
− | Le SoC peut être vu comme la compression de la [https://fr.wikipedia.org/wiki/Carte_m%C3%A8re carte mère], du [https://fr.wikipedia.org/wiki/Processeur CPU], de la [https://fr.wikipedia.org/wiki/M%C3%A9moire_vive RAM] et du [https://fr.wikipedia.org/wiki/Processeur_graphique GPU]. Le SBC | + | Le SoC peut être vu comme la compression de la [https://fr.wikipedia.org/wiki/Carte_m%C3%A8re carte mère], du [https://fr.wikipedia.org/wiki/Processeur CPU], de la [https://fr.wikipedia.org/wiki/M%C3%A9moire_vive RAM] et du [https://fr.wikipedia.org/wiki/Processeur_graphique 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 [[:Media:materiel.pdf|le matériel]] pour des explications plus poussées ! | N'hésitez pas à lire le cours sur [[:Media:materiel.pdf|le matériel]] pour des explications plus poussées ! | ||
+ | |||
== Le Raspberry... et les autres == | == Le Raspberry... et les autres == | ||
− | Le Raspberry PI (et donc le SoC Broadcom BCM28XX) possède en plus du CPU ARM un GPU [https://fr.wikipedia.org/wiki/VideoCore VideoCore] alors que les SoC AllWinner | + | Le Raspberry PI (et donc le SoC Broadcom BCM28XX) possède en plus du CPU ARM un GPU [https://fr.wikipedia.org/wiki/VideoCore 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 | + | 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 | + | Ci-dessous sont détaillées les phases de démarrage des différents SBC : |
<div align="center"> | <div align="center"> | ||
{|class="wikitable" width="85%" | {|class="wikitable" width="85%" | ||
Ligne 35 : | Ligne 36 : | ||
# exécution du quatrième chargeur d'amorçage ''kernel.img'' | # exécution du quatrième chargeur d'amorçage ''kernel.img'' | ||
#* le [https://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27exploitation kernel] démarre avec les paramètres du fichier ''cmdline.txt'' | #* le [https://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27exploitation 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 | + | #* 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. | + | 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. |
[[Fichier:Img sd card content rpi.png|centré|300px]] | [[Fichier:Img sd card content rpi.png|centré|300px]] | ||
|width=40%| | |width=40%| | ||
Ligne 42 : | Ligne 43 : | ||
#* la première partie de la BROM (0xffff0000) est le FEL (pour la programmation de la flash) | #* 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) | #* 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 | + | # eGON.BRM cherchera le noyau Linux (vmlinuz et initrd) sur les périphériques dans cet ordre: |
#* SD1 | #* SD1 | ||
#* NAND (mémoire eMMC) | #* NAND (mémoire eMMC) | ||
Ligne 50 : | Ligne 51 : | ||
On peut observer le répertoire ''boot'' à partir d'une image et pour cela il faut: | 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'' | * 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 | + | * 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 | + | * lister les fichiers grâce à ''ll'' |
[[Fichier:Img list file armbian.png|centré|800px]] | [[Fichier:Img list file armbian.png|centré|800px]] | ||
|} | |} | ||
</div> | </div> | ||
− | 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 ! | + | 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 = | = Utilisation de Qemu = | ||
− | Tout d'abord assurez-vous d'avoir [https://www.qemu.org/download/ 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' | + | Tout d'abord assurez-vous d'avoir [https://www.qemu.org/download/ 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 ! |
[[Fichier:Qemu listing emulator exe.png|centré]] | [[Fichier:Qemu listing emulator exe.png|centré]] | ||
Ceux qui vont nous intéresser sont : | Ceux qui vont nous intéresser sont : | ||
− | * qemu-system-arm pour les | + | * qemu-system-arm pour les processeurs ARM jusqu'à la V7 (32bits) |
− | * qemu-system-aarch64 pour les | + | * qemu-system-aarch64 pour les processeurs ARM V8+ (64bits) |
Qemu s'utilise en ligne de commande avec certains paramètres dont voici les principaux: | Qemu s'utilise en ligne de commande avec certains paramètres dont voici les principaux: | ||
Ligne 83 : | Ligne 85 : | ||
|- | |- | ||
|style="vertical-align:top"| | |style="vertical-align:top"| | ||
− | Cette carte utilise un SoC AllWinner H2+ et d'après la [http://wiki.friendlyarm.com/wiki/images/0/08/Allwinner_H2%2B_Datasheet_V1.2.pdf documentation] de AllWinner le CPU est un ARM Cortex-A7 (32 bits): | + | Cette carte utilise un SoC AllWinner H2+ et d'après la [http://wiki.friendlyarm.com/wiki/images/0/08/Allwinner_H2%2B_Datasheet_V1.2.pdf documentation] de AllWinner le CPU est un ARM Cortex-A7 (32 bits) : |
| | | | ||
[[Fichier:allwinner h2 documentation.png|600px]] | [[Fichier:allwinner h2 documentation.png|600px]] | ||
|- | |- | ||
|style="vertical-align:top"| | |style="vertical-align:top"| | ||
− | Il ne nous reste plus qu' | + | Il ne nous reste plus qu'à trouver un SBC avec le même jeu d'instruction (ARMv7) équivalent dans Qemu: |
| | | | ||
<pre> | <pre> | ||
Ligne 113 : | Ligne 115 : | ||
|- | |- | ||
|style="vertical-align:top"| | |style="vertical-align:top"| | ||
− | On remarque que que des SBCs utilisent un CPU Cortex-A (cubieboard, ast2600-evb, ...) de la même famille que le [https://fr.wikipedia.org/wiki/ARM_Cortex-A Cortex-A7] et | + | On remarque que que des SBCs utilisent un CPU Cortex-A (cubieboard, ast2600-evb, ...) de la même famille que le [https://fr.wikipedia.org/wiki/ARM_Cortex-A Cortex-A7] et sont donc 100% compatibles ([http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.cortexa/index.html ''The ARM Cortex-A7 MPCore processor is fully compatible with other Cortex-A family of processors'']). |
− | Il ne reste plus qu' | + | Il ne reste plus qu'à télécharger l'image d'Armbian sur le [[Iso_install_sdcard#T.C3.A9l.C3.A9charger_l.27ISO|site d'OrangePi]] et à la décompresser pour regarder le répertoire boot et notamment la partie dtd: |
|width=50% style="valign:top"| | |width=50% style="valign:top"| | ||
[[Fichier:Armbian dtd pi zero.png]] | [[Fichier:Armbian dtd pi zero.png]] | ||
Ligne 122 : | Ligne 124 : | ||
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 ! | 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 | + | Dans un répertoire, décompressez les fichiers initrd, vmlinuz et dtd correspondants (grâce à 7zip si vous êtes sous Windows) |
| | | | ||
[[Fichier:Folder initrd vmlinuz dtd armbian.png]] | [[Fichier:Folder initrd vmlinuz dtd armbian.png]] | ||
|- | |- | ||
|style="vertical-align:top"| | |style="vertical-align:top"| | ||
− | Vous pouvez | + | Vous pouvez créer un script ''bat'' avec le contenu suivant: |
| | | | ||
<pre> | <pre> | ||
Ligne 194 : | Ligne 196 : | ||
|- | |- | ||
|style="border-bottom:1px solid black"| | |style="border-bottom:1px solid black"| | ||
− | -nic user,model=allwinner-emac,hostfwd=tcp:: | + | -nic user,model=allwinner-emac,hostfwd=tcp::2222-:22 |
|style="border-bottom:1px solid black"| | |style="border-bottom:1px solid black"| | ||
carte réseau ''allwinner-emac'' avec redirection du port tcp 2222 local sur le port 22 de la machine émulée | carte réseau ''allwinner-emac'' avec redirection du port tcp 2222 local sur le port 22 de la machine émulée | ||
Ligne 200 : | Ligne 202 : | ||
|- | |- | ||
|style="vertical-align:top"| | |style="vertical-align:top"| | ||
− | Cela permet, après le temps | + | Cela permet, après le temps mis par l'émulateur pour démarrer le système, de pouvoir se logger. |
|| | || | ||
[[Fichier:Qemu orange pi zero logging.png]] | [[Fichier:Qemu orange pi zero logging.png]] | ||
Ligne 208 : | Ligne 210 : | ||
{|style="text-align:left; vertical-align:top; width:80%" | {|style="text-align:left; vertical-align:top; width:80%" | ||
|- | |- | ||
− | || | + | |style="vertical-align:top"| |
− | || | + | Pour le Raspberry Pi, les choses ne sont pas aussi simples : 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ésents sur la première partition fat du fichier img | ||
+ | |style="vertical-align:top"| | ||
+ | [[Fichier:raspi fat partition content.png]] | ||
+ | |- | ||
+ | |style="vertical-align:top"| | ||
+ | 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'') | ||
+ | |style="vertical-align:top"| | ||
+ | [[Fichier:Folder rpi emulation content.png]] | ||
+ | |- | ||
+ | |style="vertical-align:top"| | ||
+ | Enfin, on peut créer le fichier bat suivant: | ||
+ | <pre> | ||
+ | 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 | ||
+ | </pre> | ||
+ | |style="vertical-align:top"| | ||
+ | Reprenons dans l'ordre : | ||
+ | {|width="100%" | ||
+ | ! Option !! Signification | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -M raspi3 | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | SoC BCM28XX | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -m 1024 | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | 1024MB de RAM | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -dtb | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | indique le fichier ''datatree'' | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -kernel | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | indique le noyau Linux | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -drive | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | indique le fichier image | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -append | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | indique les paramètres du noyau | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -nographic -serial stdio -monitor none | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | pas de sortie graphique mais plutôt série sur la sortie standard | ||
+ | |- | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | -net user,hostfwd=tcp::2222-:22 | ||
+ | |style="border-bottom:1px solid black"| | ||
+ | carte réseau avec redirection du port tcp 2222 local sur le port 22 de la machine émulée | ||
+ | |} | ||
+ | |- | ||
+ | |style="vertical-align:top"| | ||
+ | Une fois l'émulateur démarré (avec quelques erreurs...) et que l'on s'est connecté (pi/raspberry), on découvre que l'on n'a pas de carte réseau ! | ||
+ | |||
+ | Le modèle de SBC ''raspi3'' de Qemu n'intègre pas la partie réseau ([https://www.microchip.com/wwwproducts/en/LAN9514 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é [https://ownyourbits.com/2017/02/06/raspbian-on-qemu-with-network-access/ ici]. | ||
+ | |style="vertical-align:top"| | ||
+ | <div style="width:100%"> | ||
+ | <pre> | ||
+ | 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:~$ | ||
+ | </pre> | ||
+ | </div> | ||
|} | |} | ||
+ | = Redimensionnement de l'image = | ||
+ | Pour finir, il ne reste plus qu'a redimensionner l'image ''img'' et pour cela nous allons utiliser la commande ''qemu-img.exe'': | ||
+ | <pre> | ||
+ | qemu-img.exe resize -f raw Armbian_20.02.1_Orangepizero_buster_current_5.4.20.img +1G | ||
+ | </pre> | ||
+ | Cela permet d'ajouter 1Go supplémentaire ! Cette manipulation se fait émulateur arrêté... | ||
+ | = Désactivation de la sonde CPU = | ||
+ | Avec certaine platine Sunxi, comme la cubieboard, l'erreur suivante peut survenir : | ||
+ | <pre> | ||
+ | ...thermal thermal_zone0: failed to read out thermal zone 0 | ||
+ | </pre> | ||
+ | Ce n'est absolument pas grave, il faut simplement désactiver la lecture de la sonde de température CPU : | ||
+ | <pre> | ||
+ | echo disabled >/sys/class/thermal/thermal_zone0/mode | ||
+ | </pre> | ||
+ | Cette modification ne résiste pas au redémarrage, pour cela il faudra ajouter la ligne précédente dans le fichier ''/etc/rc.local'' ! |
Version actuelle datée du 30 juin 2021 à 14:30
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 |
---|---|
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. |
On peut observer le répertoire boot à partir d'une image et pour cela il faut:
|
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 !
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+. |
|||||||||||||||||||||||
Cette carte utilise un SoC AllWinner H2+ et d'après la documentation de AllWinner le CPU est un ARM Cortex-A7 (32 bits) : |
|||||||||||||||||||||||
Il ne nous reste plus qu'à 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 sont donc 100% compatibles (The ARM Cortex-A7 MPCore processor is fully compatible with other Cortex-A family of processors). Il ne reste plus qu'à télécharger l'image d'Armbian sur le site d'OrangePi et à la décompresser pour regarder le répertoire boot et notamment la partie dtd: |
|||||||||||||||||||||||
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 correspondants (grâce à 7zip si vous êtes sous Windows) |
|||||||||||||||||||||||
Vous pouvez créer 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: |
| ||||||||||||||||||||||
Cela permet, après le temps mis par l'émulateur pour démarrer le système, de pouvoir se logger. |
Le Raspberry Pi
Pour le Raspberry Pi, les choses ne sont pas aussi simples : 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ésents sur la première partition fat du fichier img |
|||||||||||||||||||
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 :
|
|||||||||||||||||||
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 :
| ||||||||||||||||||
Une fois l'émulateur démarré (avec quelques erreurs...) et que l'on s'est connecté (pi/raspberry), on découvre que l'on n'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:~$ |
Redimensionnement de l'image
Pour finir, il ne reste plus qu'a redimensionner l'image img et pour cela nous allons utiliser la commande qemu-img.exe:
qemu-img.exe resize -f raw Armbian_20.02.1_Orangepizero_buster_current_5.4.20.img +1G
Cela permet d'ajouter 1Go supplémentaire ! Cette manipulation se fait émulateur arrêté...
Désactivation de la sonde CPU
Avec certaine platine Sunxi, comme la cubieboard, l'erreur suivante peut survenir :
...thermal thermal_zone0: failed to read out thermal zone 0
Ce n'est absolument pas grave, il faut simplement désactiver la lecture de la sonde de température CPU :
echo disabled >/sys/class/thermal/thermal_zone0/mode
Cette modification ne résiste pas au redémarrage, pour cela il faudra ajouter la ligne précédente dans le fichier /etc/rc.local !