Laboratorul 04. QEMU & Tools

Până acum am interacționat cu sisteme embedded ce au avut la baza un sistem de operare Real Time numit NuttX, ce a fost configurat si compilat folosind Kconfig-uri si CMake.

În continuare, laboratorul își propune să vă familiarizeze cu sisteme embedded care rulează Linux, începând de la dezvoltare și configurare, până la mentenanță. Vom trata subiecte precum:

• Emularea sistemelor;
• Rularea/Compilarea de aplicații pe un sistem embedded;
• Bootloadere, Kernel, rootfs & initramfs;
• Construirea unei distribuții Linux optimizată pentru sisteme embedded;
• Instalarea și configurarea de servicii.

Sistemele Linux oferă o mulțime de avantaje dezvoltatorilor de produse, care micșorează timpul de dezvoltare, lucru care este din ce în ce mai important în zilele noastre:

• versatilitate: Sistemele Linux nu trebuie să fie single-purpose, se pot adăuga multiple funcționalități cu ușurință (chiar și în etapa de post-producție)
• codebase mare: Sistemele Linux abundă de aplicații user-space, drivere pentru o mulțime de dispozitive, suport pentru multe protocoale/sisteme de fișiere/etc.
• securitate: Sistemele care folosesc servicii comune în Linux beneficiază de același nivel de securitate ca pe un sistem desktop sau server

De-a lungul anilor Linux a devenit cel mai folosit sistem de operare pentru aplicațiile embedded. Îl puteți găsi folosit în orice:

• telefoane mobile (Android)
• router-e
• DVR, NAS
• quadcoptere
• console de jocuri
• frigidere

Sistemele embedded diferă foarte mult în dimensuni și putere de procesare, unele dintre ele apropiindu-se chiar de puterea de procesare a unui calculator obișnuit. De asemenea, aplicațiile pe care acestea le rulează pot fi foarte variate (ex: smartphone), amestecând diferențele dintre un calculator obișnuit și un sistem embedded. Un lucru care deosebește însă sistemele embedded este modul de interacțiune cu utilizatorii, care foarte rar se face printr-un ecran și o tastatură. Lipsa unui mod tradițional de interacțiune cu utilizatorul este și ceea ce face dezvoltarea unui sistem embedded mai grea, dar și mai interesantă.

Cele mai întâlnite două metode de interacțiune cu un sistem embedded în timpul dezvoltării sunt: consola serială și conexiunea SSH. Dintre acestea, conexiunea SSH este metoda mai robustă și mai simplu de utilizat, însă ea e disponibilă doar pe sistemele care dispun de o interfață de rețea. Consola serială, însă este de obicei prezentă pe orice sistem și permite interacțiunea cu sistemul chiar și înainte ca interfața de rețea să fie disponibilă (ex: în bootloader sau înainte de inițializarea driver-ului de rețea).

RaspberryPi Model B

Vom lucra în principal cu RaspberryPi 3, un sistem de calcul bazat pe un procesor “System on Chip” ARM de la Broadcom. Specificațiile complete sunt:

• procesor: 64-bit quad-core ARM Cortex-A53, 1.2GHz
• 2GB RAM
• 4 porturi USB 2.0
• 1 conector Ethernet
• card microSD
• HDMI, jack audio, RCA
• Diverse alte periferice: GPIO, UART-uri, I²C, SPI, I²S

Schema perifericelor RaspberryPi

Din punct de vedere hardware, RaspberryPi este un dispozitiv simplu, care expune diferitele periferice pe care le oferă SoC-ul Broadcom. Singura excepție o reprezintă Hub-ul USB, care dublează numărul de porturi USB disponibile și atașează și un dispozitiv Ethernet la SoC-ul Broadcom.

Diagrame bloc

Diagrame bloc

Diagrama bloc

Diagrama block a chip-ului de USB și Ethernet

Există două concepte importante folosite în dezvoltarea unui sistem embedded: target și host. Target-ul este reprezentat de sistemul embedded pe care îl dezvoltăm și la care ne conectăm (ex: RaspberryPi, Intel Galileo etc.). Host-ul este reprezentat de calculatorul pe care îl folosim pentru dezvoltare și prin care ne conectăm cu sistemul embedded. Pentru a elimina inconvenientele compilării pe sistemul embedded (target-ul) compilarea se face de obicei pe un sistem desktop (host-ul). Bineînțeles, acum pot apărea probleme dacă target-ul și host-ul folosesc procesoare cu arhitecturi diferite (executabilul generat de host nu va fi înțeles de procesorul target-ului). Aceste probleme apar deoarece compilarea va folosi în mod implicit compilatorul host-ului: host-compiler-ul (ex: gcc).

Rezolvarea constă în instalarea pe host a unui compilator care poate genera executabile înțelese de target. Acest compilator poartă denumirea de cross-compiler sau toolchain, el rulând pe arhitectura host-ului, dar generând cod pentru arhitectura target-ului. Procesul prin care un program este compilat pe un alt sistem diferit de sistemul target se numește cross-compiling.

Există patru componente de bază într-un lanț de instrumente de compilare încrucișată Linux. În plus față de acestea, sunt necesare câteva dependențe pentru a construi gcc în sine:

1. gcc (contine compilatorul în sine, cc1 pentru C, cc1plus pentru C++ ce generează numai cod de asamblare în format text, apoi gcc, g++, care apeleaza compilatorul în sine, dar și asamblatorul și linkerul binutils, biblioteci precum libgcc (gcc runtime), libstdc++ (the C++ library), libgfortran etc și fișiere antet pentru biblioteca standard C++);
2. binutils (contine ld, as, addr2line, ar, c++filt, gold, gprof, nm, objcopy, objdump, ranlib, readelf, size, strings, strip);
3. kernel headers: antetele kernelului de Linux (definiții ale apelurilor de sistem, diferitelor tipuri de structuri și alte definiții similare);
4. biblioteca standard C (e.g., glibc, newlib, uclibs, musl etc.), ce oferă implementarea funcțiilor standard POSIX, plus câteva alte standarde și extensii).

Diferențierea între host-compiler și cross-compiler se face prin prefixarea acestuia din urmă cu un string, denumit prefix de forma <arch>-<furnizor>-<os>-<libc/abi> (ex: aarch64-linux-gnu-), ce conține următoarele variabile (trăsături ale target-ului):

• <arch>, arhitectura CPU: arm, mips, powerpc, i386, i686 etc.
• <furnizor>, (în mare parte) șir de formă liberă, ignorat de autoconf
• <os>, sistemul de operare. Fie none , fie linux în scopul acestei discuții.
• <libc/abi>, combinație de detalii despre biblioteca C și ABI-ul în uz

După cum v-ați obișnuit, aceste două utilitare sunt de-facto standard în dezvoltarea de programe de sistem. Extindeți secțiunea de mai jos pentru mai multe detalii:

$ make CROSS_COMPILE=aarch64-linux-gnu- hello

QEMU este un emulator / hipervizor, care permite rularea unui sistem de operare complet ca un simplu program în cadrul unui alt sistem. A fost dezvoltat inițial de Fabrice Bellard și este disponibil gratuit, sub o licență open source. QEMU poate rula atât pe Linux, cât și pe Windows [1] [3] [4].

Este un hypervizor, deoarece poate virtualiza componentele fizice ale unui sistem de calcul, pentru a permite rularea unui sistem de operare, numit oaspete (guest), în cadrul altui sistem de operare, numit gazdă (host). În acest mod de funcționare, atât sistemul guest, cât și sistemul host, folosesc aceeași arhitectură (ex: x86). QEMU poate folosi un modul de nucleu, KVM, pentru a accelera rularea guest-ului, atunci când există suport pentru virtualizare în hardware. În acest caz QEMU poate atinge o performanță comparabilă cu sistemul nativ, deoarece lasă mare parte din cod să se execute direct pe procesorul host. Folosind KVM sunt suportate diferite arhitecturi, printre care x86, PowerPC și S390 [1].

Este un emulator deoarece poate rula sisteme de operare și programe compilate pentru o platformă (ex: o placă ARM) pe o altă platformă (ex: un PC x86). Acest lucru este făcut prin translatarea dinamică a intrucțiunilor architecturii guest în instrucțiuni pentru arhitectura host. Ca un emulator, QEMU poate rula în două moduri [2] [4]:

• User-mode emulation, în care un executabil obișnuit (user-space), compilat pentru o arhitectură, este rulat pe o altă arhitectură. În acest mod de funcționare instrucțiunile din executabil sunt translatate în instrucțiuni ale arhitecturii host, iar argumentele apelurilor de sistem sunt convertite pentru a putea fi pasate sistemului de operare host. Sistemele de operare emulate sunt: Linux, Mac OS X și BSD. Principalele utilizări sunt cross-debugging-ul și cross-compilarea, unde rulăm un compilator nativ al arhitecturii target, pe arhitectura host.
• System emulation, în care este emulat un sistem de calcul complet. QEMU permite emularea unui număr mare de platforme, bazate pe diferite arhitecturi (ex: x86, ARM, PowerPC, MIPS, SPARC, MicroBlaze etc.), împreună cu perifericele lor. În acest mod de funcționare pot fi rulate sisteme de operare întregi, printre care Windows, Linux, Solaris, BSD și DOS.

În dezvoltarea sistemelor embedded, QEMU este folosit deoarece poate emula un sistem de calcul complet, nefiind necesar ca sistemul țintă (target) pentru care se face dezvoltarea, și sistemul host, pe care se face dezvoltarea, să folosească aceeași arhitectură. Acest lucru permite ca dezvoltarea software-ului pentru un sistem embedded să poată fi făcută în paralel cu proiectarea hardware-ului, lucru crucial pentru obținerea unui timp de dezvoltare scurt. Un alt avantaj pe care il poate avea emularea, mai ales a sistemelor low-end, este o viteză superioară a emulării pe un sistem host performant, în comparație cu sistemul target.

Pentru rularea unei mașini virtuale cu KVM se folosește comanda qemu-kvm împreună cu imaginea pentru hard disk. În acest caz imaginea hard disk-ului trebuie să conțină un sistem compatibil cu arhitectura host, accelerarea oferită de KVM putând fi folosită doar dacă guest-ul și host-ul folosesc arhitecturi compatibile (ex: x86_64).

Pentru rularea în user-mode emulation poate fi folosit unul din executabilele de forma qemu-<arch> împreună cu executabilul pe care vrem să-l rulăm [5]. Bineînțeles, acest executabil trebuie să fie compatibil cu arhitectura aleasă, <arch>, iar momentan QEMU oferă suport pentru user-mode emulation doar pe Linux și BSD. Dintre cele două, suportul pentru BSD nu este însă la fel de complet ca cel pentru Linux [6]

Exemplu de rulare in user-mode emulation:

qemu-arm -cpu <procesor> <executabil>

Pentru rularea în modul system emulation se folosește unul din executabilele de forma qemu-system-<arch> împreună cu imaginea pentru hard disk [7].

Exemplu de rulare in modul system emulation:

qemu-system-arm -machine <arhitectura> -drive file=... [+ multe alte argumente]

În modul mașină virtuală sau system emulation QEMU simulează un întreg sistem de calcul. În lipsa unor alte argumente se folosește însă o configurație implicită de sistem, care este specifică fiecărei arhitecuri în parte. QEMU poate însă simula o gamă largă de configurații de sistem. În limbajul QEMU acestea se numesc mașini și pot fi selectate cu opțiunea -machine.

QEMU oferă însă și un control mai fin asupra configurației sistemului simulat printr-o serie de alte opțiuni, precum [8]:

• -cpu - specifică tipul de procesor care va fi emulat
• -m - specifică dimensiunea memoriei RAM
• -hda, -hdb etc. - specifică imaginea pentru primul hard disk, respectiv al doilea hard disk, ș.a.m.d
• -fda, -fdb - specifică imaginea pentru primul floppy disk, respectiv al doilea floppy disk
• -cdrom - specifică imaginea folosită de cdrom
• -serial, -parallel - specifică porturile seriale, respectiv, paralele și modul de interacțiune a acestora cu host-ul

Configurații mai avansate pot fi obținute cu opțiunile -device, -drive, -net, -soundhw, -bt care adaugă dispozitive periferice, de stocare, plăci de rețea și de sunet și, respectiv, dispozitive bluetooth [8]. Documentația oferă informații despre toate aceste opțiuni, precum și multe altele.

