La vera storia di un progetto hardware

La vera storia di un progetto hardware

di Roberto Premoli - Problemi ed incidenti nulla possono contro una buona motivazione, quella di guadagnarsi un'indipendenza digitale: la gestazione di PremoBoard raccontata dal suo ideatore
di Roberto Premoli - Problemi ed incidenti nulla possono contro una buona motivazione, quella di guadagnarsi un'indipendenza digitale: la gestazione di PremoBoard raccontata dal suo ideatore

L’oggetto che si è poi trasformato nella PremoBoard è frutto di una lunga gestazione: dal primo “E se…” alla versione finale e all’avvio della campagna di crowdfunding è passato circa un anno e mezzo.

L’idea iniziale era creare un Access Point evoluto, in pratica una linuxbox dedicata al networking ma dalle dimensioni contenute, circa 6x9cm tutto compreso (nell’immagine a destra, una delle prime bozze per la verifica delle dimensioni e posizionamento dei componenti principali). Inizialmente come modulo-cpu venne presa in considerazione Aria , un modulo cpu di soli 4x4cm progettato e realizzato in Italia da Acme Systems , che però non disponeva di nessun connettore a bordo, proprio per permettere dimensioni minime. Di contro, l’adozione di un modulo già fatto permetteva di saltare tutta la parte di progettazione della parte CPU/memoria/alimentazione: un evidente vantaggio.
Il modulo Aria garantiva 3 porte USB, ma solo una LAN, mentre il desiderio era di averne almeno due per attività di firewalling: serviva quindi dell’elettronica in più.

Al di là di questo, il problema era che le prestazioni sul fronte LAN non erano eccellenti, mentre uno degli obiettivi era poter saturare la banda passante, cioè garantire i 100Mb/s. Serviva qualcosa di più rispetto ad Aria, che è ottimizzato per minimi ingombri e bassi consumi, non per prestazioni elevate. Abbandonato a malincuore il modulo italiano, le attenzioni si rivolsero alla nota Raspberry Pi , ma l’analisi della sua architettura la etichettava come non all’altezza: infatti il soc BROADCOM BRM2835 ha una sola porta USB che deve veicolare tutto il traffico della scheda (LAN + 2 USB). Buono per attività a basso I/O, ma non in grado di rispettare i requisiti minimi che ci si era dati all’inizio e le prove sul campo confermavano le carenti prestazioni in quanto a MB/s veicolati sulla LAN.

In pratica la Raspberry Pi univa due svantaggi: una CPU mediocre e gli ingombri di una scheda embedded. A quel punto, tanto valeva sacrificare qualche centimetro di ingombro e passare ad una scheda master di classe superiore, e la scelta della CubieBoard divenne naturale: senza contare che la presenza della porta SATA permetteva l’uso di una periferica di massa evitando soluzioni pasticciate come l’uso di un disco esterno connesso via USB. La CubieBoard ha molte frecce in più al suo arco che le permettono di surclassare la Raspberry, vediamone alcune.

– CPU ARMv7@1008MHz (ma scalabile tra 30Mhz e 1200Mhz)
– PORTA LAN 10/100 su chipset dedicato
– 3 PORTE USB 2.0 (2 normali, una mini OTG)
– PORTA SATA
– 1 GB RAM
– 4 GB FLASH
– Porta Infrarossi

Preme sottolineare che sia la porta LAN che le 3 porte USB sono gestite su bus indipendenti, quindi non ci sono colli di bottiglia. Inoltre la CubieBoard era – ed è – disponibile sia in versione mono core che in versione a doppio core, nel caso fosse necessario estremizzare le prestazioni.

La decisione era dunque presa: non si sarebbe realizzato un prodotto finito ma semplicemente una scheda di espansione da connettere alla scheda principale dotata di CPU. E visto che la CubieBoard ha come nome “le_prime_5_lettere_del_cognome_del_progettista”+”board”, venne usato lo stesso principio per “battezzare” la PremoBoard.

Nel frattempo montava lo sdegno per lo scandalo NSA e per l’arroganza con cui degli autonominatisi sceriffi del mondo facevano strage della privacy di chiunque: tutte cose note da tempo, ma che ora erano ufficialmente dimostrate. Spiare è spiare: non fa alcuna differenza se chi spia indossa la mascherina della Banda Bassotti sul volto o una stella di cartone dorato sul petto… che si è appuntato da solo. Certo, se chi spia ha l’approvazione della Magistratura allora va bene, ma primo deve averla e secondo deve essere la Magistratura del Paese di residenza dello spiato, non di un paese a mezzo emisfero di distanza.

