Risuscitare un Western Digital Mybook World Edition

Prima pubblicazione 25 luglio 2007

Diario delle Revisioni
Revisione 0.0.22007-08-06MP
Versione con supporto per il Leon chip, un nuovo kernel e nuovo root filesystem
Revisione 0.0.12007-07-25MP
Prima versione

Presentazione

Qualche tempo fa un amico mi ha dato due esemplari di un piccolo NAS prodotto da Western digital, questo.

I due esemplari avevano il disco guasto, e non c'è altro modo di ripristinarli se non inviandoli al produttore. A garanzia scaduta, l'operazione è molto costosa, tanto da rendere più economico acquistarne uno nuovo.

La mia natura curiosa ha però avuto il sopravvento. Con un po' di fatica sono riuscito a ripristinare almeno le funzioni di base ed a creare un piccolo computer Linux perfettamente funzionante. Ecco come.


Sommario

1. Avvertenze
2. Lo stato iniziale.
3. Almeno una seriale!
4. Il software di base
5. Il primo bootloader
6. Il vero bootloader
7. Il supporto per il Leon
8. Il kernel
9. Ultimi aggiustamenti
10. Installazione rapida
11. Riferimenti
12. Ringraziamenti
13. Strumenti utilizzati
14. Versioni aggiornate
15. Licenza e Copyright

1. Avvertenze

Quello riportato qui è semplicemente un diario di come ho operato per riutilizzare un oggetto altrimenti destinato alla discarica. Niente di quello che c'è qui può servire a ripristinare le funzioni originali del dispositivo. Inoltre tutte le operazioni descritte hanno come risultato di invalidare una eventuale garanzia ancora valida.

Le operazioni non sono proprio alla portata di chiunque: occorre conoscenza dell'elettronica, della programmazione, degli strumenti di compilazione e creazione del software tipici del mondo Linux/Unix. Senza queste conoscenze è impossibile seguire le operazioni riportate in questo scritto. Durante la compilazione e la creazione dei tool ho incontrato numerosi problemi e innumerevoli difficoltà, che cambiano in funzione delle versioni dei software utilizzati. Mi è oggettivamente impossibile compilare una guida passo passo per ripetere tutte le operazioni, posso solo indicare come ho risolto i problemi più grandi.

Al termine delle operazioni avremo un sistema Linux funzionante, ma ridotto al minimo: kernel, shell, strumenti di sviluppo e poco altro. Ma questo dovrebbe essere sufficiente per aggiungere funzioni e applicazioni senza troppa fatica.

In ogni caso non posso fornire nessun aiuto di alcun tipo a nessuno. Per chi vuole cimentarsi, deve accontentarsi di quello che trova qui. Il motivo è semplice: non ho proprio il tempo.

In ultimo: non sono e non sarò in alcun modo responsabile di nulla. Chi decide di intervenire sul proprio Mybook™ lo fa solo ed unicamente a proprio rischio e pericolo.

2. Lo stato iniziale.

Quando mi sono giunti, i due MyBook erano completamente smontati (Figura 1, «Il MyBook»). Ovviamente i dischi erano stati tolti e cestinati, visto che erano completamente inutilizzabili.

Figura 1. Il MyBook

Il MyBook

Dopo aver rigirato fra le mani i vari pezzi, mi sono concentrato sull'elettronica. Da un breve ricerca su Google con la sigla del chip più grande, OXE800 mi ha portato sul sito del produttore e sul sito di qualcuno che aveva parzialmente modificato il MyBook, almeno nelle sue funzioni software.

Leggendo inoltre notizie frammentarie raccolte sul forum di Western Digital ho raccolto tutte le informazioni che mi servivano:

  • Processore: ARM 926 compatibile.

  • Architettura: proprietaria, con bus PCI.

  • Memoria: RAM 32M, ROM sconosciuta.

  • Controller dischi: S-ATA a due canali, dei quali solo uno utilizzato, il primo.

  • Altre porte disponibili: USB2 di tipo host

  • Sistema operativo: Linux