O altă opțiune utilă este -kernel. Aceasta permite specificarea imaginii de kernel folosite de sistemul guest direct în comanda QEMU. Astfel, QEMU va încărca kernelul dintr-un fișier aflat pe sistemul host în loc de a-l cauta în imaginea de hard disk. Acest lucru poate reduce semnificativ timpul de iterație în momentul dezvoltării unui sistem embedded, deoarece nu mai este necesară recrearea imaginii de hard disk pentru fiecare modificare a kernel-ului.

De obicei, împreună cu specificarea imaginii de kernel este nevoie să specificăm și linia de comandă a kernel-ului. Pentru aceasta se folosește opțiunea -append împreună cu string-ul care vrem să fie pasat kernel-ului la bootare.

O ultimă opțiune, folositoare mai ales pentru debugging, o reprezintă redirectarea monitorului către consolă. Acest lucru se face cu opțiunea -monitor stdio. Monitorul oferă o interfață în linie de comandă care permite un control interactiv al modului în care se face emularea.

Pentru a emula o interfață de rețea, QEMU se bazează pe două componente: device-ul prezentat guest-ului, configurat cu opțiunea -device sau -net nic, și back-end-ul care leagă acest device de host, configurat cu opțiunea -netdev. Opțiunea -device nu este limitată la a emula doar interfețe de rețea, ea putând configura orice dispozitiv suportat de către QEMU însă, unele plăci de rețea sunt suportate doar de opțiunea -net nic.

Pentru back-end, QEMU suporta mai multe moduri, printre care:

• -netdev user - user-mode, rulează în user-space și nu necesită privilegii, însă interacțiunea cu rețeaua host-ului este complicată
• -netdev tap - tap, conectează o interfață TAP a host-ului la un VLAN emulat, permițând o configurare detaliată a topologiei folosite de guest, însă configurarea este mai complicată
• -netdev bridge - bridge, conectează o interfață TAP a host-ului la un bridge, care permite interacțiunea cu rețeaua fizică a host-ului
• -netdev socket - socket, interconectează VLAN-urile a două sisteme emulate folosind TCP sau UDP.

În mod implicit QEMU emulează un sistem cu o interfață de rețea reprezentată de un device specificat de mașina selectată, în modul user-mode. Aceasta configurare implicită nu ne oferă însă toată flexibilitatea unui target real, conectat la o rețea fizică. Din acest motiv în cadrul laboratorului ne vom folosi de modul bridge.

Bridge-ul folosit de către back-end se configurează cu parametrul br=<nume bridge>, iar device-ul pentru opțiunea -net nic se specifică prin parametrul model=<device>. Legatura dintre cele două componente se face prin adăugarea parametrului netdev=<id> la device și a parametrului id=<id> la back-end. Valoarea <id> trebuie bineînteles să fie identică pentru ca cele două componente să fie legate. În final, cele două opțiuni arată astfel: -net nic,model=<device>,netdev=<id> -netdev bridge,br=<nume bridge>,id=<id>.

student@virtual-machine:~$ ssh root@192.168.122.<X>

     ...
    -device usb-net,netdev=net0 \
    -netdev user,id=net0,hostfwd=tcp::5555-:22 \

root@rpi3-20220807:~# ip a s
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
2: enx405400123457: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 40:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4254:ff:fe12:3457/64 scope link 
       valid_lft forever preferred_lft forever

dhclient <enx...>  # <-- numele interfeței ca parametru

student@virtual-machine:~$ ssh -p 5555 root@localhost

Ca sistem de operare pentru embedded / RPI (azi, emulat), vom folosi distribuția Debian Bookworm compilată pentru ARM64.

• Actualizați lista de pachete sudo apt update
• Instalați git, vim și bridge-utils.

sudo apt install git vim wget bridge-utils

• Instalați toolchain-ul necesar pentru a cross-compila programe pentru RaspberryPi 64 biți:

sudo apt install crossbuild-essential-arm64

• Instalați QEMU folosind instrucțiunile următoare.