Ormai i cattivi – gli spioni – sono padroni del campo, e lo hanno fatto in modo splendidamente subdolo, cioè spingendo le vittime a desiderare di esserlo! Infatti centinaia di milioni di capi di bestiame umano sono già stabilmente dentro ai recinti e altre moltitudini premono ai cancelli chiedendo con grandi muggiti di entrare lì dove la propria vita digitale sarà rivoltata come un calzino, pubblicando tutto il pubblicabile su social network, scattandosi foto che vengono spedite ai server del vero padrone del telefono (chi lo ha in tasca ne è il mero possessore: chiara la differenza tra possesso e controllo ?), usando servizi di posta elettronica che leggono, scandagliano e catalogano ogni parola… evidentemente è troppo difficile leggere il chilometrico contratto realizzato appositamente in legalese, molto più facile selezionare “IO ACCETTO” per potersi fiondare a postare foto di gattini, guardare video di ubriachi che cadono e far sapere al mondo il colore dell’ultimo paio di scarpe comprato, mentre i più estremi pubblicheranno le foto dell’intervento di emorroidi che hanno subìto la settimana prima, perché il modo DEVE sapere quanti punti gli ha applicato il chirurgo.

Ma “tutto va bene, madama la Marchesa”, l’importante è spendere zero per accedere a Facebook e Gmail: e chi se ne importa se l’NSA ha un faldone elettronico con dentro più cose su di noi di quanto noi stessi si possa ricordare. Invece farsi spiare dalla NSA via Apple è più costoso: per possedere (è chiaro per tutti che possesso è ben diverso da controllo ?) lo strumento di spionaggio – pagandolo profumatamente – bisogna fare la coda al negozio, ma vuoi mettere la scarica di adrenalina entrando tra i primi per comprare a rate il nuovo cellulare mentre si canta in coro “tutti all’Apple Store”, con i commessi che applaudono ritmicamente!? È (cerebralmente) morto, Jim! Purtroppo è così: non c’è miglior schiavo di chi desidera esserlo, quindi per lui e gli altri milioni nelle stesse condizioni non c’è più nulla da fare, ma molti altri ancora al di qua della “linea di non-ritorno” possono essere “salvati”.

Deve essere però chiaro che il primo passo, come per tutti i tossicodipendenti, consiste nella volontà di uscirne, e il primo passo in questo caso è abbandonare gli strumenti schiavizzanti di matrice statunitense (Gmail, iPhone, social network) rimpiazzandoli con strumenti omologhi, ma rispettosi della privacy: per esempio, se proprio si desidera uno smartphone, un modello dotato di un sistema operativo come Replicant.us è una buona partenza. Per quanto riguarda invece l’informatica più convenzionale, occorre farsi qualche sevizio in casa come mail server, anonimizzatore di navigazione e altre cosucce…

Parafrasando liberamente, “la tecnologia toglie (libertà), la tecnologia dà (i mezzi per riprendersi la libertà depredata)”. In altre parole, l’hardware della futura Cloud-in-a-box stava prendendo forma concettualmente, ma materialmente era solo qualche disegno su carta. Sia chiaro, non si stava inventando nulla di nuovo: tutte le cose di cui si parla qui possono essere fatte con un vecchio “cassone” recuperabile dal sottoscala. Qui l’unica innovazione era unire potenza discreta, consumi contenuti, robustezza e silenziosità totale in un unico oggetto dagli ingombri ridotti, il tutto valorizzato dall’utilizzo di GNU/Linux come piattaforma software.

Una stampa 3D per la verifica degli ingombri

Vennero realizzati vari modelli stampati in 3D per verificare gli ingombri della PremoBoard, progettata per adattarsi il più possibile alla CubieBoard, in altre parole i “pieni” di una scheda avrebbero dovuto occupare i “vuoti” dell’altra, e viceversa, allo scopo di minimizzare gli ingombri totali. Inoltre vennero adottati alcuni accorgimenti per fare in modo che le due schede potessero essere assemblate faccia-a-faccia, schiena-a-schiena o fianco-a-fianco, in modo da poterne ottimizzare l’uso.
Per quanto riguarda la personalizzazione, è possibile scegliere se avere 2, 1 o nessun modulo wireless risparmiando così su costi e consumi, recuperando al contempo una o due porte USB interne, che non fa mai male avere a disposizione. Nel caso la si voglia usare come base per proprie personalizzazioni, si può avere la PremoBoard addirittura priva dei connettori RJ45 e USB.

