Manuale Gentoo Embedded

Indice:

• Argomenti Generali
  I concetti del mondo Embedded: da conoscere prima di metter mano all'hardware.
  1. Introduzione
     Un'introduzione al mondo embedded, ai cross-compilatori e ai draghi.
  2. Creare un Cross-Compilatore
     Creare un cross-compilatore sulla propria macchina!
  3. Cross-Compilare con Portage
     Usare Portage come Cross-Compilatore e Gestore di pacchetti.
  4. Cross-Compilare il Kernel
     Cross-compilare con successo un kernel per il proprio sistema!
  5. Compilare in chroot con qemu-user
     Come compilare con QEMU user.
  6. FAQ - Domande Poste Frequentemente
     FAQ - Domande Poste Frequentemente al progetto Gentoo Embedded.
• Emulatori
  Gli emulatori spesso sono validi come (o più) dell'hardware stesso.
  1. Qemu
     Un emulatore e virtualizzatore di architetture generico e open source per x86, x86_64, arm, sparc, powerpc, mips, m68k (coldfire), e superh.
  2. SkyEye
     Simulatore di hardware ARM embedded
  3. Armulator
     Emula armnommu/uClinux (Linux senza mmu) in un ambiente GDB.
  4. Softgun
     Emulatore software ARM.
  5. Hercules
     Hercules è un emulatore per mainframe System/370, ESA/390 e z/Architecture.
• I Bootloader
  Dall'oscuro all'osceno, si parlerà di alcuni tra i più comuni bootloader in circolazione e di come utilizzarli per la prima volta.
  1. Das U-Boot
     Il Bootloader Universale che supporta ogni architettura embedded esistente.
  2. NeTTrom
     Semplice bootloader per NetWinders.
  3. RedBoot
     Bootloader di ridotte dimensioni basato su eCos che supporta tutte le architetture embedded esistenti.
  4. SH-LILO
     Porting di LILO sull'architettura SuperH, sulla quale è molto diffuso.
• Schede
  Alcune schede danno subito soddisfazioni mentre altre rischiano di essere una valle di lacrime; verranno qui illustrati i problemi più comuni che si possono incontrare con alcuni tra i sistemi presenti sul mercato.
  1. Hammer/Nailboard
     Scheda arm4vl little-endian.
  2. LANTank
     NAS prodotto da I-O Data (dotato di interfaccia IDE interna) basato su un'architettura SuperH little-endian.
  3. NetWinder
     Network server prodotto da Rebel, basato su un'architettura ARMv4 little-endian.
  4. NSLU2
     NAS prodotto da Linksys (dotato di interfaccia USB) basato su un'architettura arm big-endian.
  5. QNAP TurboStation 109/209/409
     NAS ARMv5TE Little-endian da QNAP.
  6. Marvell Sheevaplug
     Scheda ARMv5TE Little-endian da Marvell.
  7. ACME SYSTEMS Netus G20
     Netus G20 (ARMv5TE) da ACME SYSTEMS.
  8. Genesi Efika MX
     Scheda ARMv7-A Little-endian di Genesi USA.
  9. Pandaboard
     Little-endian ARMv7-A da pandaboard.org.
  10. Trimslice
      Little-endian ARMv7-A di Compulab/trimslice.com.
  11. Beaglebone
      Little-endian ARMv7-A di Beagleboard.org.
• Ulteriori Sviluppi
  Questo manuale si ferma qui, vengono comunque elencate queste risorse, utili per realizzare i progetti che si ha in mente.
  1. Contatti
     I canali di comunicazione con il progetto Gentoo Embedded.
  2. Come Contribuire
     Gentoo Embedded e voi: la risposta alla domanda frequente "Cosa posso fare io?".
  3. Produttori di Hardware
     Informazioni specifiche per i produttori che desiderano dare una mano.
  4. Ampliare le proprie Conoscenze
     Ulteriore documentazione per aumentare la propria conoscenza sul mondo Linux Embedded.

A. Argomenti Generali

1. Introduzione

1.a. Preludio

Il cross development, sviluppare cioè su una piattaforma per eseguire ciò che è stato generato su di un'altra, è solitamente considerata un'arte oscura, che richiede molte ricerche, fatta di tentativi ed errori, alla cui base c'è la perseveranza. Gli intrepidi sviluppatori devono affrontare la carenza di documentazione e la mancanza di toolkit open source maturi e completi per lo sviluppo multi piattaforma. Il lavoro portato avanti dal Progetto Gentoo Embedded, dal Gruppo Gentoo Toolchain e da altri partecipanti ha prodotto e continua a migliorare un ambiente di sviluppo basato su Gentoo che semplifica notevolmente il cross sviluppo.

1.b. La Toolchain

Il termine "toolchain" si riferisce all'insieme dei pacchetti usati per creare un sistema (i "tool", ossia gli strumenti, che sono usati nella catena, "chain", di eventi composta dal prendere dati input e generare dati in output ). E' una definizione imprecisa se si guarda a quali pacchetti nello specifico sono considerati parte della toolchain, ma al fine di semplificare il concetto, si considerano tutti quei componenti necessari a compilare del codice in qualcosa di divertente e utilizzabile.

La toolchain è composta dai seguenti elementi:

• binutils - Strumenti essenziali per la manipolazione di binari (include l'assembler ed il linker)
• gcc - La Collezione di Compilatori GNU (il compilatore C e C++)
• glibc o uclibc o newlib - La libreria C di sistema
• linux-headers - Gli header del Kernel necessari alla libreria C di sistema
• gdb - Il debugger GNU

Tutti i sistemi Gentoo correttamente configurati hanno installata una toolchain come parte del sistema base. Tale toolchain è configurata per generare binari per la medesima piattaforma dove è installata.

Per generare binari su un sistema e far sì che essi possano essere eseguiti su una diversa piattaforma, si avrà bisogno di una toolchain speciale - una cosiddetta cross toolchain - specifica per la piattaforma di destinazione. Gentoo mette a disposizione per questo scopo un semplice ma potente strumento chiamato crossdev. Crossdev può generare e installare sul sistema un numero arbitrario di cross toolchain, purché supportate dal GCC. Dal momento che Gentoo installa tutti i file delle toolchain in directory specifiche per ogni architettura, tali toolchain non interferiranno con quella nativa di sistema.

1.c. Variabili d'Ambiente

Alcune variabili d'ambiente usate dalla toolchain di Gentoo e da Portage possono confondere sviluppatori non esperti di cross development. La seguente tabella spiega alcune di queste ingannevoli variabili e fornisce dei valori tipo, basati sugli esempi di cross development presentati in questa guida. Vedere Ulteriori Terminologie e Variabili per altre variabili insolite e relativi concetti.

Se, ad esempio, si avesse un desktop AMD64 con Gentoo e si desiderasse sviluppare qualcosa per il proprio PDA, architettura ARM, la tabella illustrata sopra apparirebbe così:

1.d. Ulteriori Terminologie e Variabili

canadian cross

Il processo di generare un cross-compilatore che funzionerà su una piattaforma differente da quella dove è stato compilato (CBUILD != CHOST && CHOST != CTARGET)

sysroot: system root

La directory dove il compilatore cercherà i proprio header standard e le proprie librerie

hardfloat

Il Sistema ha un'Unità a Virgola Mobile (Floating Point Unit (FPU)) per gestire calcoli matematici a virgola mobile

softfloat

Il Sistema non è dotato di una FPU hardware, perciò tutte le operazioni a virgola mobile sono approssimate in virgola fissa

PIE

Position Independent Executable (-fPIE -pie)

PIC

Position Independent Code (-fPIC)

CRT

C RunTime

Tuple

Per crossdev, è definito come una stringa nel formato ARCH-VENDOR-OS-LIBC. Vedere crossdev -t help per informarsi precise su come questa stringa può essere completata.

2. Creare un Cross-Compilatore

2.a. Prologo

La prima cosa da sapere sulla creazione di una toolchain è che certe versioni di alcuni suoi componenti non funzionano assieme. Sapere quali siano le esatte combinazioni problematiche è un dato che è in costante mutamento a seconda di come si sviluppa l'albero di portage. L'unico modo sicuro per determinare se una certa combinazione funziona è eseguire crossdev, specificando le versioni dei vari componenti secondo necessità, finché non viene completata con successo la compilazione dell'intera toolchain. Anche a quel punto, la cross toolchain potrebbe generare binari non funzionanti sul sistema di destinazione. Solo avendo pazienza e procedendo per tentativi ed errori si potrà ottenere una combinazione favorevole di tutti i fattori.

Tutti i pacchetti della toolchain sono pensati in modo tale da esser totalmente isolati in base all'architettura di destinazione, per cui non c'è modo che interferiscano con l'ambiente nativo di compilazione. Questo permette di installare cross-compilatori per qualunque architettura si desideri senza intaccare il resto del sistema.

Tuttavia, ci sono alcuni scenari, anche se in diminuzione ogni giorno che passa, che fanno sì che portage richieda o influenzi dei cambiamenti alla root reale. Per mantenere pulita la propria installazione di Gentoo, si raccomanda caldamente che l'installazione di crossdev e tutte le attività di cross-compilazione avvengano dentro ad un chroot di uno stage3 di Gentoo. (È lo stesso chroot usato per installare Gentoo.)

2.b. crossdev

Introduzione

Generare a mano un cross-compilatore era un processo lungo e tedioso. Per questo è stato integrato totalmente in Gentoo! Tramite un'interfaccia chiamata crossdev (installabile con emerge crossdev) emerge verrà eseguito con tutte le variabili d'ambiente valorizzate correttamente ed installerà tutti i pacchetti corretti per generare qualunque tipo di cross-compilatore di cui si ha bisogno. Per prima cosa bisogna installare crossdev.

# emerge crossdev

È consigliabile installare la versione instabile (~arch) di crossdev per ottenere tutte le più recenti correzioni.

In questo documento verrà coperto solamente l'utilizzo basilare di crossdev, tuttavia questo strumento può personalizzare adeguatamente il processo per la maggior parte delle necessità. Eseguire crossdev --help per ottenere alcune indicazioni su come usare crossdev. Ecco alcune delle modalità d'uso più comuni:

(Usare delle versioni specifiche dei pacchetti)
# crossdev --g [gcc version] --l [(g)libc version] --b [binutils version] --k
[kernel headers version] -P -v -t [tuple]
(Usare solamente la versione stabile)
# crossdev -S -P -v -t [tuple]

Installazione

Il primo passo consiste nel selezionare la corretta stringa per il sistema di destinazione. Prendiamo ad esempio che si voglia generare un cross-compilatore per il processore SH4 (SuperH) con supporto alle glibc per Sistema Operativo Linux. Il tutto partendo da una macchina PowerPC.

# crossdev --target sh4-unknown-linux-gnu
-----------------------------------------------------------------------------------------------------
 * Host Portage ARCH:     ppc
 * Target Portage ARCH:   sh
 * Target System:         sh4-unknown-linux-gnu
 * Stage:                 4 (C/C++ compiler)

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               linux-headers-[latest]
 * libc:                  glibc-[latest]

 * PORTDIR_OVERLAY:       /usr/local/portage
 * PORT_LOGDIR:           /var/log/portage
 * PKGDIR:                /usr/portage/packages/powerpc-unknown-linux-gnu/cross/sh4-unknown-linux-gnu
 * PORTAGE_TMPDIR:        /var/tmp/cross/sh4-unknown-linux-gnu
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _
 * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ...                          [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-binutils.log
 * Emerging cross-binutils ...                                                                 [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...                                                               [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-linux-headers.log
 * Emerging cross-linux-headers ...                                                            [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-glibc.log
 * Emerging cross-glibc ...                                                                    [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage2.log
 * Emerging cross-gcc-stage2 ...                                                               [ ok ]

Test Veloce

Se tutto è andato come previsto, si dovrebbe avere un compilatore nuovo fiammante sulla propria macchina. Facciamo una prova!

$ sh4-unknown-linux-gnu-gcc --version
sh4-unknown-linux-gnu-gcc (GCC) 4.2.0 (Gentoo 4.2.0 p1.4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ echo 'int main(){return 0;}' > sh4-test.c
$ sh4-unknown-linux-gnu-gcc -Wall sh4-test.c -o sh4-test
$ file sh4-test
sh4-test: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

Se il comando crossdev fallisse, saranno comunque a disposizione i log per analizzare il problema che si è verificato. Se non si è in grado di risolvere il problema, aprite pure un bug sul bugzilla di Gentoo. Per maggiori informazioni visitare la pagina dei Contatti.

Disinstallazione

Per disinstallare una toolchain, è sufficiente usare l'opzione --clean. Se la sysroot è stata modificata a mano, vi verrà domandato se cancellarne il contenuto, per cui potreste volere mettere in pipe yes | al comando.

# crossdev --clean sh4-unknown-linux-gnu

Nel caso non lo si abbia già notato, cancellare tutti i file contenuti nella directory /usr/CTARGET/ è completamente sicuro.

Opzioni

Ovviamente crossdev può fare molte altre cose, per scoprirle, basta lanciare crossdev --help.

2.c. I dettagli della Cross-Compilazione

Introduzione

Generalmente ci sono due strade percorribili per generare il proprio compilatore. La via "maestra" e l'oscura scorciatoia.

La via "maestra" è:

1. binutils
2. header del kernel
3. header delle libc
4. gcc stage1 (solo c)
5. libc
6. gcc stage2 (c/c++/etc...)

L'oscura scorciatoia invece è:

1. binutils
2. header del kernel
3. gcc stage1 (solo c)
4. libc
5. gcc stage2 (c/c++/etc...)

Molte persone seguono la scorciatoia perche la generazione degli header delle libc richiede molto tempo, specie su macchine lente. Inoltre installare gli header del kernel e/o delle libc senza un cross-compilatore funzionante potrebbe esser una scocciatura. Ricordate però che se si cerca aiuto sui cross-compilatori, il progetto upstream non vi offrirà supporto se avrete utilizzato la scorciatoia.

La scorciatoia inoltre richiede uno stage1 "menomato". Dal momento che si sta compilando senza gli header, non è possibile abilitare le varie opzione della sysroot né è possibile compilare correttamente le librerie del gcc. Questa situazione può essere accettabile solo se si usa lo stage1 per compilare la libreria C e il kernel, per tutto il resto sarà necessario un compilatore basato su sysroot.

Di seguito verrà descritta solo la via "riconosciuta", i passi da fare comunque sono praticamente gli stessi. Per la scorciatoia sarà sufficiente applicare qualche patch supplementare al gcc.

Sysroot

La cross-compilazione avverrà usando il metodo della sysroot. Ma cosa si intende precisamente quando si parla di sysroot ?

Dalla documentazione del gcc:
Dice al GCC di considerare dir come la radice (NdT. root) di un'alberatura contenente il filesystem di root del sistema operativo di destinazione. Gli header del sistema di destinazione, le librerie e gli oggetti a run-time saranno ricercati al suo all'interno.

La directory radice solitamente viene posizionata in /usr/$CTARGET .

/usr/$CTARGET/
|-- bin/
|-- lib/            librerie di runtime critiche (libc/ldso/etc...)
`-- usr/
|-- include/    header per lo sviluppo
|   |-- linux/      come il kernel linux
|   `-- asm/        come le dir. specifiche per ogni architettura
`-- lib/        librerie di runtime / sviluppo non critiche

Come si può notare, è una configurazione analoga alla / , solo che si trova in /usr/$CTARGET. Questa scelta non è ovviamente accidentale, ma pensata di proposito così da rendere semplice la migrazione di applicazioni e/o librerie da /usr/$CTARGET alla / sull'architettura di destinazione. volendo, è possibile utilizzare /usr/$CTARGET come NFS root pronta all'uso!

Binutils

Prelevare l'ultima versione del pacchetto binutils e scompattarlo.

L'opzione di configurazione --disable-werror è usata per evitare che la compilazione delle binutils fallisca per via dei warning. Caratteristica molto utile per gli sviluppatori, molto problematica invece per gli utenti.

$ ./configure \
     --target=$CTARGET \
     --prefix=/usr \
     --with-sysroot=/usr/$CTARGET \
     --disable-werror
$ make
$ make install DESTDIR=$PWD/install-root

Il motivo per cui le binutils vengono installate nella directory install-root è per permettere la rimozione di componenti di cui non si ha bisogno. Ad esempio, una normale installazione creerà /usr/lib/libiberty.a che non deve però far parte del sistema in uso. Va perciò fatta prima un po' di pulizia:

$ rm -rf install-root/usr/{info,lib,man,share}

Installare quindi quanto rimasto :

# cp -a install-root/* /

Header del kernel

Prelevare l'ultimo pacchetto del kernel e scompattarlo. Gli header possono essere installati in 2 modi: ripuliti o grezzi. La prima è chiaramente migliore (richiede però una versione recente del kernel Linux), ma verranno illustrate brevemente entrambe.

$ yes "" | make ARCH=$ARCH oldconfig prepare
# mkdir -p /usr/$CTARGET/usr/include
# cp -a include/linux include/asm-generic /usr/$CTARGET/usr/include/
# cp -a include/asm-$ARCH /usr/$CTARGET/usr/include/asm

# make ARCH=$ARCH headers_install INSTALL_HDR_PATH=/usr/$CTARGET/usr

Header delle libc di sistema

Prelevare l'ultimo pacchetto delle glibc e scompattarlo. Le Glibc sono piuttosto esigenti, per questo andranno compilate in una directory differente da quella dei sorgenti.

$ mkdir build
$ cd build
$ ../configure \
     --host=$CTARGET \
     --prefix=/usr \
     --with-headers=/usr/$CTARGET/usr/include \
     --without-cvs \
     --disable-sanity-checks
# make -k install-headers install_root=/usr/$CTARGET

Purtroppo le glibc non sono perfette e richiedono che alcune operazioni siano fatte a mano:

# mkdir -p /usr/$CTARGET/usr/include/gnu
# touch /usr/$CTARGET/usr/include/gnu/stubs.h
# cp bits/stdio_lim.h /usr/$CTARGET/usr/include/bits/

GCC Stage 1 (solo C)

Prima di tutto bisogna fare in modo che il gcc trovi gli header delle libc.

# ln -s usr/include /usr/$CTARGET/sys-include

Quindi prelevare l'ultima versione del pacchetto gcc e scompattarlo.

$ mkdir build
$ cd build
$ ../configure \
     --target=$CTARGET \
     --prefix=/usr \
     --with-sysroot=/usr/$CTARGET \
     --enable-languages=c \
     --disable-shared \
     --disable-checking \
     --disable-werror \
     --disable-libmudflap \
     --disable-libssp \
     --disable-libgomp \
     --disable-libssp
$ make
$ make install DESTDIR=$PWD/install-root

Come le binutils, anche il gcc crea dei file che non ci interessano.

$ rm -rf install-root/usr/{info,include,lib/libiberty.a,man,share}

Installare poi quanto rimasto (tutto dovrebbe finire nelle directory del CTARGET specificato, senza sovrascrivere alcun file del sistema in uso):

# cp -a install-root/* /

Libc di Sistema

Eliminare la vecchia cartella di compilazione del gcc e ricrearla.

$ rm -rf build
$ mkdir build
$ cd build
$ ../configure \
     --host=$CTARGET \
     --prefix=/usr \
     --without-cvs
$ make
# make install install_root=/usr/$CTARGET

GCC Stage 2 (Tutti i frontend)

È giunta l'ora di compilare un GCC completo. Scegliere i frontend al compilatore d'interesse; per semplicità si selezioneranno solo C e C++.

$ ./configure \
     --target=$CTARGET \
     --prefix=/usr \
     --with-sysroot=/usr/$CTARGET \
     --enable-languages=c,c++ \
     --enable-shared \
     --disable-checking \
     --disable-werror
$ make
# make install

File Core Runtime

Ci sono diversi file core runtime casuali di cui si vorrebbe conoscerne la funzione. Ecco una breve spiegazione.

L'ordine generale in fase di linking:

... crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o

3. Cross-Compilare con Portage

3.a. Variabili

Ci sono alcune importanti variabili che verranno usate in questa sezione.

È possibile valorizzarle tutte a mano, ma questo ovviamente diventa presto una scocciatura. Un'idea migliore è invece quella di specificare queste variabili in uno script di shell così da evitare di digitarle ogni volta.

3.b. Configurazione del Filesystem

Il cross-compilare un sistema richiede generalmente due alberature di directory. La prima, dove tutti i file di sviluppo sono normalmente installati. Questa è la vostra sysroot. L'altra alberatura è invece dove verranno installati i file che devono essere eseguiti. Una volta installati con emerge tutti i pacchetti nella sysroot (senza aver rimosso alcun file) sarà sufficiente installare tramite pacchetti binari o copiando a mano tutti i file desiderati nell'alberatura di esecuzione.

È convenzione usare l'alberatura presente sotto /usr/CTARGET/ come sysroot, dato che il cross-compilatore è già configurato per cercare in tale percorso le directory degli include e delle librerie. È anche possibile usare un'altra directory, aggiungendone poi il percorso alle CPPFLAGS/LDFLAGS tramite l'opzione -I/-L, ma questo opzione storicamente si è rivelato esser problematica: anche se dovesse funzionare, è sconsigliata e scoraggiata. D'ora in avanti si assumerà che si stia usando la sysroot come propria ROOT di sviluppo.

Il sistema che poi si vorrà eseguire avrà probabilmente bisogno di un po' di lavoro per esser alleggerito e snellito. Proprio per via dei file che si rimuoveranno dai pacchetti installati, questo ambiente non è adatto per la compilazione. Mentre si installa la sysroot si possono generare pacchetti binari dei vari applicativi, dai quali, con l'aggiunta della variabile INSTALL_MASK sono facilmente rimuovibili i file giudicati superflui. Leggere man make.conf per ottenere maggiori informazioni.

3.c. Introduzione: wrapper di crossdev

Ci sono dei semplici script wrapper che imposteranno al posto dell'utente le variabili d'ambiente in modo da farle puntare alle giuste posizione per permettere la cross compilazione usando emerge. PORTAGE_CONFIGROOT e ROOT punteranno entrambe a SYSROOT.

# emerge crossdev

È possibile usare questi strumenti sia per installare nella propria root di sviluppo (sysroot) sia in quella per l'esecuzione. Per quest'ultima, specificarla usando semplicemente l'opzione --root. Per esempio, se si ha effettuato l'emerge di una toolchain armv4tl-softfloat-linux-gnueabi tramite crossdev successivamente si dovrebbe invocare il comando come un normale emerge, usando però il prefisso ctarget:

# armv4tl-softfloat-linux-gnueabi-emerge pkg0 pkg1 pkg2

Come impostazione predefinita questi wrapper usano l'opzione --root-deps=rdeps per evitare che le dipendenze dell'host vengano incluse nell'albero delle dipendenze. Ciò potrebbe portare ad alberi di dipendenze incompleti. Perciò si potrebbe voler usare --root-deps singolarmente per vedere il grafico completo delle dipendenze.

Come impostazione predefinita i wrapper si collegheranno al profilo embedded generico. Questo viene fatto per semplificare le cose, ma l'utente potrebbe desiderare un profilo di destinazione più avanzato. Per poterlo fare è possibile aggiornare il collegamento simbolico al profilo.

# ln -s /usr/portage/profiles/default/linux/arm/10.0
${SYSROOT}/etc/make.profile

E naturalmente per cambiare le impostazioni del sistema di destinazione, tipo flag USE, FEATURES e VIDEO_CARDS, si modificheranno i file di configurazione standard di portage.

# $EDITOR ${SYSROOT}/etc/make.conf

Qualche volta ci sono alcun test addizionali per gli script di configurazione che bisogna necessariamente aggirare. Per far ciò i wrapper esportano alcune variabili per forzare i test a ricevere la risposta desiderata. Ciò aiuterà a prevenire sprechi di risorse nei pacchetti che aggiungono funzioni locali per aggirare eventuali problemi nel proprio sistema che impedirebbero l'esecuzione del test. Di volta in volta potrebbe essere necessario aggiungere variabili aggiuntive a questi file in /usr/share/crossdev/include/site/ in modo da permettere la compilazione di un pacchetto. Per capire quale variabile bisogna aggiungere, spesso basta eseguire un grep sullo script di configurazione per individuare la variabile autoconf e aggiungerla all'appropriato file di destinazione. Ciò diviene ovvio dopo le prime volte che si esegue tale operazione.

3.d. Disintallazione

Se si desidera disinstallare ed eliminare quanto fatto, sarà sufficiente rimuovere l'alberatura presente nella sysroot, senza intaccare alcun pacchetto nativo installato. Si legga anche la sezione relativa alla disinstallazione nella guida relativa alla cross-compilazione.

4. Cross-Compilare il Kernel

4.a. Sorgenti

Prima di tutto occorre installare i sorgenti del kernel. Si può utilizzare portage per installare il pacchetto necessario, o scaricarli dall'Archivio dei Kernel Linux o da dove si preferisce. Il metodo per compilarli è sempre lo stesso.

Bisognerà installare il kernel nella sysroot così che se si effettuerà la cross-compilazione dei pacchetti che includono moduli del kernel, il processo sarà trasparente. Altrimenti si potranno compilare i sorgenti del kernel dove si preferisce. Alcuni mantengono i sorgenti del kernel in /usr/src/, ad esempio.

4.b. Preparazione alla Cross-compilazione

Due sono le variabili usate dal kernel per selezionare l'architettura di destinazione. Normalmente questi valori sono ricavati dall'ambiente dove viene compilato il kernel, in questo caso però l'ambiente non corrisponde all'architettura di destinazione, per cui bisogna forzarle. Le variabili in questione sono ARCH e CROSS_COMPILE. I valori predefiniti per entrambe si trovano nel Makefile presente nella directory radice dei sorgenti e possono essere forzati da linea di comando.

La variabile ARCH indica il nome l'architettura di destinazione, nel formato specificato dal kernel. Mentre portage e altri programmi usano la dicitura "x86", il kernel usa "i386". Per avere un'idea delle sigle delle diverse architetture visualizzare il contenuto della subdirectory arch/.

La variabile CROSS_COMPILE dovrebbe essere auto esplicativa. Essa va valorizzata con il prefisso della propria toolchain (trattino finale "-" incluso). Perciò se si invoca la propria toolchain come x86_64-pc-linux-gnu-gcc, sarà sufficiente eliminare quel gcc in coda ed il risultato è ciò che si dovrà usare: x86_64-pc-linux-gnu-.

C'è una variabile aggiuntiva, INSTALL_MOD_PATH, che definisce dove verrà creata la directory /lib e dove verranno memorizzati tutti i moduli. Sebbene non serva trasferire i sorgenti del kernel nel proprio dispositivo di destinazione, se si compilerà un qualunque modulo ci sarà bisogno di questa directory.

Ci sono due modalità per preparare il sistema. È possibile modificare il Makefile presente nella directory radice o valorizzare le variabili rilevanti da linea di comando. Entrambe sono corrette: è solo una questione di gusti, perciò verranno illustrate entrambe. Sceglierne una delle due.

# Il Makefile di un kernel vanilla si presenta così
ARCH            ?= $(SUBARCH)
CROSS_COMPILE   ?=

# Specificare i valori predefiniti di ARCH e CROSS_COMPILE
ARCH            ?= arm
CROSS_COMPILE   ?= arm-unknown-linux-gnu-

# make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- ....

È anche possibile usare un piccolo script per semplificarsi la vita se si deve lavorare con diversi kernel contemporaneamente. Questo script verrà chiamato xkmake.

#!/bin/sh
exec make ARCH="arm" CROSS_COMPILE="arm-unknown-linux-gnu-" INSTALL_MOD_PATH="${SYSROOT}" "$@"

Così quando si vorrà compilare un kernel o fare qualunque altra cosa, sarà sufficiente eseguire xkmake al posto di make.

4.c. Configurazione e Compilazione

A questo punto, la configurazione e la compilazione del kernel è la stessa di ogni altro kernel, per cui non verrà approfondito l'argomento dato che sono presenti già molti HOWTO e guide che trattano l'argomento in dettaglio.

# cd "${SYSROOT}/usr/src/linux"
# xkmake menuconfig
# xkmake

5. Compilare in chroot con qemu-user

5.a. Utilizzo

6. FAQ - Domande Poste Frequentemente

6.a. Mi dà l'errore "configure: error: C compiler cannot create executables"

Questo è un errore generico e può esser causato da un'infinità di situazioni. Il test è molto semplice: il compilatore scelto può creare eseguibili? Questo però dipende numerose condizioni che devono essere verificate: la toolchain deve essere completamente integra, il compilatore e le opzioni di compilazione devono essere appropriate, l'ambiente deve essere configurato correttamente, ecc... Il solo modo per trovare l'origine del problema è quello di leggere riga per riga il file config.log fino a dove viene eseguito tale test e di vedere il messaggio d'errore generato dalla toolchain.

6.b. "epatch" fallisce sempre su un sistema appena compilato

Il pacchetto bash non cross-compila molto bene e mischia le definizioni dei segnali ta sistema host e target. Questa problematica si manifesta in diverse maniere a seconda della combinazione di architecture tra host e target. Per risolvere il problema è sufficiente ricompilare il pacchetto bash. "Ma la bash usa epatch!" verrà fatto notare. Per questo, si dovrà modificare l'ebuild commentando tutte le chiamate a epatch. Una volta installato con questo metodo il pacchetto bash funzionante, scommentare e ricompilarlo nuovamente.

6.c. La costruzione di uClibc va in segfault/crash quando sta compilando i locale

Il supporto alla localizzazione da parte di uClibc è al momento altamente sperimentale. A meno che non si abbia veramente la necessità di tale supporto (e la volontà di aiutare a risolvere il problema), disabilitare semplicemente il supporto aggiungendo -nls -iconv -pregen -userlocales alla propria USE quando si compilerà uClibc.

B. Emulatori

1. Qemu

1.a. Utilizzo

DA COMPLETARE

2. SkyEye

2.a. Utilizzo

DA COMPLETARE

3. Armulator

3.a. Utilizzo

DA COMPLETARE

4. Softgun

4.a. Utilizzo

DA COMPLETARE

5. Hercules

5.a. Utilizzo

DA COMPLETARE

C. I Bootloader

1. Das U-Boot

1.a. Utilizzo

Piuttosto che duplicare le informazioni esistenti, consultare la documentazione ufficiale e il relativo wiki principale.

2. NeTTrom

2.a. Utilizzo

DA COMPLETARE

3. RedBoot

3.a. Utilizzo

DA COMPLETARE

4. SH-LILO

4.a. Utilizzo

DA COMPLETARE

D. Schede

1. Hammer/Nailboard

1.a. Specifiche della scheda :

# La scheda viene alimentata solo tramite la porta USB (non è richiesto alcun alimentatore esterno)
# Connettore USB Maschio (upstream)
# Connettore USB Femmina (downstream)
# Dispositivo JTAG USB integrato (attraverso il chip FT2232)
# USB Hub integrato
# porta console seriale USB (attraverso il chip FT2232)
# GPIO controllato via USB (per la configurazione)
# Interfaccia gadget USB (attraverso il modulo Hammer)
    * Driver Gadget Ethernet (default)
    * Driver Gadget Porta Seriale
    * Driver Mass Storage Driver

# Interfaccia host USB (attraverso il modulo Hammer)
    * USB 1.1 Compliant
    * Supporto Bassa Velocità (2mb)
    * Supporto Alta Velocità (12mb)

# 3 LED Utente disponibili
    * Due sulla Nail Board
    * Un LED utente sul modulo Hammer
    * LED utente sulla scheda Hammer

# 2 interruttori a bottone gestiti via interrupt
# PWM buzzer controllabile dall'utente
# Bottone di Reset
# LED Alimentazione
# Header di espansione (20-pin: 2 x10)
    * +5V disponibile
    * +3.3V disponibile
    * 2 porte SPI
    * 2 connettori per Porta Seriale (TX/RX)
    * GPIO
    * Interrupt Esterni
    * Gli header possono essere configurati tramite jumper

# Header del modulo Hammer
    * Accesso a tutti i 40 I/O pins del modulo Hammer
    * Header della dimensione di 0.1 pollici

1.b. /proc/cpuinfo

Processor	: ARM920T rev 0 (v4l)
BogoMIPS	: 101.17
Features	: swp half thumb
CPU implementer	: 0x41
CPU architecture: 4T
CPU variant	: 0x1
CPU part	: 0x920
CPU revision	: 0
Cache type	: write-back
Cache clean	: cp15 c7 ops
Cache lockdown	: format A
Cache format	: Harvard
I size		: 16384
I assoc		: 64
I line length	: 32
I sets		: 8
D size		: 16384
D assoc		: 64
D line length	: 32
D sets		: 8

Hardware	: TCT_HAMMER
Revision	: 0000
Serial		: 0000000000000000

1.c. Preparazione alla Cross Compilazione

echo '>=cross-arm-softfloat-linux-uclibc/gcc-4' >> /etc/portage/package.mask
echo 'dev-embedded/openocd ft2232 ftdi' >> /etc/portage/package.use
modprobe ftdi_sio
emerge openocd
ACCEPT_KEYWORDS="~*" emerge crossdev
crossdev arm-softfloat-linux-uclibc

echo '>=cross-armv4l-softfloat-linux-uclibceabi/gcc-4' >>
/etc/portage/package.mask
echo 'dev-embedded/openocd ft2232 ftdi' >> /etc/portage/package.use
modprobe ftdi_sio
emerge openocd
ACCEPT_KEYWORDS="~*" emerge crossdev
crossdev armv4tl-softfloat-linux-uclibceabi

1.d. Ulteriori informazioni:

• TinCanTools
• TCT-Hammer Wiki
• Hammer Board
• Nail Board
• Configurazione Kernel Predefinita
• Nail Schematic
• (Gentoo Embedded) Riferimenti Firmware
• (Gentoo Embedded) Riferimenti Configurazione Kernel

2. LANTank

2.a. Specifiche di IO-Data LANTANK:

# Processore SH4 SH7751 ~266MHz
# 64MB RAM
# IDE controller Artop Electronic Corp ATP865
# Ethernet controller 10/100Mbit Realtek 8139C+
# 2x NEC USB 2.0

2.b. /proc/cpuinfo

machine         : LANDISK
processor       : 0
cpu family      : sh4
cpu type        : SH7751R
cpu flags       : fpu ptea
cache type      : split (harvard)
icache size     : 16KiB (2-way)
dcache size     : 32KiB (2-way)
bogomips        : 266.24
master_clk      : 266.66MHz
module_clk      : 33.33MHz
bus_clk         : 133.33MHz
cpu_clk         : 266.66MHz
tmu0_clk        : 8.33MHz

2.c. Preparazione alla Cross Compilazione

# emerge crossdev
# crossdev sh4-unknown-linux-gnu

#!/bin/sh

CHOST=sh4-unknown-linux-gnu

#export CBUILD=$(portageq envvar CBUILD)
export SYSROOT="/usr/${CHOST}"
export PORTAGE_CONFIGROOT="/usr/${CHOST}"

# optional exports
export enable_malloc0returnsnull=yes \
        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes

# optional export for glib:2
export glib_cv_uscore=no glib_cv_stack_grows=no \
        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
        ac_cv_func_posix_getpwuid_r=yes \
        ac_cv_func_posix_getgrgid_r=yes \
        ac_cv_header_pwd_h=yes \
        ac_cv_func_getpwuid_r=yes \
        glib_cv_sizeof_gmutex=40

FAKEROOT=
if [[ $(id -u) != 0 ]]; then
        if [[ $(type -p fakeroot) != "" ]]; then
                FAKEROOT=fakeroot
        fi
fi

${FAKEROOT} emerge -q "$@"

CHOST=sh4-unknown-linux-gnu
CBUILD=x86_64-pc-linux-gnu
ARCH="sh"
ROOT=/usr/${CHOST}/
ACCEPT_KEYWORDS="sh ~sh"
USE="${ARCH} zlib bindist make-symlinks minimal \
        input_devices_keyboard input_devices_evdev \
        video_cards_fbdev video_cards_dummy"

VIDEO_CARDS="fbdev dummy"

INPUT_DEVICES="evdev keyboard mouse touchscreen"
USE_EXPAND="video_cards input_devices"
MARCH_TUNE="-m4"
CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/
-I${ROOT}/include/"

CXXFLAGS="${CFLAGS}"
LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"

PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
MAKEOPTS="-j8"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"

PORTDIR_OVERLAY="/usr/portage/local/"
PKGDIR=${ROOT}/packages/
PORTAGE_TMPDIR=${ROOT}/tmp/
PORTAGE_WORKDIR_MODE=2775
PORTAGE_ECLASS_WARNING_ENABLE=0

CLEAN_DELAY=0
EPAUSE_IGNORE=1
EBEEP_IGNORE=1

2.d. Riferimenti:

• Pagina di Mike Frysinger' riguardo a LANTANK

3. NetWinder

3.a. Rebel NetWinder

# Processore DEC/Intel StrongARM 110 ~233MHz
# Chipset DEC/Intel 21285 FootBridge
# 32/64/128MB RAM
# Chip grafico Intergraphics Systems CyberPro 2000A con 2MB RAM, VGA output
# Controller IDE WinBond 553
# Chip audio RockWell WaveArtist
# Philips 7111 video capture/WinBond 9660 TV Encoder
# 1x WinBond 940 10BaseT Ethernet controller
# 1x Digital 21143(Tulip) 10/100BaseT Ethernet controller

3.b. /proc/cpuinfo

Processor       : StrongARM-110 rev 4 (v4l)
BogoMIPS        : 185.54
Features        : swp half 26bit fastmult
CPU implementer : 0x44
CPU architecture: 4
CPU variant     : 0x0
CPU part        : 0xa10
CPU revision    : 4

Hardware        : Rebel-NetWinder
Revision        : 59ff
Serial          : 0000000000000000

3.c. Preparazione alla Cross Compilazione

# emerge crossdev
# crossdev armv4l-unknown-linux-gnu

#!/bin/sh

CHOST=armv4l-unknown-linux-gnu

#export CBUILD=$(portageq envvar CBUILD)
export SYSROOT="/usr/${CHOST}"
export PORTAGE_CONFIGROOT="/usr/${CHOST}"

# optional exports
export enable_malloc0returnsnull=yes \
        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes

# optional export for glib:2
export glib_cv_uscore=no glib_cv_stack_grows=no \
        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
        ac_cv_func_posix_getpwuid_r=yes \
        ac_cv_func_posix_getgrgid_r=yes \
        ac_cv_header_pwd_h=yes \
        ac_cv_func_getpwuid_r=yes \
        glib_cv_sizeof_gmutex=40

FAKEROOT=
if [[ $(id -u) != 0 ]]; then
        if [[ $(type -p fakeroot) != "" ]]; then
                FAKEROOT=fakeroot
        fi
fi

${FAKEROOT} emerge -q "$@"

CHOST=armv4l-unknown-linux-gnu
CBUILD=x86_64-pc-linux-gnu
ARCH="arm"
ROOT=/usr/${CHOST}/
ACCEPT_KEYWORDS="arm ~arm"
USE="${ARCH} zlib bindist make-symlinks minimal \
        input_devices_keyboard input_devices_evdev \
        video_cards_fbdev video_cards_dummy"

VIDEO_CARDS="fbdev dummy"

INPUT_DEVICES="evdev keyboard mouse touchscreen"
USE_EXPAND="video_cards input_devices"
MARCH_TUNE="-mcpu=strongarm110"
CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/
-I${ROOT}/include/"

CXXFLAGS="${CFLAGS}"
LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"

PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
MAKEOPTS="-j8"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"

PORTDIR_OVERLAY="/usr/portage/local/"
PKGDIR=${ROOT}/packages/
PORTAGE_TMPDIR=${ROOT}/tmp/
PORTAGE_WORKDIR_MODE=2775
PORTAGE_ECLASS_WARNING_ENABLE=0

CLEAN_DELAY=0
EPAUSE_IGNORE=1
EBEEP_IGNORE=1

3.d. Riferimenti:

• NetWinder.org

4. NSLU2

4.a. Utilizzo

DA COMPLETARE

5. QNAP TurboStation 109/209/409

5.a. Documentazione Gentoo

Allo stato attuale, le schede TS109/TS209 e TS409 sono supportate da Gentoo grazie a QNAP Inc., che ha fornito l'hardware agli sviluppatori di Gentoo per creare e documentare il processo d'installazione.

• Documentazione riguardante l'installazione di Gentoo sulla QNAP TurboStation TS109/TS209
• Documentazione riguardante l'installazione di Gentoo sulla QNAP TurboStation TS409

5.b. Specifiche QNAP TurboStation TS109/209/409:

# Marvell Orion SoC MV88F5182 (per il TS109/209) e MV88F5281 (per il TS409)
# Processore Marvell Feroceon ARMv5TE 500MHz
# 128/256/512MB DDR2 RAM tra i diversi modelli
# 8MB NAND Flash
# Marvell SATA2 controller
# Marvell Gigabit Ethernet controller

# LED disponibili:
    * Led alimentazione (solo TS109/209)
    * Led di Statuo
    * Led HDD SATA HDD
    * Led interfaccia di rete
    * Led USB

# Pulsante Reset
# 3x Porte USB 2.0
# 1x Porta eSATA, solo TS109
# Buzzer

5.c. /proc/cpuinfo

Processor       : Feroceon rev 0 (v5l)
BogoMIPS        : 498.07
Features        : swp half thumb fastmult vfp edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 0
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 1
I line length   : 32
I sets          : 1024
D size          : 32768
D assoc         : 4
D line length   : 32
D sets          : 256

Hardware        : QNAP TS-409
Revision        : 0000
Serial          : 0000000000000000

5.d. Preparazione alla Cross Compilazione

emerge crossdev
crossdev armv5tel-softfloat-linux-gnueabi

#!/bin/sh

CHOST=armv5tel-softfloat-linux-gnueabi

#export CBUILD=$(portageq envvar CBUILD)
export SYSROOT="/usr/${CHOST}"
export PORTAGE_CONFIGROOT="/usr/${CHOST}"

# optional exports
export enable_malloc0returnsnull=yes \
        ac_cv_file__usr_share_sgml_X11_defs_ent=1 \
        ac_cv_func_setpgrp_void=yes ac_cv_func_setgrent_void=yes \
        ac_cv_func_calloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes \
        gl_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
        ac_cv_func_memcmp_working=yes ac_cv_func_strnlen_working=yes

# optional export for glib:2
export glib_cv_uscore=no glib_cv_stack_grows=no \
        glib_cv_stack_grows=no  glib_cv_has__inline=yes \
        glib_cv_has__inline__=yes glib_cv_hasinline=yes \
        glib_cv_sane_realloc=yes glib_cv_va_copy=yes \
        glib_cv___va_copy=yes glib_cv_va_val_copy=no \
        glib_cv_rtldglobal_broken=no glib_cv_uscore=no \
        ac_cv_func_posix_getpwuid_r=yes \
        ac_cv_func_posix_getgrgid_r=yes \
        ac_cv_header_pwd_h=yes \
        ac_cv_func_getpwuid_r=yes \
        glib_cv_sizeof_gmutex=40

FAKEROOT=
if [[ $(id -u) != 0 ]]; then
        if [[ $(type -p fakeroot) != "" ]]; then
                FAKEROOT=fakeroot
        fi
fi

${FAKEROOT} emerge -q "$@"

#
CHOST=armv5tel-softfloat-linux-gnueabi
CBUILD=x86_64-pc-linux-gnu
ARCH="arm"
ROOT=/usr/${CHOST}/
ACCEPT_KEYWORDS="arm ~arm"
USE="${ARCH} zlib bindist make-symlinks minimal \
        input_devices_keyboard input_devices_evdev \
        video_cards_fbdev video_cards_dummy"

VIDEO_CARDS="fbdev dummy"

INPUT_DEVICES="evdev keyboard mouse touchscreen"
USE_EXPAND="video_cards input_devices"
MARCH_TUNE="-march=armv5t -mtune=arm926ej-s"
CFLAGS="-Os -pipe ${MARCH_TUNE} -fomit-frame-pointer -I${ROOT}/usr/include/ -I${ROOT}/include/"

CXXFLAGS="${CFLAGS}"
LDFLAGS="-L${ROOT}/usr/lib -L${ROOT}/lib"

PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/"
MAKEOPTS="-j8"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"

PORTDIR_OVERLAY="/usr/portage/local/"
PKGDIR=${ROOT}/packages/
PORTAGE_TMPDIR=${ROOT}/tmp/
PORTAGE_WORKDIR_MODE=2775
PORTAGE_ECLASS_WARNING_ENABLE=0

CLEAN_DELAY=0
EPAUSE_IGNORE=1
EBEEP_IGNORE=1

5.e. Ulteriori informazioni:

• QNAP Inc.
• Pagina di Martin Michlmayr riguardante i dispositivi basati su QNAP ARM

6. Marvell Sheevaplug

6.a. Documentazione Gentoo

Attualmente la scheda Marvell Sheevaplug è supportata da Gentoo grazie a Marvell che ci ha messo a disposizione l'hardware per creare e documentare il processo d'installazione.

• Documentazione riguardante l'installazione di Gentoo sulla scheda Marvell Sheevaplug

6.b. Specifiche Marvell Sheevaplug

# Marvell Kirkwood SoC 88F6281
# Marvell Feroceon ARMv5TE 1200MHz processor
# 512MB DDR2 RAM
# 512MB NAND Flash
# Marvell Gigabit Ethernet controller
# 1x SDHC slot
# 1x USB 2.0 port
# 1x mini-USB 2.0 port (for integrated JTAG and serial access)
# Reset button

6.c. /proc/cpuinfo

Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell SheevaPlug Reference Board
Revision        : 0000
Serial          : 0000000000000000

6.d. Riferimenti:

• Marvell
• Marvell's Sheevaplug community

7. ACME SYSTEMS Netus G20

7.a. Documentazione Gentoo

Netus G20 è una scheda di 4x4 cm, predisposta per Linux, con un motore interno basato su Atmel(TM) AT91SAM9G20 (ARMv5TE) e venduto da ACME SYSTEMS. Viene supportato da Gentoo grazie al produttore e specialmente da Davide Cantaluppi che ne effettua la manutenzione. Di fatto, Gentoo è il sistema operativo predefinito fornito con questo dispositivo.

7.b. Specifiche ACME SYSTEMS Netus G20

# CPU Atmel AT91SAM9G20 basata su ARM926EJ-S con una velocità di clock di 400MHz.
# 64MBytes di SDRAM con accesso a 32bit.
# 8MBytes di Dataflash.
# Dimensioni 40x40mm. Peso 10g.
# Intervallo temperatura operativa: -20º + 70º
# Quattro connettori da 60 pin (altezza 0.8mm) con i seguenti segnali disponibili sui lati superiore ed inferiore (vedere la piedinaturat)
  # One USB 2.0 Full Speed (12 Mbits per second) Device Port.
  # Two USB 2.0 Full Speed (12 Mbits per second) Host Ports.
  # One Ethernet MAC 10/100 Base T Port.
  # Image Sensor Interface (ITU-R BT. 601/656 12 bit).
  # One Two-slot MultiMedia Card Interface (MCI). SDCard/SDIO and MultiMediaCard(TM) Compliant.
  # Four Universal Synchronous/Asynchronous Receiver Transmitters (USART) with RS485 support.
  # Two 2-wire UARTs.
  # Two Master/Slave Serial Peripheral Interfaces (SPI).
  # One Synchronous Serial Controller (SSC). I2S Analog Interface Support.
  # Two Wire Interface
  # Four-channel 10-bit ADC.
  # 80 general purpose I/O lines multiplexed with up to two peripheral I/Os.
    # Individually Programmable Open-drain, Pull-up Resistor and Synchronous Output.
    # All I/O Lines are Schmitt Trigger when programmed as inputs.
    # Input Change Interrupt Capability on Each I/O Line.
  # Serial 2 wire console port.
  # JTAG Console and Boundary Scan on All Digital Pins (IEEE(R) 1149.1).
# Two Three-channel 16-bit Timer/Counters with PWM Generation.
# Watchdog timer.
# Real-time clock (optional external battery backup).
# Very Slow Clock Operating Mode.

7.c. /proc/cpuinfo

netusg20 / # cat /proc/cpuinfo
Processor    : ARM926EJ-S rev 5 (v5l)
BogoMIPS    : 197.83
Features    : swp half thumb fastmult edsp java
CPU implementer    : 0x41
CPU architecture: 5TEJ
CPU variant    : 0x0
CPU part    : 0x926
CPU revision    : 5

Hardware    : Atmel AT91SAM9G20-EK
Revision    : 0000
Serial        : 0000000000000000

7.d. dmesg

Linux version 2.6.31-gentooGentooNETUSembedded (root@localhost) (gcc version
4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5) ) #29 Fri Oct 16 12:00:28 CEST 2009
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G20-EK
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat c04046a0, node_mem_map c0426000
  Normal zone: 128 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 16256 pages, LIFO batch:3
Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: mem=64M console=ttyS0,115200 rootdelay=5
root=/dev/mmcblk0p1 rw rootfstype=reiserfs rootflags=data=writeback
init=/sbin/init nodevfs
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60652KB available (3840K code, 256K data, 108K init, 0K highmem)
Hierarchical RCU implementation.
NR_IRQS:192
AT91: 96 gpio irqs in 3 banks
Console: colour dummy device 80x30
console [ttyS0] enabled
Calibrating delay loop... 197.83 BogoMIPS (lpj=989184)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
tcb_clksrc: tc0 at 16.012 MHz
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
NTFS driver 2.1.29 [Flags: R/W].
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
JFS: nTxBlock = 474, nTxLock = 3795
msgmni has been set to 118
io scheduler noop registered
io scheduler deadline registered (default)
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
atmel_usart.3: ttyS3 at MMIO 0xfffb8000 (irq = 8) is a ATMEL_SERIAL
atmel_usart.4: ttyS4 at MMIO 0xfffd0000 (irq = 23) is a ATMEL_SERIAL
brd: module loaded
loop: module loaded
ssc ssc.0: Atmel SSC device at 0xc48d8000 (irq 14)
PPP generic driver version 2.4.2
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffc4000 irq 21 (3a:1f:34:08:54:54)
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:00,
irq=-1)
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 20, io mem 0x00500000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: AT91 OHCI
usb usb1: Manufacturer: Linux 2.6.31-gentooGentooNETUSembedded ohci_hcd
usb usb1: SerialNumber: at91
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
mice: PS/2 mouse device common for all mice
usbcore: registered new interface driver xpad
xpad: X-Box pad driver
at91_rtt: dev (254:0)
rtc-at91sam9 at91_rtt.0: rtc core: registered at91_rtt as rtc0
IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs
i2c /dev entries driver
at24 0-0050: 65536 byte 24c512 EEPROM (writable)
i2c-gpio i2c-gpio: using pins 55 (SDA) and 56 (SCL)
AT91SAM9 Watchdog: sorry, watchdog is disabled
at91_wdt: probe of at91_wdt failed with error -5
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
Bluetooth: HCILL protocol initialized
Bluetooth: Generic Bluetooth USB driver ver 0.5
usbcore: registered new interface driver btusb
at91_mci at91_mci: 4 wire bus mode not supported - using 1 wire
Registered led device: ds5
Registered led device: ds1
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
rtc-at91sam9 at91_rtt.0: readtime: 2009-09-19 14:56:38
rtc-at91sam9 at91_rtt.0: setting system clock to 2009-10-19 14:56:38 UTC
(1255964198)
Waiting 5sec before mounting root device...
usb 1-2: new full speed USB device using at91_ohci and address 2
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address 8fe4
mmcblk0: mmc0:8fe4 SU04G 3.69 GiB
 mmcblk0: p1
usb 1-2: New USB device found, idVendor=1370, idProduct=0323
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: pitchBLACK
usb 1-2: Manufacturer: Swissbit
usb 1-2: SerialNumber: 000010004269FR0002b5
usb 1-2: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
REISERFS (device mmcblk0p1): found reiserfs format "3.6" with standard
journal
REISERFS (device mmcblk0p1): using writeback data mode
REISERFS (device mmcblk0p1): journal params: device mmcblk0p1, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit age
30, max trans age 30
REISERFS (device mmcblk0p1): checking transaction log (mmcblk0p1)
REISERFS (device mmcblk0p1): Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) on device 179:1.
Freeing init memory: 108K
eth0: link up (100/Full)
eth0: no IPv6 routers present

7.e. Riferimenti:

• ACME SYSTEMS Netus G20

8. Genesi Efika MX

8.a. Documentazione Gentoo

Il processo per il supporto della scheda Genesi USA Efika MX è in corso, grazie a Genesi USA che ha fornito agli sviluppatori di Gentoo l'hardware necessario per permettere loro di portare avanti questo obbiettivo.

• Documentazione riguardante l'installazione di Gentoo su uno Smarttop Genesi USA Efika MX

8.b. Specifiche Genesi Efika MX

# Freescale i.MX51 SoC
# Processore ARMv7-A 800MHz ARM Cortex-A8
# 512MB DDR2 RAM
# 8GB SSD Flash
# Scheda Wireless Ralink RT3070USB
# Scheda Ethernet ASIX AX88772 USB 2.0
# Scheda audio
#
# 1x SDHC slot
# 2x USB 2.0 port
# 1x HDMI out
# 1x Audio IN
# 1x Audio OUT
# 1x Ethernet 100Mbps
# Pulsante alimentazione
#
# Scheda con interfaccia seriale e JTAG

8.c. /proc/cpuinfo

Processor	: ARMv7 Processor rev 1 (v7l)
BogoMIPS	: 799.53
Features	: swp half thumb fastmult vfp edsp
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x2
CPU part	: 0xc08
CPU revision	: 1

Hardware	: Genesi Efika MX
Revision	: 51025
Serial		: 0000000000000000

8.d. Riferimenti:

• Genesi USA
• PowerDeveloper.org

9. Pandaboard

9.a. Documentazione Gentoo

Attualmente, la Pandaboard è supportata su Gentoo grazie a pandaboard.org che fornisce agli sviluppatori l'hardware per creare e documentare i processi d'installazione.

• Documentazione riguardante l'installazione di Gentoo su Pandaboard

9.b. Specifiche Pandaboard

# TI OMAP SoC 4430
# Dual-core ARMv7-A 1GHz Cortex-A9 processor
# 1GB DDR2 RAM
# USB-based SMSC 9514-JZX Ethernet controller and USB HUB
# LS Research WL1271 SDIO module (WLAN, BT, FM)
#
# 1x SDHC/MMC/SDIO slot
# 2x USB 2.0 port
# 1x mini-USB 2.0 OTG port
# 1x HDMI out
# 1x DVI-D out(HDMI connector)
# 1x Audio IN
# 1x Audio OUT
# 1x RS232 serial port
# 1x RJ45 port

# Pulsante Reset e definito dall'utente

9.c. /proc/cpuinfo

Processor	: ARMv7 Processor rev 2 (v7l)
processor	: 0
BogoMIPS	: 2013.49

processor	: 1
BogoMIPS	: 1963.08

Features	: swp half thumb fastmult vfp edsp thumbee neon vfpv3 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0xc09
CPU revision	: 2

Hardware	: OMAP4430 Panda Board
Revision	: 0010
Serial		: 0000000000000000

9.d. References:

• Pandaboard.org

10. Trimslice

10.a. Documentazione Gentoo

Il Compulab TrimSlice è supportato in Gentoo, grazie a Compulab/Trimslice.com che ci ha fornito l'hardware per per creare e documentare il processo d'installazione.

• Documentazione sull'installazione di Gentoo su TrimSlice

10.b. Specifiche TrimSlice

# Nvidia Tegra2 SoC
# Dual-Core ARMv7-A 1GHz ARM Cortex-A9 processor
# 1GB DDR2-667 RAM
# Realtek RTL8111DL Gigabit Ethernet
# Soundcard
#
# 1x SDHC slot
# 1x MicroSD slot
# 4x USB 2.0 ports
# 1x microUSB port for serial
# 1x HDMI out, 1x DVI out(depends on the model)
# 1x Audio IN
# 1x Audio OUT
# 1x Ethernet 1Gbps
# Power button
#

10.c. /proc/cpuinfo

Processor	: ARMv7 Processor rev 0 (v7l)
processor	: 0
BogoMIPS	: 1998.84

processor	: 1
BogoMIPS	: 1998.84

Features	: swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0xc09
CPU revision	: 0

Hardware	: TrimSlice
Revision	: 0000
Serial		: 0x00000000000000000

10.d. Riferimenti:

• Trimslice.com (in inglese, NdT)

11. Beaglebone

11.a. Documentazione Gentoo

Il Beaglebone è supportato in Gentoo, grazie a Beagleboard.org che ci ha fornito l'hardware per per creare e documentare il processo d'installazione.

• Documentazione sull'installazione di Gentoo su Beaglebone

11.b. Specifiche Beaglebone

# ARMv7-A 500MHz(USB power)/720MHz(PSU power) TI AM3358/9 ARM Cortex-A8 processor
# 256MB DDR2 RAM
# SMSC LAN8710A Ethernet card
#
# 1x microSDHC slot
# 1x USB 2.0 Type-A port
# 1x mini-USB 2.0 OTG port
# 1x RJ45
#
# Reset and user-defined button

11.c. /proc/cpuinfo

(Note: running in USB power)
Processor	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 498.89
Features	: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: am335xevm
Revision	: 0000
Serial		: 0000000000000000

11.d. Riferimenti:

• Beagleboard.org (in inglese, NdT)

E. Ulteriori Sviluppi

1. Contatti

1.a. Mailing List

Il primo passo per partecipare al progetto Gentoo Embedded è quello di iscriversi alla mailing list gentoo-embedded@gentoo.org. Dopo di che, chiedere se c'è in progetto di supportare qualcosa di vostro interesse, proporre un nuovo progetto o sceglierne uno tra quelli già pianificati e contribuire.

Per maggiori informazioni, visitare la pagina dedicata alle mailing list.

1.b. IRC

È possibile parlare con sviluppatori e utenti sul canale IRC #gentoo-embedded su irc.freenode.net per avere maggiori informazioni o solo chiaccherare del progetto o dei vari sotto progetti.

Per maggiori informazioni, visitare la pagina dedicata ai canali IRC.

1.c. Bugzilla

Il progetto si appoggia al Gentoo Bugzilla per tener traccia di tutto. Tutti i bug report dovrebbero andare a finire qui.

Per maggiori informazioni, leggere la Guida alla Segnalazione di Bug in Gentoo.

2. Come Contribuire

2.a. Dove Contribuire

Prima di tutti, leggere la pagina dedicata ai canali di comunicazione con il progetto Gentoo Embedded e iscriversi come indicato. Per favore non cominciate a scrivere email ai singoli sviluppatori.

Di seguito si evidenzieranno i diversi modi in cui potrete dare una mano. Contribuite come e quando potete!

2.b. Arch Tester

Spesso considerata un'attività noiosa, è sfortunatamente critica per il corretto funzionamento di un port. Richiede il testing dei nuovi pacchetti che devono esser marcati come stabili o che non sono ancora stati testati su una specifica architettura. Semplicemente scegliete la vostra architettura embedded preferita (arm, m68k, mips, ppc, sh) e cominciate a tener d'occhio gli alias sul Gentoo Bugzilla. Quando viene aperto un bug di richiesta di stabilizzazione o di testing per una architettura, testate il pacchetto in questione nel vostro ambiente e riportate nel bug come sono andate le cose. Se desiderate contribuire ulteriormente, diventate sviluppatori dell'architettura in questione e cominciate direttamente a mandare voi stessi le correzioni! :) Visitate la pagina del progetto Gentoo Developer Relations per maggiori informazioni.

2.c. Release Engineers

Ogni release di Gentoo comporta stage aggiornati, base necessaria per creare nuove installazioni native. Ogni architettura (arm, m68k, sh) necessita di una persona dedicata che crei gli stage e che tenga traccia e corregga gli errori che via via vengono riscontrati.

2.d. Sviluppatori per uno specifico dispositivo

Avete un fantastico nuovo dispositivo embedded e ci volete metter su gentoo? Fatelo! Una volte che ce l'avrete fatta, mettete insieme un po' di informazioni a riguardo e fatele integrare nel Manuale di Gentoo Embedded. Dopo di che, cominciate a a creare delle immagini pronte all'uso per permettere ad altri di sfruttare tale tipologia di dispositivo e contribuire.

2.e. Rispondete alle Domande

Avete una buona conoscenza e vi piacere aiutare gli altri? Stupendo! Ogni giorno sulle nostre mailing list/sui nostri canali irc/etc... riceviamo domande che richiedono solo che qualcuno le le legga e risponda per quanto può. Magari imparerete anche voi un paio di cose!

2.f. Autori di Documentazione

Uno dei punti di forza di Gentoo è la documentazione. La quale però non si scrive da sola, per questo c'è bisogno di persone che conoscano il formato GuideXML per la documentazione così da dare una mano a mantenere ed espandere la documentazione sul progetto Gentoo Embedded.

3. Produttori di Hardware

3.a. Donazioni in Hardware

Ovviamente il primo modo per offrire supporto è attraverso l'hardware. È difficile sviluppare qualcosa senza avere l'hardware su cui testarlo. In genere ci sono due tipologie di macchine: (1) Piattaforme hardware generiche per lo sviluppo e (2) piattaforme specifiche per un particolare dispositivo. Una piattaforma generica può essere pensata come macchine per un uso "desktop" dove il sistema è autonomo, ha un ampio storage in locale (un harddisk per esempio e non una memoria flash), ed è dotato di connettività. Queste piattaforme sono molto utili perché permettono la generazione di software per una particolare architettura. Quando invece si fa riferimento a dispositivi specifici si intendono architetture come quelle di PDA o cellulari. L'obiettivo dello sviluppo in tal caso è quello di produrre un firmware utilizzabile su uno di questi dispositivi.

Se vi avanza dell'hardware, sentitevi liberi di contattare il Gentoo Embedded team per trovare la migliore destinazione per la vostra donazione. Grazie!

4. Ampliare le proprie Conoscenze

4.a. Libri

Libri sui Sistemi Embedded

• Building Embedded Linux Systems
• Designing Embedded Hardware
• Programming Embedded Systems
• Embedded Linux Primer
• Embedded Linux System Design and Development

Libri sul Kernel Linux

• Linux Device Drivers
• Understanding the Linux Kernel
• Linux Kernel in a Nutshell
• Linux Kernel Primer
• Understanding Linux Network Internals
• Linux Kernel Development

4.b. Collegamenti

Forum dedicati al mondo Embedded

• Embedded Linux Developer Forum
• The uClinux Distribution

Pagine relative alla cross-compilazione

• Cross GCC Mailing List
• crosstool-NG
• Crosstool

Progetti

• Binutils
• GCC
• Glibc
• Linux Kernel
• uClibc
• BusyBox

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.