Finalmente è arrivato!
Il primo telefonino libero è tra noi, lo si può acquistare e funziona! Il gruppo di acquisto Firenze è stato tra i primi a ricevere il telefonino in Italia, l'acquisto collettivo è stato fatto presso la tedesca Handheld-Linux, che per 319 euri ha offerto il FreeRunner con astuccio e auricolari/microfono.
La scatola è spartana, ma con un suo stile. La documentazione praticamente assente rimanda alle pagine web dedicate ad OpenMoko. Per iniziare questo è il link: Getting Started.
Questo è il contenuto della confezione:
Alcuni link utili:
L'interfaccia utente non è intuitiva come quella del mio vecchio Nokia 1100, ma con il software originale sono stato in grado di inviare e ricevere SMS, fare e ricevere telefonate, accedere alla riga di comando. Il viaggio è appena cominciato!
Collegando il cavetto USB ad un computer GNU/Linux, il kernel riconosce il Neo FreeRunner:
usb 1-7: new full speed USB device using ohci_hcd and address 9 usb 1-7: configuration #1 chosen from 2 choices usb0: register 'cdc_ether' at usb-0000:00:0b.0-7, CDC Ethernet Device, 9e:e3:ed:c0:bd:58
il modulo kernel usbnet crea un'interfaccia usb0 che possiamo configurare. Per consentire al Neo l'accesso a internet configuriamo anche il DNAT per le richieste DNS (verso il nostro server DNS 192.168.2.2) e il MASQUERADE, in pratica facciamo da gateway e DNS server al Neo:
linux:~# ifconfig usb0 192.168.0.200 linux:~# iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.2.2 linux:~# iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -j MASQUERADE linux:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Per ottenere lo stesso effetto automaticamente al collegamento del cavetto USB, sul PC si aggiunge questo al file /etc/network/interfaces
:
allow-hotplug usb0 iface usb0 inet static address 192.168.0.200 netmask 255.255.255.0 network 192.168.0.0 post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 post-up iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.2.2 post-up echo 1 > /proc/sys/net/ipv4/ip_forward
Il Neo ha indirizzo predefinito 192.168.0.202, ha come default gateway e server DNS il 192.168.0.200, ha il server ssh (dropbear) attivo e la password di root è vuota:
linux:~# ssh root@192.168.0.202 The authenticity of host '192.168.0.202 (192.168.0.202)' can't be established. RSA key fingerprint is 68:b6:7e:cc:81:99:1a:30:f9:25:b9:60:6f:8c:84:d8. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.202' (RSA) to the list of known hosts. root@192.168.0.202's password: root@om-gta02:~#
Dalla shell ssh si aggiorna l'elenco dei pacchetti contenuti nel repository:
opkg update
L'aggiornamento di dropbear conviene farlo dalla finestra terminale del Neo
opkg upgrade dropbear
dalla shell ssh si può aggiornare tutto il resto:
opkg upgrade
Viene segnalato un problema grave del ricevitore GPS; in pratica la microSD inserita genera interferenza per cui il segnale dei satelliti viene molto disturbato.
Con l'aggiornamento del kernel (ho eseguito un upgrade completo il 2008-07-22) pare proprio che il workaround software sia stato installato; sono riuscito ad ottenere il primo fix in 162 secondi, il successivo in poco più di 20 secondi. Anche la forza del segnale ricevuto pare buona.
Esiste anche un workaround hardware: saldare un piccolo condensatore tra due contatti della microSD.
Ho eseguito un test sulle possibili interferenze della microSD con il ricevitore GPS secondo le linee guida della pagina Howto Test Your GPS with agpsui. Ho tenuto sempre la microSD inserita: nel primo test ho eseguito solo agpsui, nel secondo test ho lanciato anche la riproduzione di un brano .mp3 di circa 3 Mb per verificare se la lettura della flash influisce sulla ricezione del segnale GPS.
Il risultato è incoraggiante; sia il TTFF (inferiore al minuto) che la media dei segnali ricevuti (circa 129 dBm) sono del tutto simili nei due casi. I test sono stati eseguiti in condizioni ottimali di visibilità.
Durante l'accesso alla microSD:
Può darsi che la lettura del brano mp3 produca ben pochi accessi alla flash memory (cache, ecc.), ma si tratta di uno scenario abbastanza verosimile, paragonabile ad esempio alla lettura della mappa di un programma di navigazione. Sicuramente il fix software è stato installato (immagine del root filesystem OM2007.2 del 2008-07-22). Non so se dalla fabbrica è stato applicato anche qualche fix hardware. Ad ogni modo non c'è alcun condensatore visibile saldato sui contatti della microSD.
Queste le versione software/hardware del mio FreeRunner:
root@om-gta02:~# cat /etc/om-version Tag Name: VERSION: 905a9d7ec21de0835f9ee21cc5231acb66f3e339 Branch: org.openmoko.dev Build Host: buildhost.openmoko.org Time Stamp: Tue, 22 Jul 2008 02:51:41 +0200
root@om-gta02:~# libgsmd-tool -m shell libgsm-tool - (C) 2006-2007 by Harald Welte and OpenMoko, Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY rv # # Get revision revision: "HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8"
S/N: 8A8602500 DATE CODE: 20080621
Il FreeRunner è arrivato dalla fabbrica con installata la distribuzione OpenMoko 2007.2. Esistono altre distribuzioni per questo hardware. Ecco un riassunto:
Nell'ottimo articolo GTK, ASU, FSO? TMTLA! vengono confrontate le varie distribuzioni e si parla anche della promettente distribuzione FSO.
Probabilmente la direzione giusta a breve/medio termine è installare ASU. Un buon compromesso immediato potrebbe essere un dual boot 2007.2 e Qtopia, con quest'ultimo installato sulla microSD. I primi esperimenti ovviamente li ho fatti con 2007.2.
Il gestore pacchetti è opkg
(che sostituisce il vecchio ipkg
), i repository si configurano in /etc/opkg/
, i comandi più utili sono:
opkg list_installed opkg list opkg install <package>
In questa pagina sono elencati alcuni repository più o meno ufficiali. Interessante è l'Angstrom che contiene vari pacchetti (tra cui mc, navit, …). Con la distrbuzione attualmente installata sul FreeRunner si deve attingere dalla Angstrom armv4t, versione 2007.12.
Per aggiungere una icona nel menu applicazioni si crea un nuovo file .desktop nella directory /usr/share/applications
, poi si fa un restart del server X:
/etc/init.d/xserver-nodm restart
GPS e navigazione: queste le prime applicazioni che mi interessava sperimentare sul FreeRunner. Dopo le prime ore di uso si capisce chiaramente che il software di sistema è decisamente immaturo (OM2007.2); non è pensabile di usarlo quotidianamente per fare/ricevere telefonate o SMS. Questo mi ha preoccupato non poco, temendo che allo stato attuale ci fosse ben poco da sperimentare.
A livello applicativo la prima sorpresa positiva viene ta tangoGPS. Il software utilizza le mappe bitmap generate da OpenStreetMap, è in grado di fare il pre-load della zona interessata fino al livello di zoom desiderato. Durante l'uso si comporta in modo fluido, facilmente utilizzabile sia con lo stilo che con il dito: il primo programma che giustifica l'acquisto del FreeRunner! La versione per OpenMoko è scaricabile direttamente dal sito del progetto.
New 2009-02-02! Navit invece è un software di navigazione basato su mappa vettoriale (sempre OpenStreetMap). Il vantaggio è quello di poter scaricare tutta l'Italia in pochi megabyte (attualmente l'Italia occupa circa 21 Mb). L'usabilità delle attuali versioni (CVS 1873) è paragonabile a quella di tangoGPS, conviene installare il pacchetto precompilato per OpenMoko che contiene anche una patch che migliora notevolmente il panning della mappa (verificare che sia attiva l'opzione drag_bitmap=“1”
in navit.xml
). Il programma si lascia usare, sebbene con qualche spigolosità. La funzione di routing pare richiedere troppe risorse: appena si chiede di calcolare un percorso il programma rallenta al punto tale da diventare inutilizzabile. Speriamo che sia possibile ottimizzare l'algoritmo per renderlo compatibile con la CPU del Neo. Non ho provato ancora la funzione di indicazioni vocali, soprattutto perchè la sintesi vocale di espeak ancora non supporta i fonemi in italiano.
Prima di lanciare un programma di navigazione conviene disabilitare lo screen saver ed eventualmente forzare il fast-charge se l'adattatore da accendisigari non lo negozia automaticamente, questo è lo script che utilizzo su Om2008.9:
#!/bin/sh # Start the GPS daemon if not already running. if ! (ps uax | grep -v grep | grep -q /usr/sbin/gpsd); then /etc/init.d/gpsd start fi # Force current limit to 500 mA. # The FreeRunner draws only 100 mA from the car lighter. echo 500 > /sys/class/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous # Disable screen saver. xset s reset xset s off # Exec the program exec /usr/bin/navit
L'aggiornamento del software (applicativi e kernel) avviene generalmente via opkg, che provvede ad aggiornare i pacchetti e cerca di mantenere le configurazioni e personalizzazioni effettuate.
Eventualmente è possibile reinstallare tutto il sistema (perdendo le personalizzazioni) riscrivendo l'immagine del root filesystem e l'immagine del kernel nella flash memory.
Esiste un altro pezzo di software nel Neo: il bootloader U-Boot. Questo svolge le operazioni che su un normale sistema GNU/Linux vengono eseguite da GRUB, inoltre ha alcune funzioni tipiche del BIOS di un PC. Per aggiornare U-Boot è necessario flashare l'immagine nella memoria flash.
Se per avviare il Neo si tiene premuto il tasto AUX e si preme per pochi secondi il tasto Power si accede al menu di U-Boot.
Il menu U-Boot predefinito del FreeRunner consente di avviare da una installazione alternativa sulla microSD. Un motivo per flashare l'ultima versione di U-Boot è che la vecchia versione di U-Boot (1.3.2-moko12) richiede che il kernel alternativo risieda su una partizione vfat della microSD, mentre le versioni a partire dal 2008-07-23 accettno anche partizioni ext2/3.
Con il Neo 1973 (predecessore del FreeRunner) aggiornare l'U-Boot potrebbe essere pericoloso: se l'operazione non va a buon fine il Neo potrebbe non avviarsi e potrebbe essere impossibile anche entrare nel menu U-Boot per ripetere l'operazione di flash. Il FreeRunner invece ha due copie del boot loader, una nella flash NAND e un'altra nella NOR flash, quindi dovrebbe essere sempre possibile avviare il FreeRunner.
Il FreeRunner contiene due copie del boot loader U-Boot; è possibile scegliere quale usare al momento del bootstrap.
Accendere il FreeRunner tenendo premuto il tasto AUX e premendo il pulsante POWER, si accede al menu U-Boot contenuto nella memoria NOR (piccola memoria flash, contiene solo questo boot loader di emergenza):
U-Boot 1.3.2-moko12 (May 9 2008 - 10:28:48) *** BOOOT MENU (NOR) *** Boot Boot from microSD (FAT+ext2) Set console to USB Set console to serial Reboot Power off Press [AUX] to select, [POWER] to execute.
Le versioni di U-Boot antecedenti al 2008-07-23 non riescono a fare boot da una partizione ext2 o ext3 della microSD a causa di un bug. Tuttavia per aggiornare il contenuto della memoria NOR bisogna utilizzare la debug board.
Per accedere al U-Boot contenuto nella memoria NAND accendere il FreeRunner tenendo premuto il tasto POWER e premere contemporaneamente il tasto AUX per circa 7 secondi, compare il menu:
U-Boot 1.3.2-rc2-dirty-moko12 (Apr 9 2008 - 09:31:05) *** BOOOT MENU (NAND) *** Boot Boot from microSD (FAT+ext2) Set console to USB Set console to serial Set console to USB Set console to serial Reboot Power off Press [AUX] to select, [POWER] to execute.
A causa del bug visto sopra, volendo fare un'installazione su microSD ed ext3, bisogna aggiornare U-Boot.
NOTA: ext3 potrebbe causare un invecchiamento precoce della SD a causa delle continue riscritture del journal. Almeno in teoria le memorie SD dovrebbero supportare il wear leveling per attenuare il problema.
Per flashare l'U-Boot in NAND si deve ovviamente partire da quello in NOR. Si installa il pacchetto Debian dfu-util sul PC di appoggio, si scarica l'immagine (ad esempio gta02v5_and_up-u-boot.bin
) e si esegue questa procedura:
dfu-util -a u-boot -R -D gta02v5_and_up-u-boot.bin
Per evitare problemi di permessi il comando è stato eseguito da utente root:
linux# dfu-util -a u-boot -R -D gta02v5_and_up-u-boot.bin dfu-util - (C) 2007 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY Opening USB Device 0x0000:0x0000... Claiming USB DFU Runtime Interface... Determining device status: state = appIDLE, status = 0 Device really in Runtime Mode, send DFU detach request... Resetting USB... Opening USB Device... Found Runtime: [0x1d50:0x5119] devnum=8, cfg=0, intf=0, alt=1, name="u-boot" Claiming USB DFU Interface... Setting Alternate Setting ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Transfer Size = 0x1000 bytes_per_hash=4330 Starting download: [##################################################] finished! state(2) = dfuIDLE, status(0) = No error condition is present Done! Resetting USB to switch back to runtime mode
Durante l'aggiornamento di oggi (2008-07-28) qualcosa è andato storto: il pacchetto kernel-image-2.6.24 è stato aggiornato alla versione corrente, ma pare che contenga un errore. La procedura di installazione con opkg
ha cancellato l'immagine presente nella flash, ma non ha scritto quella nuova. Di conseguenza il boot successivo ha fallito, rimanendo bloccato sullo splash screen. È stato necessario rimuovere la batteria per spengere il FreeRunner.
Avviando con il menu di U-Boot (premendo il tasto Power mentre si tiene premuto il tasto AUX) e scegliendo l'opzione boot si riesce a leggere i messaggi altrimenti coperti dallo splash screen, ho potuto notare che l'immagine del kernel era corrotta e falliva il checksum.
Bene (anzi, malissimo!!!) è l'occasione giusta per imparare a flashare l'immagine del kernel dal menu di U-Boot.
Anzitutto ho scaricato l'immagine del kernel corrente. Attenzione: bisogna che l'immagine corrisponda alla versione dei moduli installati nel root filesystem, nel mio caso dovevano essere gli ultimi disponibili visto che avevo eseguito un opkg update
e un opkg upgrade
. L'aggiornamento quotidiano dei pacchetti avviene dai seguenti URL:
http://buildhost.openmoko.org/daily-feed/all/Packages.gz http://buildhost.openmoko.org/daily-feed/armv4t/Packages.gz http://buildhost.openmoko.org/daily-feed/neo1973/Packages.gz http://buildhost.openmoko.org/daily-feed/om-gta02/Packages.gz
Ho cercato il file uImage-om-gta02-latest.bin più recente in
http://buildhost.openmoko.org/daily/freerunner/
Sul PC ho anche installato il pacchetto Debian dfu-util. L'operazione di flash del nuovo kernel è semplice:
linux:~# dfu-util -a kernel -R -D ./uImage-om-gta02-latest.bin
Questo è l'output del comando dfu-util
:
dfu-util - (C) 2007 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY Opening USB Device 0x0000:0x0000... Claiming USB DFU Runtime Interface... Determining device status: state = appIDLE, status = 0 Device really in Runtime Mode, send DFU detach request... Resetting USB... Opening USB Device... Found Runtime: [0x1d50:0x5119] devnum=10, cfg=0, intf=0, alt=3, name="kernel" Claiming USB DFU Interface... Setting Alternate Setting ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Transfer Size = 0x1000 bytes_per_hash=35797 Starting download: [##################################################] finished! state(2) = dfuIDLE, status(0) = No error condition is present Done! Resetting USB to switch back to runtime mode
Al termine dell'operazione l'immagine del kernel è risultata corretta e il FreeRunner ha potuto fare nuovamente bootstrap.
NOTA: con questa stessa procedura è possibile installare la nuova versione di sviluppo 2008.9, erede di ASU. Le immagini di Om2008.9 sono disponibili per il download.
ASU è la August Software Update, nuova versione di OpenMoko prevista per Agosto 2008. Si tratta del porting di Qtopia su X.
Si installa ASU su una microSD in modo da avere il dual boot con il sistema operativo originale (OM2007.2). Le pagina con le istruzioni complete è Booting from SD, qui ho fatto solo un riassunto.
Inserita una microSD nel PC e formattata secondo questo schema:
Device Boot Start End Blocks Id System /dev/sdb1 1 5 10048+ 6 FAT16 /dev/sdb2 6 130 252000 83 Linux /dev/sdb3 131 984 1721664 83 Linux
Copiato il kernel in sdb1 e scompattato il root filesystem in sdb2. La terza partizione verrà utilizzata come spazio dati e montato in /media/card/
.
wget http://buildhost.openmoko.org/daily/freerunner/200807/20080722/openmoko-qtopia-x11-image-om-gta02.tar.gz mount /dev/sdb1 /media/sdb1 mount /dev/sdb2 /media/sdb2 cp /media/sdb2/boot/uImage-2.6.24 /dev/sdb1/uImage.bin tar -C /media/sdb2 -xzvf openmoko-qtopia-x11-image-om-gta02.tar.gz
Se vogliamo che la terza partizione venga montata in /media/card/
, si deve mettere in blacklist le prime due partizioni in /etc/udev/mount.blacklist
(con il nome che viene assegnato al device dal kernel del Neo):
/dev/mmcblk0p1 /dev/mmcblk0p2
inoltre si modifica /etc/fstab:
/dev/mmcblk0p3 /media/card auto defaults,async,noatime,noauto 0 0
Riassumendo i paragrafi precedenti, questo è un esempio di come si effettua il backup e la reinstallazione completa del FreeRunner (perdendo tutte le personalizzazioni).
ATTENZIONE: fare il dump di una partizione della memoria flash crea un file di dimensioni pari all'intera partizione, ben superiori alla dimensione delle immagini utilizzate per flashare inizialmente il device.
In teoria dovrebbe essere possibile fare il backup delle immagini contenute nella memoria flash con l'utility dfu-util
. Tuttavia esiste un grave bug nell'upload dal device al PC (opzione -U
), per cui le immagini scaricate dal FreeRunner risultano corrotte e non utilizzabili. Se ad esempio si flasha nuovamente sul FreeRunner l'immagine del kernel ottenuta con il procedimento seguente, si ottiene un checksum error durante la fase di boot e conseguente blocco.
Il bug è confermato con U-Boot 1.3.2-moko12 (2008-12-18) e dfu-util r4067.
Ad ogni modo, questa sarebbe la procedura (da non usare a causa del bug!):
# WARNING! OpenMoko bug #1843 produces bad images! dfu-util -a kernel -R -U bkp_kernel.bin dfu-util -a splash -R -U bkp_splash.bin dfu-util -a u-boot -R -U bkp_u-boot.bin dfu-util -a u-boot_env -R -U bkp_u-boot_env.bin
Per salvare l'immagine del rootfs (partizione rootfs) si potrebbe procedere in modo analogo, ma il file ottenuto avrebbe il difetto di occupare tutta la dimensione della flash (250 Mb), non il solo spazio effettivamente usato dai file.
Ecco la dimensione e il contenuto di ciascuna partizione:
splash.bin | 640 Kb | Dump dello splash-screen compresso gzip (480x640x16 frame buffer, RGB bits = 5:6:5, HWSWP = 1). |
---|---|---|
kernel.bin | 8.0 Mb | Immagine del kernel (u-boot/PPCBoot image). |
u-boot.bin | 256 Kb | Il boot loader U-Boot. |
u-boot_env.bin | 256 Kb | La configurazione di U-Boot, editabile con envedit.pl. |
rootfs.jffs2 | 247 Mb | Immagine del root filesystem, di tipo jffs2. |
Per aggirare il bug di dfu-util
/U-Boot
si può fare il dump della flash con nanddump
, i requisiti per usare questo metodo sono:
nanddump
.Verifichiamo le partizioni sulla flash
cat /proc/mtd dev: size erasesize name mtd0: 00200000 00010000 "physmap-flash.0" mtd1: 00040000 00020000 "u-boot" mtd2: 00040000 00020000 "u-boot_env" mtd3: 00800000 00020000 "kernel" mtd4: 000a0000 00020000 "splash" mtd5: 00040000 00020000 "factory" mtd6: 0f6a0000 00020000 "rootfs"
effettuiamo il dump di un paio di esse:
nanddump --omitoob -f mtd1_u-boot.dump /dev/mtd1 nanddump --omitoob -f mtd3_kernel.dump /dev/mtd3
Omettiamo dal dump i byte out-of-band (OOB), che contengono informazioni di servizio (bad block marks, error correction codes).
Il file così ottenuto deve essere identico a quello usato durante il flashing iniziale, a meno della dimensione. Ecco come confrontare i due file solo per i primi byte:
cmp --bytes=1780096 Om2008.12-om-gta02.uImage.bin mtd3_kernel.dump
Il kernel dovrebbe essere disponibile anche come file /boot/uImage
sul FreeRunner, ma nel mio caso differisce di 7 byte rispetto all'originale.
Il dump della partizione rootfs con questo metodo è sconsigliato, sia per per i motivi di dimensione visti sopra, sia perché il contenuto non è consistente: alcuni file e directory presenti sul FreeRunner non risultano quando si monta l'immagine via loop device (perché? ).
Per effettuare il dump del rootfs vedere il metodo che segue.
Come accennato, il dump della partizione flash crea un file pari alla dimensione della partizione. Per il root filesystem è particolarmente penalizzante sia per lo spazio occupato (250 Mb) sia per il tempo impiegato.
Ecco quindi una procedura alternativa per ottenere un'immagine jffs2 di backup, pronta per essere flashata. Il tutto si esegue da una shell del FreeRunner, l'immagine viene trasferita sul PC (192.168.0.200) via ssh:
opkg install mkfs-jffs2 mkdir /var/volatile/tmp/rootfs mount -t jffs2 /dev/mtdblock6 /var/volatile/tmp/rootfs mkfs.jffs2 -d /var/volatile/tmp/rootfs -e 128 --pad --no-cleanmarkers -x lzo \ | ssh root@192.168.0.200 'cat > rootfs.jffs2' umount /var/volatile/tmp/rootfs
L'immagine jffs2 viene generata sul FreeRunner, per questo è necessario installare il pacchetto mkfs-jffs2
. La procedura impiega circa 20 minuti per 110 Mb.
Jffs2 è un filesystem journaled specifico per memorie flash MTD. Per montare un'immagine jffs2 si può usare l'emulazione MTD su block device offerta dal kernel:
losetup /dev/loop0 Om2008.12-om-gta02.rootfs.jffs2 modprobe block2mtd block2mtd=/dev/loop0,131072 cat /proc/mtd modprobe jffs2 modprobe mtdblock mount -t jffs2 -o ro /dev/mtdblock0 /mnt
NOTA1: il FreeRunner ha architettura little-endian come i processori x86, su altre architettura è necessario convertire il file jffs2 prima di montarlo.
NOTA2: se si realizza uno script con i comandi sopra, considerare che i vari modprobe richiedono alcuni istanti prima di essere operativi, occorre inserire degli sleep opportuni.
NOTA3: un bug nel kernel Linux prima della versione 2.6.25 può provocare dei kernel panic montando un filesystem jffs2. Il crash è preceduto da errori del tipo:
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00fe6710: 0x7b2b instead jffs2_scan_inode_node(): CRC failed on node at 0x0f5f2bf4: Read 0xb4f0ed85, calculated 0xc9878958
La procedura effettua il trasferimento tramite cavetto USB con l'utility dfu-util
.
Entrare nel menu U-Boot con uno dei metodi visti sopra ed eseguire questi comandi per installare le nuove versioni (tra un upload e l'altro il FreeRunner potrebbe spengersi):
dfu-util -a u-boot -R -D gta02v5_and_up-u-boot.bin dfu-util -a kernel -R -D Om2008.12-om-gta02.uImage.bin dfu-util -a rootfs -R -D Om2008.12-om-gta02.rootfs.jffs2 dfu-util -a splash -D Om2008.9.splash.gz
NOTA: L'immagine 2008.12 utilizza i repository http://downloads.openmoko.org/repository/Om2008.8/, vedi /etc/opkg/*.conf
.
Per testare le possibilità di programmazione sul FreeRunner ho voluto scrivere un piccolo programma che gestisce le connessioni PPP. Essendo scritto in Python GTK, il nome è ovviamente PyPPP. Le istruzioni su come usare la connessione GPRS sono un po' confuse, inoltre mi sono scontrato con uno strano problema relativo all'inizializzazione del modem.
Considerato che è il mio secondo programma in Python (il primo in cui ho usato le GTK) il risultato mi soddisfa abbastanza. La home page del progetto è su projects.openmoko.org dove potete trovare i sorgenti e il supporto. Per l'installazione potete usare lo script install.sh
che provvede anche a installare un'icona per il desktop. Si può utilizzare sia con lo stilo che con il dito.
Per far funzionare PyPPP bisogna prima configurare la connessione PPP; io ho una connessione con Wind ed ho usato i file mostrati in questa pagina: Wind pppd scripts.
Gli script consentono di avviare e fermare la connessione rispettivamente con i classici comandi pon
e poff
. Prima di eseguire pon
bisogna fermare il demone gsmd
e resettare opportunamente il modem, dopo aver terminato la connessione bisogna riavviare gsmd
. A tutto questo provvede ovviamente PyPPP.
Per eseguire PyPPP con Om2008.9 è sufficiente installare il pacchetto python-pygtk
e python-subprocess
.
Con Om2007.2 risolvere le dipendenze non è stato semplice perché i repository attualmente mi paiono un po' confusi. Ad ogni modo l'elenco dei pacchetti che ho installato è il seguente:
e li ho scaricati da buildhost.automated.it e da www.angstrom-distribution.org.
WARNING: It seems that there is a problem after the ppp connection is terminated. Despite the gsmd daemon is restarted I cannot send SMS messages. Another user reported that he must restart the Xserver to register again with the telco operator.
Con la distribuzione Om2008.9 conviene installare il pacchetto illume-config
, fornisce una tastiera multifunzione finger/stylus. Per essere sicuri che la tastiera di Qtopia sia disabilitata aggiungere in /etc/X11/Xsession.d/89qtopia
la riga:
export QTOPIA_NO_VIRTUAL_KEYBOARD=1
I file di configurazione della tastiera sono in /usr/lib/enlightenment/modules/illume/keyboards
. Con l'installazione del pacchetto compare la scritta qwerty in alto a sinistra, per attivare o disattivare la tastiera. Nel top shelf compare anche l'icona chiave inglese per accedere al menu Configuration di illume.
Sfortunatamente con Om2007.2 non è stata ancora implementata la possibilità di passare dalla tastiera multi-tap (usabile con il dito) ad una QWERTY (usabile solo con lo stilo). Preferendo quella completa ho seguito le istruzioni per installare la Matchbox keyboard. In pratica si scarica l'archivio keyboard-ipk.tar.bz2, si disinstalla (con opkg remove -force-depends
) il pacchetto originale multitap-pad e si installano i file .ipkg contenuti nell'archivio.
Se si desidera un'icona nel systray per attivare e nascondere la tastiera basta aggiungere keyboard all'elenco degli applet nel file /etc/matchbox/session
.
Unfortunately I got several troubles using the FreeRunner. The overall impression is that the device is not so reliable; most of the time is surely a software issue, but sometimes also the hardware seems not to be rock solid. Here are some of the issues that I catched in the first week of use.
Starting kernel
message. After an hour and cooling down the Neo in the shadow, the boot succeeded./usr/share/i18n/locales
).gpe-scap
fails to open /lib/libc.so
, make a link: ln -s libc.so.6 /lib/libc.so
Alcune componenti hardware del Neo FreeRunner: