Come si avvia una Raspberry Pi

Di - 27 September 2013 - in
Post image for Come si avvia una Raspberry Pi

Una delle cose piú interessanti dei computer è senz’altro il modo in cui eseguono la procedura detta di bootstrap (boot per gli amici), che serve ad accenderli e a caricare il sistema operativo. Persino il nome della procedura è curioso: il bootstrap è la strisciolina di tessuto o pelle dietro gli stivali, che va tirata indossandoli, e viene dal detto anglosassone “tirarsi su tirando il bootstrap”, ovvero tiarsi su da sé.

Si tratta di una procedura particolarmente interessante poiché per effettuarla è necessario avviare una cascata di eventi causa-effetto che da un’azione puramente hardware (l’accensione dell’alimentazione elettrica) arrivino per gradi a trasferire ed eseguire un software, il sistema operativo, necessario per eseguire gli altri software.

Una macchina curiosa come la Raspberry Pi non potrà che avere una procedura ancora piú interessante del solito.

Vediamo come è fatto l’hardware di questo piccolo e versatile computer.

La Raspberry Pi esiste in due modelli, il Model A, che consuma un po’ meno, ha una sola porta USB e niente Ethernet, mentre il B ha due USB ed un’interfaccia Ethernet.

Tutto quello che in un normale PC è sulla scheda madre, nella Raspberry Pi è concentrato in un singolo circuito integrato, il Broadcom BCM2835, che contiene una CPU ARM11 da 700MHz, una GPU VideoCore IV capace di decodificare video a 1080p, 256MB di RAM e alcune ROM. Un chip contenente un’intera scheda madre viene chiamato System-on-Chip o SoP.

Il resto della scheda, grande come una carta di credito, contiene tutto quello che in un PC sarebbero le schede figlie: l’apparato per l’Ethernet (nel modello B), il lettore SD (il sistema operativo risiede su SD, dettaglio che sarà importante in seguito), il modulo per l’USB, l’interfaccia video/audio HDMI, l’interfaccia video RCA assieme al jack audio, e diverse interfacce di comunicazione con periferiche e circuiti esterni.

Al momento dell’accensione, avviene quello che avviene su qualsiasi macchina: la corrente attiva una ROM, che è un oggetto che si può immaginare come un circuito programmabile (programmato al momento della costruzione del chip) che dà output elettrici stabiliti a seconda dell’input elettrico che riceve. Questa ROM contiene quello che si chiama bootloader di primo livello, un piccolo programma che gira su un mini-processore RISC. Questo bootloader ha il solo compito di montare, ovvero riconoscere e permettere di leggere, la prima partizione della scheda SD. In tale partizione, che è formattata FAT 32, si trova il bootloader di secondo livello, che il bootloader di primo livello carica in una cache L2 della GPU. Questo bootloader di secondo livello può essere visto leggendo la scheda SD con qualunque computer: è il file bootloader.bin.

Fin qui le cose sono state del tutto normali, non troppo diverse da quelle dei PC che utilizziamo solitamente. Ma una cosa molto curiosa c’è: finora l’unico processore utilizzato è stato il piccolo RISC, e a questo punto dovrebbe toccare alla CPU. E invece non avviene cosí: abbiamo visto che il bootloader di secondo livello è stato caricato in una cache della GPU, e infatti verrà eseguito dalla GPU, che si occuperà di attivare la RAM e di caricare un altro file presente sulla scheda SD, start.elf. Si tratta, avete indovinato, del bootloader di terzo livello, che è un po’ troppo voluminoso per le cache e ha quindi bisogno di essere caricato in RAM.

Questo terzo bootloader è analogo, sotto alcuni aspetti (ma assolutamente non del tutto) al BIOS della macchina. Contiene infatti il firmware della GPU, ed è in grado di leggere ed eseguire il file config.txt, modificabile dall’utente, contenente tutte le impostazioni della macchina.

La Raspberry Pi, infatti, è un oggetto estremamente versatile: nel semplice file di configurazione, modificabile banalmente leggendo la scheda SD con un qualunque PC anche Windows (considerando che la partizione in cui si trova è FAT e leggibilissima da Windows) si possono cambiare parametri anche molto delicati dell’hardware. Si può modificare la frequenza di clock (anche portandola in overclock) sia della CPU che della GPU, si può cambiare la frequenza delle memorie, e molte altre cose come alcuni parametri video.

Letto il file, il nostro bootloader di terzo livello, prima ancora di leggere la configurazione, si occupa dell’assegnazione della memoria. La memoria viene divisa in due parti, la prima riservata alla GPU e la seconda alla CPU, dando dunque la precedenza alla GPU. Sono presenti diverse versioni del file .elf, sostituibili a quello di default, che dividono la memoria in modi diversi (io uso la Raspberry Pi per cose che non utilizzano molto la GPU, e dunque le assegno pochissima memoria).

Finito di compiere le operazioni descritte nella configurazione, il bootloader carica finalmente nella RAM dedicata alla CPU il kernel del sistema operativo, descritto nel file cmdline.txt, e attiva la povera CPU che è stata finora in attesa in modalità reset. Il kernel finalmente compie le operazioni necessarie all’avvio del sistema operativo e al montaggio della partizione principale della scheda SD.

A questo punto, sembrerebbe, i bootloader non servono più. Invece non è così: l’ultimo bootloader è qualcosa di più di un semplice firmware. Si tratta infatti di un vero e proprio sistema operativo, proprietario, chiamato VideoCore OS. Tale sistema rimane caricato nella RAM riservata alla GPU, e è pienamente operativo. Il SoC Broadcomm presente nella Raspberry Pi, infatti, non rende disponibili tutte le sue funzioni direttamente al sistema operativo. Qualsiasi sistema installato dovrà comunicare attraverso mailbox messaging con il VideoCore OS, che fa da interfaccia per alcune funzioni.

Insomma, sulla Raspberry Pi la GPU la fa da padrona, sia nella gestione della RAM, sia per il fatto che alcune funzioni vengono messe a disposizione solo dal suo sistema operativo. Un’architettura un po’ strana e curiosa, e criticata da qualcuno per il suo non essere completamente Open Source. Ma valeva davvero la pena esplorarla.

Via | The Kandyan Code

Leave a Reply

Lorenzo Breda Articolo scritto da

Studente di Informatica a Roma, si occupa di programmazione web sopratutto lato server, e di accessibilità del web. Utilizza e ama Debian GNU/Linux, e si interessa di fisica, fumetto, trekking e fotografia (gli ultimi due possibilmente abbinati). Collabora con Googlab da aprile 2012.

Contatta l'autore

Previous post:

Next post: