La soluzione in breve

L’idea è semplice: usare un sistema domotico open-source (Home Assistant) integrato con modelli di intelligenza artificiale per interpretare comandi vocali, elaborare risposte e fornire feedback audio. Il tutto senza dipendere da servizi cloud proprietari (come Alexa o Google Assistant), garantendo maggiore privacy e personalizzazione.

I componenti chiave sono:

• Home Assistant (versione 2026.2.1) come hub centrale.
• Due addon di Home Assistant per l’AI:
  • Local OpenAI LLM (1.3.1) per gestire il modello linguistico.
  • OpenAI Whisper Cloud (1.3.2) per il riconoscimento vocale.
• Mistral AI come fornitore del modello linguistico (più economico e compliant con il GDPR e l’EU AI Act che diventerà cogente in Agosto 2026).
• PicoTTS per la sintesi vocale di base (integrato nativamente in Home Assistant).

Passo 1: Configurare Mistral AI

Prima di tutto, è necessario registrarsi su Mistral AI e generare una chiave API all’indirizzo https://console.mistral.ai/home. Per comodità, io l’ho chiamata homeassistant, ma potete usare il nome che preferite. Questa chiave servirà per collegare Home Assistant ai servizi di Mistral.

Attenzione: Mistral, come molti provider di inferenza, ha una offerta variegata. Offre un livello gratuito con crediti limitati (verificate le condizioni aggiornate sul loro sito), ha la possibilità di funzionare in abbonamento con un canone mensile e supporta una modalità di pagamento a consumo, chiamata API. In generale, poiché non voglio essere legato ad un tool di un venditore specifico, io opto sempre per la fatturazione a consumo dell’accesso mediante API. Questo tipo di accesso permette spesso di pagare di meno di un abbonamento. Ad esempio, il modello mistral-small-latest (quello che sto usando io) ha un prezzo accessibile e funziona egregiamente per questo scopo. Trovate tutte le informazioni sui prezzi dell’uso delle API qua.

Passo 2: Installare e configurare gli addon in Home Assistant

OpenAI Whisper Cloud

Installate l’addon da HACS di Home Assistant. Nella configurazione, selezionate Mistral come fornitore del servizio. Incollate la chiave API generata in precedenza. In automatico il sistema vi proporrà di usare il modello voxtral-mini-latest.

Local OpenAI LLM

Anche qui, installate l’addon (versione 1.3.1 o successiva) da HACS. Attenzione: versioni precedenti dell’addon non funzionano con Mistral (si veda questa issue) su Github. Nella configurazione, oltre alla chiave API, dovete specificare l’URL del servizio Mistral: https://api.mistral.ai/v1/.

Se l’installazione non crea automaticamente un conversation agent, aggiungetelo manualmente con l’apposito pulsante nella schermata delle integrazioni. E’ possibile creare anche più di un agente di conversazione, basandosi su diversi modelli (e costi). Come vi dicevo, io uso mistral-small-latest.

I modelli di Mistral hanno la caratteristica di non obbedire sempre alle richieste di formattazione e troppo spesso tendono a generare testo in formato markdown. Questa formattazione non va bene con i sistemi Text-To-Speech (TTS), che finiscono con leggere i tag del markup. Per ovviare a questo nella scheda dell’integrazione di Local OpenAI LLM è necessario clickare sul simbolo di configurazione dell’agente di conversazione e modificare la configurazione dell’agente nel modo seguente:

You are a voice assistant for Home Assistant.
Answer questions about the world truthfully.
Answer in plain text. Never use markdown. Keep it simple and to the point.

Può sembrare poco, ma l’aggiunta di Never use markdown. fa la differenza.

Passo 3: Abilitare la sintesi vocale con PicoTTS

PicoTTS è un motore di text-to-speech (TTS) basilare ma funzionale per testare la soluzione, perché in questa applicazione ci interessa di più capire il linguaggio naturale dell’utente ed eseguire azioni, piuttosto che fare conversazione. PicoTTS ha una voce robotica e limitata perché è pensato per sistemi embedded. Per attivarlo, modificate il file configuration.yaml di Home Assistant aggiungendo:

tts:
    - platform: picotts

Riavviate Home Assistant, in modo da abilitare tutti i componenti.

Passo 4: Collegare i puntini in Home Assistant

Ora è il momento di unire tutto:

• Andate in Impostazioni > Assistenti vocali.
• Verificate che ci sia un assistente predefinito chiamato Home Assistant. Qualora non fosse presente si può aggiungerne uno
• Nella sezione AI Agent, scegliete quello che avete creato con il modello che avete selezionato configurando Local OpenAI LLM (mistral-small-latest in questo esempio) e disabilitate la gestione dei comandi in locale (altrimenti bypassereste l’AI).
• In Riconoscimento vocale, impostate Mistral AI Whisper.
• Infine, in Sintesi vocale, selezionate PicoTTS.

Dovreste ritrovarvi con una configurazione simile a questa:

Testare la soluzione

A questo punto, potete usare l’interfaccia web o la companion app di Home Assistant (disponibile per Android e iOS) per interagire con il sistema. In alto destra c’è la voce Assist (attenzione, nella app potrebbe essere collassata nell’icone dei re puntini) con cui sarà possibile avviare una conversazione. Attenzione: potrebbe accadere che su Firefox non vi funzioni il microfono. Questo accade perché siete connessi all’interfaccia web mediante HTTP e non HTTPS.

Qualora il sistema vi piaccia, potete automatizzare i comandi vocali con Voice, lo smart speaker ufficiale di Home Assistant.

Per gli impazienti, ecco un calcolatore per determinare le prestazioni di un sistema di visione, secondo la norma EN/IEC 62676-4.

Spiegazione della norma EN/IEC 62676-4

La norma EN/IEC 62676-4 raccoglie i requisiti e le raccomandazioni per la corretta progettazione, installazione, verifica e manutenzione di un Video Surveillance System (VSS).

Come tutte le normative più moderne, anche la 62676-4 è una norma basata sull’analisi dei rischi. L’analisi deve considerare:

• il costo delle perdite
• l’ubicazione del sito
• le restrizioni di accesso al sito
• gli eventi pregressi

L’output di tale analisi confluirà nel Documento dei Requisiti Operativi (DRO) e a ciascun elemento da proteggere verrà assegnato il grado di rischio, come definito nella EN/IEC 62676-1-1. Il grado di rischio può assumere i seguenti valori:

• 1, ovvero low risk, che identifica un sistema o sito che non necessita del controllo delle funzioni perché non esposto al rischio di manomissioni
• 2, ovvero low to medium risk, che identifica un sistema o sito in cui non viene monitorato il funzionamento perché dispone di protezioni semplici contro le manomissioni. In un impianto di videosorveglianza per un obiettivo di questo tipo, questo si traduce nel fatto che le telecamere non sono accessibili dall’esterno.
• 3, ovvero medium to high risk, che identifica un sistema o sito in cui vengono controllati sia il funzionamento che le manomissioni. A questo livello di rischio corrisponde anche una preprazione tecnica di base dell’aggressore, che potrebbe sapere come manomettere il sistema di videosorveglianza.
• 4, ovvero high risk, che identifica un sistema o sito con elevate protezioni contro le manomissioni in cui viene garantito anche il controllo della funzionalità. A questo livello di rischio sono associate un’alta competenza tecnica degli intrusori e non è ammesso perdere le registrazioni.

In base al grado rischio di ciascun elemento da proteggere potr&agrave essere usata una telecamera per verificare il corretto funzionamento del bene. In base all’oggetto da proteggere, la camera potrà effettuare una delle azioni previste dal modello MDORII:

• Monitor che richiede 12 pixel/metro sul bersaglio
• Detect che richiede 25 pixel/metro sul bersaglio
• Observe che richiede 62 pixel/metro sul bersaglio
• Recognise che richiede 125 pixel/metro sul bersaglio
• Identify che richiede 250 pixel/metro sul bersaglio
• Inspect che richiede 1000 pixel/metro sul bersaglio

Come accadeva nel criterio di Johnson, la massima distanza a cui una telecamera può garantire la risoluzione deciderata dipende dalla lente e dalle carettaristiche del sensore.

Un po’ di formule

La distanza basata sulla EN/IEC 62676-4 è facilmente ricavabile con la trigonometria dei triangoli rettangoli.

\[ d = \frac{res}{2} . \frac{1}{pixel per metro} . \frac{1}{\tan( \alpha_{tele, hor}) } \]

Dove con α si indica l’angolo di visione, deifnito come nella pagina del criterio di Johnson.

Non è facile riassumere 20 mesi di studio, impegno e, inevitalmente, tensioni in una singola pagina di un blog. Le persone che ho conosciuto, le materie che ho studiato, la difficoltà nell’incastrare tutto questo con la famiglia, il lavoro e le trasferte, semplicemente non ci stanno.

Il giorno della proclamazione Giacomo Tomezzoli, un mio compagno di corso eletto a rappresentante della classe ha letto un discorso che riassume magnificamente l’esperienza. Poiché non voglio perdere questo discorso, ho deciso di riportarlo in questa pagina.

Buonasera al gradito ed egregio ospite dott. Sandro Stramare, al Presidente Visentin, al Direttore Scientifico Prof. Vinelli, ai rappresentanti della Faculty, ad Alessia e allo staff, a tutti i colleghi diplomandi, alla dott.ssa De Stefani che seguirà, a tutti voi presenti.

Cari ingegneri e non ingegneri (perché se una cosa mi è parsa chiara da subito frequentando queste aule è che questa divisione in caste esiste, una iattura per gli ingegneri), è un onore per me rappresentare i diplomandi dell’EMBA 14 e poi capirete il motivo. Non preoccupatevi, nessuna presentazione ad effetti speciali oggi, ma qualche riflessione, qualche PERCHE’. Spero capace di dare una traccia di un viaggio, importante, che abbiamo fatto e che faremo.

Per fare sintesi e farci un augurio, per raccontarci che cosa alla fine ci siamo portati a casa, ho deciso di recuperare ed adattare una storia che mi ha affascinato molto e che ritengo possa essere condivisa in questa occasione, magari qualcuno di voi l’ha già sentita. E’ una storia utilizzata nel talent management, è la storia di un ragazzino, un ragazzino che giocava a calcio per le strade e le piazze della sua città, fino ad arrivare ai campetti di periferia e poi sulla cima del mondo. La storia racconta che questo ragazzino tirasse con il piede destro, provasse – in sostanza - a fare tutto ciò che facevano i suoi coetanei. Fino al giorno in cui un signore, che lo osservava da bordo campo, gli disse: perché non provi con il piede sinistro? Scoprirai il tuo vero talento. E così fu, quel ragazzino diventò un giocatore, un campione, un fuoriclasse per l’esattezza, che arrivò a fare probabilmente il gol più bello nella storia del calcio moderno, con ben 11 tocchi di palla fatti col solo piede sinistro, il suo più autentico talento.

Lasciamolo lì, per un momento, quel ragazzino, e proviamo ora a ripercorrere un’altra storia, brevemente, quella che ci ha cambiato, quella di questi 20 mesi intensi all’interno di questo magnifico contesto.

Che cosa è stato l’EMBA? I nostri amici, parenti e colleghi se lo immaginano? Quando siamo arrivati non lo sapevamo cosa sarebbe diventato per noi. In queste aule, in una delle business school più antiche d’Italia tutto ha avuto corso come farebbe un torrente in piena.

Partimmo con la contabilità d’azienda e fu subito terrorismo psicologico. Per non cadere nella trappola dell’effetto possessione la sera si ricalcavano gli appunti. Siamo passati a segmentare segmentare segmentare il mercato, per chiudere con un enciclopedico piano di marketing. Di lì a poco ci siamo cimentati con i metodi quantitativi e la matematica finanziaria, materia in cui la classe si è subito divisa in due gruppi: chi stava in apnea per più di 2 minuti e chi sapeva la matematica (io appartenevo al primo gruppo). Abbiamo costruito modelli su modelli di controllo di gestione nella calura dei mesi estivi – esattamente 12 mesi fa. Volato via il primo anno ecco arrivare la finanza, non le fiamme gialle, ma quella d’impresa. In equilibrio verticale ma precario per tutta la durata del corso abbiamo stabilito con accuratezza le opportunità finanziarie di una società biomedicale. Via di corsa quindi verso il modulo più lungo, le operation e la supply chian, dove siamo stati deliziati con addirittura una lezione aggiuntiva e dove abbiamo attraversato idealmente tutte le fasi della catana del valore. Siamo quindi passati al modulo delle risorse umane, dove imparammo a selezionare, organizzare e valutare… e dove siamo stati valutati (non facile come sembrava). Infine la strategia d’impresa, l’oceano blu, il posizionamento, i modelli di business, le fusioni e le acquisizioni. Il docente, avvisato dai colleghi, ci ha pregato di non essere anch’egli travolto dalla nostra tracotanza (vi prego poche paginette, ci ha detto).

Ma fosse solo questo: un business game dominato dalla HairWash, un business plan combattuto fino alla fine dalla Froota e dalla Tonazzo, un project work dove tutti hanno cercato di stare con onore alle spalle della Hachiko team. Ma poi il project management, l’international management, l’information technology, le diversità culturali con gli abitanti dell’isola di Morenia (che qui non imito), le competenze trasversali, il publick speaking, la gestione dello stress, i lavori di gruppo bendati, quelli con le assi di legno (e qui sorvoliamo), con i ponti di carta, l’orientamento nei boschi di Tretto, la scrittura di un libro a 48 mani, la realizzazione di un gioco in scatola, Fred sull’iceberg che si stava sciogliendo, il beer game, gli incontri di coaching, la gestione della complessità. Basta, non c’era più spazio. Nemmeno Athena, dea greca della Sapienza avrebbe retto a tanto.

Se è difficile spiegare COSA sia stato proviamo allora a raccontarvi COME è stato questo MBA? Non posso certo dirlo io, lo possono solo dire tutti loro, i miei colleghi.

Che cosa è stato l’EMBA? I nostri amici, parenti e colleghi se lo immaginano? Quando siamo arrivati non lo sapevamo cosa sarebbe diventato per noi. In queste aule, in una delle business school più antiche d’Italia tutto ha avuto corso come farebbe un torrente in piena.

1. Acceleratore per Umberto ➡️ lavoratore instancabile
2. Arricchente per Giacomo ➡️ fortunato e spero degno portavoce quest’oggi
3. Autovalutazione per Enrico Z. ➡️ grande uomo di gruppo
4. Coinvolgente per Marco ➡️ e i suoi puntuali e precisi punti di vista
5. Complementativo per Graziano ➡️ pressione e passione nelle vene
6. Conferma per Piazza ➡️ unico commerciale a cui interessa il viaggio oltre che la meta
7. Confronto per Ketty ➡️ imprenditrice, linguista e ottimista
8. Consapevolezza per Sabrina ➡️ super direttiva e affidabile
9. Destabilizzante per Elena ➡️ visione strategica e decisione
10. Edificante per Loris ➡️ alto potenziale, uno che vende armi al Vaticano
11. Entusiasmante per Valentina ➡️ determinazione allo stato puro
12. Fenomenale per Fabio ➡️ il pragmatismo e l’azione in persona
13. Illuminante per Lorenzo ➡️ da cui la ormai famosa matrice di Lorenz
14. Impegnativo per Riccardo B ➡️ uomo quadrato che quadra i conti, di tutti oserei dire
15. Introspettivo per Paolo ➡️ il maestro, il sensei, venuto da Combai
16. Neurostimolante per Soncin ➡️ manager veloce e sempre sul pezzo
17. Pertinente per Giulia ➡️ preparata e consapevole non solo nello stile
18. Prospettiva per Carlo ➡️ DNA da acuto osservatore
19. Rete iperspaziale per Michele ➡️ loquace anticonformista
20. Sicurezza per Ciuffo ➡️ sintesi perfetta di creatività ed ingegneria
21. Stimolante per Sturli ➡️ professionista rigoroso e affidabile
22. Stupefacente per Federico ➡️ il tecnico divenuto Manager
23. Trasformante per Ottavio ➡️ ingegnere tutto d’un pezzo, però ora trasformato
24. Variopinto per Manuel ➡️ il nostro saggio di classe, un sussidiario

Non ci crederete ma 24 professionisti – che mi sono permesso di ricordare - mi hanno consegnato 24 definizioni diverse e bellissime, alle quali dedicherei un applauso. Un bel quadro che consegniamo al CUOA e che può essere usato per sponsorizzare le prossime edizioni dell’EMBA.

Tuttavia queste belle definizioni non sono sufficienti. Perché ognuno ha sintetizzato all’estremo concetti e sentimenti. Perché ognuno è arrivato qui con le proprie aspettative, perché ognuno ha interpretato questo percorso come voleva, trascinato dagli altri, trascinando gli altri, ma anche indipendentemente dagli altri.

Questa è stata una classe tosta, che dopo il primo giorno di presentazioni si è tolta subito di dosso i timori è ha iniziato a testa bassa ciò che si sarebbe dovuto fare. Una classe tosta, mi permetto di affermare, perché questo EMBA è stato tosto, nei contenuti, nelle relazioni, nelle dinamiche, nell’interfacciarsi con la faculty, che ha risposto con prontezza alle sollecitazioni, quando ricevute. C’è stato poco di scontato e tanto di guadagnato.

Che cosa ci portiamo a casa? Possiamo tornare ora a quel ragazzino su quel campetto di periferia, archètipo di una storia che oggi ci appartiene più che mai.

Tutti noi siamo arrivati qui che sapevamo usare il nostro piede destro, anche bene direi: gli ingegneri di produzione sapevano fare gli ingegneri di produzione, i commerciali sapevano vendere, i tecnici sapevano fare i tecnici, i contabili sapevano che investimenti a lungo richiedono fonti a lungo, e così via. Siamo arrivati qui perché ci siamo resi conto che non volevamo più incaponirci solo con il nostro piede destro – questa è la verità - avevamo bisogno di coltivare nuovi talenti, perché solo con nuovi talenti potevamo puntare all’eccellenza. E così oggi chi sapeva gestire reparti di produzione sa anche di contabilità aziendale, chi gestiva una rete di fornitura sa anche comprendere le dinamiche del mercato, chi aveva cura dei clienti comprende anche le esigenze di un conto economico e di uno stabilimento produttivo, chi faceva marketing sa anche come è fatta un’impresa oltre che come sia fatto un sondaggio. Tutti hanno aggiunto talenti, hanno imparato ad usare meglio il loro piede destro, certamente, ma possono ambire a tirare anche con il loro piede sinistro, chissà forse fino ad arrivare un giorno anch’essi sulla cima del mondo.

E allora cari colleghi, se è vero – come ci hanno detto - che l’innovazione è una disobbedienza andata a buon fine, noi disobbedimmo a noi stessi e alla prassi comune il giorno che siamo giunti qui e che abbiamo deciso di volerci impossessare di un po’ di innovazione, di qualche nuovo talento. E’ giusto che ora ci proviamo: chi riuscirà a segnare all’incrocio dei pali, chi colpirà la traversa, chi sfiorerà il goal, l’importante è che si continui ad entrare continuamente in contatto con il nostro piede sinistro, con i nostri nuovi talenti.

Fatemi dire: i nostri figli nel 40% dei casi potrebbero fare un lavoro che oggi nemmeno esiste.

Vediamo se da qualcuno di questi FANTASTICI MANAGER MANCINI nascerà un’innovazione tanto importante.

Lo possiamo fare per noi stessi, per le aziende e i clienti che crederanno in noi, e per le nostre famiglie, le persone che ci sono state vicine in questi quasi 20 mesi di fatiche. Anche loro come noi hanno vissuto momenti alterni, alti e bassi, entusiasmi e tensioni. Facciamogli allora un caloroso applauso…

Grazie al Prof. Vinelli per la professionalità, ad Alessia e allo staff per quanto fatto, ai docenti tutti. Grazie ai miei colleghi ai quali rivolgo un invito: mai perdersi di vista!!!

e grazie a tutti voi per aver ascoltato un manager mancino.

Giacomo Tomezzoli per gli EMBA 14.

As many of you know, Videotec is contributing member of ONVIF, and I attend the Face2Face meetings and contribute to the ONVIF specifications. ONVIF is nowadays the standard protocol for the CCTV market, thus it is the best choice for explaining the issues that may rise with poor time synchronization between a camera and a VMS. These consideration in general apply to proprietary protocols as well, so even if you are not using ONVIF you should not stop reading this article.

How does password-based authentication work in ONVIF?

ONVIF is based on Web Services and the SOAP protocol. In the core specification, two methods are selected for authentication:

• WS-UsernameToken
• HTTP digest

WS-UsernameToken was the first authentication method for the ONVIF protocol. The credential is embedded in the header of the SOAP message used to transport.

HTTP digest was added in a second phase of the protocol development. The main difference from the previous method is that it is based on the HTTP headers, thus it it not handled by the ONVIF protocol, but by the underlying web-server.

The ONVIF Core Specification explains in Section 5.12.1 how to make these two authentication methods live together in an ONVIF device. They key idea is that an ONVIF device can support both methods, and wrong time synchronization impacts differently both of them.

Time synchronization in WS-UsernameToken

Let start by looking at an example of a payload of an authenticated SOAP message:

<wsse:Security>
    <wsse:UsernameToken>
        <wsse:Username>NNK</wsse:Username>
        <wsse:Password Type="...#PasswordDigest">
            weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==
        </wsse:Password>
        <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
        <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
    </wsse:UsernameToken>
</wsse:Security>

As we can see, three elements are sent unencrypted:

• the username
• the nonce
• the timestamp of the creation of the UsernameToken payload.

The password is the output of an hashing function that takes into account not only the plain text password, but also the nonce and the timestamp, with the following formula:

Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )

Since the camera stored internally the value of the password, it can recalculate the Password_Digest and only if it gets the same result as the one sent by the client it can authorize the required action.

Why does it hashes also the nonce and the timestamp? They are both needed to avoid replay attacks. If only the password is hashed, in practice there is no difference from using plain text password to access the service, as it happens in the HTTP basic authentication schema. In fact, if an attacker is able to get access to just one message, he could use the same password hash again and again to send malicious commands to the camera.

By adding a nonce and a time stamp, this risk is eliminated:

• nonces shall not be accepted by the camera more than once. To implement this, cameras usually have a buffer of used nonces, and every time they have a new request they check if the supplied nonce has already been used.
• since cameras are embedded systems with limited RAM and storage, they cannot store all the previously used nonces. The buffer is usually sized so that the camera can hold all the nonce of an interval. Once a nonce is older that a set number of seconds, it is considered expired and removed from the list of used nonces. An attacker could at this point replay the nonce to attack the camera. By checking also the created timestamp the replay attack will fail, because repeating the nonce will generate a different hash value.

As a final security measure, cameras verify that the created timestamp is synchronized with the internal clock with a certain clock skew tolerance. As an example, the default clock skew tolerance in gSoap is 300s. Any message generated with a difference of time bigger than the values is discarded because it could be either a replay attack or something trying to crack the camera’s firmware.

Trivia: how can an ONVIF tool configure a Profile-S camera that is just out from the box which implements only WS-UsernameToken as authentication method?

The correct handshake procedure is:

1. the client invokes GetSystemDateAndTime to get the camera clock value;
2. the client checks its internal clock;
3. the client determines the time difference between the two values;
4. the client sends a SetSystemDateAndTime to synchronize the clock of the camera with the clock of the system;
5. the client configures all other parameters.

On the market there are VMSs that implement this handshake procedure when adding cameras into the system.

Time synchronization in HTTP digest

Unlike WS-UsernameToken, the HTTP digest authentication method does not explicitly include information about time in its definition. Still, in the RFC7616 the possibility of including the timestamp is suggested as an option to increase security.

Before entering the details for adding timestamp to the HTTP digest, it is necessary to explain how is works.

Let’s suppose that the client is requesting /dir/index.html page on a web-server

GET /dir/index.html HTTP/1.0
Host: localhost

If the access to the page is restricted, the web-server will send back the following answer

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>

The key part of the response is the WWW-Authenticate header. This header specifies a realm, which is the description of the restricted area that the user is trying to access, the quality of protection qop, which specifies that authentication can be either be used to perform authentication (auth) or to to perform authentication and verification of message integrity (auth-int), the specifies a number that can be used only once every time a WWW-Authenticate header is generated called nonce and an opaque value, which is a string of that that should not be modified by the client.

At this point the client repeats the request, by adding the Authorization header:

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

As it can be easily seen, realm, nonce and opaque are sent back to the server without any modification, while the client chooses the auth method as quality of protection (which means only authentication)

Finally the web-server accepts the requests and gives a positive response:

HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

So far, so good, because time is not involved in the basic mechanism of the Digest authentication. However, this way of performing authentication is exposed to reply attacks. In fact, a client could re-transmit the same command to the camera with the unaltered Authorization field and the camera could not discriminate if the sender is good or malicious. For this reason, RFC2617 states

The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. A nonce might, for example, be constructed as the base 64 encoding of

time-stamp H(time-stamp ":" ETag ":" private-key)

where time-stamp is a server-generated time or other non-repeating value, ETag is the value of the HTTP ETag header associated with the requested entity, and private-key is data known only to the server. With a nonce of this form a server would recalculate the hash portion after receiving the client authentication header and reject the request if it did not match the nonce from that header or if the time-stamp value is not recent enough. In this way the server can limit the time of the nonce’s validity.

For this reason, devices that implement this strategy to prevent replay attacks must have a reliable source of time. Time must be monotone even after a reboot, to have this kind of protection working.

What about encryption?

Since password-based authentication schemes are in general weak, the ONVIF protocol offers a way to totally bypass passwords in the Advanced Security specifications.

In this schema, authentication and authorization are performed over x.509 certificates. However, certificates have a validity range, expressed in terms of Not Before and Not After. Thus, preventing the usage of expired certificates still requires time synchronization, to make sure certificates are accepted in the desired time interval.

What’s the best timezone?

Many users require burning date and time into the video at compression time, so that they can easily recognize when the video was recorded. In order to get a better user experience, users required to have time expressed in their time zone.

This choice, unfortunately, may introduce drawbacks, because in may time zones time is not monotone. In fact, daylight savings introduces two discontinuities a year. In one part of the year local clocks will be advanced by one hour, leaving a hole of 60 minutes. In the other discontinuity, the same hour will exist twice, exposing the system to replay attacks.

Daylight saving is the most immediate use case scenario to understand that holes in time may exist, but it is not the only one. Let’s think about cargo ships: their journey is likely to span over different time zones.

How to configure an authoritative time server in Windows Server

Windows offers an NTP server that can be used to synchronize the IP cameras. Unfortunately, in CCTV many systems are air-gapped, either because of security policies or simply because they are physically located in places where a connection to the Internet is not available.

If the Windows server is not able to synchronize with one or more server of a higher stratum, it will announce itself as a not authoritative NTP server. As a result, devices may refuse to synchronize with the server, preventing the CCTV from working.

Microsoft provides instructions about how to configure an isolated NTP server:

1. Select Start > Run, type regedit, and then select OK.
2. Locate and then select the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
3. In the right-pane, right-click AnnounceFlags, and then select Modify.
4. In Edit DWORD Value, type A in the Value data box, and then select OK.
5. Close Registry Editor.
6. At the command prompt, type the following command to restart the Windows Time service, and then press Enter: net stop w32time && net start w32time

Per iniziare è necessario scaricare Etcher, il programma consigliato da Armbian per flashare le schede microSD. Il passo successivo consiste nello scaricare da Armbian l’immagine del sistema operativo desiderato. Ad oggi Armbian offre per la scheda in questione due immagini per server, una basata su Debian ed una basata su Ubuntu.

Al primo login ai accede con root/1234 ed il sistema chiede di cambiare la password. L’IP è in DHCP.

Essendo una Debian, la prima cosa che vien voglia di fare è smanettare con apt-get, ma per avere un sistema debina funzionante è necessario lanciare il comando update-command-not-found per generare i file do configurazione di apt. Successivamente, come da ordinaria amministrazione, è necssario lanciare apt-get update aggiornare l’elenco dei pacchetti.

Il punto però che mi ha stupito di più è stato il fatto che in questa scheda è possibile installare sia pacchetti con archiettura arm64 che con architettura armhf. GNU/Debian supporta il multiarch, è abbastanza comune la presenza di librerie x86 su sistemi amd64, ma è la prima volta che mi sono imbattuto nel multiarch su piattaforma ARM.

Dopo aver fatto diverse prove ho scoperto OpenProject, che è meno stiloso di Jira ma è comunque molto completo. L’ho installato su un server baremetal di Scaleway, riuscendo ad avere una piattaforma che posso condividere con i miei compagni di eMBA al prezzo di 3€/mese.

Le istruzioni online per installare OpenProject sono un po’ sgangherate, quindi ho deciso di riassumere qui tutti i passaggi, nel caso in cui altre persone fossero interessate.

Una premessa: OpenProject è un programma opensource, che viene distribuito in pacchetti per chi lo vuole eseguire su un proprio server, altrimenti viene venduto as a service. I pacchetti per Debian sono disponibili ad oggi fino a Jessie, mentre per Stretch il software non è disponibile come già pacchettizzato e non è nemmeno agevole installarlo a mano, perché MySQL è diventato MariaDB e ci sono alcuni problemi con le versioni più aggiornate di Ruby. Ecco perché sul server di scaleway ho installato Debian Jessie e non Stretch. Per fortuna Debian fornisce gli aggiornamenti di sicurezza per oldstable, quindi non è un problema non avere l’ultima versione.

Iniziamo con l’importare la firma digitale del repository dei pacchetti di OpenProject per Debian Jessie:

root@debian:~# wget -qO- https://dl.packager.io/srv/opf/openproject-ce/key | apt-key add -

Per proseguire è necessario installare apt-transport-https, perché packager.io, il sito mediante il quale vengono distribuiti i pacchetti, fornisce il software solo mediante https e non http.

root@debian:~# apt-get install apt-transport-https

A questo punto è necessario aggiungere i repository per Let’s encrypt ed OpenProject:

root@debian:~#  echo 'deb http://ftp.debian.org/debian jessie-backports main' | \
    tee /etc/apt/sources.list.d/backports.list

root@debian:~# wget -O /etc/apt/sources.list.d/openproject-ce.list \
    https://dl.packager.io/srv/opf/openproject-ce/stable/7/installer/debian/8.repo

Installiamo certbot per la generazione dei certificati

root@debian:~# apt-get update
root@debian:~# apt-get install python-certbot-apache -t jessie-backports
root@debian:~# certbot --apache -d nome.sito.it

A questo punto, se la procedura è andata a buon fine, dopo aver risposto ad alcune semplici domande, dovreste vedere questi file:

root@debian:~# ls /etc/letsencrypt/archive/nome.sito.it/
cert1.pem  chain1.pem  fullchain1.pem  privkey1.pem
root@debian:~#

I certificati di Let’s Encrypt hanno una durata limitata di 90 giorni e devono essere rinnovati. I motivi di questa scelta sono spiegati qui e di fatto viene fatto perché si vuole fare in modo che se un certificato viene compromesso l’impatto sia limitato. Per non dover aggiornare a mano i certificati basta mettere una entry nella crontab:

root@debian:~# crontab -e
# m h  dom mon dow   command
* 7,19 * * * certbot -q renew

e dimenticarsi del rinnovo dei certificati. Vale la pena notare che ad ogni rinnovo verranno generati dei vecchi certificati, con numero progressivo incrementato di uno. Quindi al primo rinnovo nella directory /etc/letsencrypt/archive/nome.sito.it/ troveremo questi file

root@debian:~# ls /etc/letsencrypt/archive/nome.sito.it/
cert1.pem  chain1.pem  fullchain1.pem  privkey1.pem
cert2.pem  chain2.pem  fullchain2.pem  privkey2.pem
root@debian:~#

Per evitare problemi al rinnovo, nei passaggi successivi verrà usata la directory /etc/letsencrypt/live/nome.sito.it/, che contiene link simbolici sempre aggiornati all’ultimo certificato generato.

Fatto questo è il momento di installare OpenProject:

root@debian:~# apt-get install openproject

Questo comando provvederà ad installare tutte le dipendenze. Per la creazione del sito bisogna lanciare il seguente comando e prepararsi a rispondere ad una serie di domande:

root@debian:~# openproject configure

Il programma di configurazione è molto ricco, io di solito scelgo di:

• installare mysql
• installare apache2, che chiede il fully qualified domain name (FQDN) del sito, in questo caso nome.sito.it , non specifico nessun server path prefix perché ho un server ad hoc per usare OpenProject ed abilito ssl
• come file del certificato ssl imposto /etc/letsencrypt/live/nome.sito.it/cert.pem
• come chiave del certificato imposto /etc/letsencrypt/live/nome.sito.it/privkey.pem come chiave ,
• non aggiungo alcuni CA bundle, perché in Debian c’è già il file /etc/ssl/certs/ISRG_Root_X1.pem , che è il certificato di Internet Security Research Group, ovvero la fondazione a capo di Let’s Encrypt
• installare svn
• installare git
• installare sendmail
• installare memcached

A questo punto potrebbe essere rimasto attivo un disto di default di apache2, quindi per sicurezza basta lanciare questi due comandi

root@debian:~# a2dissite 000-default-le-ssl.conf
root@debian:~# /etc/init.d/apache2 restart

A questo punto, per iniziare ad usare il programma, basta aprire un browser e visitare il sito https://nome.sito.it . Il primo accesso avverrà come admin/admin, ma verrà immediatamente richiesto di impostare un’altra password.

Controlliamo di non aver lasciato schifezze in giro

Il sito funziona, ma verifichiamo di non aver dimenticato in giro programmi indesiderati

root@debian:~# apt-get install nmap

Cosa possiamo esserci dimenticati?

root@debian:~# namp <ip pubblico>
Starting Nmap 6.47 ( http://nmap.org ) at 2017-09-27 14:36 CEST
Nmap scan report for aa.bb.cc.dd
Host is up (0.000011s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
80/tcp  open  http
111/tcp open  rpcbind
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 2.57 seconds
root@debian:~# 

La porta 22 aperta va bene, è per ssh, altrimenti come facciamo manutenzione?

La porta 25 aperta è di postfix, e non va assolutamente bene. È vero che nel file /etc/postfix/main.cf c’è la riga:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

che non permette di ricevere email se non dall’interfaccia di loopback, tuttavia esistono delle RBL che mettono in lista nera i server che hanno la porta 25 aperta. Per ovviare questo è necessario pubblicare dei recordi SPF e DKIM nella zona del proprio dominio. La cosa più semplice per uso hobbistico invece è modificare /etc/postfix/main.cf sostituendo la riga

inet_interfaces = all

con

inet_interfaces = loopback-only

e riavviare postfix. L’ultima porta da sistemare è la 111, occupata dal processo rcpbind. Questo è dovuto al fatto che Debian installa portmap di default, e per rimuoverlo basta dare il seguente comando:

root@debian:~# dpkg --purge rpcbind nfs-common

Aggiornamento

È stata rilasciata la versione 7.3.0 di OpenProject. La procedura di aggiornamento è semplice, ma richede un minimo di attenzione. Servono i seguenti comandi:

root@debian:~# apt-get update
root@debian:~# apt-get install --only-upgrade openproject
root@debian:~# openproject configure

In questo modo viene scompattato il pacchetto nuovo, ma per aggiornare il software viene usato il comando openproject configure che provvedere ad applicare tutte le migrazioni del database, se necessario.

Nella versione 7.3.0 di fine Settembre 2017 è stata introdotta la possibilità di citare gli utenti con @nome come nella suite Atlassian. Per fine Novembre 2017 è prevista la versione 7.4 che avrà altre evoluzioni minori, mentre per Marzo 2018 è previsto il rilascio di OpenProject 8.0 con un editor WYSIWYG per il wiki.

Per chi fosse interessato è possibile fare riferimento alla roadmap ed alla development timeline del progetto.

Per questo motivo ho cercato se è possibile eseguire una shell dentro vim, e mi sono imbatutto in ConqueTerm che sembra fare proprio quello che voglio. Basta scaricare il file conqueterm_2.2.vmb ed installarlo con Vim

:open conqueterm_2.2.vmb
:so %

I file .vmb sono file Vimball, ovvero dei file con i plugin per vim e gli script per automatizzarne l’installazione. Quindi basta aprirli ed eseguirli, come mostrato nel blocco precedente.

A questo punto riavviamo vim e proviamo il comando :ConqueTermVSplit bash. Voilla:

Questa estate Microsoft ha rilasciato il .Net Core 2.0. Il linguaggio mi ha sempre incuriosito, però non mi sono mai trovato bene con Mono, il compilatore opensource per C# perché non supporta tutte le librerie di sistema di .Net. Con la nuova release di .Net e l’annuncio in grande stile del supporto della piattaforma Linux ho deciso di fare una prova.

Si inizia con l’installazione di un po’ di pacchetti di supporto:

root@debian:~# apt-get update
root@debian:~# apt-get install curl libunwind8 gettext apt-transport-https

Successivamente è necessario aggiungere la chiave con cui Microsoft firma i propri pacchetti:

root@debian:~# curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > /etc/apt/trusted.gpg.d/microsoft.gpg

Successivamente è necessario aggiunere l’archivio dei pacchetti per Debian Stretch:

root@debian:~# echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-debian-stretch-prod stretch main" > /etc/apt/sources.list.d/dotnetdev.list

A questo punto è possibile procedere con l’installazione dell’SDK .Net:

root@debian:~# apt-get update
root@debian:~# apt-get install dotnet-sdk-2.0.0

Facciamo un hello world

A questo punto, per verificare che tutto funzioni, creiamo una applicazione i nconsole che saluti il mondo:

user@debian:~$ dotnet new console -o hello
user@debian:~$ cd hello

Come si può vedere il comando crea una seriel di file, tra cui Program.cs :

using System;

namespace hello
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Per compilare ed eseguire il programma basta lanciare il seguente comando:

user@debian:~/hello$ dotnet run
Hello world!
user@debian:~/hello$ 

Se si vuole solo eseguire il programma senza compilarlo è possibile usare il seguente comando:

user@debian:~/hello$ dotnet exec bin/Debug/netcoreapp2.0/hello.dll
Hello world!
user@debian:~/hello$ 

E per i webservice?

Purtroppo nonostate il core di .Net sia stato portato su Linux, il framework .Net è ancora disponibile solo su Windows. Come riportato qua, esiste il pacchetto WCF connected service che permette di realizzare client di web service usando solo il core .Net . Purtroppo il generatore delle classi per accedere ai servizi funziona solo sotto windows, ma poi il codice è compilabile anche da Linux. Il vero problema è che WCF connected service supporta solo un sottoinsieme del suo equivalente sotto windows, ed è carente per tutte le estensioni WS-*, il che vuol dire mancanza di supporto a meccanismi di autenticazione, WD-Addressing, e meccanismi di trasporto.

Peccato, speravo meglio. Senza libreria grafica e funzioni di rete standard, C# su Linux rimane secondo me ancora un giocattolo.

U-boot è stato configurato con il file uEnv.txt il cui contenuto può risultare abbastanza criptico per i non addetti ai lavori. Per capirne il significato è meglio partire dalla shell di u-boot.

All’avvio della scheda, u-boot scrive il seguente output sulla seriale:

U-Boot SPL 2017.05-jumpnow (Jun 22 2017 - 19:16:50)
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2017.05-jumpnow (Jun 22 2017 - 19:16:50 +0200)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

<ethaddr> not set. Validating first E-fuse MAC
Net:   cpsw
Press SPACE to abort autoboot in 2 seconds

Se durante i due secondi viene premuta la barra spaziatrice il processo di boot si interrompe e u-boot propone la sua shell interattiva:

=> 

U-boot ha una serie di parametri predefiniti, nel caso della beaglebone black questi parametri sono un numero molto elevato. Per vederli è necessario lanciare il comando printenv:

=> printenv
arch=arm
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
baudrate=115200
board=am335x
board_name=A335BNLT
board_rev=00C0
board_serial=2716BBBK2133
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_fdt=try
boot_fit=0
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 legacy_mmc0 mmc1 legacy_mmc1 nand0 pxe dhcp
bootcmd=run envboot; setenv mmcdev 1; run envboot; setenv mmcdev 0; run findfdt; run distro_bootcmd
bootcmd_dhcp=if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_legacy_mmc0=setenv mmcdev 0; setenv bootpart 0:2 ; run mmcboot
bootcmd_legacy_mmc1=setenv mmcdev 1; setenv bootpart 1:2 ; run mmcboot
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_nand=run nandboot
bootcmd_pxe=dhcp; if pxe get; then pxe boot; fi
bootcount=2
bootdelay=2
bootdir=/boot
bootenvfile=uEnv.txt
bootfile=zImage
bootm_size=0x10000000
bootpart=0:2
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
console=ttyO0,115200n8
cpu=armv7
dfu_alt_info_emmc=rawemmc raw 0 3751936
dfu_alt_info_mmc=boot part 0 1;rootfs part 0 2;MLO fat 0 1;MLO.raw raw 0x100 0x100;u-boot.img.raw raw 0x300 0x400;spl-os-args.raw raw 0x80 0x80;spl-os-image.raw raw 0x900 0x2000;spl-os-args fat 0 1;spl-os-image fat 0 1;u-boot.img fat 0 1;uEnv.txt fat 0 1
dfu_alt_info_ram=kernel ram 0x80200000 0x4000000;fdt ram 0x80f80000 0x80000;ramdisk ram 0x81000000 0x4000000
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadbootenv; then echo Loaded env from ${bootenvfile};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;
eth1addr=04:a3:16:b1:10:d7
ethact=cpsw
ethaddr=04:a3:16:b1:10:d5
fdt_addr_r=0x88000000
fdtaddr=0x88000000
fdtfile=undefined
findfdt=if test $board_name = A335BONE; then setenv fdtfile am335x-bone.dtb; fi; if test $board_name = A335BNLT; then setenv fdtfile am335x-boneblack.dtb; fi; if test $board_name = BBBW; then setenv fdtfile am335x-boneblack-wireless.dtb; fi; if test $board_name = BBG1; then setenv fdtfile am335x-bonegreen.dtb; fi; if test $board_name = BBGW; then setenv fdtfile am335x-bonegreen-wireless.dtb; fi; if test $board_name = BBBL; then setenv fdtfile am335x-boneblue.dtb; fi; if test $board_name = A33515BB; then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; then setenv fdtfile am335x-evmsk.dtb; fi; if test $board_name = A335_ICE; then setenv fdtfile am335x-icev2.dtb; fi; if test $fdtfile = undefined; then echo WARNING: Could not determine device tree to use; fi;
finduuid=part uuid mmc ${bootpart} uuid
fit_bootfile=fitImage
fit_loadaddr=0x88000000
importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t ${loadaddr} ${filesize}
init_console=if test $board_name = A335_ICE; then setenv console ttyO3,115200n8;else setenv console ttyO0,115200n8;fi;
kernel_addr_r=0x82000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x82000000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadfit=run args_mmc; bootm ${loadaddr}#${fdtfile};
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
mmcboot=mmc dev ${mmcdev}; setenv devnum ${mmcdev}; setenv devtype mmc; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadimage; then if test ${boot_fit} -eq 1; then run loadfit; else run mmcloados;fi;fi;fi;
mmcdev=0
mmcloados=run args_mmc; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdtaddr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcrootfstype=ext4 rootwait
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=dhcp
netboot=echo Booting from network ...; setenv autoload no; dhcp; run netloadimage; run netloadfdt; run netargs; bootz ${loadaddr} - ${fdtaddr}
netloadfdt=tftp ${fdtaddr} ${fdtfile}
netloadimage=tftp ${loadaddr} ${bootfile}
nfsopts=nolock
partitions=uuid_disk=${uuid_gpt_disk};name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
pxefile_addr_r=0x80100000
ramargs=setenv bootargs console=${console} ${optargs} root=${ramroot} rootfstype=${ramrootfstype}
ramboot=echo Booting from ramdisk ...; run ramargs; bootz ${loadaddr} ${rdaddr} ${fdtaddr}
ramdisk_addr_r=0x88080000
ramroot=/dev/ram0 rw
ramrootfstype=ext2
rdaddr=0x88080000
rootpath=/export/rootfs
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x80000000
soc=am33xx
spiargs=setenv bootargs console=${console} ${optargs} root=${spiroot} rootfstype=${spirootfstype}
spiboot=echo Booting from spi ...; run spiargs; sf probe ${spibusno}:0; sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; bootz ${loadaddr}
spibusno=0
spiimgsize=0x362000
spiroot=/dev/mtdblock4 rw
spirootfstype=jffs2
spisrcaddr=0xe0000
static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
stderr=ns16550_serial
stdin=ns16550_serial
stdout=ns16550_serial
update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}
vendor=ti
ver=U-Boot 2017.05-jumpnow (Jun 22 2017 - 19:16:50 +0200)

Environment size: 8250/131068 bytes
=>

Di tutti questi parametri ce ne sono alcuni che sono necessari per effettuare il boot del sistema compilato in precedenza, altri che servono per effettuare il boot di sistemi linux da altri dispositivi. In particolar modo i parametri più importanti sono:

• bootdelay=2 è il numero di secondi che il bootloader attende prima di lanciare il comando di boot del sistema linux. Può essere utile aumentare il valore di questa variabile per dare un po’ più di tempo all’operatore per interrompere il boot del sistema. Nel caso di prodotti finiti invece non è raro trovare sistemi configurati con bootdelay=0, che impedisce di lanciare una shell interattiva e fa subito lanciare il boot di sistema. Questo assieme ad altri accorgimenti viene usato per ridurre il tempo di boot.
• bootpart=0:2 indica la partizione da cui effettuare il boot. E’ della sintassi x:y, dove x indica il numero della microSD ed y è il numero della partizione. x vale 0 per indicare la microSD da cui è stato avviato u-boot, quindi nel caso in cui venga fatto il boot da microSD il valore 0 indica la microSD ed il valore 1 la eMMC, mentre se si avvia il sistema preinstallato nella memoria eMMC, ad x=0 corrisponde la eMMC e a x=1 corrisponde la microSD. Il valore di y indica invece l’indice della partizione dove cercare il kernel, che nel nostro caso è stato messo nella prima partizione VFAT, assieme ad MLO e u-boot.
• bootdir=/boot indica se il kernel deve essere cercato in una subdirectory o nella radice del filesystem. Nei sistemi GNU/Linux desktop tradizionalmente kernel e di file necessari all’avvio sono salvati nella cartella /boot, mentre nei sistemi embedded può essere vero o meno. Spesso la scelta di dove mettere kernel e bootloader è più dettata dalle strategie di firmware upgrade che motivi estetici.
• console=ttyO0,115200n8 è uno dei parametri fondamentali: informa il kernel di redirigere il suo output della seriale. Solo in questo modo è possibile vedere come si comporta al boot e determinare quali sono i problemi che fanno fallire il boot del sistema. Per non sbagliare lo passo sempre, perché passarlo non costa nulla e non si sa mai come sia configurato un sistema. Non è questa variabile ad essere la diretta responsabile della redirezione dell’output del kernel sulla seriale, ma viene usata per formare i bootargs, ovvero la linea di comando che viene passata al kernel.
• fdtaddr=0x88000000 specifica a quale indirizzo caricare in memoria il Flattened Device Tree (FDT), ovvero il file che indica come mappare tutte le periferiche del System-on-Chip.
• fdtfile=undefined specifica il nome di quale FDT utilizzare.
• loadaddr=0x82000000 specifica invece a quale indirizzo di memoria caricare il kernel.
• mmcroot=/dev/mmcblk0p2 ro questa variabile viene usata per assemblare i bootargs, per indicare al kernel di linux dove troverà il rootfs.
• mmcrootfstype=ext2 rootwait anche questa varaibile viene usate per assemblare i bootargs, nello specifico per dire al kernel di linux che tipo di filesystem deve aspettarsi per il rootfs.
• optargs=consoleblank=0 è una variabile che, sempre usata per assemblare i bootargs, dice al kernel di non mettere in risparmio energetico un eventuale monitor collegato alla porta HDMI della scheda.
• nohdmi=bbb-nohdmi.dtb indica il file contenente il Device Tree Database
• loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile} è il comando con cui u-boot carica il kernel.

Quando u-boot leggere il file uEnv.txt legge tutti i parametri impostati dall’utente e sovrascrive i valori di default. Nello specifico, vediamo cosa cambia con le variabili passate mediante il file uEnv.txt . Per semplificare la cosa le righe sono state riordinate

bootpart=0:1
bootdir=
bootfile=zImage
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}

Queste prime righe dicono di selezionare la prima partizione della scheda microSD e di caricare il file zImage direttamente dalla radice del filesystem.

console=ttyO0,115200n8
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext2 rootwait
optargs=consoleblank=0
mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}

Di queste righe, le prime quattro vengono usate per specificare dei parametri usati per assemblare i bootargs. L’ultima riga definisce il comando mmcargs, che quando viene eseguito popola la variabile d’ambiente d’ambiente bootargs con tutti i parametri da passare al kernel.

fdtaddr=0x88000000
fdtfile=zImage-bbb-nohdmi.dtb
loadaddr=0x82000000
nohdmi=bbb-nohdmi.dtb
findfdtfile=if test -e mmc ${bootpart} ${bootdir}/nohdmi; then setenv fdtfile ${nohdmi}; fi;
loadfdt=run findfdtfile; load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}

Queste variabili ridefiniscono alcuni parametri necessari al caricamento del Device Tree Database da usare con la scheda

uenvcmd=if run loadfdt; then echo Loaded ${fdtfile}; if run loadimage; then run mmcargs; bootz ${loadaddr} - ${fdtaddr}; fi; fi;

Questa ultima riga definisce il comando predefinito che u-boot esegue quando spira il timeout bootdelay. Nello specifico, il comando esegue i seguenti passi:

1. Carica il device tree database
2. Carica il kernel
3. Esegue mmcargs per impostare i bootargs
4. Lancia il kernel

Trivia

Dopo aver letto questa pagina dovrebbe essere chiaro che i bootargs giocano un ruolo fondamentale nel boot, perché cambiano non poco il comportamento del kernel. Talvolta per debug serve capire con quali bootargs il sistema sia partito avendo solo a disposizione solo lo GNU/Linux già funzionante.

Come si può vedere con quali bootargs è partito?

La risposta è leggendo /proc/cmdline:

root@beaglebone:~# cat /proc/cmdline
console=ttyO0,115200n8 consoleblank=0 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait
root@beaglebone:~#

• MLO
• u-boot.img
• zImage
• zImage-bbb-nohdmi.dtb
• core-image-minimal-beaglebone.tar.xz

Il processore della Beaglebone Black, un Texas Instruments Sitara AM3358 è un processore molto ricco e offre diverse modalità di boot. Il suo boot può essere suddiviso nelle seguenti fasi:

1. il processore esegue un microcodice fuso all’interno del System-on-Chip (SoC) detto ROM Code o bootloader di primo livello, per cercare i dispositivi di boot
2. il ROM code carica il bootloader di secondo livello o x-loader, chiamato anche x-loader, SPL o MLO (si veda sotto perché ha così tanti nomi).
3. MLO effettua una minima configurazione del sistema e carica u-boot
4. u-boot inizializza altre periferiche, carica il kernel, predispone i suoi parametri di boot ed avvia il kernel
5. il kernel completa l’inizializzazione dell’hardware, monta il rootfs e dà vita a init che porta a termine l’inizializzazione del sistema

ROM code

Questo piccolo programma è fuso all’interno del chip, non è modificabile, e viene eseguito automaticamente all’accensione del sistema.

Il ROM code ha due funzioni principali:

1. Configurare ed inizializzare correttamente le periferiche primarie:
   • inizializzare lo stack
   • configurare il watchdog ad un intervallo di tre minuti
   • configurare i PLL ed i clock di sistema
2. Preparare il dispositivo per il bootloader di secondo livello:
   • verificare i dispositivi da cui caricare il bootloder successivo
   • copiare in RAM il codice del bootloader da eseguire

La lista dei dispositivi da utilizzare nella ricerca del bootloader di secondo livello è configurata mediante dei pin di strap-in, indicati nella documentazione tecnica del Sitara come SYSBOOT[15:0].

Nel caso della beaglebone, il funzionamento di questi pin è illustrato nella pagina 6 degli schematici.

Come si può vedere a pagina 8 degli schematici per la eMMC e a pagina 11 per la microSD, la eMMC è connessa ad MMC1 e la microSD è connessa a MMC0. Sempre a pagina 6 si può vedere come è connesso il bottone uSD BOOT. Quando viene premuto porta il bit SYSBOOT[2] a 0 e quindi viene eseguita la seconda sequenza di boot, che va a ricercare il bootloader di secondo livello nella MMC0, mentre se non viene premuto il bit SYSBOOT[2] varrà 1 e quindi verrà eseguita la prima sequenza di boot, ch darà priorità al boot ad eMMC rispetto a quello da microSD. Le beaglebone sono tutte in vendita con un sistema linux embedded già programmato nella eMMC, quindi a meno di non cancellare la eMMC, se il bottone uSD BOOT non viene premuto il sistema partirà sempre da eMMC. In questo caso, volendo avviare un sistema custom da microSD, sarà sempre necessario accendere la beaglebone black tenendo premuto il bottone di boot da microSD.

Il bottone uSD BOOT è il boot button in questa immagine.

