Linux su Xbox 360. Seconda parte del Tutorial.
Bene. Avevo terminato la prima parte del Tutorial parlando dell'hardware della Xbox 360 e dei driver che è necessario implementare, sia a livello di S.O. che di Kernel per rendere possibile al S.O. di interagire con i vari dispositivi hardware della console.
Vi consiglio, prima di iniziare la lettura di questa seconda parte del Tutorial, di rileggervi attentamente la prima parte, perchè possiate avere tutto ben presente.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. "Xenon Linux Loader" aka XeLL.
Questo software lo conoscete tutti. Era XeLL(ous) per le console con dashboard vulnerabile ad SMC Hack (JTAG). E' XeLL Reloaded per le console che sfruttano l'exploit Reset Glitch Hack.
Lo conoscete perchè è quello che vi permette di leggere la famosa CPU Key abbinata alla DVD Key.
Ma XeLL è molto...molto di più. Gli sviluppatori l'hanno reso il "punto di partenza" per permettere l'esecuzione di software homebrew, fino ad arrivare a rendere possibile l'installazione di Linux.
Ad esempio: Queste sono le stringhe di codice che rendono possibile la visualizzazione a schermo degli eFUSE, la CPU Key e la DVD Key:
Codice:
#ifndef NO_PRINT_CONFIG
printf(" * FUSES - write them down and keep them safe:\n");
char *fusestr = FUSES;
for (i=0; i<12; ++i){
u64 line;
unsigned int hi,lo;
line=xenon_secotp_read_line(i);
hi=line>>32;
lo=line&0xffffffff;
fusestr += sprintf(fusestr, "fuseset %02d: %08x%08x\n", i, hi, lo);
}
printf(FUSES);
print_cpu_dvd_keys();
network_print_config();
#endif
Non ci capite molto, lo so. Ma quello che è importante, per ora, è che vediate cos'è, praticamente, XeLL.
XeLL-Reloaded cattura i threads della CPU, li inizializza ed ha la capacità di avviare un file .elf da dispositivi USB (fat-fat32), HDD (fat-fat32), rete (tftp) o CDROM (ISO9660).
E' diviso in stage. Il primo stage inizializza l'hardware, poi decomprime ed inizializza il secondo stage.
Il secondo stage carica i driver richiesti (network, sata, input) ed esegue i compiti descritti in basso.
Cos'è un thread? Il thread è l'unità minima di un processo.
Ogni volta che deve eseguire un'operazione inizializza un processo. Per inizializzarlo gli assegna uno stack (uno spazio) virtuale di memoria. Due processi che devono comunicare fra loro posson farlo solo attraverso il kernel. I processi sono costituiti da threads, che sono l'unità più piccola di istruzioni che può essere eseguita dal sistema operativo. I threads condivisono lo spazio virtuale degli indirizzi di memoria e possono scambiarsi informazioni senza invocare il sistema operativo.
XeLL è basato su LibXenon. Cosa può fare?
Oltre ai compiti già conosciuti:
- Può decomprimere e caricare file compressi (gzip). Es. InitRamFS.
- Supporta l'alta definizione (HDMI) alla risoluzione di 1280x720p. Cambia la modalità di visualizzazione da NTSC a PAL se opportuno.
- Attiva tutti i core della CPU alla loro massima velocità.
- Supporta USB 2.0, grazie a TinyEHCI, quindi abbiamo 480Mbps teorici in I/O con HDD e USB Keys.
- Supporta funzionalità di rete grazie a lwIP 1.4, indirizzamento dinamico e assegnazione di indirizzo statico se il DHCP è assente.
- Permette l'accesso al lettore DVD via DMA (accesso più rapido).
- L'accesso a XeLL è consentito anche da parte di un'applicazione homebrew.
- Crea un server web minimale in grado di fornire CPU e DVD Key e il Dump della NAND.
- Permette l'aggiornamento tramite il caricamento da dispositivo di memorizzazione di massa o ottico di un file chiamato "updxell.bin"
- Tramite una funzione di loop continua a fare il polling dei dispositivi finchè non viene caricato un file valido (".elf", "kboot.conf","zImage.z","vmlinux").
- Esegue il parsing e la decrittazione del keyvault.
- Supporta file di configurazione kboot.conf.
- Permette il caricamento opzionale di un initramfs esterno.
- Visualizza un menu che permette il caricamento di file LibXenon eseguibili.
E tutto questo, ragazzi, in soli 256 KByte di codice compilato!
XeLL è in continua fase di miglioramento.
L'ultima distribuzione pubblica ufficiale al momento di scrivere (14.02.2012) risale al 23.09.2011. E le sue funzionalità erano molto minori a quelle descritte più sopra.
Il 19 Febbraio 2012 è stata rilasciata una nuova release: 0.991 che porta numerosi miglioramenti. Ad ogni modo alla data dell'aggiornamento, 1 Marzo 2012, ci sono stati già ulteriori miglioramenti, quindi la scelta migliore è sempre quella di compilarsi da sè il proprio kernel.
Adesso quindi vedremo come compilarci l'ultima versione disponibile di XeLL-Reloaded ancora in testing.
*** Attenzione *** Alla data di oggi, dopo la release 0.991 la scelta migliore sta nel compilare il sorgente di xell, invece che Xell-Testing, perchè il codice verrà aggiornato spesso anche nella release ufficiale oltre che quella di test. Lascio comunque i passaggi per fare il build della versione testing sotto spoiler.
Quindi, per compilare XeLL:
1. Do per scontato che abbiate già compilato la vostra libreria LibXenon.
Se non lo aveste fatto, dalla vostra home:
Codice:
sudo su
git clone https://github.com/Free60Project/libxenon
cd libxenon/toolchain
./build-xenon-toolchain toolchain
Alla fine della procedura, meglio descritta nel tutorial "La Libreria LibXenon e le applicazioni", bisogna esportare le variabili d'ambiente.
La procedura aggiornata è questa (da root):
Codice:
touch /etc/profile.d/devkitxenon.sh
nano /etc/profile.d/devkitxenon.sh
Il file dovrà avere questo aspetto:
Codice:
#!/bin/bash
export DEVKITXENON="/usr/local/xenon"
export PATH="$PATH:$DEVKITXENON/bin:$DEVKITXENON/usr/bin"
Riavviate la macchina.
Adesso copiate sul vostro computer il sorgente di XeLL:
Codice:
sudo git clone https://github.com/Free60Project/xell
cd xell
sudo make
Questa è la procedura per compilare Xell-Testing.
Oltre a indircarvi come compilarla, ve ne farei volentieri l'upload, ma gli sviluppatori hanno espressamente dichiarato che le versioni WIP (work in progress) non devono essere rilasciate. Sono disponibili delle versioni RC (Release Candidate) precompilate, ma la cosa migliore, ragazzi, è imparare a compilarsela da sè, così da non dover attendere che qualcuno lo faccia per noi.
Allora,
il progetto per lo sviluppo di XeLL si chiama "xell-testing" ed è prelevabile da qui: "https://github.com/tuxuser/xell-testing".
Come è prelevabile ormai dovreste saperlo. Dalla vostra home digitate:
Codice:
git clone https://github.com/tuxuser/xell-testing
Se però adesso provate ad eseguire un Make, vi verrà restituito un errore.
Per compilare le applicazioni Homebrew dichiarate in testing è stata sviluppata una libreria specifica: "LibXenon-Testing".
Per compilarci la nostra build di XeLL, dovremo quindi prima compilare la libreria di sviluppo.
Dalla vostra home:
Codice:
git clone https://github.com/tuxuser/libxenon-testing
Quando il cloning è terminato, navigate nella cartella "libxenon-testing/toolchain".
Da lì:
Codice:
./build-xenon-toolchain toolchain
Le fasi sono identiche a quelle per la compilazione della Toolchain originale.
Al termine della compilazione, tornati al prompt dei comandi, entrate nella cartella "xell-testing" e date un
.
La compilazione avverrà correttamente e al termine vi ritroverete 3 file compilati:
- xell-gggggg.bin ==> Questo è il binario di XeLL che, rinominato in updxell.bin permette di aggiornare XeLL nella nostra memoria NAND.
- xell-1f.bin ======> Questa è la versione di XeLL per le console che sfruttano l'exploit SMC Hack (JTAG).
- xell-2f.bin ======> Questa è la versione di XeLL per le console che sfruttano l'exploit RGH.
Adesso procedete all'aggiornamento di XeLL nella vostra console. Quindi, al contrario dei vecchi metodi utilizzati finora:
- Rinominate il file xell-gggggg.bin appena compilato in updxell.bin ed inseritelo nella root di una penna USB o di un CD/DVD-ROM ed avviate XeLL. Questi troverà il file updxell.bin e lo eseguirà. Al riavvio avrete la nuova versione di XeLL.
XeLL ha anche la capacità di flashare la NAND, perchè include il codice del Rawflasher (v4).
In questo caso ovviamente dovete avere il dump della NAND già remappato e reso valido con la vostra CPU Key. Rinominate il vostro dump in
"updflash.bin" e copiatelo nella root di una penna USB o di un CD/DVD-ROM. Avviate XeLL. Questi troverà il file updflash.bin e lo eseguirà.
Adesso occupiamoci del secondo tassello del puzzle. Il file kboot.conf.
2. Kboot.conf
Questo file di configurazione è fondamentale perchè assolve diversi compiti:
1. Permette di impostare un indirizzo IP statico sulla nostra console.
2. Permette di impostare un indirizzo IP per il server TFTP (copriremo questo argomento in seguito).
3. Esegue il parsing della modalità video disponibile sul nostro monitor, TV ed imposta quella più appropriata.
4. Abilita i core della CPU ed i threads per avere la massima velocità disponibile. (Altrimenti sarebbe necessario avviare prima la Dashboard e poi XellLaunch, in questo modo la Xbox avrebbe già abilitato tutti i threads e i core.
5. Permette di eseguire e mostrare a video un menu di scelta dei file da eseguire, impostandone volendo uno di default nel caso non venga selezionata una scelta.
6. Permette di passare parametri di boot al Kernel Linux! Questo è quello che ci interessa moltissimo.
In questo modo potremo rendere l'avvio del kernel dinamico, aggiungere o rimuovere parametri di boot che normalmente e com'è stato fatto finora andavano specificati nel kernel (stringa CONFIG_CMDLINE). Il problema è che se uno di quei parametri confliggeva con la nostra installazione o desideravamo aggiungere funzionalità aggiuntive (es. la persistenza ad una distro Live), dovevamo ogni volta riconfigurare e ricompilare il kernel!
Allora, il miglior modo per spiegarvi questo file di configurazione è farvelo vedere. Qui vi aggiungo due modelli del file che uso io. Ve li differenzio per praticità, può benissimo esistere un solo file di configurazione sia per avviare Linux, sia per le applicazioni LibXenon.
Kboot.conf commentato e completo di indicazioni. Permette di lanciare Kernel Linux e Applicazioni LibXenon.
Codice:
#KBOOTCONFIG
; #KBOOTCONFIG Solo questa stringa dev'essere presente alla prima linea del file.
# General XeLL options
; netconfig - L'IP descritto verrà settato solo se valido. Se non è valido o è commentato XeLL ; userà o il DHCP o se questo non è disponibile, questo indirizzo IP/netmask statico ; (192.168.1.99/255.255.255.0)
ip=192.168.1.22
netmask=255.255.255.0
gateway=192.168.1.1
; Impostazione di un server TFTP
; Se nessun server TFTP viene specificato o è invalido/commentato, XeLL userà un indirizzo ; IP ; richiesto al DHCP o nel caso questi non sia disponibile il seguente indirizzo IP statico: ; 192.168.1.98
tftp_server=192.168.1.2
; Imposta la modalità video che dev'essere presentata a schermo. Se il valore non è valido o ; commentato XeLL farà un parsing per trovare la modalità valida e imposterà quella ; automaticamente.
; 0: VIDEO_MODE_VGA_640x480
; 1: VIDEO_MODE_VGA_1024x768
; 2: VIDEO_MODE_PAL60
; 3: VIDEO_MODE_YUV_480P
; 4: VIDEO_MODE_PAL50
; 5: VIDEO_MODE_VGA_1280x768
; 6: VIDEO_MODE_VGA_1360x768
; 7: VIDEO_MODE_VGA_1280x720
; 8: VIDEO_MODE_VGA_1440x900
; 9: VIDEO_MODE_VGA_1280x1024
; 10: VIDEO_MODE_HDMI_720P
; 11: VIDEO_MODE_YUV_720P
; 12: VIDEO_MODE_NTSC
videomode=10
; Abilita i core della CPU e i threads. Se il valore non è valido o è commentato, XeLL lascerà ; la velocità della CPU invariata.
; 1: XENON_SPEED_FULL
; 2: XENON_SPEED_3_2
; 3: XENON_SPEED_1_2
; 4: XENON_SPEED_1_3
; If no value is set/set invalid/commented, XeLL won't change CPU Speed
speedup=1
# Menu di Boot per Linux o Applicazioni LibXenon
# La configurazione è opzionale. Non indicando nulla, XeLL cercherà di eseguire i file # eseguibili standard.
; Voce di Menu di default -
; Se non viene specificato nulla o la stringa non è valida, XeLL farà il boot della prima voce.
default=zlx_browser_usb
; Timeout del Menu. "0" equivale all'esecuzione automatica senza scelta da parte dell'utente!
timeout=10
; Voci di Menu. Sia per Linux che per le Applicazioni LibXenon.
; Il primo parametro dev'essere il kernel o l'eseguibile LibXenon!
zlx_browser_usb="uda:/xenon.elf"
Kboot.conf usato per avviare Linux.
Codice:
#KBOOTCONFIG
; ip=192.168.1.22
; netmask=255.255.255.0
; gateway=192.168.1.1
; tftp_server=192.168.1.3
videomode=10
speedup=1
default=ubuntu_from_usb
timeout=10
ubuntu_from_usb="uda:/vmlinux root=/dev/sda6 ip=dhcp console=tty0 video=xenonfb fb=false panic=60 maxcpus=3 --"
ubuntu_from_hdd="uda:/vmlinux root=/dev/sda1 ip=dhcp console=tty0 video=xenonfb fb=false panic=60 maxcpus=3 --"
Sezione di Kboot.conf usato per INSTALLARE Linux.
Codice:
install_from_usb="uda:/vmlinux initrd=uda:/ubuntuppcnetload.gz preseed/file=/hd-media/oneiric.preseed priority=critical auto=true ip=dhcp console=tty0 video=xenonfb fb=false panic=60 maxcpus=3 --"
ubuntu_from_dvd="dvd:/vmlinux initrd=dvd:/ubuntuppcnetload.gz preseed/file=/cdrom/oneiric.preseed priority=critical auto=true ip=dhcp console=tty0 video=xenonfb fb=false panic=60 maxcpus=3 --"
ubuntu_from_tftp="vmlinux initrd=ubuntuppcnetload.gz preseed/url=(ftp://nostro_server_ftp/oneiric.preseed priority=critical auto=true ip=dhcp console=tty0 video=xenonfb fb=false panic=60 maxcpus=3 --"
ubuntu_ripristino="uda:/vmlinux initrd=uda:/ubuntuppcnetload.gz rescue/enable=true console=tty0 video=xenonfb panic=60 maxcpus=3 --"
Come potete capire, in fase d'installazione chiederemo a XeLL di caricare, oltre al Kernel, un'immagine compressa di un file system minimale che contiene i moduli del kernel necessari a montare il filesystem in "/" (percorso di root) ed uno o più script che caricano questi moduli montano il FS del Sistema Operativo ed eseguono init, che completerà l'avvio del sistema operativo, impostante l'ambiente dell'utente e permettendo l'interazione dell'utente ed il login.
L'initrd che caricheremo è un'immagine standard utilizzata per l'installazione da rete Internet di una distribuzione. Questa è una caratteristica meravigliosa della modularità di Linux, cosa che non credo con Windows si vedrà mai. Attenzione, quest'immagine AVVIA SOLTANTO IL PROCESSO DI INSTALLAZIONE. Per tutto il resto ci affideremo al file di preconfigurazione "oneiric.preseed".
Per questo, per chi già non sapesse farlo, abbiamo bisogno di imparare a creare un nostro server FTP che poi farà da base per tutti quegli elementi che devono essere personalizzati. Queste nozioni verranno affrontate nella terza parte del Tutorial.
E passiamo al terzo tassello. Il Kernel.
3. The Linux Kernel (dirlo in inglese suona più figo :P)
Mi sembra di aver già accennato cosa fosse un Kernel. E' il cuore del S.O., che contiene le istruzioni base, i moduli, i driver e le configurazioni necessarie al suo funzionamento. Niente Kernel, Niente Sistema Operativo.
Veniamo alla parte pratica.
Linux. Distribuzione Debian Squeeze. Il Kernel base utilizzato è il 2.6.32.X. Quindi per i nostri scopi, la versione Kernel che compileremo (2.6.38.8) sarà più che sufficiente.
Linux. Distribuzione Ubuntu Oneiric Ocelot. Il Kernel base utilizzato è il 2.6.38.8. Qualsiasi versione inferiore o non funzionerà o genererà instabilità, quindi nemmeno provateci.
I passi fondamentali sono 3:
1. Download e Decompressione del Kernel.
2. Applicazione di un file .diff.
3. Applicazione di un file di configurazione del Kernel.
4. (Opzionale) Modifica della configurazione del Kernel.
Ma prima di vedere all'opera l'intero processo, dobbiamo fare una premessa, indispensabile.
Con l'attuale versione di LibXenon, che utilizza il compilatore GCC alla versione 4.6.1, la compilazione non riuscirà e verrà restituito un errore.
Risolvendo l'errore il Kernel compilerà correttamente, ma quando andremo ad utilizzarlo per avviare Linux, scaturiranno tantissimi errori nell'inizializzazione del modulo ATA del Kernel (non dipende dal nostro modulo SATA per la Xbox, quello è OK).
Altro problema che potrebbe venir fuori sarebbe quello della diversa assegnazione della periferica SATA. Il nostro HDD, invece di essere inizializzato come "/dev/sda", potrebbe essere inizializzato al minimo come "/dev/sdb" o "/dev/sdX" a seconda del numero di dispositivi di memorizzazione di massa connessi alla console.
Attualmente GCC 4.6.1 funziona correttamente solo per Kernel inferiori alla versione 2.6.32.
Stiamo facendo un'analisi dettagliata per adattare il compilatore alle versioni attuali del Kernel, ma non abbiamo ancora una soluzione completa.
Quindi, perchè il Kernel sia compilato correttamente dobbiamo creare una sub-istanza di LibXenon che utilizza GCC 4.4.0.
Dalla vostra home:
Codice:
git clone https://github.com/Free60Project/libxenon libxenon-gcc4.4
Questo comando clona il codice sorgente della libreria nella cartella "libxenon-gcc4.4".
Andate poi nella cartella Toolchain della libreria appena scaricata. Mi raccomando a non confondervi andando in quella della libreria originale.
Dalla vostra home:
Codice:
cd libxenon-gcc4.4/toolchain
e con il vostro editor di testo preferito, es. gedit o nano, editate lo script "build-xenon-toolchain".
Seguite alla lettera la lista delle modifiche da fare:
- Alla riga 12 sostituite: "GCC=gcc-4.6.1" con "GCC=gcc-4.4.0"
- Alle righe 7 - 37 - 57 - 58 - 59, sostituite "/usr/local/xenon" con "/usr/local/xenon_old"
Salvate ed uscite.
Perchè il compilatore GCC funzioni per LibXenon ha bisogno di essere patchato. Questo avviene anche per la compilazione della libreria LibXenon corrente, anche se non ve ne accorgete.
La patch ve la fornisco io, perchè in rete non è disponibile da nessuna parte. Rinominate l'estensione del file da ".txt" a ".diff".
La patch, dal nome "gcc-4.4.0.diff" andrà copiata nella cartella Toolchain di libxenon-gcc4.4.
Per chi adesso pensa "ora cerco il file su google", cercate di capire che i ".diff" sono specifici per architettura, versione e hardware. Il .diff per GCC per LibXenon è unico e non può essere sostituito con un altro .diff generico.
Ora, iniziate il processo di compilazione come ormai già sapete.
Dalla vostra home:
Codice:
./build-xenon-toolchain toolchain
Le fasi della compilazione sono identiche a quelle per la compilazione della libreria LibXenon originale.
***Attenzione*** Alla fine del processo di compilazione NON DOVRETE INSERIRE LE VARIABILI ALL'INTERNO DEL FILE .BASHRC anche se questo viene specificato dallo script.
Una volta finito, andate a fare la spesa:
Ecco la lista:
- Kernel Linux 2.6.38.8 ==>
Codice:
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.8.tar.xz
- File .diff per il Kernel ==>
Codice:
wget https://github.com/Free60Project/linux-kernel-xbox360/raw/master/2.6.38/patch-2.6.38.8-xbox0.11.1.diff
File .config per il Kernel ==>
Codice:
wget https://github.com/Free60Project/linux-kernel-xbox360/raw/7f1f245a7df9c10b3aafe11bd530323b4b48d33c/xenon_config
Estraete il kernel nella vostra home:
Codice:
tar Jxvf linux-2.6.38.8.tar.gz
Rinominate "xenon-config" in ".config" e copiate il file ".diff" e il file ".config" nella cartella del kernel.
Codice:
cp patch-2.6.38.8-xbox0.11.1.diff linux-2.6.38.8/patch.diff
mv xenon-config linux-2.6.38.8/.config
Codice:
cd linux-2.6.38.8
Applichiamo la patch del file .diff
Codice:
patch -p1 < patch.diff
Applichiamo il file .config al Kernel
Codice:
make CROSS_COMPILE=xenon- ARCH=powerpc oldconfig
Questo comando applica la configurazione al kernel che permette il caricamento di moduli e driver dei componenti e delle periferiche della Xbox 360.
Avete una minima idea di quanto è complicato il file testuale di configurazione del Kernel?
Volete davvero mettervi a configurare stringhe del genere?
Codice:
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_SCHED_HRTICK=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_HUGETLB_PAGE_SIZE_VARIABLE=y
CONFIG_IOMMU_HELPER=y
# CONFIG_SWIOTLB is not set
Per rendervelo più comprensibile e permettervi di avere un'interfaccia più intuitiva, soprattutto per capire cosa state configurando,
Codice:
apt-get install ncurses-dev
Al termine, sempre dalla cartella del Kernel,
Codice:
make CROSS_COMPILE=xenon- ARCH=powerpc menuconfig
Questo comando aprirà un'interfaccia grafica di configurazione del Kernel, dove i parametri di configurazione sono molto più comprensibili.
Per il momento, il mio consiglio è quello di lasciare tutto com'è e non toccare niente. Quel file di configurazione ha tutti i parametri necessari per un avvio pulito delle distribuzioni Linux.
Unica eccezione, per Ubuntu, prima di compilare il Kernel, aprite con un editor il file .config:
E cercate queste stringhe:
Codice:
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
E sostituitele con:
Codice:
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
Salvate ed uscite.
Il perchè di questa modifica lo spiegherò nella terza parte del tutorial.
Adesso, finalmente, siamo pronti alla compilazione.
Dalla cartella del kernel lanceremo il comando Make. Ma, come cross compiler invece che CROSS_COMPILE=xenon-,daremo il percorso per intero che punta al compilatore GCC 4.4.0 e non al 4.6.1 della LibXenon attuale.
Codice:
make CROSS_COMPILE=/usr/local/xenon_old/bin/xenon- ARCH=powerpc all
Ricordatevi, se avete un processore multicore, che potete velocizzare la compilazione utilizzando,dopo il make, l'opzione -j(X) dove X è il numero di core.
Verranno compilati i driver e i moduli del kernel.
Alla fine del processo di compilazione, nel percorso "linux-2.6.38.8/arch/powerpc/boot" troverete il file zImage.xenon.
Quello è il vostro sudato Kernel Linux compilato, che andrà rinominato, a vostra scelta, "vmlinux", "xenon.elf", "zImage.z".
Perchè a vostra scelta?
Perchè ciò che conta è l'intestazione del file.
Adesso bisogna compilare i moduli:
Dalla cartella del kernel:
Codice:
make CROSS_COMPILE=xenon- ARCH=powerpc INSTALL_MOD_PATH=/home/NOMEUTENTE/modules modules_install
Questo comando installa i moduli del Kernel.
I moduli sono dei driver che non vengono incorporati all'interno del kernel, ma vengono caricati dal kernel durante l'avvio del Sistema Operativo, ad esempio per rendere il kernel più leggero.
Se avete notato, alla fine della compilazione del kernel, leggete stringhe come questa:
Codice:
LD [M] drivers/scsi/scsi_wait_scan.ko
Questi sono i moduli. Il comando dato sopra crea una cartella modules con alcuni file all'interno. Per ora non toccatela. Ci servirà dopo aver installato Linux.
E con questo, anche la seconda parte è terminata. Rimane l'ultima parte dove vedremo l'installazione di Linux.
Probabilmente non la scriverò subito. A parte i miei impegni personali, siamo in fase di testing sia per gli Homebrew che per Linux quindi ho davvero poco tempo. Intanto prendete confidenza con questi comandi e questo e gli altri tutorial.
@Electron
Appena posso ti posto il login della Xbox360 con LUbuntu ^_^
Ethereal
17Likes
LinkBack URL
About LinkBacks
Rispondi Citando
Originariamente Scritto da Ethereal
dato che io odio la scrittura delle date in americano!
Segnalibri