Gentoo Logo

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.

Variabile Significato quando si genera una Cross-Toolchain Significato quando si generano dei "Cross-Binari"
CBUILD Piattaforma su cui si sta compilando Piattaforma su cui si sta compilando
CHOST Piattaforma su cui la cross-toolchain sarà eseguita Piattaforma su cui saranno eseguiti i binari compilati dalla cross-toolchain
CTARGET Piattaforma su cui sarano eseguiti i binari compilati dalla cross-toolchain Piattaforma su cui sarano eseguiti i binari compilati dalla cross-toolchain. Ridondante, ma non c'è pericolo se si imposta questa variabile, e solo pochi binari si comportano allo stesso modo.
ROOT Percorso alla root virtuale (/) dove si andrà a installare
PORTAGE_CONFIGROOT Percorso alla root virtuale (/) dove portage potrà trovare i suoi file di configurazione (come /etc/make.conf)

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ì:

Variabile Valore per Generare la Cross-Toolchain Valore per Generare i "Cross-Binari"
CBUILD x86_64-pc-linux-gnu x86_64-pc-linux-gnu
CHOST x86_64-pc-linux-gnu arm-unknown-linux-gnu
CTARGET arm-unknown-linux-gnu non impostato
ROOT non impostare -- Come impostazione predefinita punta a / /percorso/dove/verrà/installato
PORTAGE_CONFIGROOT non impostare -- Come impostazione predefinita punta a / /percorso/ambiente/portage/per/arm/

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.

Codice 2.1: Installare crossdev

# emerge crossdev

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

Nota: Se si sta effettuando un aggiornamento da una vecchia versione di crossdev, e c'è crossdev-wrappers installato, assicurarsi prima di disinstallare crossdev-wrappers. Le cross-toolchain esistenti rimarranno intatte.

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:

Codice 2.2: Opzioni di crossdev utili