Nel caso di boot da microSD, il ROM code cerca la prima partizione formattata in FAT32 e carica il file MLO contenuto in essa. Il file MLO contiene il bootloader di secondo livello ed alcuni byte di intestazione che istruiscono il ROM code sulla dimensione del file e l’indirizzo di memoria dove questo programma deve essere caricato.

x-loader, il bootloader di secondo livello detto anche Secondary Program Loader (SPL)

Per spiegare cosa è x-loader è necesario un piccolo preambolo:

Fino a qualche anno fa la compilazione di u-boot aveva come output un singolo file, u-boot.bin o u-boot.img che doveva essere caricato nelle schede come primo bootloader. L’immagine di u-boot è “grande”, che nel mondo embedded vuol dire che è oltre 200KB. Questo può essere un problema, perché al momento del caricamento del bootloader in RAM non è detto che la DDR sia inizializzata e funzionante. I processori di Texas Instruments, anche prima del Sitara, avevano della RAM statica (SRAM) al loro interno, che al boot viene usata per l’inizializzazione del SoC. Per questo motivo, quando Texas Instruments ha iniziato a produrre i SoC della linea OMAP ha preso una parte dei sorgenti di u-boot per realizzare x-loader, una versione minimale di u-boot, il cui scopo è inizializzare la DDR e caricare uno u-boot completo. L’idea di avere un bootloader che usasse la RAM statica interna dei SoC per inizializzare la DDR è stata successivamente ripresa anche da altri produttori, per cui i sorgenti di x-loader e di altri bootloader minimali sono stati unificati con u-boot e per avere un unico bootloader ed evitare una proliferazione di minibootloader realizzati di diversi produttori di SoC.

I compiti di questo bootloader sono:

1. inizializzare il pin muxing del SoC
2. inizializzare i clock e la memoria DDR
3. caricare lo u-boot vero e proprio in memoria ed eseguirlo

I processori Sitara sono molto ricchi di periferiche e sebbene abbiano un migliaio di pin non sono in grado di esportare tutte le periferiche sulla loro footprint. Per questo motivo ed anche perché alcune periferiche possono essere connesse a piedini diversi in base alle necessità di sbroglio, è necessario configurare correttamente il multiplexing delle interfacce. Questo viene realizzato configurando opportunamente dei registri chiamati PINMUX, ed una prima configurazione deve essere fatta dal bootloader, per poter eseguire correttamente u-boot.

Dopo aver inizializzato la RAM DDR, il bootloader di secondo livello cerca il file u-boot.img nella stessa partizione da cui è stato caricato. Una volta che lo ha caricato il bootloader di secondo livello termina facendo un salto senza ritorno all’entry point di u-boot.

U-boot

A questo punto tutta la procedura di boot a basso livello è stata completata e si arriva alla shell di u-boot, abbastanza familiare per chi lavora con i sistemi embedded.

Lo scopo di u-boot è:

1. configurare le periferiche per caricare il kernel
2. caricare il Device Tree Blob (DTB) file in memoria per istruire il kernel su come configurare le periferiche
3. caricare il kernel in memoria
4. configurare i bootargs, variabili d’ambiente con cui si configurano alcune opzioni del kernel
5. terminare la propria esecuzione, saltando senza ritorno all’entry point del kernel in RAM

Ultima parte del processo di boot

Una volta avvia il kernel effettua l’inizializzazione del sistema:

1. decompressione e riposizionamento del kernel in RAM
2. inizializzazione delle periferiche rimanenti
3. inizializzazione di tutte le strutture dati necessarie al sistema operativo
4. inizializzazione degli stack di rete
5. fork() ed esecuzione del processo di init

All’esecuzione di fork() viene creato il processo con PID 1. Questo è il primo, ed in partenza unico, processo in userspace. Questo processo viene eseguito come root e deve inizializzare tutto lo userland, far partire processi di getty sui pseudoterminali o sulle seriali, montare i filesystem e gestire la rete. Se per qualche motivo questo processo termina il sistema crasha, di solito con questo messaggio:

Kernel panic - not syncing: Attempted to kill init!

Dopo la teoria, la pratica

Per prima cosa è necesario partizionare la scheda microSD. La configurazione minima richiede due partizioni:

• una partizione FAT32 dove mettere almeno MLO, u-boot.img ed uEnv.txt
• una partizione EXT2 dove estrarre l’immagine compilata precedentemente

Nel mio computer la microSD viene mappata su /dev/sdd, nel vostro potrebbe essere un altro device file, in base ai dispositivi connessi al vostro PC.

Il partizionamento seguito per questo esempio è il seguente e va bene per delle prime prove, ma come vedremo in futuro è troppo limitato se dobbiamo gestire anche il software upgrade.

root@debian:~# fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 15.9 GB, 15931539456 bytes
255 heads, 63 sectors/track, 1936 cylinders, total 31116288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *          63      257039      128488+   c  W95 FAT32 (LBA)
/dev/sdd2          257040    31116287    15429624   83  Linux

Command (m for help):

Quando formattiamo la prima partizione della microSD è meglio assicurarsi di usare come dimensione 16 per le File Allocation Table (FAT), mentre per la seconda possiamo usare inizialmente un filesystem ext2 standard:

root@debian:~# mkfs.vfat -F 16 -n "boot" /dev/sdd1
root@debian:~# mkfs.ext2 /dev/sdd2

A questo punto copiamo all’interno della partizione FAT i seguenti file:

• MLO
• u-boot.img
• zImage
• zImage-bbb-nohdmi.dtb

Sempre all’interno di questa partizione creiamo il file uEnv.txt con il seguente contenuto:

bootpart=0:1
bootdir=
bootfile=zImage
console=ttyO0,115200n8
fdtaddr=0x88000000
fdtfile=zImage-bbb-nohdmi.dtb
loadaddr=0x82000000
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext2 rootwait
optargs=consoleblank=0
nohdmi=bbb-nohdmi.dtb
mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}
findfdtfile=if test -e mmc ${bootpart} ${bootdir}/nohdmi; then setenv fdtfile ${nohdmi}; fi;
loadfdt=run findfdtfile; load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
uenvcmd=if run loadfdt; then echo Loaded ${fdtfile}; if run loadimage; then run mmcargs; bootz ${loadaddr} - ${fdtaddr}; fi; fi;

Il file uEnv.txt contiene la configurazione di u-boot. Se non è presente u-boot userà i parametri hard coded che gli sono stati passati durante la compilazione. La spiegazione dettagliata dei parametri presenti in questo file verrà esposta in un prossimo post. ATTENZIONE: onde evitare problemi vari di compatibilità con alcune versioni di uboot, il file uEnv.txt deve essere salvato in formato Unix e deve avere come ultima riga una riga vuota.

La preparazione della partizione ext2 è molto più semplice, perché basta copiare il file core-image-minimal-beaglebone.tar.xz dentro alla partizione montata, posizionarsi nella directory dove è il file e lanciare il comando tar xJfv core-image-minimal-beaglebone.tar.xz . Notate come file è compresso con xz e non con i classici gzip o bzip2, quindi il flag per decomprimere questo tipo di archivio è J.

Per debuggare il boot è necessario connettersi alla prima UART della beaglebone black. Per fare questo la soluzione migliore è usare un adattatore USB.

L’UART è esportata sul connettore J1 e per connettermi uso un cavo simile a questo. E’ un cavo che converte emula da un lato una seriale su USB e dall’altro esporta tutti i segnali con livelli logici TTL.

Per connettere il cavo alla scheda bisogna collegare

• la massa al pin J1 (quello a destra nell’immagine)
• l’RX al pin 4
• il TX al pin 5

come mostrato in figura:

Dopo aver configurato tutto, è necessario alimentare la scheda ricordandosi di tener premuto il bottone per il boot da microSD e questo è il risultato:

U-Boot SPL 2017.05-jumpnow (Jun 22 2017 - 19:16:50)
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2017.05-jumpnow (Jun 22 2017 - 19:16:50 +0200)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