Dal punto di vista logico, la PremoBoard è suddivisa in due (ogni metà gestisce una LAN, una WIFI e una o più USB), e ogni metà è controllata da una linea USB della CubieBoard, allo scopo di massimizzare l’I/O. Nel caso il master disponga di una sola linea di USB (per esempio se si vuole usare come scheda principale un Arduino YUN o una Raspberry A) è possibile riconfigurare tramite jumper la PremoBoard per essere gestita da una sola linea USB, anche se questo comporterà un calo di prestazioni.

La struttura generale era definita, ma tornando all’aspetto pratico, serviva un disegnatore tecnico: la persona che aveva dato inizialmente la propria disponibilità abbandonò improvvisamente all’Epifania del 2014 per problemi personali, lasciando il progetto praticamente bloccato: in poche settimane si trovò un sostituto che prestò la propria valida opera volontariamente, fornendo anche i contatti con una ditta a pochi chilometri di distanza per la realizzazione del primo prototipo. Purtroppo la ditta in questione tirò in lungo oltre ogni previsione di ritardo massimo, fornendo i primi modelli a maggio inoltrato.

A sinistra, la CubieBoard con il primo prototipo della PremoBoard, a destra, le due schede accoppiate frontalmente

Venne il momento della verità, cioè la verifica delle capacità di I/O delle porte LAN della PremoBoard, le cui prestazioni dipendono dai “muscoli” della CPU. Era stato arbitrariamente impostato il confine tra “successo” ed “insuccesso” a 70 Mb/s, ma quando i test dimostrarono che le LAN della PremoBoard erano gestite a velocità piena (100Mb/s), fu chiaro che la scelta iniziale della CubieBoard si era dimostrata valida. Per la cronaca, la scheda fu testata con successo anche su PC con Windows XP, Windows 7 e GNU/Linux: l’hardware veniva riconosciuto al volo da GNU/Linux mentre in ambiente Windows partiva la richiesta di accesso ad Internet per il reperimento dei driver.

All’entusiasmo iniziale seguirono giornate convulse, perché i due prototipi “morivano” dopo pochi minuti d’uso: alcuni diodi si surriscaldavano facendo bloccare la scheda, che riprendeva vita solo dopo essersi raffreddata. Alla fine furono identificati i colpevoli in alcuni condensatori al tantalio, la cui sostituzione fece sparire i problemi di instabilità. Se la parte di rete cablata era soddisfacente, anche la parte wireless doveva essere all’altezza. Prima di tutto era necessario che i chipset fossero pienamente supportati dal software, permettendo di essere usati come Access Point. I modulini 8188 scelti inizialmente avevano degli ingombri minuscoli e rispondevano alle esigenze software, ma una volta saldati a bordo e testati, dimostrarono di essere “opachi” cioè avevano una sensibilità infima: nello stesso appartamento bastava cambiare stanza e la rete non si vedeva più. Occorreva trovare qualcosa di meglio, come il chipset RT5370. Purtroppo i moduli che li ospitavano erano grandi il doppio di quelli precedenti, per cui occorreva ridisegnare parzialmente il layout della scheda (attività comunque già prevista perché la prima versione presentava errori da correggere).

Il prossimo passo sarebbe stato realizzare la versione finale del circuito stampato, per cui si cominciò col produttore a parlare di numeri, cioè quanto sarebbe venuta a costare la produzione: ma lo scenario prospettato non era confortante. A quel punto tornò alla ribalta il primo disegnatore, che molto gentilmente segnalò dei produttori/assemblatori (sempre italiani, ci teniamo a precisarlo) che prospettarono dei costi vivi molto più abbordabili. Dopo il ridisegno parziale del layout della scheda vennero realizzati tre esemplari di pre-produzione, uno dei quali prenotato da Marco Calamari, che – ho dimenticato di dirlo – ho avuto modo di incontrare a Bologna nel luglio del 2014: in tale occasione gli parlai del mio progetto e Marco vi colse le opportunità di “privacy” implicite, e mi avrebbe poi invitato a presentarlo di persona al convegno e-privacy tenutosi lo scorso ottobre a Cagliari.

