La comunità dietro al Raspberry Pi (e per estensione, a Linux) ha dato vita a una straordinaria quantità di sviluppi, ma se c'è un elemento con cui mantiene una dura battaglia, è il codice proprietario associato al modulo video VideoCore IV di Broadcom presente in tutti i modelli del computer. La classica scorciatoia per ottenere funzionalità è quella che molti chiamano un «blob»; tuttavia, la sviluppatrice Kristina Brooks ha pubblicato un bootloader preliminare che cerca di spezzare quel lucchetto sul Raspberry Pi.
La Free Software Foundation descrive la necessità di codice proprietario per inizializzare correttamente un Raspberry Pi come «falla fatale». Naturalmente, la FSF estende la stessa cortesia a tutto l'hardware che si trova in una situazione simile, anche se dobbiamo riconoscere che il duello tra la comunità e la VPU Broadcom VideoCore IV si è protratto molto più a lungo di quanto immaginassimo all'inizio (il Raspberry Pi è sul mercato da più di quattro anni). I benefici del Raspberry Pi sono abbastanza grandi da mettere da parte questa restrizione tecnica, ma se l'obiettivo è rendere la piattaforma «più aperta», prima o poi bisognerà incrociare le spade con essa.
A questo punta il recente lavoro della programmatrice Kristina Brooks, che ha pubblicato su GitHub un bootloader open source per la VPU nel Raspberry Pi. La descrizione ufficiale parla di un piccolo firmware in grado di inizializzare UART, il PLL della VPU e ARM. L'idea è che questo nuovo codice sostituisca il bootcode.bin che si trova nella scheda SD del Raspberry Pi, ed è già stato testato sulle tre generazioni principali del computer. Brooks spiega che è necessario avere UART se si desidera una qualsiasi uscita, e restano diversi problemi da risolvere, tra cui l'uso corretto dei core nei nuovi modelli del RPi.
Inutile dirlo, lo sviluppo è ancora lontano dal poter avviare Linux, e da un certo punto di vista penso che sia più logico collocare il bootloader al livello di una prova di concetto. La direzione del progetto è corretta, e sia Brooks che il resto dei collaboratori citati nella pagina di GitHub hanno fatto un lavoro formidabile, inclusa la stessa Broadcom per aver liberato gli «header». Aspetti critici come l'accelerazione hardware e il supporto ai codec sono ancora in sospeso, e potrebbe non raggiungere mai una posizione ottimale, ma con pazienza, impegno e maggiore collaborazione, sicuramente vedremo un Raspberry Pi più aperto di quanto lo sia oggi.