[Tutorial] Linux su Xbox 360. Parte Prima. L'Hardware e i driver.
La Xbox 360, come le altre console del momento, è un computer. Questo lo sappiamo tutti.
Possiede, a grandi linee, un processore, una scheda grafica, una scheda di rete (due nel caso della versione Slim) e una scheda audio, canali SATA e USB.
Sono queste caratteristiche che hanno permesso di iniziare a pensare alla Xbox non solo come ad una console ma anche una possibile Workstation che potesse avere a bordo un Sistema Operativo e svolgere le normali funzioni di un computer.
Perchè Linux e non Windows, che è molto più utilizzato dall'utente medio?
La risposta non è "perchè non è possibile". Teoricamente installare Windows sarebbe possibile. Ho detto teoricamente, quindi non iniziate a fantasticare
La scelta ricade su degli aspetti fondamentali di un software open-source invece che chiuso.
1. Lo sviluppo, sia del S.O. che dei driver. Con un software open source l'intera comunità interessata può utilizzare il codice sorgente, apportare modifiche, adattarlo e migliorarlo.
2. L'Hardware della Xbox non è un hardware standard. Non potete andare in un negozio di prodotti informatici e acquistare una CPU o una GPU di ricambio. Per questo motivo avere delle librerie e un S.O. chiuso sarebbe una follia.
Ed è questa la base di partenza della prima parte del tutorial per installare Linux sulla vostra Xbox 360.
Quali distribuzioni è possibile installare?
Al momento, tutte le versioni di Ubuntu e Debian sono installabili.
Sono in lavorazione, ma i tempi non sono brevi, installazioni di FreeBSD e MACosX.
Quindi, cosa dev'essere preso in considerazione per l'installazione?
Nome in codice IBM "Waternoose" e Microsoft "XCPU", dai developer chiamata "Xenon", è il cuore della nostra console.
E' una CPU a 64 bit basata sull'architettura dei processori PowerPC G5 della IBM, con set di istruzioni PowerPC e tecnologia eFuse della IBM.
Possiede 3 cores simmetrici, ognuno dei quali gira a 3.2 GHz.
Ogni core ha 64 KByte di cache L1 (32+32).
Tecnologia HyperThreading SMT a due vie il che significa che per 3 CPU sono disponibili 6 threads.
E' presente una cache L2 di 1 MByte.
*** Attualmente è possibile utilizzare tutti e 3 i core ma non i threads secondari perchè generano instabilità ***
*** Le CPU IBM PowerPC hanno un bug che causa degli SpinLock casuali. Senza scendere troppo nel dettaglio, la conseguenza è che la console freeza. Inizialmente era necessario disabilitare il supporto SMT per ridurre quasi a zero gli spinlock, attualmente, dopo aver apportato alcune modifiche, il kernel ed il sistema operativo sono molto stabili. Si parla di una probabilità di spinlock attorno all' 1-2%.
Se ciò avviene, molte volte è a causa del driver audio, che si trova ad uno stage ancora primitivo.
Ubuntu gestisce l'eccezione molto meglio di Debian, che solitamente freeza pochi secondi dopo lo spinlock.***
Il supporto al processore dev'essere aggiunto nel Kernel. Se il Kernel non fosse in grado di riconoscere il processore non riuscirebbe a indirizzare le istruzioni.
Questo non è un problema. Dopo aver scaricato il Kernel ufficiale vi verranno forniti dei file per patcharlo e configurarlo.
2. LA GPU
Nome in codice "C1", progettata da ATI, può essere comparata ad una ATI Radeon X1900 per quanto riguarda le prestazioni. E' comunque precursore di diverse istruzioni che poi sono state adottate nella serie R600 di ATI.
Supporta le DirectX 9 e limitatamente le DirectX10.
Con i modelli Slim, la Microsoft ha introdotto la XCGPU, che ha integrato la CPU Xenon e la GPU Xenos sullo stesso die, e la eDRAM nello stesso package.
Come fa la scheda video ad interfacciarsi con il Sistema Operativo? Utilizzando un Framebuffer. Cos'è un Framebuffer?
E' un astrazione (o virtualizzazione) dell'hardware della scheda video, rappresentato da una memoria nella quale vengono memorizzate le informazioni sui fotogrammi video che devono essere inviati in uscita (output).
In questo modo il software, dal Sistema Operativo alle applicazioni, può accedere all'hardware della scheda video attraverso questa interfaccia, senza che sia necessario aver compilato del codice SPECIFICO PER QUEL PARTICOLARE HARDWARE VIDEO.
Linux utilizza come base il Linux Framebuffer (fbdev), per mostrare a video la console e ora la GUI. Prima del Framebuffer era necessario fare delle chiamate specifiche all'hardware con enormi problemi di compatibilità e software che doveva essere scritto per poter lavorare solo su quello o quell'altro hardware.
Per la grafica è stato quindi progettato Xenosfb, un Framebuffer Driver per il chip Xenos della Xbox 360. E' basato proprio sul Linux Framebuffer (sul quale anche gli altri produttori di driver Linux per schede video si sono appoggiati all'inizio come sorgente).
*** Attualmente non è presente accelerazione hardware. Non è possibile cambiare risoluzione in runtime. La risoluzione viene derivata dalle impostazioni della Dashboard. ***
E' importante sapere che tutti i progressi fatti sullo sviluppo di questo driver sono stati raggiunti solo grazie a reverse engineering e continui test. Non si era in possesso di alcuna documentazione o librerie di sviluppo.
E questa è la prima parte.
Di quali altri driver abbiamo bisogno?
3. HARD DISK DRIVE.
Normalmente, come ben sapete l'Hard Disk viene formattato dalla console con un File System denominato FATX (o XTAF per la struttura little endian).
Perchè venga correttamente inizializzato da Linux, è presente un modulo nel Kernel.
Questione "Dual Boot" - Non so se affrontarla separatamente perchè significa andare parecchio in fondo ai dettagli tecnici della struttura dell'HDD della Xbox.
Allora:
Ogni HDD della Xbox 360 contiene 3 partizioni.Le prime due sono uguali per tutte le dimensioni degli HDD. L'Offset di queste partizioni è da 0x0 a 0x0x130eb0000.
La terza partizione inizia a 0x130eb0000 e utilizza tutto lo spazio disponibile a seconda della dimensione dell'HDD. Sarebbe la partizione principale, dove sono salvati i giochi, i salvataggi, ecc...). Quindi supponendo che si vuole avere 60 GByte per la Xbox e 60 GByte per Linux:
La soluzione è quella di creare un marker all'interno della partizione che identifica, a partire dall'offset 0x130eb0000, gli ultimi 60 GByte del disco come già utilizzati e quindi non utilizzabili dalla partizione. In Linux poi si dovrebbe modificare il driver che inizializza il FS per specificare di iniziare il partizionamento a partire dall'offset 0xXXXXXXXXX, nel caso supposto, 60 GB dopo. A quel punto scrivere un nuovo header di 0x12 byte e creare una nuova tabella di partizione.
Ma sono soluzioni che non contemplerò nel tutorial. Utilizzate un HDD differente. E' la soluzione più sicura e pulita.
4. ETHERNET ADAPTER.
La Xbox possiede un chip integrato (ICS1893BF oppure BCM5241) che fornisce connettività di rete 10/100 Mbps. I modelli Slim hanno anche un chip (88W8786U-NAP2) della Marvel per la connettività Wi-Fi. Perchè possano interagire con il S.O. è necessario caricare degli specifici moduli nel kernel.
5. AUDIO.
Questa è forse la nota più dolente. Attualmente un driver esiste, e lo utilizzeremo caricandolo nel kernel. Il chip audio viene correttamente rilevato e caricato dal sistema. Debian Squeeze però restituisce un Kernel Failure nel caricare il modulo PCM. Ubuntu reagisce molto meglio e sono riuscito ad ottenere i normali suoni del Sistema Operativo anche su HDMI e i file audio, dopo aver caricato gli opportuni codec, funzionano benissimo.
6. DISPOSITIVI DI INPUT (MOUSE - TASTIERA - JOYPAD)
Avendo dei registri I/O abbastanza generici per tutte le funzionalità principali, la tastiera ed il mouse vengono inizializzati con un driver generico da parte del S.O. Per il Joypad, anche wireless, è presente un pacchetto che ne emula il funzionamento come fosse un mouse.
Attenzione, Debian Squeeze funzionerà specificando i moduli per tastiera e mouse.
Ubuntu Oneiric invece si affida ad evdev per la gestione dei dispositivi di input.
Altri moduli scritti specificamente per il funzionamento di Linux sulla Xbox 360 sono i seguenti:
Xenon ANA e Probe, moduli fondamentali come complemento al Framebuffer.
Modulo RTC (Real Time Clock) per la sincronizzazione dei cicli.
Il driver Framebuffer è l'unico che dovremo espressamente caricare all'interno del S.O perchè non è integrato nel kernel.
Da solo però non funziona, semplicemente perchè il sistema operativo non sa che cosa pescare.
Per caricarlo, andremo a modificare il file Xorg.conf. Questo file è il file di configurazione del server X.
Per i meno esperti di sistemi operativi Linux, X è il server (inteso come modulo che fornisce servizi) che fornisce una GUI al S.O.
In Debian Squeeze questo file di configurazione è già presente. Andrà modificato nel modo più opportuno.
In Ubuntu Oneiric però questo file manca, perchè è stato deciso di non includerlo a partire dalla versione 9.04. La sua configurazione però dev'essere differente dal file Xorg.conf di Squeeze.
Per semplicità, nella seconda parte del tutorial farò l'upload anche di questo file, spiegandolo passo passo, in modo da darvi tutti gli strumenti.
Bene. La prima parte del tutorial è completa. Se rileggendolo, mi accorgo di aver dimenticato qualcosa, aggiorno il tutorial e lascio un post per avvisare.
Ora, la seconda parte...Sicuramente più interessante.
Questi saranno gli argomenti:
- XeLL. Compilazione del sorgente di XeLL più recente, per le sue funzionalità avanzate rispetto all'ultima versione pubblica (build date: 23.09.2011).
- Configurazione del file kboot.conf. Questo file è essenziale per numerosi scopi. Quello che interessa a noi è la capacità di passare parametri di boot al kernel.
- Compilazione del Kernel. Quale compilare e come compilarlo.
- Preparazione dell'ambiente necessario ad installare Linux. Vedremo cosa ci dobbiamo procurare e perchè, in riferimento anche a quanto specificato in un post precedente. L'installazione di Linux, infatti, non avverrà tramite CD/DVD o immagine ISO, ma via Web. Il metodo di installazione sarà quello della preconfigurazione e dell'immagine necessaria alla net-installation.
Segnalibri