Più il tempo passava e meno pensavo alla PremoBoard come scheda indipendente (anche se continua a rimanere tale) e più all’entità “Cloud-in-a-Box” (CiaB), cioè l’unione di PremoBoard e CubieBoard per la quale ho provveduto a realizzare una scheda “porta disco” per ottenere un blocco compatto composto dalla stratificazione di disco+PremoBoard+CubieBoard, mentre per chi non necessita del disco, ho realizzato una custodia in alluminio e plastica per contenere le sole due schede elettroniche in un volume estremamente ridotto: 35x68x108mm. Nei tempi morti tra un passo e l’altro della produzione, ho anche disegnato il logo facendolo stampare su spillette e qualche maglietta.

A sinistra, il KIT_H, che permette di realizzare la CiaB “orizzontale”, con PremoBoard e CubieBoard connesse fianco-a-fianco, alle quali è possibile aggiungere opzionalmente in disco da 3.5” come si vede a destra

Ottenuti finalmente le schede finali, ho assemblato due CiaB (una con disco) e ho cominciato a fare dei test.

Parliamo delle prestazioni? Utilizzando la CubieBoard mono core abbiamo che:
– L’accesso sequenziale al disco fisso garantisce 48MB/s;
– Le due USB della PremoBoard, collegate con cavi incrociati a due PC di test, riescono ad erogare quasi 19MB/s (contro i 20BM/s teorici);
– le WIFI usate in contemporanea sono entrambe stabilmente oltre i 1500KB/s, mentre una WIFI singola raggiunge facilmente i 2300KB/s;
– le porte USB testate con delle “chiavette” di memoria fanno registrare velocità di I/O comprese tra i 10 e i 20MB/s a seconda delle prestazioni delle singole chiavette.

Fino ad ora i freddi numeri, ma ci sono esempi di utilizzo pratico.
Ho installato hostapd , il server dhcp e droopy : quest’ultimo è un semplice server web che permette di caricare/scaricare file in modo molto facile. Con questa minimale configurazione, la CiaB diventa subito un Access Point in grado di ricevere ed erogare flussi di bit sia via etere che via cavo di rete, il tutto senza dover installare servizi come samba, nfs o ftp: si accende al CiaB e nel giro di pochi secondi si è operativi. Insomma, un modo rapido per condividere file con amici o clienti, molto più flessibile del solito disco USB. Andando oltre l’ambito locale ed esponendo la CiaB ad Internet (aprendo le dovute porte sul modem ADSL) ho testato con successo applicativi come ownCloud : una specie di Dropbox ma realizzato tramite software libero) e Bittorrent (mi piace avere sempre le iso di Debian per x86, AMD64, PowerPC, ARM e kFreeBSD a disposizione per qualunque evenienza).

Una LAN servirà tramite dhcp la intranet, mentre la terza sarà dedicata a (future) attività di DMZ. Una porta wireless verrà configurata come Access Point ridirezionato verso internet, previa però la configurazione filtri di parental control per impedire l’accesso a quella parte di internet non adeguata per i giovani navigatori, il tutto coadiuvato dall’impostazione di accesso temporizzato in determinate fasce orarie. Altre attività in agenda sono l’attivazione di un mirror Debian per avere a disposizione i pacchetti .deb alla più alta velocità possibile all’interno della Rete Locale, dopodiché seguirà l’installazione di un server squid e l’attivazione di un nodo TOR. Ovviamente per offrire servizi in “uscita”, il vincolo è la velocità di upload del proprio contratto con il fornitore di connettività, ma qui ci si scontra con limiti che non sono imputabili alla CiaB in quanto tale.

Per chi preferisce la compattezza a destra la CiaB tascabile: Per chi desidera piu spazio per i dati a sinistra si vede la CiaB “verticale”, con PremoBoard e CubieBoard connesse faccia-a-faccia, completate da disco da 2.5″

Ora siamo a dicembre 2014, dopo un anno e mezzo e migliaia di Euro spesi: la PremoBoard, con pregi e limiti, fa quello per cui era stata pensata, cioè essere una espansione WIFI/LAN/USB se vista da sola, o essere parte di uno “scatolino” orientato all’indipendenza digitale ed alla fruizione ragionata di internet. Da qui ad avere successo commerciale, ce ne corre: la campagna di Indiegogo è attiva, si tratta ora di vedere se il messaggio arriverà, e se arriverà, se sarà capito.

I cattivi hanno vinto? Per il momento pare di sì, ma nella giungla c’è ancora qualche irriducibile giapponese…

Roberto Premoli
Ideatore di PremoBoard

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il
24 dic 2014
Link copiato negli appunti