Thread per sperimentazione sistema minimo LINUX su Microcontrollore

Esigente minimali di IO, ovvero una cadrega che fa le stesse cose di una MPU collegata in seriale ad un SoC (modi Yun), ma a differenza della combo SOC+MPU, Linux su quel coso ti offre solo GPIO, spi, i2c, le solite cose, con l'aggiunta di qualche modulino, il tutto accessibile (se noti) da userspace in modo un pelo + intimo rispetto ad avere a che fare con MPU esterne. Ora, non ho ben capito che esigenze abbiate, pero' se si va un pelo oltre questo, quel coso si siede.

Quel coso ha solo esigenze didattiche at Home.

Mi devo esercitare a capire i meandri di un sistema Embedded Linux per poter operare - poi - sul Coldfire aziendale che, grossomodo, non è molto più performante di quel Philips (NPX). Non mi ricordo la sigla del Freescale, ma è una ARM Cortex-M3 che funzia a 180 MHz. E, come detto, non fa cose grandiose, ma principalmente da interfaccia utente, aggiornamento della macchina (il Sistema ha dei DSP, CPLD e FPGA che vengono aggiornati via Ethernet dal Coldfire).

Queste macchine vengono aggiornate da remoto, con password utente per accedere al sistema Linux, il quale poi esegue configurazioni della macchina e/o l'aggiornamento di tutti i dispositivi sulla mainboard e su schede separate in Bus proprietario (gestito dalla FPGA).

Inoltre c'è una la possibilità di effettuare una connessione SSL, ma non funziona, o meglio, ci mette mezzora per ogni comando. Il punto è che è stata costruita via software, io ho proposto l'utilizzo di una versione Coldfire con il Crypto-Engine, e visto che l'ho proposto, verosimilmente me lo daranno a me da smazzare, ma prima devo comprendere bene come funziona al low-level sto czz di Linux montato su una MCU.

Per ora sto pompando di brutto su libri e pubblicazioni come "Embedded System Design Modeling, Synthesis and Verification" o "Embedded Linux Primer" e altri come quelli che ti ho passato, ma finchè non metto mano su un coso vero, con relativo smanettamento, non posso fare altri progressi.

Posso usare la Raspberry, ma mi sembra qualcosa che non è proprio attinente a quello che cerco di fare.

Che ci metta 30 minuti per ogni comando e' indice che c'e' qualcosa che non va, la cadrega 68060 @ 25Mhz riesce a sostenere un tunnel ssh senza problema alcuno, nemmeno di latenza (nei limiti dell'accettabile, un po' si siede, e si sente, ma non abbastanza per farmi somatizzare fastidio), e non ha alcun cripto coso sotto al cofano.

Ma a parte questo, se ti ricordi ti avevo gia' fatto notare che le crypto faccende non sono banali da realizzare su linux

secondo me te la puoi cavare se in freescale vi danno loro support per il cripto engine (tradotto vi spediscono un kernel module, a cui poi dovrai poi adattare la libreria libSSL e sue amiche)

per cui io indagherei bene sul perche' e percome quel coso ci mette 30 minuti, dopo di che forzerei un SoC con i contro attributi ben consapevole che su linux i cripto cosi non sono mai stati il fiore all'occhiello, anzi ... sopratutto nelle vpn accellerator non hanno mai funzionato. Le vpn sono un esempio + avanzato, pero' il cripto coso e buona parte dell'impalcatura che lo tiene su e' lo stesso, e diciamo pure che mi ci sono scottato.

In sostanza quel coso dip40 va bene per giocare con i moduli, cosi' imparti un po' a gestirti i gpio da userspace usando servizi devname e scrivendoci attorno app mirate, cosi' se hai in mano la cadrega ci giochi ed impari al learn by example, e ci impari pure come organizzare una toolchain (che tanto in sti cosi prima o poi ti tocca), ma per la parte cript, e/o giocare con ssh ... io fossi in te indagherei e/o farei indagare la magagna, dopo di che per sicurezza e sopravvivenza mi prenderei e punterei i piedi affinche prendano un SoC potente, e la parte SSL la sbolognerei li.

Potresti anche far girare nbench per vedere un po' di che numeri parliamo, mi aspetto a pelo che il coso dip40 non debba avere problemi a sostenere almeno un tunnel SSH, in fondo ha lo stesso profilo (eccezzion fatta per l'architettura, e per il fatto che non ha una lan interna ma si rifa ad SPI+ENC, peccato da 10Mbit/sec) di un router sul quale e' "normale" poter accedere in ssh e/o gestire servizi SSL.

Ti consiglio anche di leggere
'Linux Device drivers' di Alessandro Rubini. La 2nd Edition dovrebbe essere gratuita in formato PDF.

Ammappete! Il coso DIP40 + Board + Shipping + Iva è costato 45euri. Una board con SoC a 1 GHz linux based, costa quasi di meno...

Tornando al sistema SSL, in realtà non ci mette mezz'ora, era un parafrasare. Ma cmq qualche minuto si!

Inoltre durante l'aggiornamento del Sistema Linux della macchina (Kernel, ramdisk, varie EEPROM) impiega un tempo non determinato per generare le chiavi RSA dell'Hash. In alcuni sistemi ci mette 2 minuti, in altri fino a 20(!). Perchè? Non lo sanno. Work in progress (come detto non sono dei super IngeGGneri come te)

Inoltre è un pò ambiguo il sistema di raccolta di informazioni del Software di aggiornamento. Questo Software, windows-based, fatto in Visual Basic (.Net) va a leggere i processi in atto nel sistema (credo che lanci un comando tipo "top") ogni tot secondi, e finchè vede che in Ram continua a girare il processo della generazione delle chiavi, il Software Visual-basico considera il thread ancora in lavorazione e non passa alla fase successiva.
Il Softwerista alza le mani e dice che non è colpa sua e che del resto non ci capisce niente. La "colpa", ovviamente, è del Linuxista!

E' mai possibile che il Coldfire ci metta così tanto a generare le chiavi RSA? O ancora più precisamente: come mai il processo rimane in Ram così tanto (diversi minuti)?