Differences
This shows you the differences between two versions of the page.
|
si:laboratoare:04 [2023/10/30 11:36] florin.stancu |
si:laboratoare:04 [2024/10/29 19:54] (current) radu_ioan.pascale [Exerciții] Add python virtualenv note |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Laboratorul 04. QEMU & Tools ====== | + | ===== Laboratorul 04. Nuttx - LVGL, timere, butoane ===== |
| - | <note important> | + | Scopurile laboratorului: |
| - | Atenție! Pentru rezolvarea laboratorului, recomandăm folosirea sistemului de operare Ubuntu 22.04. | + | |
| - | Puteți descărca o mașina virtuală Ubuntu 22.04 de pe [[https://github.com/cs-pub-ro/SI-Lab-VM/releases/|GitHub + torrent]] și apoi folosiți [[https://www.vmware.com/content/vmware/vmware-published-sites/us/products/workstation-player/workstation-player-evaluation.html.html|VmWare Player]] pentru a o rula. | + | |
| - | </note> | + | |
| - | ===== Introducere ===== | + | * Familiarizarea cu o bibliotecă populară pentru aplicații grafice pentru dispozitive embedded - [[https://lvgl.io/|LVGL]]. |
| + | * Utilizarea de evenimente asincrone generate de timere si butoane. | ||
| - | 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. | + | ==== Prezentarea suportului de laborator ==== |
| - | Î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: | + | In cadrul laboratorului vom folosi [[https://github.com/dantudose/open-smartwatch | un smartwatch]] ce are la baza un microcontroller **ESP32-S3**. Placa vine dotata cu multe componente externe (dupa cum se poate vedea si in imaginea de mai jos), dar astazi vom folosi doar display-ul, un timer hardware si butonul ''BOOT_BUTTON''. |
| - | * Emularea sistemelor; | + | [[https://github.com/radupascale/smartwatch-licenta|{{ si:laboratoare:pcb2_no_bg.png?500 }}]] |
| - | * 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. | + | |
| - | ==== De ce Linux? ==== | + | {{ :si:laboratoare:hacktor_buttons.jpg|}} |
| - | 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: | + | Butoanele sunt denumite in felul urmator, incepand din stanga sus, in sens trigonometric: |
| - | * **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) | + | * **RESET_BUTTON** |
| - | * **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. | + | * **BOOT_BUTTON** |
| - | * **securitate**: Sistemele care folosesc servicii comune în Linux beneficiază de același nivel de securitate ca pe un sistem desktop sau server | + | * **DOWN_BUTTON** |
| + | * **UP_BUTTON** | ||
| - | 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 | ||
| - | * [[http://store.steampowered.com/livingroom/SteamMachines/ | console de jocuri]] | ||
| - | * [[http://www.geek.com/chips/this-intelligent-fridge-runs-linux-on-an-arm-chip-1297126/ | frigidere ]] | ||
| - | După cum se poate vedea, 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ă. | + | ==== LVGL pe scurt ==== |
| - | 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). | + | LVGL (Lightweight Versatile Graphics Library) este o bibliotecă open-source folosita pentru a crea interfete grafice pe dispozitive embedded. Biblioteca functioneaza pe majoritatea microcontrollerelor ce indeplinesc minimul de resurse necesar - 32kB RAM si 128 kB de memorie flash. De asemenea, biblioteca pune la dispozitie si zeci de exemple de layout-uri care pot fi adaptate in functie de use-case, vedeti demo-uri [[https://lvgl.io/demos|aici]]. |
| - | 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). | + | Utlizarea bibliotecii presupune initializarea de catre aceasta a unui obiect de tip ''lv_display_t'' ce reprezinta o interfata catre driver-ul ecranului pe care se va face afisarea. In cadrul laboratorului de astazi, partea de setup este deja implementata si ne vom concentra doar pe cum anume putem folosi API-ul pentru a crea widget-uri (puteti citi mai multe [[https://docs.lvgl.io/master/intro/basics.html|aici]]). |
| - | Rezolvarea constă în instalarea pe //host// a unui compilator care poate genera executabile înțelese de //target//. Acest compilator poartă denumirea de **cross-compiler**, 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**. | + | Pe scurt, o aplicatie standard ce foloseste LVGL va face urmatorii pasi: |
| + | * Initializeaza biblioteca si display-ul (initializarea obiectului de tip ''lv_display_t'', drawbuffere, callback-uri, etc.). | ||
| + | * Crearea unui thread separat care verifica periodic daca display-ul trebuie updatat. | ||
| + | * Apelarea functiilor de biblioteca in thread-ul principal pentru a desena pe display. Aceste functii creeaza task-uri ce vor fi procesate pe rand de catre celalalt thread (ceea ce se va face in cadrul laboratorului). | ||
| - | Această tehnică este folosită pentru a separa mediul de dezvoltare de mediul în care programul trebuie să ruleze. Acest lucru ne este util în cazul: | + | Pentru a afisa pe un ecran, se pleaca de la un ''lv_obj_t'' ce reprezinta cel mai simplu obiect care poate fi randat. Acesta are coordonate, un parinte, un stil si optional alte obiecte copil. Impartirea ierarhica a elementelor ce trebuie desenate pe ecran ne permite printre altele sa aplicam transformari simultan asupra mai multor obiecte si sa aliniem widget-uri noi raportat la ce este deja existent pe ecran. |
| - | * sistemelor embedded, sisteme limitate din punct de vedere hardware, unde resursele nu sunt suficiente pentru întreg mediul de dezvoltare (ex: AVR, iOS, Android etc.); | + | Exemplul de cod de mai jos ilustreaza cum putem crea o "scena" noua cu un widget simplu pe care scriem un mesaj. |
| - | * compilării pentru arhitecturi diferite, un exemplu fiind distribuțiile Linux, unde se poate folosi o singură mașină pentru a compila pentru diferite arhitecturi (ex: x86, x86-64, ARM etc.) kernelul și restul distribuției; | + | |
| - | * compilării programului într-o fermă de servere, unde pentru performanță maximă, se va putea folosi orice mașină disponibilă, indiferent de arhitectura procesorului //host// sau a versiunii sistemului de operare. | + | |
| - | Diferențierea între //host-compiler// și //cross-compiler// se face prin prefixarea acestuia din urmă cu un string, denumit **prefix**, care, prin convenție, conține o serie de informații despre arhitectura //target// (ex: ''aarch64-linux-gnu-''). De asemenea, și restul utilitarelor folosite pentru compilare (ex: ''as'', ''ld'', ''objcopy'' etc.) vor avea același prefix. Tot ce trebuie să facem este să instruim sistemul de build să folosească //cross-complier//-ul pentru compilare. | + | <code C> |
| + | /* ... */ | ||
| + | void lv_hello(void) | ||
| + | { | ||
| + | /* Cream o scena noua pe care sa desenam si o setam ca fiind scena activa */ | ||
| + | lv_obj_t *screen = lv_obj_create(NULL); | ||
| + | lv_scr_load(screen); | ||
| + | |||
| + | /* Putem seta culoarea default modificand stilul obiectului */ | ||
| + | lv_obj_set_style_bg_color(lv_screen_active(), lv_color_hex(0x003a57), LV_PART_MAIN); | ||
| - | <note important> | + | /* Cream un widget nou de tipul label al carui parinte va fi "screen" */ |
| - | Prefixul unui cross compiler se termină întotdeaduna cu ''-''. El va fi concatenat la numele utilitarelor (ex: ''gcc'') pentru a obține numele complet (ex: ''aarch64-linux-gnu-gcc'') | + | lv_obj_t *label = lv_label_create(lv_screen_active()); |
| - | </note> | + | lv_label_set_text(label, "Hello world"); |
| - | + | ||
| - | <note tip> | + | /* Putem modifica de asemenea culoarea textului si putem centra obiectul relativ la parinte */ |
| - | Prin convenție, majoritatea sistemelor de build folosite în lumea Linux acceptă variabila de mediu ''CROSS_COMPILE'' pentru specificarea prefixului care trebuie folosit atunci când se dorește o //cross-compilare//. | + | lv_obj_set_style_text_color(lv_screen_active(), lv_color_hex(0xffffff), LV_PART_MAIN); |
| - | </note> | + | lv_obj_align(label, LV_ALIGN_CENTER, 0, 0); |
| - | + | } | |
| - | + | /* ... */ | |
| - | ===== RaspberryPi ===== | + | |
| - | + | ||
| - | | {{:si:lab:2015:intro:raspberry-pi-3-ports.jpg?400|}} | | + | |
| - | ^ 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 | + | |
| - | * 1GB 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 | + | |
| - | + | ||
| - | | {{:si:lab:2015:intro:rasp-hardware.png?400|}} | | + | |
| - | ^ Schema perifericelor RaspberryPi ^ | + | |
| - | + | ||
| - | ==== Schema bloc ==== | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | <spoiler Diagrame bloc> | + | |
| - | | {{:si:lab:2015:intro:raspberrypi_blockdiagram.png?direct&600 | }} | | + | |
| - | ^ Diagrama bloc ^ | + | |
| - | + | ||
| - | | {{:si:lab:2015:intro:9512_blockdiagram.png?direct&600 | }} | | + | |
| - | ^ Diagrama block a chip-ului de USB și Ethernet ^ | + | |
| - | </spoiler> | + | |
| - | + | ||
| - | ===== QEMU ===== | + | |
| - | + | ||
| - | [[http://qemu.org| 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 [[https://en.wikipedia.org/wiki/Fabrice_Bellard| Fabrice Bellard]] și este disponibil gratuit, sub o licență open source. QEMU poate rula atât pe Linux, cât și pe Windows [[#referinte| [1]]][[#referinte| [3]]][[#referinte| [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 [[#referinte| [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 [[#referinte| [2]]][[#referinte| [4]]]: | + | |
| - | * //[[http://wiki.qemu.org/download/qemu-doc.html#QEMU-User-space-emulator| 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//. | + | |
| - | * //[[http://wiki.qemu.org/download/qemu-doc.html#QEMU-System-emulator-for-non-PC-targets| 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//. | + | |
| - | + | ||
| - | ==== Instalare ==== | + | |
| - | + | ||
| - | Cel mai simplu mod de instalare pe o distribuție Linux este de a folosi //package manager//-ul. În majoritatea distribuțiilor pachetul principal se numește ''qemu'' și cuprinde de obicei toate executabilele aferente diferitelor moduri de funcționare ale QEMU. Dacă se dorește doar modul de virtualizare cu KVM poate fi instalat pachetul ''qemu-kvm'', iar dacă se dorește modul de emulare a unui sistem ARM poate fi instalat pachetul ''qemu-system-arm''. | + | |
| - | <note> | + | |
| - | <code shell Ubuntu 22.04> | + | |
| - | sudo apt update | + | |
| - | sudo apt install qemu qemu-kvm qemu-system-arm qemu-utils | + | |
| </code> | </code> | ||
| - | </note> | ||
| - | Dacă distribuția folosită nu oferă un pachet pentru QEMU (ex: Windows) sau pachetul oferit conține o versiune prea veche (ex: Fedora 17), se poate alege instalarea din surse. În acest caz, sursele oficiale pot fi downloadate din [[https://git.qemu.org/?p=qemu.git;a=summary| repository]]-ul de Git, iar pentru instrucțiuni de compilare se poate urmări [[http://wiki.qemu.org/download/qemu-doc.html#compilation| pagina de manual]]. | + | Output: |
| + | [[https://docs.lvgl.io/master/examples.html#a-very-simple-hello-world-label|{{ si:laboratoare:hello_lvgl.png }}]] | ||
| - | ==== Rulare ==== | + | Biblioteca ne permite astfel sa ne cream mai multe pagini si sa le incarcam dinamic folosind ''lv_screen_load''. |
| - | 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). | + | ==== Utilizarea de evenimente asincrone pentru timere si butoane in NuttX ==== |
| - | 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 [[#referinte| [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 [[#referinte| [6]]] | + | Suportul de laborator este configurat astfel incat device-urile atat pentru butoane, cat si pentru timer sa fie inregistrate in ''/dev/buttons'' si ''/dev/timer0''. Interactiunea cu ele este similara cu ce s-a discutat in cadrul laboratorului 2 la senzorul de lumina. Se apeleaza ''open'' pentru a obtine un file descriptor catre device, iar folosind ''ioctl'' putem configura alti parametrii cum ar fi frecventa de generare a intreruperilor timer-ului. |
| - | <note> | + | Pe langa aceste configurari de baza, in cadrul scheletului de laborator puteti gasi codul necesar pentru tratarea evenimentelor asincrone generate de timer/buton in doua modalitati diferite. Pe scurt: |
| - | Exemplu de rulare in **user-mode emulation**: | + | - Timer-ul este configurat ca la generarea unui semnal sa apeleze din thread-ul principal functia de callback pentru tratarea semnalelor. |
| - | <code> | + | - Pe de alta parte, un task separat trateaza evenimentele generate de apasarea butonului. Task-ul se afla in majoritatea timpului in starea de //Waiting// datorita apelului functiei ''sigwaitinfo''. |
| - | qemu-arm -cpu <procesor> <executabil> | + | |
| - | </code> | + | |
| - | </note> | + | |
| - | + | ||
| - | Pentru rularea în modul //system emulation// se folosește unul din executabilele de forma ''qemu-system-<arch>'' împreună cu imaginea pentru hard disk [[#referinte| [7]]]. | + | |
| - | + | ||
| - | <note> | + | |
| - | Exemplu de rulare in modul **system emulation**: | + | |
| - | <code> | + | |
| - | qemu-system-arm -machine <arhitectura> -cpu <procesor> -kernel <kernel_file> -append "root=/dev/sda2" -drive file=<rootfs_file>,index=0,media=disk,format=raw | + | |
| - | </code> | + | |
| - | </note> | + | |
| - | + | ||
| - | ==== Configurare ==== | + | |
| - | + | ||
| - | Î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''. | + | |
| - | + | ||
| - | <note> | + | |
| - | <code shell Nokia N800 tablet> | + | |
| - | qemu-system-arm -machine n800 <disk image> | + | |
| - | </code> | + | |
| - | </note> | + | |
| - | QEMU oferă însă și un control mai fin asupra configurației sistemului simulat printr-o serie de alte opțiuni, precum [[#referinte| [8]]]: | + | ==== Exerciții ==== |
| - | * ''-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 [[#referinte| [8]]]. [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html| 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. | + | **0.** Setup: |
| + | * Accesati urmatorul [[https://github.com/radupascale/hectorwatch-nuttx|link]] si urmati instructiunile din README pentru a clona repository-ul cu suportul pentru laborator si pentru a instala toolchain-ul pentru **ESP32-S3**. | ||
| <note important> | <note important> | ||
| - | Pe unele sisteme emulate este chiar obligatoriu ca opțiunea ''-kernel'' să fie prezentă, deoarece emularea sistemului nu include și un bootloader. Fără un bootloader, sistemul nu știe altfel cum să găsească imaginea de kernel. | + | Cititi cu atentie instructiunile legate de procesul de //flashuire// al ceasului. |
| </note> | </note> | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ==== Networking ==== | ||
| - | |||
| - | 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>''. | ||
| - | |||
| - | <note> | ||
| - | Înainte de realizarea configurațiilor de rețea, dezactivați conectarea automată din setările sistemului de operare (Settings -> Network -> Wired -> Connect Automatically (off)) | ||
| - | </note> | ||
| - | |||
| - | Pentru a crea și configura //bridge//-uri se folosește utilitarul **brctl** din pachetul **bridge-utils**. Crearea unui //bridge// care să ofere unui //guest// accesul la rețea fizică a //host//-ului se face astfel: | ||
| - | |||
| - | <code> | ||
| - | sudo brctl addbr virbr0 # creăm bridge-ul | ||
| - | sudo brctl addif virbr0 <interfata fizica> # adăugam interfața fizică a host-ului la bridge | ||
| - | sudo ip address flush dev <interfata fizica> # ștergem adresa IP de pe interfața fizică, doar dacă avem o adresă | ||
| - | # IP pe interfață. Va șterge și ruta default automat | ||
| - | sudo dhclient virbr0 # obținem adresa IP pentru bridge și ruta default prin DHCP | ||
| - | </code> | ||
| - | |||
| - | Dacă nu merge obținerea adreselor prin DHCP, se poate configura manual adresa și ruta default: | ||
| - | <code> | ||
| - | ip address show # notăm ip-ul și prefixul interfeței fizice | ||
| - | ip route show # notăm ruta implicită | ||
| - | sudo brctl addbr virbr0 # creăm bridge-ul | ||
| - | sudo brctl addif virbr0 <interfata fizica> # adaugăm interfața fizică a host-ului la bridge | ||
| - | sudo ip address del <ip>/<prefix> dev <interfata fizica> # mutăm adresa interfeței fizice | ||
| - | sudo ip address add <ip>/<prefix> dev virbr0 # pe bridge | ||
| - | sudo ip link set dev virbr0 up | ||
| - | sudo ip route add default via <gateway> # readăugam ruta implicită | ||
| - | </code> | ||
| - | |||
| - | Pentru ca //bridge//-ul să fie acceptat de QEMU el trebuie configurat și în fișierul ''/etc/qemu/bridge.conf'' sub forma: | ||
| - | |||
| - | <code text bridge.conf> | ||
| - | allow virbr0 | ||
| - | </code> | ||
| - | |||
| - | ===== Toolchain ===== | ||
| - | |||
| - | Toolchain-ul reprezintă colecția de programe de dezvoltare software care sunt folosite pentru a compila și a obține un program executabil. | ||
| - | |||
| - | Programele care în majoritatea cazurilor sunt incluse în toolchain sunt: | ||
| - | * gcc - compilatorul de C; | ||
| - | * g++ - compilatorul de C++; | ||
| - | * as - assamblorul; | ||
| - | * ld - linker-ul; | ||
| - | * objcopy - copiază dintr-un fișier obiect în alt fișier obiect; | ||
| - | * objdump - afișează informații despre fișierul obiect; | ||
| - | * gdb - debugging. | ||
| - | |||
| - | Formatul folosit în general pentru definirea unui toolchain este: ''<arch>-<furnizor>-<os>-<libc/abi>'', ce are următorul șir de componente: | ||
| - | * ''<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 | ||
| - | |||
| - | 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: | ||
| - | - binutils (contine ld, as, addr2line, ar, c++filt, gold, gprof, nm, objcopy, objdump, ranlib, readelf, size, strings, strip) | ||
| - | - 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++). | ||
| - | - Antetele kernelului de Linux (kernel headers - definiții ale apelurilor de sistem, diferitelor tipuri de structuri și alte definiții similare) | ||
| - | - Biblioteca C (glibc, newlib, uclibs, musl etc. - oferă implementarea funcțiilor standard POSIX, plus câteva alte standarde și extensii) | ||
| - | |||
| - | |||
| - | <note>Versiunea kernelului de Linux folosită pentru anteturile kernelului trebuie să fie aceeași versiune sau mai vechi decât versiunea kernelului care rulează pe sistemul țintă. În caz contrar, biblioteca standard C ar putea folosi apeluri de sistem care nu sunt furnizate de kernel.</note> | ||
| - | |||
| - | Procesul de generare al unui toolchain cross-compilat Linux este următorul: | ||
| - | - Se generează întâi binarele din codul sursă binutils | ||
| - | - Se generează librăriile matematice, dependențe ale gcc (compilate pentru mașina gazdă): mpfr, gmp, mpc | ||
| - | - Se instalează anteturile kernelului de Linux | ||
| - | - Se generează o prima versiune de gcc: fără suport pentru o bibliotecă C, doar cu suport pentru legături statice | ||
| - | - Se generează biblioteca standard C folosind prima etapă gcc | ||
| - | - Se generează gcc-ul final, cu suport pentru biblioteca standard C și suport pentru legături dinamice | ||
| - | |||
| - | ===== make ===== | ||
| - | |||
| - | Un program important pentru dezvoltarea unui sistem embedded, și nu numai, îl reprezintă //make//. Acest utilitar ne permite automatizarea și eficientizarea procesului de compilare prin intermediul fișierelor //Makefile//. Pentru o reamintire a modului de scriere a unui //Makefile// revedeți urmatoarea resursa - [[https://makefiletutorial.com/| makefiletuturial]]. | ||
| - | |||
| - | Pentru ușurarea dezvoltării pe multiple sisteme embedded, fiecare având toolchain-ul lui propriu, vom dori să scriem //Makefile//-uri generice, care pot fi refolosite atunci când prefixul //cross-compiler//-ului se schimbă. Pentru aceasta va trebui să parametrizăm numele utilitarelor apelate în //Makefile//. Putem folosi în acest caz variabile de mediu în cadrul //Makefile//-ului. Acestea pot fi configurate apoi din exterior în funcție de sistemul //target// pentru care compilăm la un moment dat, fără a mai fi necesară editarea //Makefile//-urilor. | ||
| - | |||
| - | Cel mai simplu mod de a face acest lucru este să urmăm convenția deja stabilită pentru variabila de mediu care conține prefixul //cross-compiler//-ului: ''CROSS_COMPILE''. Putem folosi această variabilă de mediu în cadrul //Makefile//-ului nostru utilizând sintaxa de expandare unei variabile, ''$(//<variabila>//)'', și prefixând numele utilitarului cu variabila pentru prefix. | ||
| - | |||
| - | <code makefile Makefile> | ||
| - | hello: hello.c | ||
| - | $(CROSS_COMPILE)gcc hello.c -o hello | ||
| - | </code> | ||
| - | |||
| - | Orice variabilă exportată în shell-ul curent va fi disponibilă și în fișierul //Makefile//. Putem de asemenea pasa variabile utilitarului //make// și sub formă de parametri, astfel: | ||
| - | |||
| - | <code shell> | ||
| - | $ make CROSS_COMPILE=aarch64-linux-gnu- hello | ||
| - | </code> | ||
| - | |||
| - | ===== bash ===== | ||
| - | |||
| - | O mare parte din dezvoltarea unui sistem embedded se face prin intermediul terminalului. Shell-ul care rulează în terminal permite personalizarea unor aspecte utile pentru dezvoltare precum variabilele de mediu încărcate la fiecare rulare. Aceste personalizări se fac însă în fișiere de configurare specifice fiecărui shell. | ||
| - | |||
| - | Pentru //bash// aceste fișiere reprezintă niste script-uri care sunt rulate automat și se găsesc în ''/etc'' (afectează toți utilizatorii) și în ''$HOME'' (afectează un singur utilizator). Prin intermediul fișierelor din ''$HOME'' fiecare utilizator își poate personaliza shell-urile pentru propriile nevoi. Aceste fișiere sunt: | ||
| - | |||
| - | * ''.bash_profile'' - este executat când se pornește un shell de login (ex: primul shell după logare); | ||
| - | * ''.bashrc'' - este executat cand se pornește orice shell interactiv (ex: orice terminal deschis); | ||
| - | * ''.bash_logout'' - este executat când shell-ul de login se închide. | ||
| - | |||
| - | Un alt fișier util folosit de //bash// este ''.bash_history'', care memorează un istoric al comenzilor interactive rulate. Istoricul comenzilor este salvat în acest fișier la închiderea unui shell. Pentru o reamintire a unor comenzi utile în linia de comandă puteți revizita laboratorul de USO - [[https://ocw.cs.pub.ro/courses/uso/laboratoare/laborator-08/| Automatizare în linia de comandă]]. | ||
| - | |||
| - | <note tip> | ||
| - | În dezvoltarea unui sistem embedded este deseori utilă adăugarea în variabila ''$PATH'' a căilor către diferitele tool-uri folosite, pentru ca acestea să poată fi accesate direct prin numele executabilului. Modificarea variabilei ''$PATH'' pentru fiecare shell pornit se poate face ușor prin intermediul fișierelor de personalizare a shell-ului. | ||
| - | </note> | ||
| - | |||
| - | ===== Setup ===== | ||
| - | |||
| <note important> | <note important> | ||
| - | Atenție! Pentru rezolvarea laboratorului vom folosi aceeaşi mașină virtuală Ubuntu 22.04 pe care am folosit-o în **Laboratorul 3** rulată în [[https://www.vmware.com/products/workstation-player/workstation-player-evaluation.html|VmWare]]. | + | In cazul in care aveti erori legate de versiunea de ''esptool'' pe masina virtuala, incercati sa creati un environment nou de python: |
| - | </note> | + | <code python> |
| - | + | python3 -mvenv .venv | |
| - | === QEMU === | + | source .venv/bin/activate |
| - | + | pip install esptool | |
| - | Vom configura accesul //target//-ului la Internet. | + | |
| - | + | ||
| - | * Întâi asigurati-va ca aveti access la internet in cadrul masinii virtuale. | + | |
| - | * Emulați interfața de rețea folosind un USB network adaptor virtual. Pentru a avea access la serviciul de SSH din QEMU o sa avem nevoie de port-forwarding pentru portul 22 (SSH default). Pentru a realiza acest lucru, adaugam parametrul ''hostfwd=tcp::5555-:22'' in optiunea de ''-netdev'' din comanda de ''qemu-system-aarch64'': | + | |
| - | + | ||
| - | <code> | + | |
| - | ... | + | |
| - | -device usb-net,netdev=net0 \ | + | |
| - | -netdev user,id=net0,hostfwd=tcp::5555-:22 \ | + | |
| </code> | </code> | ||
| - | |||
| - | |||
| - | * Rulăm distribuția [[ https://raspi.debian.net/tested-images| Debian 12 (Bookworm)]] folosind QEMU în modul //system emulation//. | ||
| - | * Kernel-ul, Device Tree Blob-ul (''.dtb'') si imaginea de InitRD trebuie extrase din imaginea de Debian conform instructiunilor din [[ https://ocw.cs.pub.ro/courses/si/laboratoare/03 | Laboratorul 3]], sectiunea **System-mode emulation**. | ||
| - | |||
| - | <code> | ||
| - | sudo qemu-system-aarch64 \ | ||
| - | -machine raspi3b \ | ||
| - | -kernel vmlinuz-5.18.0-3-arm64 \ | ||
| - | -initrd initrd.img-5.18.0-3-arm64 \ | ||
| - | -dtb bcm2837-rpi-3-b.dtb \ | ||
| - | -sd 20220808_raspi_3_bookworm.img \ | ||
| - | -append "console=ttyS1 root=/dev/mmcblk0p2 rw rootwait rootfstype=ext4" \ | ||
| - | -device usb-net,netdev=net0 \ | ||
| - | -netdev user,id=net0,hostfwd=tcp::5555-:22 \ | ||
| - | -nographic \ | ||
| - | -serial null \ | ||
| - | -serial mon:stdio | ||
| - | </code> | ||
| - | |||
| - | * Logarea pe //target// se face doar cu user-ul **root**. | ||
| - | |||
| - | |||
| - | * Verificam interfetele disponibile | ||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | |||
| - | <note important> | ||
| - | Daca nu aveti nicio interfata de tipul ''enx...'', reporniti QEMU. | ||
| </note> | </note> | ||
| - | * Putem observa ca nu avem nicio adresa IP asociata interfetei. Pentru a realiza acest lucru, vom cere una prin intermediul protocolului DHCP. | + | **1.** Config: |
| - | <code> | + | * Pentru a incepe sa lucrati la laborator selectati si compilati cu configuratia ''lab04si'': |
| - | dhclient $(ls -1 /sys/class/net | grep enx) | + | |
| - | </code> | + | |
| - | * Verificati ca avem o adresa IP asociata interfetei ''enx''. | + | <note tip>''./tools/configure.sh -l ./boards/custom-boards/esp32s3-hectorwatch/configs/lab04si''.</note> |
| - | <code> | + | |
| - | 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 | + | |
| - | inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enx405400123457 | + | |
| - | valid_lft 84722sec preferred_lft 84722sec | + | |
| - | inet6 fec0::4254:ff:fe12:3457/64 scope site dynamic mngtmpaddr | + | |
| - | valid_lft 86288sec preferred_lft 14288sec | + | |
| - | inet6 fe80::4254:ff:fe12:3457/64 scope link | + | |
| - | valid_lft forever preferred_lft forever | + | |
| - | </code> | + | |
| - | * Verificati ca avem acces la internet. | + | * Rulati aplicatia ''lab04si'' din NSH. |
| + | * Ne dorim sa configuram aplicatia astfel incat sa nu fie nevoie sa ne conectam cu ''picocom'' pentru a rula aplicatia ''lab04si'' de fiecare data cand o sa modificam ce se afiseaza pe ecran. Pentru asta, e nevoie sa facem urmatoarele modificari in ''menuconfig'': | ||
| + | * CONFIG_INIT_ENTRYPOINT = "lab04si_main" | ||
| + | * CONFIG_BOARD_LATE_INITIALIZE = y | ||
| + | * In NSH_LIBRARY ----> Have architecture-specific initialization = n | ||
| - | <code> | + | **2.** Updatarea continutului afisat de LVGL: |
| - | root@rpi3-20220807:~# ping 8.8.8.8 | + | * Accesati directorul ''nuttx-apps/examples/lab04si'' si urmați TODO-urile marcate cu **(2)** în schelet. |
| - | </code> | + | * Adăugați o nouă etichetă aliniata sub prima care să afișeze timpul în formatul **minute:secunde** cu valoarea implicită **00:00**. |
| - | * Creati o parola pentru utilizatorul ''root''. | + | * Puteți folosi fie **sprintf** într-un buffer, fie să formatați direct cu [[https://docs.lvgl.io/master/API/widgets/label/lv_label.html#_CPPv421lv_label_set_text_fmtP8lv_obj_tPKcz|lv_label_set_text_fmt()]]). |
| - | <code> | + | * Pentru aliniere, puteti folosi ''lv_align_obj_to''. |
| - | root@rpi3-20220807:~# passwd | + | |
| - | </code> | + | |
| - | * Configurati serivicul de SSH sa accepte logarea ca root | + | |
| - | <code> | + | |
| - | root@rpi3-20220807:~# vim /etc/ssh/sshd_config | + | |
| - | PermitRootLogin yes | + | **3.** Utilizarea timerelor hardware în NuttX |
| - | </code> | + | * Urmați TODO-urile marcate cu **(3)** din schelet. |
| + | * Timer0 este deja configurat (urmariti funcția **setup_timers** apelată la începutul execuției programului pentru detalii). Ne dorim să realizăm următoarele lucruri: | ||
| + | * să contorizăm secundele în handler-ul timer-ului. | ||
| + | * să actualizăm ecranul cu numărul de minute/secunde *numărate de timer* in bucla principala. | ||
| - | * Reporniti serviciul de SSH. | + | <note info> |
| - | <code> | + | Timer-ul este configurat să genereze evenimente o dată pe secundă; puteți modifica acest comportament schimbând valoarea lui `TIMER_INTERVAL` în scheletul de cod. |
| - | root@rpi3-20220807:~# systemctl restart ssh | + | |
| - | </code> | + | |
| - | + | ||
| - | * Connectati-va la QEMU prin intermediul port-ului forward-uit catre masina noastra. | + | |
| - | <code> | + | |
| - | student@virtual-machine:~$ ssh -p 5555 root@localhost | + | |
| - | </code> | + | |
| - | + | ||
| - | === Raspberry Pi ==== | + | |
| - | * Conectiati-va la reteaua Wi-Fi ''LabSI-PR703'' cu parola ''Il0v3-rpi''. | + | |
| - | + | ||
| - | * Conectati-va prin intermediul serivicului de SSH la Raspberry Pi-ul prezent pe masa voastra. | + | |
| - | * Folositi user-ul ''root'' si parola ''Il0v3-rpi'' | + | |
| - | <code> | + | |
| - | ssh root@10.3.14.X | + | |
| - | </code> | + | |
| - | + | ||
| - | + | ||
| - | ===== Exerciții ===== | + | |
| - | + | ||
| - | <note important> | + | |
| - | Atenție! Pentru rezolvarea laboratorului recomandăm folosirea sistemului de operare Ubuntu 22.04. | + | |
| - | Puteți descărca o mașina virtuală Ubuntu 22.04 de pe torrent ([[https://ocw.cs.pub.ro/courses/_media/si/lab/si_lab_vm_2022.torrent.zip|.torrent.zip]]) sau o variantă de pe OSBoxes [[https://www.osboxes.org/ubuntu/|osboxes]] și apoi folosiți [[https://www.vmware.com/content/vmware/vmware-published-sites/us/products/workstation-player/workstation-player-evaluation.html.html|VmWare Player]] pentru a o rula. | + | |
| </note> | </note> | ||
| - | Imaginea de VM cu Ubuntu 22, oferită de echipa de SI, are ca login user-ul si parola: student/student. | + | **BONUS.** Gestionarea inputului de la utilizator: |
| + | * Urmați TODO-urile marcate cu **(BONUS)** din schelet. | ||
| + | * Modificați codul astfel încât inițial timer-ul să fie oprit. | ||
| + | * Ne dorim ca apăsarea butonului **BOOT** (stanga jos, vezi mai sus) să oprească/pornească timer-ul. | ||
| - | Ca sistem de operare embedded, vom folosi distribuția [[https://raspi.debian.net/|Debian Bookworm]] compilată pentru [[https://raspi.debian.net/tested-images|ARM64]]. | ||
| - | ==== 0. Instalați programele și utilitarele necesare ==== | ||
| - | * Actualizați lista de pachete ''sudo apt update'' | ||
| - | * Instalați ''git'', ''vim'' și ''bridge-utils''. | ||
| - | <code> | ||
| - | sudo apt install git vim wget bridge-utils | ||
| - | </code> | ||
| - | * Instalați toolchain-ul necesar pentru a cross-compila programe pentru RaspberryPi 64 biți: | ||
| - | <code> | ||
| - | sudo apt install gcc-aarch64-linux-gnu | ||
| - | </code> | ||
| - | * Instalați QEMU folosind instrucțiunile următoare. | ||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | * Descărcați și dezarhivați o imagine de Debian Bookworm pentru Raspberry PI Model 3B+ [[https://raspi.debian.net/tested-images/|de aici]]. | ||
| - | |||
| - | ==== 1. Opțiunile Qemu ==== | ||
| - | |||
| - | Aflați parametrii pentru opțiunile ''-machine'' și ''-cpu'' necesari pentru a emula sistemul nostru. | ||
| - | |||
| - | <note tip> | ||
| - | * Re-citiți despre modalitățile de [[#rulare|rulare]]. | ||
| - | * Citiți pagina de manual sau [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html| documentația]] online pentru cele două opțiuni. | ||
| - | * Hint: | ||
| - | <code> | ||
| - | qemu-system-aarch64 -machine help | ||
| - | qemu-system-aarch64 -machine <platforma> -cpu help | ||
| - | </code> | ||
| - | </note> | ||
| - | |||
| - | ==== 2. User-mode emulation ==== | ||
| - | |||
| - | 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. Rulați acest executabil atât pe host, cât și pe target-ul RaspberyPi. Ce observaţi când rulaţi pe target? | ||
| - | |||
| - | <code> | ||
| - | #include <stdio.h> | ||
| - | int main(void) | ||
| - | { | ||
| - | printf("hello world\n"); | ||
| - | } | ||
| - | </code> | ||
| - | |||
| - | * 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? | ||
| - | * Compilați pe //host// program-ul **hello world** pentru a putea rula pe //target//-ul RaspberryPi | ||
| - | |||
| - | <note important> | ||
| - | In mod normal executabilul astfel obtinut nu merge rulat si pe sistemul host. | ||
| - | In cazul in care merge rulata aplicatia de hello world si in host explicatie pentru care se intampla asta este: qemu instaleaza un handler care permite aceasta translatia direct, doar ca acest lucru se intampla selectiv, deoarece nu pe toate sistemele de operare este instalat/configurat similar. | ||
| - | </note> | ||
| - | |||
| - | <note tip> | ||
| - | * Re-citiți despre modalitățile de [[#rulare|rulare]]. | ||
| - | * Citiți introducerea acestui [[https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst| kernel feature]]. | ||
| - | * Veti afla mai multe despre cross-compilare in [[04| laboratorul 4]]. | ||
| - | </note> | ||
| - | |||
| - | <note tip> | ||
| - | * Instalați //toolchain//-ul pentru RaspberryPi (local, pe //host//), dacă acesta nu există deja, pentru a putea cross-compila programe pentru RaspberryPi: <code> sudo apt-get install gcc-aarch64-linux-gnu </code> | ||
| - | * Prefixul //cross-compiler//-ului este ''aarch64-linux-gnu-''. Compilatorul este ''aarch64-linux-gnu-gcc''. | ||
| - | </note> | ||
| - | |||
| - | |||
| - | ==== 3. System-mode emulation ==== | ||
| - | |||
| - | 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 [[https://www.qemu.org/docs/master/system/arm/raspi.html|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 [[https://raspi.debian.net/tested-images|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). | ||
| - | |||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | Extrageți imaginea de kernel, dtb-ul si initrd-ul din imaginea de disc de Debian downloadată | ||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | 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): | ||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | 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): | ||
| - | |||
| - | <code> | ||
| - | qemu-img resize 20220808_raspi_3_bookworm.img 4G | ||
| - | </code> | ||
| - | |||
| - | <note tip> | ||
| - | * Re-citiți despre modalitățile de [[#rulare|rulare]]. | ||
| - | * Revedeți parametrii de [[#configurare| configurare]] ai QEMU și citiți pagina de manual sau [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html| documentația]] acestora. | ||
| - | * Pentru a inchide mașina virtuală, folosiți, din cadrul ei, comanda ''sudo halt'' sau ''sudo poweroff''. Dacă doriți să opriți din terminal de pe host, opriti procesul ''qemu'' cu ajutorul comenzii ''killall qemu-system-aarch64''. | ||
| - | * Dacă întâlniți probleme de rulare qemu, însă acesta se închide prea repede și nu puteți vedea eroarea, folosiți argumentele ''-no-reboot -no-shutdown''. | ||
| - | </note> | ||
| - | |||
| - | ==== 4. Instalați serviciul Libvirt ==== | ||
| - | |||
| - | 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ă. | ||
| - | |||
| - | <code> | ||
| - | sudo apt install virtinst | ||
| - | </code> | ||
| - | |||
| - | folosiți kernel-ul, initrd-ul si imaginea discului de la ex.3 pentru a crea o mașină virtuală: | ||
| - | |||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | 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ă. | ||
| - | |||
| - | ==== 5. Schimbați configurația VM-ului (CPU-ul si RAM) ==== | ||
| - | |||
| - | 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: | ||
| - | |||
| - | <code> | ||
| - | virsh edit NUME_VM | ||
| - | </code> | ||
| - | |||
| - | Î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: | ||
| - | |||
| - | <code> | ||
| - | sudo sysctl vm.overcommit_memory=1 | ||
| - | </code> | ||
| - | |||
| - | 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: | ||
| - | |||
| - | <code> | ||
| - | cat /proc/cpuinfo | ||
| - | </code> | ||
| - | |||
| - | <code> | ||
| - | free -m | ||
| - | </code> | ||
| - | |||
| - | ==== 6. Accesul la Internet ==== | ||
| - | |||
| - | 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. 3. | ||
| - | |||
| - | * Emulați interfața de rețea folosind un ''USB network adaptor'' virtual | ||
| - | <code> | ||
| - | -device usb-net,netdev=net0 \ | ||
| - | -netdev bridge,br=...,id=net0 | ||
| - | </code> | ||
| - | |||
| - | Pentru a avea Internet in interiorul VM-ului, putem urma pașii din secțiunea [[#networking| configurare a rețelei]] sau putem instala daemon-ul libvirt, care creează in mod automat bridge-ul "virbr0". | ||
| - | |||
| - | <code> | ||
| - | sudo apt install libvirt-daemon-system | ||
| - | </code> | ||
| - | |||
| - | Folosiți numele noului bridge pentru adaptorul de retea virtual, și permiteți folosirea lui în libvirt: | ||
| - | |||
| - | <code> | ||
| - | echo "allow virbr0" >> /etc/qemu/bridge.conf | ||
| - | </code> | ||
| - | |||
| - | După ce pornește mașina virtuală, listați interfețele de rețea si porniți clientul de DHCP: | ||
| - | |||
| - | <code> | ||
| - | ip addr | ||
| - | dhclient enx405400123457 | ||
| - | </code> | ||
| - | |||
| - | <note tip> | ||
| - | * Înainte de realizarea configurațiilor de rețea, dezactivați conectarea automată din setările sistemului de operare (Settings -> Network -> Wired -> Connect Automatically (off)) și puneți placa de rețea a mașinii virtuale Ubuntu in modul de NAT (Devices -> Network -> Network Settings). Dacă folosiți o rețea wired și nu vă merge cu NAT atunci setați pe modul Bridged Adapter. Atenție, NU setați pe modul "NAT Network". | ||
| - | {{ :si:laboratoare:screenshot_2020-10-12_at_17.47.41.png |Setare rețea}} | ||
| - | * Recitiți secțiunea de [[#networking| configurare a rețelei]] în QEMU. | ||
| - | * Folosiți ''sudo'' pentru rularea ''qemu-system-arm''. | ||
| - | </note> | ||
| - | |||
| - | <note important> | ||
| - | In cazul in care aveti doar conexiune prin wifi, nu veti putea folosi configuratia cu bridge, ci va fi nevoie sa folositi o interfata de tip tap. Urmariti configuratia descrisa in al 2-lea raspuns de [[https://superuser.com/questions/694929/wireless-bridge-on-kvm-virtual-machine/1009881 | aici]]. | ||
| - | </note> | ||
| - | |||
| - | ==== 7. Rulați programul compilat la punctul 2 pe ''guest'' ==== | ||
| - | |||
| - | <note tip> | ||
| - | * Copiați executabilul folosind utilitarul ''scp'' de pe host pe guest. | ||
| - | </note> | ||
| - | |||
| - | ==== 8. BONUS ==== | ||
| - | |||
| - | 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. | ||
| - | |||
| - | Ce puteți spune despre conținutul celor 2 fișiere executabile create la exercițiul anterior? | ||
| - | |||
| - | <note tip> | ||
| - | * Dacă o variabilă nu este setată, construcția ''$(//<variabilă>//)'' într-un //Makefile// va fi echivalentă cu șirul vid. | ||
| - | </note> | ||
| - | |||
| - | <note tip> | ||
| - | * Pentru informaţii legate de tipul fişierelor se poate folosi comanda **file**; | ||
| - | * Conținutul unui fișier executabil poate fi inspectat cu utilitarul **objdump** (ptr //target// folosiţi utilitarul din toolchain: **aarch64-linux-gnu-objdump**) | ||
| - | </note> | ||
| ==== Resurse ==== | ==== Resurse ==== | ||
| - | <hidden> | + | * [[https://nuttx.apache.org/docs/latest/faq/index.html#how-to-start-directly-my-application-instead-starting-nsh|How to start directly my application instead starting NSH]] |
| - | * {{:si:laboratoare:qemu_solutii_2022.txt | Solutii laborator Qemu }} | + | * [[https://docs.lvgl.io/master/intro/basics.html|LVGL Basics]] |
| - | </hidden> | + | * [[https://docs.lvgl.io/8.3/porting/timer-handler.html|Timer Handler LVGL]] |
| - | ===== Resurse ===== | + | * [[https://docs.lvgl.io/8.3/widgets/core/label.html|Labels in LVGL]] |
| - | <hidden> | + | * [[https://nuttx.apache.org/docs/latest/reference/user/07_signals.html|NuttX Signal Interface]] |
| - | * {{:si:laboratoare:tools_solutii_2022.zip|Soluție laborator toolchain}} | + | * [[https://nuttx.apache.org/docs/latest/components/drivers/character/timers/timer.html|Timer Driver in NuttX]] |
| - | </hidden> | + | * [[https://github.com/dantudose/open-smartwatch | Hacktor Watch]] |
| - | * [[https://raspi.debian.net/tested/20220808_raspi_3_bookworm.img.xz| Imaginea Debian 13 (Bookwork) pentru Raspberry Pi 3B]] | + | |
| - | + | ||
| - | ===== Referințe ===== | + | |
| - | - [[http://wiki.qemu.org/Main_Page| QEMU website]] | + | |
| - | - [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html#Introduction| QEMU man page (Introduction)]] | + | |
| - | - [[https://en.wikibooks.org/wiki/QEMU| QEMU Wikibooks page]] | + | |
| - | - [[https://en.wikipedia.org/wiki/QEMU| QEMU Wikipedia page]] | + | |
| - | - [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html#Linux-User-space-emulator| QEMU man page (Linux User space emulator)]] | + | |
| - | - [[https://wiki.freebsd.org/QemuUserModeToDo| QEMU BSD user-mode status page]] | + | |
| - | - [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html#ARM-System-emulator| QEMU man page (ARM System emulator)]] | + | |
| - | - [[https://qemu.weilnetz.de/doc/4.2/qemu-doc.html#sec_005finvocation| QEMU man page (Invocation)]] | + | |
| - | - [[http://elinux.org/RPi_Hardware| RaspberryPi hardware description]] | + | |
| - | - [[https://www.techrepublic.com/article/how-to-enable-copy-and-paste-in-virtualbox/|Copy-paste in VirtualBox]] | + | |
| - | + | ||