Dal sito del supporto di Western Digital è disponibile in download un pacchetto piuttosto consistente di sorgenti e utility per il MyBook, ma, oltre alla dimensione, 400Mbytes, non vi sono le applicazioni proprietarie di Western Digital che rendono tale il MyBook, quindi non c'è modo di ricostituire le funzioni e l'operatività originale.

Non solo: gran parte dei sorgenti necessari per la compilazione, configurati per questo oggetto, sono mancanti o forniti nella configurazione predefinita, quindi inutilizzabili.

Per arrivare ad avere almeno un nucleo funzionante, un kernel, una shell, gli strumenti per compilare nuove applicazioni, un terminale da cui impartire comandi, la lotta è stata dura. Ma andiamo con ordine.

3. Almeno una seriale!

Compiere una operazione di installazione per tentativi senza alcun canale per "vedere" cosa succede è praticamente impossibile. Il MyBook non ha niente dei soliti dispositivi di input ed output: niente video, niente tastiera e meno ancora mouse. Anche il tentativo di fare il boot da un pen drive o da un disco USB collegato alla porta è risultato infruttuoso.

Dalle specifiche del costruttore del chip principale risulta però che dovrebbe esserci una porta seriale standard inclusa nel chip stesso. Guardando attentamente il circuito stampato del MyBook si nota un gruppo di quattro piazzole a saldare con un quadrato disegnato intorno e la parola Serial accanto (Figura 2, «Un connettore seriale... forse.», cerchiato in rosso), sul bordo del circuito stampato, subito dietro al connettore USB.

Figura 2. Un connettore seriale... forse.

Un connettore seriale... forse.

Il problema rimane come identificare i vari pin. Con un tester intanto possiamo definire che il pin 1 è quello dell'alimentazione a 3,3V, mentre il pin 2 è la massa. Rimangono il 3 ed il 4. Ho smontato e rimaneggiato un cavo di connessione per cellulari di tipo USB, come suggerito qui, ed andando a tentativi ho trovato che il pin 3 è RxD (ricezione dati, dal computer al MyBook), mentre il pin 4 è TxD (trasmissione dati, dal mybook al computer).

Per comunicare in modo semplice e veloce ho usato l'utility cu, che in Fedora Linux è compresa nel pacchetto uucp, che non è installato di default. La linea seriale è a 115200 bps, 8 bit, no parità, quindi il comando di avvio di cu sarà:

$ cu -l /dev/ttyUSB0 -s 115200

Attenzione, la seriale è a 3,3V

Le tensioni utilizzate dalla porta seriale non sono quelle standard, ma vanno da 0 a 3,3V, quindi occorre un adattatore. Nel mio caso il cavo USB era per un cellulare che aveva proprio questo tipo di seriale, quindi l'unico lavoro è stato quello di identificare i pin sia del cavo che del MyBook. Il cavo era per un cellulare Ericsson R300/T28, equivalente al cavo originale DCU-10/DCU-11.

In ogni caso, accendendo il MyBook con il cavo collegato non si ottiene nessuna reazione, indice che non esiste alcun tipo di monitor o di BIOS nella ROM.

4. Il software di base

Scompattando i sorgenti forniti da Western Digital si ottiene questo albero di directory:

$ ls
buildroot-patches
crosstool-patches
gpl-buildroot-archives.tar
gpl-crosstool-archives.tar
gpl-leon-archives.tar
leon
stage1
vendor

Per quanto riguarda i vari pezzi:

  • buildroot è un ambiente per la creazione di un root filesystem da zero, con il supporto per la compilazione cross. Qui servirà per creare il filesystem root con tutto il necessario per il funzionamento: lo scheletro delle directory, i tool per la compilazione e tutto quanto serve, per l'uso con il processore del MyBook che, lo ricordiamo, è un ARM.

  • crosstool è un altro ambiente per la creazione degli strumenti di sviluppo in modalità cross, ossia creare eseguibili per un processore/architettura X su un processore/architettura Y. Non l'ho usato per questa operazione.

  • leon è una implementazione di un processore con architettura SPARC, a quanto pare utilizzato in qualche versione del MyBook come acceleratore di rete, ma non ne sono sicuro. Il MyBook funziona perfettamente senza questa parte di software.

  • stage1 è la collezione di sorgenti per creare la prima parte del bootloader. Occorre però prima creare il compilatore GCC per ARM, e la libreria di base.

  • vendor contiene due directory: linux-kernel e u-boot. La prima contiene un sorgente completo del kernel 2.6.17 con aggiunto tutto il necessario per l'architettura del MyBook, mentre la seconda contiene il bootloader U-Boot, pensato anche per piccoli dispositivi embedded.

Useremo il kernel, la prima parte del bootloader in stage1, il bootloader U-Boot e Buildroot per creare gli strumenti di sviluppo cross e l'ambiente di root iniziale. Opzionalmente possiamo includere il supporto per il Leon chip (Sezione 7, «Il supporto per il Leon»).

L'ambiente utilizzato da me è Linux Fedora 7.

5. Il primo bootloader

Dobbiamo per prima cosa costruire il bootloader iniziale, contenuto in stage1. Ma ci occorrono gli strumenti per compilare codice per il processore ARM. Non solo, occorrono dati specifici sull'architettura del MyBook, che non abbiamo: indirizzi e tipo delle periferiche, mappa della memoria, ecc.

Scompattiamo il pacchetto gpl-buildroot-archives.tar, dal quale prendiamo il file buildroot-20060823.tar.bz2 e lo scompattiamo dove ci fa comodo.

La directory buildroot-patches contiene le variazioni specifiche per il MyBook originale, ma come abbiamo detto, non sarà possibile ripristinare le funzioni originali. Di tutte queste solo alcuni file possono essere utili, come ad esempio quelli in buildroot-patches/target/generic/, che rappresentano uno scheletro di base per il root filesystem del MyBook: da questo possiamo prendere alcuni file che ci possono servire, come inittab o fstab.

Possiamo anche copiare tutto il contenuto di buildroot-patches in buildroot appena scompattato, ed avere più o meno lo stesso ambiente di base del MyBook. Non è fondamentale e funziona lo stesso, anche perché molte delle applicazioni originali del MyBook non sono disponibili.

Per avere tutti i tool di sviluppo pronti per ARM, andiamo nella directory buildroot e lanciamo il comando make menuconfig, allo stesso modo in cui si fa con i sorgenti del kernel per configurarli. Il menù che appare consente di scegliere la configurazione degli strumenti di sviluppo e del filesystem di root che andremo a creare. La configurazione che ho usato io è in questo file.

Per abbreviare il processo di compilazione, conviene copiare tutti i file in buildroot-archives nella directory buildroot/dl, evitando che vengano cercati e scaricati da Internet i pacchetti necessari, anche se alcuni vengono comunque cercati, ad esempio findutils, sysklogd e sysvinit.

I tool di sviluppo comprendono il GCC, il pacchetto binutils e la libreria uClibc, una versione "leggera" della glibc, pensata per sistemi di tipi embedded con poche risorse.

Nel momento in cui andiamo a dare il via alla preparazione con il comando make da dentro la directory buildroot, ci vengono chiesti alcuni dettagli sulla configurazione della libreria uClibc, in particolare, dato che la CPU del MyBook non ha supporto hardware per i calcoli in virgola mobile, alla domanda:

Target CPU has a floating point unit (FPU) (HAS_FPU) [Y/n/?] (NEW)

risponderemo n. A tutte le altre domande possiamo rispondere con un Invio, e scegliere la risposta predefinita. Fatto questo la compilazione procede fino al termine senza intoppi.

A questo punto dovremmo avere tutte le utility di sviluppo compilate per generare e manipolare codice per il processore ARM. Sono tutte nella directory buildroot/build_arm_nofpu/staging_dir/bin. Questa directory deve essere inserita nella variabile d'ambiente PATH per avere disponibili tutti i tool necessari.

Possiamo andare dentro la directory stage1 e cominciare ad operare. Per prima cosa apriamo il Makefile ed alla riga 15:

CROSS_COMPILE ?= arm-linux-gnu-

cambiamo in:

CROSS_COMPILE ?= arm-linux-

in modo da indicare il giusto nome dei tool di sviluppo che abbiamo appena creato.

Possiamo dare il comando make ed in breve tempo avremo un file dal nome stage1.bin, mentre nella directory stage1/tools avremo un paio di programmi che ci tornano utili nel seguito.

Il file appena creato è il bootloader detto appunto "Stage 1", che si occupa di fare le minime impostazioni al computer e poi caricare il bootloader vero (detto di "Stage 2") e cedergli il controllo.

La versione da me compilata del bootloader è qui, per chi non volesse fare tutta la trafila.

Rimane da installare il bootloader di "Stage 1". Io ho usato un box esterno USB2 per dischi S-ATA, dentro cui ho infilato un disco da 250G. Una volta connesso al computer possiamo partizionare il disco e prepararlo per l'installazione. Ovviamente tutto questo deve essere fatto dal computer in cui stiamo preparando tutto l'ambiente.

Il bootloader deve essere caricato nel settore assoluto 1 del disco, ossia subito dopo il Master Boot Record, che deve anche essere preparato con le partizioni e modificato per indicare la presenza del bootloader.

Dobbiamo quindi eseguire questi passi:

  1. Dopo aver connesso il disco S-ATA al computer, dobbiamo creare le partizioni necessarie al nostro MyBook. Come primo esperimento possiamo creare solo due partizioni, una per il filesystem di root ed una per lo swap. Unica accortezza: la prima partizione deve iniziare dopo un certo numero di settori assoluti, almeno un migliaio, e deve essere una partizione con filesystem ext2 o meglio ext3. Per esempio possiamo farla partire dal secondo cilindro, invece che dal primo: questo spazio ci serve per il bootloader vero, che sarà inserito nello spazio dopo il primo bootloader a partire dal settore assoluto numero 64, e deve avere lo spazio necessario senza andare a toccare l'inizio della prima partizione. In realtà a U-Boot servono circa 200 settori, ma è meglio non essere troppo tirati con lo spazio.

  2. Con le partizioni pronte, andiamo a leggere il MBR del disco e lo mettiamo su un file a piacere (supponendo che il disco esterno S-ATA sia /dev/sdb):

    # dd if=/dev/sdb of=mbr bs=512 count=1

  3. Su questo file usiamo il programma stage1/tools/installer, che modifica il MBR per fargli caricare il primo bootloader:

    # stage1/tools/installer mbr

  4. Rimettiamo a posto il MBR con le modifiche:

    # dd if=mbr of=/dev/sdb bs=512 count=1

  5. Possiamo ora installare il bootloader di Stage 1:

    # dd if=stage1.bin of=/dev/sdb bs=512 seek=1

Arrivati qui se abbiamo il cavetto console (Sezione 3, «Almeno una seriale!») possiamo fare un semplice test di funzionamento del bootloader. Colleghiamo il disco al MyBook, il cavetto seriale al computer e lanciamo l'utility cu. Poi diamo alimentazione al MyBook. Deve comparire dopo qualche secondo la scritta: NASOx_0 Sbirciando nel sorgente in stage1/src/stage1.c possiamo capire cosa significano lettere e numeri. Ad esempio il carattere 'X' (lettera x maiuscola) significa errore in accesso al disco.

6. Il vero bootloader

Passiamo ora alla compilazione di U-Boot. Occorre modificare il Makefile in vendor/u-boot/ cancellando al riga 130, da così:

# The "tools" are needed early, so put this first
# Don't include stuff already done in $(LIBS)
SUBDIRS	= tools \
	  examples \
	  post \
	  post/cpu

a così:

# The "tools" are needed early, so put this first
# Don't include stuff already done in $(LIBS)
SUBDIRS	= tools \
	  post \
	  post/cpu

dato che viene restituito un errore nella compilazione degli esempi, che a noi non servono. Poi occorre configurare il bootloader prima di compilarlo. Il file da modificare è vendor/u-boot/include/configs/oxnas.h, e per fare le cose semplici ho creato una patch. Una volta applicata la patch possiamo andare a vedere il contenuto del file, di cui ci interessano in particolare queste due righe (la 243 e la 244 dopo l'applicazione della patch):

#define CONFIG_BOOTARGS "mem=32M console=ttyS0,115200 root=/dev/sda1 netdev=0,0,0x0030e000,0x0001,eth0 elevator=cfq"
#define CONFIG_BOOTCOMMAND "ext2load ide 0:1 0x48500000 /uImage ; bootm 0x48500000"	

La prima contiene la riga di comando che verrà passata al kernel al momento del boot, mentre la seconda contiene il comando di caricamento del kernel e quello di avvio del kernel stesso.

Il terzo e quarto parametro nella variabile netdev sono il MAC address della interfaccia ethernet. Il contenuto di CONFIG_BOOTCOMMAND si può spiegare in questo modo:

  • ext2load indica che deve essere caricato un file da una partizione di tipo ext2/ext3. Cioè il bootloader U-Boot si comporta come GRUB, accedendo alla partizione che contiene il kernel per caricarlo da un normale file. Questa sarà una grande comodità nel seguito quando vorremo sperimentare diverse configurazioni del kernel.

  • ide indica al loader che deve accedere ad un disco IDE/S-ATA

  • 0:1 indica disco:partizione, ossia primo disco, prima partizione. E' quindi evidente che la partizione che contiene il kernel dovrà essere la prima del disco. Se vogliamo usare un diverso schema di partizionamento dobbiamo di conseguenza cambiare questi valori.

  • 0x48500000 è la zona di memoria dove caricare l'immagine compressa del kernel. Conviene lasciarla così.

  • /uImage è il pathname completo del file immagine del kernel. Deve contenere anche il path completo. In questo caso sarà un file dal nome uImage nella root della prima partizione del disco. Ovviamente è case sensitive.

Il successivo comando bootm indica di passare ad eseguire quello che ha appena caricato dal disco. Se tutto è in ordine in quel momento dovremmo veder avviarsi il kernel. Ma manca ancora qualche passo.

Prima di partire con la compilazione occorre configurare U-Boot per il MyBook, con questo comando:

$ make oxnas_config
Configuring for oxnas board...

Poi possiamo avviare il make. Se si ferma immediatamente con un errore lamentando la mancanza del compilatore arm-linux-gcc dobbiamo inserirlo nella variabile PATH come detto in precedenza.

Al termine avremo un file dal nome u-boot.bin. Come detto in precedenza, questo è il bootloader di second stage che si occupa di caricare e mandare in esecuzione il vero kernel. Ora va scritto sul disco, ma prima occorre modificarlo con un header che contiene un checksum, verificato dal bootloader di stage 1. Senza questo checksum il bootloader stage 1 si rifiuta di passare il controllo al bootloader second stage. Serve un programma nel pacchetto stage1, in particolare stage1/tools/packager, usato in questo modo:

$ stage1/tools/packager vendor/u-boot/u-boot.bin u-boot.img
Input file - vendor/u-boot/u-boot.bin
Output file - u-boot.img
Input File Size - 95832

che prepara appunto questo header e scrive un nuovo file dal nome u-boot.img, pronto per essere trasferito sul disco:

# dd if=u-boot.img of=/dev/sdb bs=512 seek=64

a partire dal settore assoluto 64.

Fatto questo siamo pronti per una seconda verifica, se abbiamo il cavo seriale a disposizione. Collegando il disco e alimentando il MyBook dovremmo vedere qualcosa del genere:

NASOx_0800
dom lug 15 00:29:51 CEST 2007


U-Boot 1.1.2 (Jul 15 2007 - 19:41:08)

U-Boot code: 48D00000 -> 48D17658  BSS: -> 48D1B2C8
RAM Configuration:
Bank #0: 48000000 32 MB
*** Warning - bad CRC, using default environment

Boot reached stage -1
In:    serial
Out:   serial
Err:   serial
Initialising disks
No FIS received from device 1
Detecting SATA busses:
Bus 0: Found first device OK
  Device 0: Model: Maxtor 6V300F0 Firm: VA111630 Ser#: V60EWCCG
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 286188.8 MB = 279.4 GB (586114704 x 512)
  Device 1: not available

IDE read: device 0 block # 63, count 1 ... 1 blocks read: OK
Hit any key to stop autoboot:  1 

indice che entrambi i bootloader funzionano. Per quanto riguarda U-Boot, durante il conteggio si può interrompere premendo un tasto e si ha a disposizione una shell limitata per impartire comandi al bootloader, esattamente come in GRUB.

La mia versione precompilata di U-Boot, con le opzioni mostrate, è qui.

7. Il supporto per il Leon

Il supporto per questa parte è opzionale, dato che il MyBook funziona anche senza. Scompattiamo il file gpl-leon-archives.tar, ed otteniamo una directory dal nome leon-archives con dentro quattro file. Poi andiamo nella directory leon/toolchain/src. Dentro vi sono quattro directory, corrispondenti ai pacchetti in leon-archives. Possiamo ignorare il gdb, e concentrarci sugli altri tre. Vanno scompattati ognuno nella propria directory, lasciando le directory come sono, ad esempio per binutils, andiamo nella directory binutils e scompattiamo lì il pacchetto binutils-2.16.1.tar.bz2, ottenendo un percorso in questo modo: toolchain/src/binutils/binutils-2.16.1/.

Poi torniamo nella directory toolchain e lanciamo il make, che terminerà dopo un po' di tempo, venti minuti circa, con un errore perché non trova i sorgent idi gdb, ma lo possiamo ignorare.

Aggiungiamo al PATH il percorso assoluto fino alla directory leon/toolchain/install/gcc-3.4.6/i686-pc-linux/bin/ per avere disponibili gli strumenti di compilazione, che stavolta sono per architettura SPARC.

Fatto questo possiamo tornare alla directory leon e lanciare prima il make, seguito dal comando make -f power-button.mk. Questo produrrà vari file, ma il risultato che ci interessa sarà di posizionare due file nell'albero dei sorgenti del kernel, leon-program.h e leon-power-button-prog.h. Al momento della compilazione del kernel possiamo lasciare abilitato il supporto per il chip Leon. Il resto viene fatto durante la compilazione del kernel stesso.

8. Il kernel

Ora siamo pronti per creare il kernel adatto. I sorgenti sono in vendor/linux-kernel ed hanno già una serie di patch e modifiche per poter compilare specificamente per il MyBook. Occorre prima controllare che i tool di sviluppo siano nel PATH, ed occorre aggiungere un percorso in più, alla directory vendor/u-boot/tools/, necessario per l'utility mkimage che sarà utilizzata per creare l'immagine kernel compatibile con U-Boot. Dopo aver inserito nel PATH i due percorsi, possiamo dare il primo comando:

$ make CROSS_COMPILE=arm-linux- oxnas_wd2nc_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
...
... molte altre righe
...
*
* Library routines
*
CRC-CCITT functions (CRC_CCITT) [Y/?] y
CRC16 functions (CRC16) [N/m/y/?] n
CRC32 functions (CRC32) [Y/?] y
CRC32c (Castagnoli, et al) Cyclic Redundancy-Check (LIBCRC32C) [N/m/y/?] n

che prepara una configurazione minima del kernel per il MyBook. Mancano molte cose, e se sappiamo dove mettere le mani possiamo aggiungerle chiamando come di consueto:

$ make CROSS_COMPILE=arm-linux- menuconfig

e variando le voci che ci interessano. Se non abbiamo compilato il necessario per il Leon chip (Sezione 7, «Il supporto per il Leon») dobbiamo usare il menù per togliere una opzione che impedisce la compilazione, in System Type, Oxford Semiconductor NAS Options, togliere del tutto la voce Include support for Leon. Altrimenti possiamo passare direttamente alla compilazione.

Di seguito possiamo partire con la compilazione con il comando:

$ make CROSS_COMPILE=arm-linux- uImage
...
... molte altre righe
...
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-2.6.17.14
Created:      Tue Jul 24 15:24:09 2007
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1215572 Bytes = 1187.08 kB = 1.16 MB
Load Address: 0x48008000
Entry Point:  0x48008000
  Image arch/arm/boot/uImage is ready

dove il target uImage serve a creare una immagine compatibile con U-Boot. Al termine della fase avremo nella directory linux-kernel/arch/arm/boot/ un file dal nome uImage.

Poi passiamo a compilare i moduli:

$ make CROSS_COMPILE=arm-linux- modules

e poi installarli nel filesystem di root in preparazione con Buildroot posizionato nella directory buildroot/build_arm_nofpu/root/ con il comando:

$ make CROSS_COMPILE=arm-linux- \
> INSTALL_MOD_PATH=../../buildroot/build_arm_nofpu/root/ modules_install

Nella stessa directory possiamo posizionare l'immagine U-Boot del kernel appena creata. Siamo quasi al termine.

9. Ultimi aggiustamenti

Ora abbiamo: bootloader (first e second stage), kernel, moduli. Manca il root filesystem con il minimo per il funzionamento.

Andiamo nella directory buildroot-patches/target/generic/, e copiamo il file device_table.txt nella directory buildroot/target/generic/. Questa è la tabella dei device e dei file associati che Buildroot crea nel filesystem di root che useremo nel MyBook. Dovrebbe essere la configurazione usata per il MyBook, ed è possibile modificarla a piacere, le istruzioni di funzionamento sono in testa al file.

Poi possiamo prendere i due file inittab e fstab e copiarli nella directory buildroot/build_arm_nofpu/root/etc/. Sono rispettivamente lo script di init del sistema e la tabella dei filesystem. Possiamo adattarli alle nostre esigenze, ed ovviamente occorre sapere dove e come mettere le mani. Il formato e la sintassi sono quelle degli equivalenti file di qualsiasi distribuzione Linux, con le debite variazioni. Inoltre in inittab è aggiunta una riga per avere un terminale sulla seriale, questa:

tty1:12345:respawn:/sbin/getty -L ttyS0 115200 vt100

altrimenti non abbiamo di che comunicare con il sistema installato.

Possiamo tornare nella directory di Buildroot e ridare il comando:

$ make

per ricreare il nuovo filesystem di root con dentro kernel, moduli e device corretti. Al termine nella directory buildroot avremo un file dal nome rootfs.arm_nofpu.tar che contiene il nostro filesystem di root pronto per l'uso. La versione compilata da me è qui (11Mbytes circa).

Usando il box esterno per dischi S-ATA, trasferiamo il filesystem di root nella partizione ext3 che sarà quella di root del nuovo sistema, ovviamente scompattandolo in loco. Siamo pronti per il lancio.

Con il cavo seriale collegato accendiamo il MyBook. Entro poco tempo dovremmo avere un prompt di login. L'utente è root, senza password.

Il sistema così ottenuto è veramente minimo. Non abbiamo supporto di rete, e molte delle utility e applicazioni non sono presenti. Ma la procedura è la stessa vista fino ad ora: adesso possiamo sperimentare con varie configurazioni di kernel e di Buildroot.

10. Installazione rapida

Per chi non ha tempo di seguire tutta la procedura e vuole usare i pacchetti precompilati, la procedura è questa:

  • Prelevare i pacchetti da qui. Occorre: l'utility installer per preparare il MBR modificato, il bootloader di stage 1 stage1.bin, il bootloader U-Boot già pronto con l'header ed il checksum u-boot.img ed una immagine del filesystem di root.

  • Collegare il disco del MyBook al computer e creare le partizioni. Lo schema consigliato è: partizione di root, a partire dal secondo cilindro, dimensione 3-5Gbyte, una partizine di swap da 100Mbytes ed il resto del disco in una partizione che verrà montata come /home.

    Nel mio esemplare la tabella delle partizioni è la seguente:

    /dev/sda1               4         487     3887730   83  Linux
    /dev/sda2             488         500      104422+  82  Linux swap / Solaris
    /dev/sda3             501       36483   289033447+  83  Linux
    

    con un disco da 300Gbyte.

  • Dopo aver partizionato il disco, prelevarne il MBR (supponendo che il disco esterno S-ATA sia /dev/sdb):

    # dd if=/dev/sdb of=mbr bs=512 count=1

    modificarlo con l'utility installer:

    # ./installer mbr

    Rimettiamo a posto il MBR con le modifiche (supponendo che il disco sia sempre /dev/sdb):

    # dd if=mbr of=/dev/sdb bs=512 count=1

    Possiamo ora installare il bootloader di Stage 1:

    # dd if=stage1.bin of=/dev/sdb bs=512 seek=1

    e di seguito il bootloader di second stage:

    # dd if=u-boot.img of=/dev/sdb bs=512 seek=64

  • Possiamo ora formattare le tre partizioni: la prima e la terza con i comandi:

    # mkfs -j /dev/sdb1

    e

    # mkfs -j /dev/sdb3

    mentre la partizione di swap va formattata con il comando:

    # mkswap /dev/sdb2

    Questi passi non devono essere ripetuti se si continua ad usare lo stesso schema di partizioni. Se dobbiamo aggiornare il filesystem di root, è sufficiente cancellare il contenuto delle partizioni e proseguire dal passo successivo.

  • Possiamo montare la partizione di root del MyBook, e scompattarci il nuovo filesystem di root, che preleveremo da qui. Il comando è:

    # tar xzf rootfs.arm_nofpu-DATA.tar.gz

    dalla directory principale del disco montato, ossia se il disco è stato montato in /media/mybook il comando deve essere dato dentro questa directory. Automaticamente viene installato il nuovo kernel, i moduli, gli script di avvio e tutte le applicazioni.

  • Fatto. Possiamo scollegare il disco, dopo averlo smontato, e ricollegarlo al MyBook. Entro un paio di minuti (la prima accensione impiega più tempo per via della generazione delle chiavi crittografiche per SSH) dall'accensione dovremmo potervi accedere via telnet o via SSH.

Nelle immagini di filesystem esistono sempre e solo due utenti configurati: root con password mybook e default senza password. Con l'utente root non si può accedere via telnet, ma basta accedere con l'utente default e poi usare il comando su - per diventare root. L'utente default non può accedere via SSH perché ha password vuota. Basta assegnarne una e potrà accedere via SSH.

11. Riferimenti

12. Ringraziamenti

Un sentito ringraziamento a mia moglie, che tollera le ore passate dal sottoscritto al computer, e che per fortuna non si occupa di informatica.

Senza l'ottimo lavoro fatto dal team di sviluppo di Fedora (http://fedoraproject.org/wiki/), la mia distribuzione Linux di riferimento, questo documento non avrebbe potuto vedere la luce. Ovviamente la stessa gratitudine va agli innumerevoli individui che contribuiscono alla realizzazione di tutto il software Open Source che costituisce il corpo del sistema operativo Linux e il suo contorno di applicazioni adatte a tutte le esigenze.

Un grazie, si fa per dire, alla programmazione televisiva, in virtù della quale ho recuperato tante ore che passo in modi più piacevoli e costruttivi, almeno per me.

13. Strumenti utilizzati

Per realizzare questo documento ho usato l'ambiente di creazione ed elaborazione testi di Fedora, aderente allo standard aperto DocBook XML, disponibile sul sito http://www.docbook.org/tdg/en/html/docbook.html. Il file XML sorgente di questo documento è stato realizzato con VIM, usando un file di personalizzazione dei comandi per velocizzare la digitazione dei tag più usati.

14. Versioni aggiornate

Versioni aggiornate di questo documento le potete trovare sul mio sito web: http://ismprofessional.net/pascucci, insieme a molto altro.

15. Licenza e Copyright

Tutto il documento è rilasciato sotto una licenza Creative Commons.