sudo apt install qemu-user            # Pentru user-mode emulation
sudo apt install qemu-system-aarch64  # Pentru system-mode emulation
sudo apt install qemu-utils           # Pentru utilitare precum qemu-nbd

• Descărcați și dezarhivați o imagine de Debian Bookworm pentru Raspberry PI Model 3B+ de aici.

Compilați următorul program hello world pentru RaspberryPi și linkați static. Aflați setul de instrucțiuni folosit de executabilul generat și apoi rulați-l în QEMU folosind user-mode emulation și emulând procesorul Cortex-A53. Salvați comanda folosită pentru emulare.

#include <stdio.h>
int main(void)
{
    printf("hello world\n");
}

• Utilizaţi compilatorul aarch64-linux-gnu-gcc.
• Folosiți pentru compilator flag-ul -static pentru a obține un executabil linkat static.
• Utilitarul file oferă informații despre conținutul fișierelor primite ca argument.
• Ce se întâmplă dacă rulați executabilul direct, fără QEMU? De ce?

Rulați distribuția Debian folosind QEMU în modul system emulation. Veți avea nevoie de următoarele argumente pentru emulare.

• Kernel-ul de Linux, prin argumentul “-kernel <kernel_image_file>”.
• Imaginea de InitRD (Initial RAM Disk), prin argumentul “-initrd <initrd_file>”.
• Pentru a funcționa mașina virtuală, este nevoie sa îi pasați emulatorului si un Device Tree, prin argumentul “-dtb <device_tree_file>”.
• Modelul mașinii emulate, prin argumentul “-machine”. Consultați documentația Qemu de aici pentru lista componentelor virtualizate (procesor, memory, periferice) și alegeți modelul corespunzător pentru Raspberry Pi 3.
• Pentru imaginea discului (rootfs-ul), fom folosi Debian 12 (Bookworm) pentru RPi 3B+. Pasați imaginea discului cu argumentul “-sd <disk_file>”, deoarece vom emula un SD-card
• Folosiți string-ul root=/dev/mmcblk0p2 pentru linia de comandă a kernel-ului, deoarece rootfs-ul este pe a doua partitie a SD card-ului).

qemu-system-aarch64 \
	-machine … \
	-kernel … \
	-initrd … \
	-dtb … \
	-sd … \
	-append "console=ttyS1 root=/dev/mmcblk0p2 rw rootwait rootfstype=ext4" \
	-nographic \
	-serial null \
	-serial stdio \
	-monitor none

Extrageți imaginea de kernel, dtb-ul si initrd-ul din imaginea de disc de Debian downloadată

sudo losetup --show -fP 20220808_raspi_3_bookworm.img   # Notați numărul device-ului /dev/loop returnat de comanda losetup
sudo mkdir /mnt/debian
sudo mount /dev/loop16p1 /mnt/debian     # Înlocuiți valoarea 16 cu valoarea numărului vostru
cp /mnt/debian/vmlinuz-5.18.0-3-arm64 .
cp /mnt/debian/initrd.img-5.18.0-3-arm64 .
cp /mnt/debian/bcm2837-rpi-3-b.dtb .
# facem unmount și deconectăm imaginea din dispozitivul bloc
sudo umount /mnt/debian
sudo losetup -d /dev/loop16

Pentru montare, puteți folosi utilitarul qemu-nbd (care, în plus față de losetup, știe să deschidă mai multe formate de mașini virtuale precum vbox și vmdk):

sudo modprobe nbd max_part=8
sudo qemu-nbd -c /dev/nbd0 220121_raspi_3_bullseye.img
sudo mkdir /mnt/debian /mnt/debian/boot
sudo mount /dev/nbd0p2 /mnt/debian
sudo mount /dev/nbd0p1 /mnt/debian/boot
# acum putem explora partiția de boot din imagine
ls -l /mnt/debian/boot
# facem unmount și deconectăm imaginea din dispozitivul bloc
sudo qemu-nbd -d /dev/nbd0

Deoarece discul pasat către Qemu este de tip SD card, Qemu așteaptă ca dimensiunea discului să fie o putere a numărului 2 (ex. 512MB, 1024MB). Din acest motiv trebuie să redimensionăm discul, spre exemplu la 4GB. Qemu dispune, de asemenea, de utilitare pentru manipulat imagini (creare / redimensionare / conversie între formate):