<ethaddr> not set. Validating first E-fuse MAC
Net:   cpsw
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
934 bytes read in 4 ms (227.5 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
Running uenvcmd ...
reading /zImage-bbb-nohdmi.dtb
32741 bytes read in 8 ms (3.9 MiB/s)
Loaded zImage-bbb-nohdmi.dtb
reading /zImage
4068696 bytes read in 259 ms (15 MiB/s)
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 8fff5000, end 8fffffe4 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.33-jumpnow (oe-user@oe-host) (gcc version 6.3.0 (GCC) ) #1 Thu Jun 22 18:36:49 CEST 2017
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: TI AM335x BeagleBone Black
[    0.000000] cma: Reserved 16 MiB at 0x9f000000
[    0.000000] Memory policy: Data cache writeback
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES2.1 (sgx neon)
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
[    0.000000] Kernel command line: console=ttyO0,115200n8 consoleblank=0 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 484508K/524288K available (6144K kernel code, 387K rwdata, 1972K rodata, 1024K init, 8008K bss, 23396K reserved, 16384K cma-reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0700000   (7136 kB)
[    0.000000]       .init : 0xc0a00000 - 0xc0b00000   (1024 kB)
[    0.000000]       .data : 0xc0b00000 - 0xc0b60e68   ( 388 kB)
[    0.000000]        .bss : 0xc0b60e68 - 0xc13330fc   (8009 kB)
[    0.000000] Running RCU self tests
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] OMAP clockevent source: timer2 at 24000000 Hz
[    0.000014] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[    0.000034] clocksource: timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[    0.000074] OMAP clocksource: timer1 at 24000000 Hz
[    0.000356] clocksource_probe: no matching clocksources found
[    0.001076] Console: colour dummy device 80x30
[    0.001127] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.001135] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.001142] ... MAX_LOCK_DEPTH:          48
[    0.001148] ... MAX_LOCKDEP_KEYS:        8191
[    0.001154] ... CLASSHASH_SIZE:          4096
[    0.001160] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.001167] ... MAX_LOCKDEP_CHAINS:      65536
[    0.001173] ... CHAINHASH_SIZE:          32768
[    0.001179]  memory used by lock dependency info: 5167 kB
[    0.001186]  per task-struct memory footprint: 1536 bytes
[    0.001215] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
[    0.078819] pid_max: default: 32768 minimum: 301
[    0.079076] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.079089] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.081275] CPU: Testing write buffer coherency: ok
[    0.082342] Setting up static identity map for 0x80100000 - 0x80100058
[    0.086928] devtmpfs: initialized
[    0.116562] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    0.117334] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.117396] futex hash table entries: 256 (order: 1, 11264 bytes)
[    0.118768] pinctrl core: initialized pinctrl subsystem
[    0.122777] NET: Registered protocol family 16
[    0.129307] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.166837] omap_hwmod: debugss: _wait_target_disable failed
[    0.222289] cpuidle: using governor ladder
[    0.222313] cpuidle: using governor menu
[    0.246782] OMAP GPIO hardware version 0.1
[    0.284400] No ATAGs?
[    0.284427] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.355483] edma 49000000.edma: TI EDMA DMA engine driver
[    0.360199] usbcore: registered new interface driver usbfs
[    0.360372] usbcore: registered new interface driver hub
[    0.360536] usbcore: registered new device driver usb
[    0.361382] omap_i2c 44e0b000.i2c: could not find pctldev for node /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_i2c0_pins, deferring probe
[    0.361482] omap_i2c 4802a000.i2c: could not find pctldev for node /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/i2c1_pins, deferring probe
[    0.361553] omap_i2c 4819c000.i2c: could not find pctldev for node /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/i2c2_pins, deferring probe
[    0.389731] clocksource: Switched to clocksource timer1
[    0.463762] VFS: Disk quotas dquot_6.6.0
[    0.463874] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.512171] NET: Registered protocol family 2
[    0.513750] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[    0.513837] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.514990] TCP: Hash tables configured (established 4096 bind 4096)
[    0.515145] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.515312] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.516016] NET: Registered protocol family 1
[    0.517487] hw perfevents: enabled with armv7_cortex_a8 PMU driver, 5 counters available
[    0.529063] workingset: timestamp_bits=30 max_order=17 bucket_order=0
[    0.535578] io scheduler noop registered
[    0.535603] io scheduler deadline registered
[    0.535677] io scheduler cfq registered (default)
[    0.538519] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.544084] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.550640] omap_uart 44e09000.serial: no wakeirq for uart0
[    0.551199] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 158, base_baud = 3000000) is a OMAP UART0
[    1.123670] console [ttyO0] enabled
[    1.128984] omap_uart 481a8000.serial: no wakeirq for uart4
[    1.135176] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 159, base_baud = 3000000) is a OMAP UART4
[    1.146618] omap_uart 481aa000.serial: no wakeirq for uart5
[    1.152791] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 160, base_baud = 3000000) is a OMAP UART5
[    1.165757] omap_rng 48310000.rng: OMAP Random Number Generator ver. 20
[    1.211514] brd: module loaded
[    1.237434] loop: module loaded
[    1.242392] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.259824] libphy: Fixed MDIO Bus: probed
[    1.264613] CAN device driver interface
[    1.339817] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    1.346205] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[    1.355078] libphy: 4a101000.mdio: probed
[    1.359284] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    1.370132] cpsw 4a100000.ethernet: Detected MACID = 04:a3:16:b1:10:d5
[    1.380580] usbcore: registered new interface driver asix
[    1.386354] usbcore: registered new interface driver ax88179_178a
[    1.392876] usbcore: registered new interface driver cdc_ether
[    1.399119] usbcore: registered new interface driver smsc95xx
[    1.405253] usbcore: registered new interface driver net1080
[    1.411285] usbcore: registered new interface driver cdc_subset
[    1.417570] usbcore: registered new interface driver zaurus
[    1.423567] usbcore: registered new interface driver cdc_ncm
[    1.436582] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.443498] ehci-omap: OMAP-EHCI Host Controller driver
[    1.449325] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.456013] usbcore: registered new interface driver cdc_wdm
[    1.462147] usbcore: registered new interface driver usbtest
[    1.471019] 47401300.usb-phy supply vcc not found, using dummy regulator
[    1.486585] 47401b00.usb-phy supply vcc not found, using dummy regulator
[    1.498303] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[    1.510878] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[    1.520929] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.528038] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.535626] usb usb1: Product: MUSB HDRC host driver
[    1.540830] usb usb1: Manufacturer: Linux 4.9.33-jumpnow musb-hcd
[    1.547197] usb usb1: SerialNumber: musb-hdrc.1.auto
[    1.556615] hub 1-0:1.0: USB hub found
[    1.561550] hub 1-0:1.0: 1 port detected
[    1.572957] mousedev: PS/2 mouse device common for all mice
[    1.584128] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[    1.592181] i2c /dev entries driver
[    1.595900] Driver for 1-wire Dallas network protocol.
[    1.607206] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.617027] omap_hsmmc 48060000.mmc: Got CD GPIO
[    1.743311] ledtrig-cpu: registered to indicate activity on CPUs
[    1.750259] usbcore: registered new interface driver usbhid
[    1.756086] usbhid: USB HID core driver
[    1.761170] oprofile: using arm/armv7
[    1.765580] Initializing XFRM netlink socket
[    1.770263] NET: Registered protocol family 17
[    1.775105] NET: Registered protocol family 15
[    1.779787] can: controller area network core (rev 20120528 abi 9)
[    1.786382] NET: Registered protocol family 29
[    1.791060] can: raw protocol (rev 20120528)
[    1.795609] can: broadcast manager protocol (rev 20161123 t)
[    1.801861] Key type dns_resolver registered
[    1.806498] omap_voltage_late_init: Voltage driver support not added
[    1.813760] ThumbEE CPU extension supported.
[    1.867224] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.881112] mmc0: new high speed SDHC card at address aaaa
[    1.892372] mmcblk0: mmc0:aaaa SL16G 14.8 GiB
[    1.899725] random: fast init done
[    1.909992]  mmcblk0: p1 p2
[    1.928880] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    1.935234] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.944317] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[    1.953101] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[    1.961135] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:01 UTC (946684801)
[    1.977073] mmc1: new high speed MMC card at address 0001
[    1.987339] mmcblk1: mmc1:0001 S10004 3.56 GiB
[    1.993067] VFS: Mounted root (ext2 filesystem) readonly on device 179:2.
[    2.001612] mmcblk1boot0: mmc1:0001 S10004 partition 1 4.00 MiB
[    2.009038] mmcblk1boot1: mmc1:0001 S10004 partition 2 4.00 MiB
[    2.017376] devtmpfs: mounted
[    2.022191] Freeing unused kernel memory: 1024K (c0a00000 - c0b00000)
[    2.031244]  mmcblk1: p1 p2
INIT: version 2.88 booting
Starting udev
[    2.597955] udevd[732]: starting version 3.2.1
[    2.663815] udevd[733]: starting eudev-3.2.1
[    3.816587] EXT2-fs (mmcblk0p2): warning: mounting unchecked fs, running e2fsck is recommended
Populating dev cache
Thu Jun 22 17:12:57 UTC 2017
INIT: Entering runlevel: 5
Configuring network interfaces... [    5.129363] net eth0: initializing cpsw version 1.12 (0)
[    5.230533] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=-1)
udhcpc (v1.24.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
done.
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 2.3 beaglebone /dev/ttyO0

beaglebone login:

Eccoci quindi arrivati al termine del primo boot di Yocto Pyro per Beaglebone Black!

Notiamo alcuni punti importanti:

• Il ROM code non emette alcun output
• All’avvio MLO emette il seguente output U-Boot SPL 2017.05-jumpnow (Jun 22 2017 - 19:16:50)
• Dopo essere stato avviato da MLO, U-boot emette U-Boot 2017.05-jumpnow (Jun 22 2017 - 19:16:50 +0200)
• All’avvio il kernel emette Starting kernel
• Quando il kernel è avviato, lo userspace prende vita con l’avvio del processo di init, in concomitanza dell’output INIT: Entering runlevel: 5
• Al termine del setup dello userspace viene avviato getty sulla seriale, che richiede il login.