Ore 17:03 ~ I muscoli, gli occhi e l’autostima fanno male.
Ok. Questo post, purtroppo, sarà molto tecnico. Come possono esserlo tutti i miei post tecnici, in realtà. Non aspettatevi tutorials o cose così. Se siete quì per cercare aiuto sulla piattaforma Xilinx ML310 con Virtex II Pro… Siete nel posto sbagliato. Ne abbiamo bisogno anche noi.
Ma che dico? Ormai non c’è più nessuno che usa questa piattaforma. Non con Xilinx ISE 9.1i SP3 e EDK 9.1i SP2…
Ma prima d’iniziare, lasciate che vi mostri un’immagine…
Non sapete quante idee per videogames o campagne mi sono venute in mente partendo da quest'illustrazione. Se avete bisogno di uno spunto, comunque, ecco a voi.
Poco steampunk per i miei gusti, dite? Eh. Immagino, quello che mi ha colpito è la ragazza/spirito tutto bianco. Dove avrò già visto una cosa simile? Ah, già. {Pausa tè}
Ma torniamo all’argomento principale di questo post, ovvero quello che abbiamo fatto oggi. Come potrete comprendere dal testo io e GODS abbiamo fatto una sacco di fatica per il cazzo. Ma prima di tutto, lasciate che vi spieghi per quale motivo sto scrivendo durante il pomeriggio invece che la sera. Penso che uno screenshot basti.
Sapete da quanto è su? Da oggi a pranzo!
In pratica io e GODS siamo stati tutto il giorno a fare due cose:
- Aspettare che questo software venisse scaricato
- Capire COME poter fare per compilare un kernel più nuovo del 2.4.20 presente sulla flash in bundle con la Virtex 2 Pro
Perchè c’è questa necessità impellente di scaricare l’ELDK? In pratica, secondo questa guida, che è una delle poche ancore di salvezza in questo momento (finchè non decideremo di smettere col provare a compilare un kernel nuovo e ci metteremo a compilare tutto per quel kernel linkando staticamente le librerie), dentro quell’immagine da ~2GB c’è il cross compiler per PPC405 che ci serve. Cos’è un cross compiler? Ok, per quelli che non lo sanno è un compilatore per codice in C/C++ fatto in modo che crei degli eseguibili che funzionano con un architettura (i.e. processore, quindi assembly language) differente da quella sulla quale viene compilato il programma. Ovviamente la storia è molto più complessa di così, però non voglio stare quì a tirarvela lunga su quel fronte.
Questo cross compilatore ci serve, comunque, per entrambe le cose, ovvero, sia che noi decidiamo di ricompilare il kernel sia che noi decidiamo di compilare tutti gli applicativi per quella fuffa di Montavista Linux Professional 3.1, perciò finchè non ce l’abbiamo siamo bloccati.
E per il capire come fare a compilare il kernel come sta andando?
Beh, lì è tutt’altra storia.
Allora. Come molti di voi potranno immaginare compilare un kernel linux può essere una sega infinita, anche perchè vanno selezionati e configurate tutte le cose di base che deve fornire un sistema operativo. E quando parlo di tutte intendo anche se mettere o meno il supporto per $piattaforma che potrebbe esserci come no sul vostro {OMIODDIO! ha finito il Download. Ora GODS si addentrerà nelle profondità dell’inferno.} sistema target. In pratica, pensate di andare a fare la spesa per una casa vuota. Comprereste un antizanzare? Sì, no? Come fate a saperlo prima di sapere se la vostra zona è infestata da zanzare o meno. Oppure ancora: prendereste del detersivo per lavastoviglie? Perchè magari voi siete sicuri che comprerete una lavastoviglie, ma magari questa cosa potrebbe avvenire molto più in là. O potreste scoprire che la lavastoviglie non può venir installata a casa vostra.
Ecco. Compilare il kernel è un po’ così ma solo con una tonnellata di tecnicismi e di prolissità inutile. Ho sentito più volte dire la frase da GODS (o da me)
Ce lo mettiamo il “Support Regulators on Dialog Semiconductor DA9030/DA9034 PMIC”?
E lì cosa volete rispondere? Più che “Sì, metticelo, al massimo può servire…” non è che c’è da dire, no?
Ecco. Ora pensate a cosa succede quando fate così al supermercato. Io lo vivo ogni volta. Arrivi alla cassa e paghi un casino per cazzate. Nel nostro caso, però, i soldi sono byte. Ogni puttanata che aggiungiamo occupa spazio. Molto molto spazio. Ora, non che questo sia un problema in se, perchè abbiamo una scheda da un tot di Giga (Tipo… 4 però sono tanti per gli embeddari, ve l’assicuro), però non è molto intelligente. Più grande è un kernel e più lentamente si carica. Questo, sulle nostre macchine a core multipli che vanno a ~2GHz non è un problema, ma quando la piattaforma ha solo un core con 300MHz, proprio come una PSP o una PS2, allora inizia a farsi sentire.
E questi problemi sono solo… LA FINE. {Meanwhile, sul PC di GODS…}
Real time! Fuck yeah, Live blogging. Ecco a voi GODS che installa tonnellate di fuffa. :3
Ecco. Perchè non vi ho ancora raccontato della parte che ci sta prima.
In pratica, a partire dal kernel versione … non lo riesco a trovare, ma sicuramente a cavallo tra la versione fornitaci dalla Xilinx e quella usata in TUTTI I FOTTUTI TUTORIAL TRANNE UNO (Per non parlare del fatto che tutti usano la versione 10.1i degli strumenti ufficiali, usando così delle definizioni hardware aggiornate incompatibili con le nostre. Sul serio. Siamo arrivati a cavallo di due generazioni!), viene usato un file di descrizione dell’hardware presente sulla macchina chiamato Flattened Device Tree. Questa trovata (o standard, non ho capito) è particolarmente intelligente come cosa, in quanto permette a chi usa piattaformine fuffa di non doversi scrivere tonnellate di header files e altre cazzate dentro nelle cartelle dei sorgenti del kernel per indicargli dove andare a scrivere, leggere, sfrugnare ed altre bruttissime cose che dovrebbero venir lasciate stare.
Vabbeh. Fatto sta che, appunto, quando è uscita la board sulla quale stiamo lavorando, ovvero la Xilinx ML310, questa cosa NON esisteva ancora, perciò c’erano degli add-on per la versione 6.2i dell’EDK e dell’ISE per creare i suddetti file da mettere nei sorgenti del Kernel.
Però, fortuna degli utenti della Xilinx, una volta che sono iniziati ad apparire gli FDT, la Xilinx ha deciso di rilasciare un add-on per ISE ed EDK che permettesse loro di generare i file .dts, che descrivono l’hardware presente sulla piattaforma target, automaticamente. Una manna.
Veramente.
E INVECE!
MFW
{Meanwhile sul PC del GODS EDL... Warning Forever. Ok, direi che tra un po' ce ne andiamo a casa}
Esattamente. Questa cosa sarebbe magnifica se non fosse che noi due NON abbiamo le licenze per l’interfacciamento al controller Ethernet della Intel presente onboard. È per questo che stiamo usando un bistream preinstallato sulla CF per lavorare. Perciò non possiamo sintetizzare nessun FDT. Tutto quello che abbiamo è una serie di patch per kernel (tra cui un’interfaccia Ethernet hard-codata!).
In realtà pensiamo che uno di questi file possa aiutarci. Il fatto è che non sappiamo come possa essere possibile scrivere a manina un file .dts, in quanto richiede molte cose che non siappiamo da dove tirare fuori.
Cioè. Un’idea ce l’abbiamo…
...ma non vi piacerà.
Allora. Ora che siamo, in pratica, arrivati in fondo a questo articolo anche perchè stasera NON possiamo fare tardi, qual’è la nostra situazione?
Le prospettive sono tre:
- Seguire questa guida, collegata a quest’altra e, possibilmente, anche questa, sperando che, per una strana combinazione e grazie alla benedizione di Atena, la Luna ed Inari
- Prendere quel file mostrato nello screenshot, retro-engeneerizzarlo e sperare di riuscire a costruirci dietro un file .dts
- Compilare tutto ed usare quello che è già presente
Il piano, sappiatelo, è questo: domani provare se va la ricompilazione del kernel. Se non va mandare tutto a ‘fanculo e compilare tutto per la vecchia piattaforma. Io ne ho abbastanza di questo “linux” con tutto lockato. È impossibile lavorare con una piattaforma di cui non puoi avere i file .dts perchè sono configurabili.
Bene. Ora penso che andremo. Ho una sfida da vincere.
Per il resto non vi preoccupate. Da domani i post saranno di nuovo più divertenti. Magari meno interessanti di questo, ma più divertenti.
Certo. Dando per scontato che gli altri fossero divertenti.
Buona serata. Io vado a giocare ad Exalted. Voi che farete di bello (questo per stimolare la discussione XD)?