OpenMoko/it
From Openmoko
OpenMoko è la distribuzione che stiamo creando per il GTA01. Ha il seguente stack software:
http://people.openmoko.org/sean/specifications/images/software_stack2007.png
Una versione stampabile si può trovare qui.
| NOTE: Questo articolo ha bisogno di essere aggiornato rispetto all'architettura corrente. |
Contents |
Kernel Space
The Kernel Space consiste nel Bootloader, il Kernel, e il Power Management (gestione energetica).
Bootloader
Il Bootloader è u-boot. In seguito dovrà avere le seguenti funzioni:
- Firmware Update – Un modo per scaricare codice eseguibile usando USB DFU
- RAM Loader – Fornire un metodo per eseguire codice direttamente dalla RAM del dispositivo
- Secure Memory Interface – Fornire un metodo per mettere in sicurezza l'interfaccia che permette di scrivere sia nella RAM sia nel FLASH. Questo serve all'utilizzatore per evitare che altri utenti modifichino le sue impostazioni. Non è per imporre un blocco da parte del venditore.
- Backup – Fornire un metodo per backuppare i dati del flash. Questo potrebbe anche permettere la condivisioni delle immagini fra utenti.
Kernel
Il kernel sarà basato sulla linea 2.6.17.x usando una parte delle patch di TomTom. TomTom ha fatto un grande lavoro con il processore delle applicazioni Samsung 2410 e ha raggiunto un ottimo supporto per le schede SD. Attualmente quelle patch garantiranno un supporto per le schede SD di praticamente tutte le aziende. Successivamente dovremmo inserire questi cambiamenti nel kernel. Il kernel sarà diviso fra i seguenti componenti:
Flash
Il flash avrà le funzioni di un MTD con un accesso standard di Linux. Farà girare il filesystem JFFS2 per tutto il flash. Ci piacerebbe anche sviluppare qualche tipo di crittazione sui dati dell'utente. Questo sarà successivamente configurato nell'Interfaccia Utente. Ma per adesso, dovremo mettere in piedi il framework di supporto.
Audio
Il driver dell'audio per i codec userà Advanced Linux Sound Architecture (ALSA). Questo è lo standard per le schede audio di Linux.
Retroilluminazione
Questo sarà un driver della classe di retroilluminazione LCD.
Tastierino
Il driver del tastierino userà il dispositivo standard di input /dev/input.
Touch Screen
Il driver del touch screen userà il dispositivo standard di input /dev/input.
USB
Ci serve un supporto USB host/client per Linux, OS X, e Windows. Dovrebbe supportare le seguenti funzioni:
- Mass Storage – Essere montato da un altro dispositivo
- Host Network – Fornire il supporto alla rete tramite USB
- Linux USB Gadget – Il metodo stardard per far funzionare il dispositivo come slave
Supporto a NFS Root
Questo servirà come uno dei nostri modi per sviluppare codice del dispositivo. Ci consentirà di avere un filesystem maggiore della reale dimensione del flash. Booting_from_NFS (in english)
Bluetooth
Il supporto del Bluetooth sarà basato sullo standard Linux detto BlueZ. Supporterà i seguenti profili:
- Headset – Per le comunicazioni wireless
- OBEX – Per il trasferimento di file
- HID – Sia per le tastiere Bluetooth sia per l'emulazione del tastierino (ad esempio per i dispositivi di controllo remoto)
- Network Emulation – Per il supporto di rete Bluetooth-based
TS07.10
Questa è la parte sull'interfaccia GSM. E' basata sull'idea di creare dispositivi seriali multipli partendo da un dispositivo seriale fisico singolo. Il codice sarà struttato per lavorare come il progetto openEZX e l'architettura originaria dei Motorola. Fornirà inoltre l'ipsec per connessioni VPN sicure. Il seguente diagramma delinea l'architettura generale:
http://people.openmoko.org/sean/specifications/images/gsm_interface.png
Una versione stampabile è disponibile qui.
Vibrazione
Dobbiamo definire la nostra interfaccia. Attualmente non c'è un modo predefinito di Linux per realizzare ciò. Mickey ha proposto di (ab)usare la nuova interfaccia sui LED.
Gestione energetica
La Power Management Unit si interfaccerà con le interfacce I2C standard di Linux. Le reali transizioni fra sati energici sono TBD.
User Space
| NOTE: Useremo le glibc (not uClibC) e libX11 (complete, non ridotte) per la prima incarnazione di questo prodotto. Le alternative potranno occupare meno spazio ed essere più ottimizzate, ma molto probabilmente daranno seri problemi di integrazione. Dovremo riconsiderare questa scelta per i prossimi rilasci. |
Linux Core Services
Molti di questi servizi fondamentali comprendono un demone e una libreria.
sshd
sshd attiva un login su shell remota tramite rete.
udev
udev è responsabile della gestione dei nodi di periferica nello pseudo-filesystem /dev.
bluez
bluez è il sistema Bluetooth di Linux.
dbus
dbus è un sistema di comunicazione interprocessuale.
GSM
- GSM - gestisce la comunicazione con il modulo GSM.
- gsmd - è reponsabile della gestione del GSM backend.
- libgsm - comunicherà con gsmd e esporterà un'API per le applicazioni.
GPS
- GPS - si occupa della comunicazione con il modulo GPS
- gpsd - è il demone di gestione del GPS backend. Esporterà inoltre l'interfaccia standard gpsd. C'è un plugin per supportare l'hardware del Neo1973.
Linux User Interface
Matchbox
Un leggero gestore di finestre da O-Hand
KDrive
KDrive-fbdev è un leggero server X che gira direttamente su un Linux FrameBuffer.
libX11
La libreria X11.
GTK+
GTK+ è un toolkit GUI molto fornito. E' la base del progetto Gnome
OpenMoko Application Framework
- Vedere OpenMokoFramework
Applicazioni native
Applicazioni Finger-Based (da attivare con le dita)
Si possono trovare specifiche complete per tutte le applicazioni Finger-Based qui.
Applicazioni Stylus-Based (da attivare con lo stilo)
Si possono trovare specifiche complete per tutte le applicazioni Stylus-Based qui.
Applicazioni X11
(TBD)
Ambiente di sviluppo
L'ambiente di sviluppo consiste nell'ambiente di Build, i Tool di Sviluppo, un Server di sviluppo, un Build Server, e Workstations di Sviluppo.
Build Environment
L'intero sistema sarà costruito con Open Embedded. Usando Open Embedded otteniamo un ottimo sistema di pacchetti. Usa una cosa detta “feed” per gestire collezioni di pacchetti. I feed sono basilarmente l'equivalente dei sorgenti Debian. Open Embedded ci garantirà un sistema completo stile PDA gratuitamente. Possiamo quindi passare tutto il nostro tempo a concentrarci su applicazioni specifiche del cellulare e sorvolare sull'integrazione con l'interfaccia utente.
Tool di Sviluppo
I Development tools ci aiuteranno a standardizzare i nostri metodi internamente ed esternamente con il resto del mondo. Dato che stiamo tentando di usare più software libero possibile, naturalmente dobbiamo impiegare software libero anche per i nostri tool di sviluppo. Segue una descrizione di ogni area di lavoro importante e i tool specifici di cui abbiamo bisogno:
- Sviluppo kernel – Il Kernel userà Git. Questo è lo standard corrente per il kernel Linux. Harald farà quasi tutto il lavoro sul kernel. Rilascerà patch che finiranno nel nostro albero Open Embedded.
- Sviluppo di applicazioni / tutto il resto - Sviluppo per le applicazioni principale del cellulare e proprio come ogni altro componente oltre al kernel useremo Subversion.
- Comunicazione fra sviluppatori - Tutti i messaggi fra sviluppatori devono passare per una mailing list. Useremo Mailman per questo scopo.
- Bug Tracking - Bugzilla sarà usato per tracciare bug e problemi.
- Documentazione - La documentazione del progetto sarà scritta su un Wiki e usando Doxygen. Il Wiki sarà usato per informazioni più generiche sul progetto. Doxygen sarà usato per documentare le singole librerie e le API importanti.
Server di Sviluppo
FIC Taipei ospiterà il server principale di sviluppo. Questo userà Debian Sarge. Sarà usato per controllare il nostro codice di sviluppo, tracciare i bug, e per le Mailing List. Subversion sarà ospitato su questo server con i seguenti metodi di connessione:
- https – Per i checkout dei sviluppatori
- http – Per i checkout in sola lettura
Build Server
FIC Taipei ospiterà il principale Build Server. Anche questo avrà Debian Sarge. Tutti gli sviluppatori principali avranno un account. Sarà usato per fornire una build giornaliera dell'intero codice e documentazione. Dopo ogni build, i risultati saranno inviati per email alla Developers Mailing List. Le build giornaliere saranno archiviate sul server fino a quando l'archivazione lo permetterà. Dopo aver raggiunto la fine, si masterizzeranno dei DVD per l'archiviazione.
Developer Workstations
I singoli sviluppatori dovrebbero usare una distro derivata da Debian. Al momento stiamo usando sia Ubuntu (6.0.6) sia Debian (3.1). Creiamo un pacchetto di base con tutti i tool di sviluppo principali. Gli sviluppatori lavoreranno su una build giornaliera fornita dal build Server. Loro caricheranno il codice in flash o semplicemente useranno lo script a disposizione per creare un filesystem root NFS dall'immagine della build giornaliera. Quando necessario, possono ricostruire tutti i pacchetti modificati usando il loro Open Embedded personale. Questi pacchetti saranno aggiunti al feed personale dello sviluppatore e possono essere commitati, se pronti, al feed principale.
La versione di sviluppo corrente di OpenMoko può essere ottenuta con rsync (al momento è down).
# rsync fic@buildhost.openmoko.org:deploy/ Password: openmoko
Puoi creare (e/o aggiornare) un mirror locale di pacchetti usando questo accesso rsync.
E' disponibile anche un accesso HTTP a http://buildhost.openmoko.org/tmp/deploy/
Impostare un OpenMoko SDK
- Segui le istruzioni basate sulla vostra Distro o guardare alla guida più generica OE Getting Started.
- Nota che per adesso hai bisogno di una revisione fissa di OpenEmbedded per far andare bene la build. Le revisioni testate più recenti sono:
f499733e6db527846e1a48cf70f9862d6b3798ae hrw@openembedded.org 2006-12-18T22:35:31
- local.conf dalla directory di build dovrebbe avere questo aspetto:
MACHINE = "fic-gta01" DISTRO = "openmoko" BUILD_ARCH = "i686"
- Scarica la directory dei metadati OpenMoko da svn
- Imposta in modo giusto le variabili di ambiente:
export OMDIR=$PWD export OEDIR=$PWD/openembedded export BBPATH=$OMDIR:$OMDIR/build:$OMDIR/metadata:$OMDIR/openembedded
- A seconda del vostro ambiente forse dovete modificare metadata/conf/site.conf.