(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.

Codice 2.3: Generazione del cross-compilatore per SH4

# 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 ]

Nota: Al momento non è possibile assegnare a PORTAGE_CONFIGROOT una directory predisposta per l'architettura di destinazione prima di invocare crossdev, bisogna invece usare la propria configurazione. Se si vogliono usare FLAG use specifiche per architettura, come altivec su un'architettura non powerpc, bisogna smascherare la flag use in /usr/portage/base/use.mask, o cambiare temporaneamente il proprio profilo.

Test Veloce

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

Codice 2.4: test del cross-compilatore per SH4

$ 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.

Codice 2.5: disinstallare il cross-compiler

# 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

Avvertenza: Questa sezione è inclusa per i posteri, nella speranza che possa essere utile ad altri. I lettori a cui è dedicata sono coloro che (per una ragione o per l'altra) vogliono crearsi a mano, tutto da soli, il proprio cross-compilatore usando binutils/(glibc|uclibc)/gcc . Questa sezione non è intesa per illustrare/documentare/quelchevolete la miriade di errori di compilazione che quasi sicuramente si incontreranno lungo la via. Se avete bisogno di tale supporto, leggete la sezione Ampliare le proprie Conoscenze del Manuale, ma non lamentatevi con l'autore o chiunque altro all'interno di Gentoo.

Avvertenza: Se state ancora leggendo, dovreste controllare il progetto CrossTool (fate riferimento alla sezione Ampliare le proprie Conoscenze) che fornisce un metodo generico adatto ad ogni distribuzione per generare un cross-compilatore. Pur essendo, a giudizio dell'autore, poco più che un accrocchio, è sicuramente la migliore, nonché l'unica, via percorribile per ottenere un cross-compilatore.

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 .

Codice 3.1: tipico layout di una sysroot

/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!

Nota: Note pre sysroot:
Il vecchio metodo per cross-compilare imponeva l'uso di --prefix=/usr/$CTARGET. Se si stanno usando versioni di binutils/gcc antecedenti al supporto al sysroot, ci si potrebbe trovar a dover agire come sopra indicato. Non sarà però qui illustrato il come, in quanto (1) non si dovrebbero usare versioni così datate/arrugginite/bacate di tali componenti e (2) sarebbe molto più scomodo e problematico in confronto a sysroot.

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.

Codice 3.2: configurazione e compilazione delle binutils

$ ./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:

Codice 3.3: ripuliamo le binutils

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

Installare quindi quanto rimasto :

Codice 3.4: installazione delle binutils

# 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.

Nota: Ricordarsi di sostituire $ARCH con un valore sensato per la propria architettura.

Codice 3.5: Compilazione/installazione degli header grezzi

$ 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

Codice 3.6: compilazione/installazione degli header ripuliti

# 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.

Codice 3.7: compilazione/installazione degli header delle glibc

$ 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:

Codice 3.8: diamo una mano alle glibc

# 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.

Codice 3.9: diamo una mano al gcc

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

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

Codice 3.10: compilazione del gcc stage 1

$ 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.

Codice 3.11: ripuliamo il gcc stage 1

$ 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):

Codice 3.12: installazione del gcc stage 1

# cp -a install-root/* /

Libc di Sistema

Eliminare la vecchia cartella di compilazione del gcc e ricrearla.

Codice 3.13: compilazione/installazione delle glibc

$ 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++.

Codice 3.14: compilare/installare il gcc stage 2

$ ./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.

File forniti dalle glibc
File Funzione
crt0.o Vecchio stile del runtime code iniziale ? Nessuno lo genera più.
crt1.o Nuovo stile del runtime code iniziale. Contiene il simbolo _start che configura l'ambiente con argc/argv/libc_init/libc_fini prima di passare al main della libc. Le glibc chiamano questo file 'start.S'.
crti.o Definisce la funzione prolog; _init nella sezione .init e _fini nella sezione .fini. Le glibc chiamano questo file 'initfini.c'.
crtn.o Definisce la funzione epilog. Le glibc chiamano questo file 'initfini.c'.
Scrt1.o Usato al posto di crt1.o quando si creano eseguibili PIE.
gcrt1.o Usato al posto di crt1.o quando si crea codice con informazioni per il profiling. Compila con -pg. Produce in output dei file adatti al programma gprof.
Mcrt1.o Come gcrt1.o, ma è usato con il programma prof. Dal momento che è inutile sui sistemi linux, le glibc ne installano una versione fittizia.
File forniti dal GCC
File Funzione
crtbegin.o Usato dal GCC per trovare l'inizio dei costruttori.
crtbeginS.o Usato al posto di crtbegin.o quando si creano shared objects o eseguibili PIE.
crtbeginT.o Usato al posto di crtbegin.o quando si creano eseguibili statici.
crtend.o Usato dal GCC per trovare l'inizio dei distruttori.
crtendS.o Usato al posto di crtend.o quando si creano shared objects o eseguibili PIE.

L'ordine generale in fase di linking:

Codice 3.15: 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.

Variabile Significato
CBUILD Piattaforma su cui si sta compilando
CHOST Piattaforma per cui si sta compilando
ROOT La / virtuale sulla quale si sta installando
PORTAGE_CONFIGROOT La / dove portage può trovare i suoi file di configurazione (come make.conf)

È 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.

Codice 3.1: wrapper di crossdev

# emerge crossdev

Nota: Prima di iniziare un qualsiasi cross-emerge, bisogna eseguire emerge-wrapper --init. Assicurarsi di seguire ogni istruzione stampata a video da emerge-wrapper, prima di cominciare con il proprio cross-emerge.

È 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:

Codice 3.2: CTARGET-emerge

# 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.

Codice 3.3: ${SYSROOT}/etc/make.profile

# 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.

Codice 3.4: ${SYSROOT}/etc/make.conf

# $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.

Codice 2.1: Modifica del Makefile nella directory radice

# 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-

Codice 2.2: Valorizzare le variabili da linea di comando

# 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.

Codice 2.3: 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.

Codice 3.1: Configurazione e Compilazione

# 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 :

Codice 1.1: 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

Codice 2.1: CPU Info

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

Codice 3.1: Setup uClibc

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

Codice 3.2: Setup uClibc + EABI

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:

2. LANTank

2.a. Specifiche di IO-Data LANTANK:

Codice 1.1: Specifiche della Scheda

# 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

Codice 2.1: CPU Info

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

Codice 3.1: Setup

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

Codice 3.2: Emerge Wrapper (lantank-merge)

#!/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 "$@"

Codice 3.3: /usr/sh4-unknown-linux-gnu/etc/make.conf


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:

3. NetWinder

3.a. Rebel NetWinder

Codice 1.1: Specifiche della Scheda

# 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

Codice 2.1: CPU Info

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

Codice 3.1: Setup

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

Codice 3.2: Emerge Wrapper (netwinder-merge)

#!/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 "$@"

Codice 3.3: /usr/armv4l-unknown-linux-gnu/etc/make.conf


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:

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.

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

Codice 2.1: Specifiche della Scheda

# 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

Codice 3.1: CPU Info

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

Codice 4.1: Setup

emerge crossdev
crossdev armv5tel-softfloat-linux-gnueabi

Codice 4.2: Emerge Wrapper (qnap-merge)

#!/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 "$@"

Codice 4.3: /usr/armv5tel-softfloat-linux-gnueabi/etc/make.conf

#
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:

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.

6.b. Specifiche Marvell Sheevaplug

Codice 2.1: Specifiche della scheda

# 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

Codice 3.1: CPU Info

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:

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

Codice 2.1: Specifiche della scheda

# 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

Codice 3.1: CPU Info

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

Codice 4.1: Messaggi del kernel

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:

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.

8.b. Specifiche Genesi Efika MX

Codice 2.1: Specifiche della scheda

# 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

Codice 3.1: CPU Info

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:

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.

9.b. Specifiche Pandaboard

Codice 2.1: Specifiche Scheda

# 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

Codice 3.1: CPU Info

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:

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.

10.b. Specifiche TrimSlice

Codice 2.1: Specifiche sulla scheda

# 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

Codice 3.1: CPU Info

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:

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.

11.b. Specifiche Beaglebone

Codice 2.1: Specifiche della scheda

# 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

Codice 3.1: CPU Info

(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:

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

Libri sul Kernel Linux

4.b. Collegamenti

Forum dedicati al mondo Embedded

Pagine relative alla cross-compilazione

Progetti

Stampa

Aggiornato il 3 gennaio 2013

Oggetto: Il Manuale Gentoo Embedded vuole essere il punto di riferimento per tutti i progetti Embedded sviluppati con Gentoo. Punta infatti a coprire tutti gli aspetti del processo di sviluppo -- dalla teoria al design alla pratica.

Mike Frysinger
Autore

Ned Ludd
Autore

Robin H. Johnson
Autore

Alex Tarkovsky
Autore

Alexey Shvetsov
Autore

Raúl Porcel
Autore

Joshua Saddler
Redazione

Andrea Perotti
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.