qemu-img resize 20220808_raspi_3_bookworm.img 4G

Libvirt este un serviciu ce permite folosirea Qemu mult mai ușor. Împreună cu tool-uri precum virsh (virtual shell) sau virt-manager, utilizatorul poate crea, porni, opri, clona sau migra mașini virtuale foarte ușor si rapid. În acest laborator vom folosi tool-ul virt-install pentru a crea o noua mașină virtuală.

sudo apt install virtinst

folosiți kernel-ul, initrd-ul si imaginea discului de la ex.3 pentru a crea o mașină virtuală:

virt-install --name rpi3-qemu-si \
	--arch aarch64 \
	--machine virt \
       	--os-variant debian11 \
	--boot kernel=...,initrd=...,kernel_args="console=ttyAMA0 root=/dev/vda2 rw rootwait rootfstype=ext4" \
	--disk ... \
       	--vcpus 2 \
	--nographic \
       	--feature acpi=off

Pentru a ieși din consola virsh, folosiți combinația ctrl + ]. Avem la dispoziție următoarele comenzi:

• virsh list –all - listează toate mașinile virtuale
• virsh destroy NUME_VM - opreste o mașină virtuală
• virsh undefine NUME_VM - șterge o mașină virtuală
• virsh shutdown NUME_VM - trimite o comandă de graceful shutdown, similar cu apăsarea butonul de Power

Numele destroy poate induce putin în eroare, deoarece mașina este doar oprită și nu ștearsă.

Cu mașina virtuală de la ex. 4 oprită, editați configurația cu ajutorul următoarei comenzi și adăugați 8 procesoare si 32GB de RAM:

virsh edit NUME_VM

În mod implicit, kernel-ul va refuza alocarea de memorie virtuală pentru un process de user-space, mai mult decât are sistemul disponibil. Dar îl putem convinge cu următoarea comanda executată in VM-ul de Ubuntu 22:

sudo sysctl vm.overcommit_memory=1

Desigur, în momentul în care VM-ul începe să folosească multă memorie, VM-ul (procesul) va fi automat oprit (killed).

Porniți mașina virtuală, deschideți consola cu ajutorul comenzii “virsh console NUME_VM” și listați noua configurație:

cat /proc/cpuinfo

free -m

Configurați și testați accesul guest-ului la Internet. Salvați comanda folosită pentru emulare.

Pentru aceasta, opriți VM-ul din virsh si reluați comanda de la ex. 2 (vom folosi qemu).

• Emulați interfața de rețea folosind un USB network adaptor virtual

	-device usb-net,netdev=net0 \
	-netdev bridge,br=...,id=net0 

Pentru a avea Internet in interiorul VM-ului, putem urma pașii din secțiunea configurare a rețelei.

Dacă doriți să folosiți modul bridge, instalați daemon-ul libvirt care îl configurează ajutomat:

sudo apt install libvirt-daemon-system

Folosiți numele noului bridge pentru adaptorul de retea virtual, și permiteți folosirea lui în libvirt:

echo "allow virbr0" >> /etc/qemu/bridge.conf

După ce pornește mașina virtuală, listați interfețele de rețea si porniți clientul de DHCP:

ip addr
dhclient en<XYZ>

Creați un Makefile generic pentru programul hello world care poate compila pentru orice sistem target în funcție de variabilele primite (convenția CROSS_COMPILE). Compilați programul pentru host și pentru target-ul RaspberryPi, apoi salvați executabilele generate.

Copiati cu scp binarul necesar pe target, ce observati?

Ce puteți spune despre conținutul celor 2 fișiere executabile create la exercițiul anterior?

• Imaginea Debian 13 (Bookwork) pentru Raspberry Pi 3B

1. QEMU website
2. QEMU man page (Introduction)
3. QEMU Wikibooks page
4. QEMU Wikipedia page
5. QEMU man page (Linux User space emulator)
6. QEMU BSD user-mode status page
7. QEMU man page (ARM System emulator)
8. QEMU man page (Invocation)
9. RaspberryPi hardware description
10. Copy-paste in VirtualBox