Risuscitare un Western Digital Mybook World Edition

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.

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

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:

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.

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.

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

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.

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:

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.

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:

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.

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:

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.

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.

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.

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.

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

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.

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.

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.

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

Tutto il documento è rilasciato sotto una licenza Creative Commons.