Openmoko under QEMU/it

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Quale hardware è supportato)
 
(46 intermediate revisions by 5 users not shown)
Line 1: Line 1:
QEMU può essere utilizzato in tre diversi modi per eseguire [[OpenMoko/it|OpenMoko]]. A seconda del motivo per cui stai per usare l'emulatore, dovresti scegliere la soluzione più adatta.
+
{{Languages|Openmoko under QEMU}}
 +
QEMU può essere utilizzato in tre diversi modi per eseguire [[Openmoko/it|Openmoko]]. Dovresti scegliere la soluzione più adatta, a seconda del motivo per cui stai per usare l'emulatore.
  
*''PC'' - OpenMoko può essere compilato per essere eseguito su una normale macchina i386, a 32 o a 64 bit e probabilmente questa è la via più veloce per eseguire OpenMoko se vuoi una anteprima su come appare e funziona. In questo caso QEMU verrà utilizzato unicamente per isolare l'installazione [[OpenMoko/it|OpenMoko]] dal resto del sistema, o, se non stai usando un sistema UNIX, QEMU fornirà un modo non intrusivo e veloce per ottenere una macchina Linux. Altre informazioni possono essere trovate in [[FAQ/it|FAQ]], [[Getting OpenMoko working on host with Xoo/it|qui]] e [[Getting OpenMoko working on host with Xephyr/it|qui]].
+
*''PC'' - Openmoko può essere compilato per essere eseguito su una normale macchina i386, a 32 o a 64 bit. Probabilmente questa è la via più veloce per eseguire Openmoko se vuoi una anteprima sul suo aspetto e funzionamento. In questo caso QEMU verrà utilizzato unicamente per isolare l'installazione [[Openmoko/it|Openmoko]] dal resto del sistema o, se non stai usando un sistema UNIX, QEMU fornirà un modo non intrusivo e veloce per ottenere una macchina Linux. Altre informazioni si trovano in [[FAQ/it|FAQ]], [[Getting Openmoko working on host with Xoo/it|qui]] e [[Getting Openmoko working on host with Xephyr/it|qui]].
  
*''Integrator/CP'' - Questa è la macchina ARM-based di default che QEMU utilizza. Questo metodo va utilizzato con MACHINE="qemuarm" ed è sufficiente per eseguire l'immagine rootfs originale di OpenMoko, nessun componente hardware tra [[:Category:Neo1973 Hardware/it | Neo1973 Hardware]] verrà emulato, ad eccezione della CPU. Altre informazioni in [[FAQ/it#Q:_Is_there_an_emulator_available_for_OpenMoko.3F|FAQ]].
+
*''Integrator/CP'' - Questa è la macchina basata sul ARM di QEMU di difetto. Questo metodo va utilizzato con MACHINE="qemuarm" ed è sufficiente per eseguire l'immagine rootfs originale di Openmoko, nessun componente hardware tra [[:Category:Neo1973 Hardware/it | Neo1973 Hardware]] verrà emulato, ad eccezione della CPU. Altre informazioni in [[FAQ/it#Q:_C.27.C3.A8_un_emulatore_disponibile_per_Openmoko.3F|FAQ]].
  
*''Neo1973'' - Nei repositories OpenMoko è disponibile una versione di QEMU in grado di emulare la maggior parte dell'hardware [[Neo1973/it|Neo1973]] ma non tutto per ora. Quando il progetto sarà più maturo verrà integrato nel ramo di sviluppo principale di QEMU.
+
*''Neo1973'' - Nei repositori Openmoko è disponibile una versione di QEMU in grado di emulare la maggior parte dell'hardware [[Neo1973/it|Neo1973]] ma non tutto per ora. Quando il progetto sarà più maturo verrà integrato nel ramo di sviluppo principale di QEMU.
  
 
== Emulazione Neo1973 ==
 
== Emulazione Neo1973 ==
  
Questo metodo permette (ovviamente) di eseguire l'immagine rootfs originale di OpenMoko, dovrebbe essere anche in grado di eseguire l'u-boot originale e le immagini del kernel, le stesse che usa un Neo1973 reale. Altra differenza rispetto al metodo Integrator/CP, è che in questo modo possiamo ottenere una risoluzione corretta dello schermo, alcune (false) letture della batteria e altre cose simili. Attualmente, le parti mancanti all'emulatore sono: [[Hardware:AGPS/it|AGPS]] e [[Bluetooth/it|Bluetooth]] - il lavoro su questa parti procede. Anche con queste parti mancanti, QEMU dovrebbe fornire un aiuto sostanziale agli sviluppatori nel debugging del kernel e di u-boot.
+
Questo metodo permette (ovviamente) di eseguire l'immagine rootfs originale di Openmoko, dovrebbe essere anche in grado di eseguire l'u-boot originale e le immagini del kernel, le stesse che usa un Neo1973 reale. Altra differenza rispetto al metodo Integrator/CP, è che in questo modo possiamo ottenere una risoluzione corretta dello schermo, alcune (false) letture della batteria e altre cose simili. Attualmente, le parti mancanti all'emulatore sono: [[Hardware:AGPS/it|AGPS]] e [[Bluetooth/it|Bluetooth]] - il lavoro su queste parti procede. Anche senza esse, QEMU dovrebbe fornire un aiuto sostanziale agli sviluppatori nel debugging del kernel e di u-boot.
  
QEMU '''*non*''' può essere utilizzato, e probabilmente nemmeno altri emulatori possono, per misurare le prestazioni generali di OpenMoko. L'esecuzione del codice in QEMU avviene alla massima velocità che il computer host è in grado di fornire, con un overhead dovuto alla necessità di tradurre il codice. Questo overhead non è uniforme per tutte le differenti istruzioni, quindi se il tuo Neo virtuale riporta circa 100 BogoMIPS (che è la velocità di un Neo reale), azioni differenti eseguite dall'emulatore potrebbero essere portate a termine a velocità diverse. Nella maggior parte dei casi, il Neo virtuale eseguirà più velocemente rispetto ad uno reale (le operazioni legate all'audio potrebbero essere un'eccezione).
+
QEMU '''*non*''' può essere utilizzato, come probabilmente nemmeno altri emulatori, per misurare le prestazioni generali di Openmoko. L'esecuzione del codice in QEMU avviene alla massima velocità che il computer host è in grado di fornire, con un overhead dovuto alla necessità di tradurre il codice. Questo overhead non è uniforme per tutte le differenti istruzioni, quindi se il tuo Neo virtuale riporta circa 100 BogoMIPS (che è la velocità di un Neo reale), azioni differenti eseguite dall'emulatore potrebbero essere portate a termine a velocità diverse. Nella maggior parte dei casi, il Neo virtuale eseguirà più velocemente rispetto ad uno reale (le operazioni legate all'audio potrebbero essere un'eccezione).
  
 
=== Quale hardware è supportato ===
 
=== Quale hardware è supportato ===
Line 20: Line 21:
 
! Hardware !! Stato !! Note utilizzo
 
! Hardware !! Stato !! Note utilizzo
 
|- style="background-color:#eeeedd;"
 
|- style="background-color:#eeeedd;"
! colspan="3"|S3C2410A Processor
+
! colspan="3"|Processore S3C2410A
 
|-
 
|-
|ARM920T core || Works || Already in mainline QEMU.
+
|ARM920T core || Funziona || Presente in QEMU.
 
|-
 
|-
|Basic guts || Work || This includes GPIO interface, DMA, Interrupt Controller, Timers, NAND controller, MMC/SD host, [[I2C]] and IIS interfaces, Memory & Clock & Power management controllers, RAM.
+
|Basic guts || Funziona || Comprende l'interfaccia GPIO, DMA, Interrupt Controller, Timers, NAND controller, MMC/SD host, [[I2C/it|I2C]] e IIS interfaces, Memory & Clock & Power management controllers, RAM.
 
|-
 
|-
|Serial ports || Works || Use the "-serial" switch (maybe be specified multiple times) to tell QEMU where serial input/output should go to. GSM module will be connected on UART0.
+
|Serial ports || Funziona || Usa "-serial" switch (potrebbe essere specificato diverse volte) per dire a QEMU dove mandare i serial input/output. Il modulo GSM andrà connesso a UART0.
 
|-
 
|-
|RTC || Works || On start QEMU will load it with current time/date - the Neo1973 [[kernel]] doesn't use it for time/date source currently.
+
|RTC || Funziona || All'avvio QEMU verrà caricato con l'ora/data corrente - il [[kernel/it|kernel]] Neo1973 attualmente non lo usa come sorgente.
 
|-
 
|-
|SPI || Works || The guest kernel can drive it using either the SPI interface or raw GPIO bitbanging.
+
|SPI || Funziona || Il kernel guest può utilizzarlo sia tramite interfaccia SPI che tramite raw GPIO bitbanging.
 
|-
 
|-
|LCD || Works || The virtual LCD will display as in QEMU window iff "-nographic" is not specified.
+
|LCD || Funziona || Il LCD virtuale verrà visualizzato come in una finestra QEMU se "-nographic" non viene specificato.
 
|-
 
|-
|ADC || Works || Mouse events in QEMU window generate what would be touchscreen events on a Neo1973 and are passed to the guest OS through the on-chip ADC.
+
|ADC || Funziona || Gli eveti del mouse nella finestra QEMU, generano quello che gli eventi del touchscreen genererebbero su un Neo1973 e sono rimandati al sistema guest attraverso il on-chip ADC.
 
|-
 
|-
|OHCI USB || Works || This part is in mainline QEMU. Use the "-usb" switch to enable the controller and "usb_add" in QEMU monitor to attach new virtual or physical USB devices.
+
|OHCI USB || Funziona || Compresa nel ramo principale di QEMU. Usare "-usb" per abilitare il controller e "usb_add" nel monitor QEMU per connettere nuovi device USB, virtuali o meno.
 
|-
 
|-
|Slave USB || Works || Linux's dummy HCD in conjunction with gadget filesystem API is used to make the virtual Neo appear as a real one connected to the host computer. See [[#Setting up USB connection|Setting up USB connection]] below. (Experimental)
+
|Slave USB || Funziona || Linux dummy HCD, unito alle API aggiuntive del filesystem, viene usato per fare in modo che il Neo virtuale appaia come se fosse realmente connesso all'host. Vedere [[#Setting up USB connection/it|Configurare connessioni USB]]. (Sperimentale)
 
|-
 
|-
|Watchdog || Works || This is one of the less important on-chip peripherals in S3C2410. It is however used by Linux for rebooting the board.
+
|Watchdog || Funziona || Questa è una delle periferiche meno importanti in S3C2410. Viene comunque usata da Linux per il riavvio della scheda.
 
|- style="background-color:#eeeedd;"
 
|- style="background-color:#eeeedd;"
! colspan="3"|[[I2C]] bus peripherals
+
! colspan="3"| Periferiche bus [[I2C/it|I2C]]
 
|-
 
|-
|[[PCF50606]] || Works || (Aka PMU) Fakes the battery charge level (set at 88%), POWER button, etc. Also contains and RTC, also unused by Linux.
+
|[[PCF50606/it|PCF50606]] || Funziona || (Chiamato anche PMU) Falsifica la carica della batteria (fissa ad 88%), il tasto POWER, etc. Contiene anche RTC, non utilizzato da Linux.
 
|-
 
|-
|[[LM4857]] || Works
+
|[[LM4857/it|LM4857]] || Funziona
 
|-
 
|-
|[[WM8753L]] || Works || The CODEC is also connect to the CPU's IIS port. Basic [[Neo1973 Audio Subsystem|audio functionality]] is supported - see QEMU documentation on getting audio input/output from the emulator. Volume control has no effects.
+
|[[WM8753L/it|WM8753L]] || Funziona || Il CODEC è connesso anche alla porta IIS della CPU. Le [[Neo1973 Audio Subsystem/it|funzionalità audio]] di base sono supportate - vedere la documentazione QEMU per informazioni sul funzionamento dell'audio nell'emulatore. Il controllo del volume non funziona.
 
|- style="background-color:#eeeedd;"
 
|- style="background-color:#eeeedd;"
! colspan="3"|Other peripherals
+
! colspan="3"|Altre periferiche
 
|-
 
|-
|NAND Flash || Works || However, some pieces are not confirmed to be completely compatible with the real hardware because of lack thereof. Use "-mtdblock flashimagefilenamehere" switch to point QEMU to your flash image. The file should be at least 69206016 bytes big.
+
|NAND Flash || Funziona || Comunque, per alcune parti non è confermata la completa compatibilità con l'hardware reale a causa della sua mancanza. Usare "-mtdblock flashimagefilenamehere" per indicare l'immagine a QEMU. Il file dovrebbe essere grande almeno 69206016 bytes.
 
|-
 
|-
|JBT6K74-AS(PI) || Works || (Aka LCM) Wired to the SPI channel 1
+
|JBT6K74-AS(PI) || Funziona || (Chiamato anche LCM) Cablato sul canale SPI 1
 
|-
 
|-
|Buttons || Work || Enter is the AUX button, Space is the POWER button. Wired to on-chip GPIO and PCF50606.
+
|I tasti || Funziona || Il tasto "enter" corrisponde al tasto AUX, "spazio" al tasto POWER. Cablato su GPIO e PCF50606.
 
|-
 
|-
|SD card || Works || This part is already in mainline QEMU. Use the "-sd cardimagegoeshere" switch to point QEMU to the card image. The regular QEMU monitor commands for removable media can also be used. The card works, however the on-chip host controller gave block length errors on heavy I/O despite working as described in specification. I suspect the kernel driver. DMA operation is not tested.
+
|Scheda SD || Funziona || Questa parte è già compresa in QEMU. Usare "-sd limmaginedischedavaqui" per indicare l'immagine a QEMU. Si può anche utilizzare il monitor QEMU per i media rimovibili. Il lettore funziona ma a volte il controller dell'host ottiene errori nella dimensione dei blocchi se sottoposto a pesanti operazioni I/O, probabilmente a causa dei driver nel kernel. Le operazioni DMA non sono testate.
 
|-
 
|-
 
|Bluetooth
 
|Bluetooth
|style="background-color:#ffffcc;"|Works
+
|style="background-color:#ffffcc;"|Funziona
|A generic Bluetooth HCI (just like the BlueCore4 chip) is connected to internal USB hub (just like the Delta DBFM dongle). Currently qemu emulates no other bluetooth devices, so the dongle behaves as if there was no BT-enabled slaves around, being the only device on the piconet, i.e. is not really useful. Likely a Bluetooth keyboard will be emulated. A physical Bluetooth dongle can also be attached to the emulator (see USB documentation in QEMU).
+
|Un HCI Bluetooth generico (come il chip BlueCore4) è connesso all'hub USB interno (come il Delta DBFM dongle). Attualmente QEMU non emula altri device bluetooth, quindi si comporta come unico device nella piconet, i.e. non è molto utile. Potrà essere emulata una tastiera Bluetooth. Un dispositivo Bluetooth può comunque essere connesso all'emulatore (vedere la documentazione QEMU relativa all'USB).
 
|-
 
|-
|[[GSM]] || Works || A fake modem is connected to UART0 understanding a (currently quite limited) subset of AT commands. Ultimately it should support as much functionality as possible (basic AT command set, fake GPRS connections, dialing and SMS send/receive). This way all parts of the phone subsystem (CALYPSO, TWL3014, TRF6151) will not have to be emulated. There is a possibility to wire a real GSM modem to QEMU's serial port.
+
|[[GSM/it|GSM]] || Funziona || Un modem virtuale è connesso a UART0 e comprende un sottoinsieme (attualmente abbastanza limitato) di comandi AT. Ultimamente dovrebbe supportare la maggior parte delle funzionalità (comandi AT base, connessioni GPRS, chiamate e SMS). In questo modo tutta la parte del "sottosistema telefono" (CALYPSO, TWL3014, TRF6151) non ha bisogno di emulazione. C'è la possibilità di connettere un reale modem GSM alla porta seriale di QEMU.
 
|-
 
|-
|[[Hardware:AGPS|AGPS]]
+
|[[Hardware:AGPS/it|AGPS]]
|style="background-color:#ffcccc;"|To Do
+
|style="background-color:#ffcccc;"|Da fare
|There are obvious difficulties emulating the chip, but hopefully it can be made to present the guest OS with some fixed coordinates later when more is known about the chip. Again a real chip could be connected to QEMU's serial port.
+
|Ci sono alcune ovvie difficoltà nell'emularlo ma si spera di riuscirci impostando il sistema ospite con delle coordinate fisse quando il chip sarà più conosciuto. Anche in questo caso, un chip reale può essere connesso alla porta seriale di QEMU,.
 
|}
 
|}
  
Current development is aiming for [[:Category:Neo1973_Hardware#GTA01Bv4 | GTA01Bv4]] compatibility; [[:Category:Neo1973_Hardware#GTA01Bv3 | earlier revisions]] can also be emulated if needed. The differences between the hardware revisions currently only manifest themselves in GPIO wiring. Hardware emulation is implemented in a clean-room manner using official specifications where possible.
+
Lo sviluppo attuale è centrato sulla compatibilità [[:Category:Neo1973_Hardware/it#GTA01Bv4 | GTA01Bv4]];
 +
[[:Category:Neo1973_Hardware/it#GTA01Bv3 | versioni precedenti]] possono essere emulate se necessario. La differenza tra le revisioni hardware attualmente si manifesta solo nel GPIO. L'emulazione hardware è implementata in modo pulito, usando le specifiche ufficiali dove possibile.
  
== How to get it running ==
+
== Come renderlo funzionante ==
  
=== Using MokoMakefile ===
+
=== Usando MokoMakefile ===
  
This is arguably the easiest way of building qemu-neo1973 since you won't need to deal with the compiling and flashing processes yourself. See [[MokoMakefile#QEMU|MokoMakefile]] for details. (Please note that building all of MokoMakefile takes hours to days while the instructions below take on average 15 minutes to complete).
+
Questo è probabilmente il metodo più semplice per ottenere qemu-neo1973 visto che non sono necessari i processi di compilazione ed installazione. Vedere [[MokoMakefile/it#QEMU|MokoMakefile]] per maggiori dettagli. (Notare che la compilazione completa di MokoMakefile dura diverse ore, a volte giorni, mentre questa procedura circa 15 minuti).
  
=== Manual setup ===
+
=== Configurazione manuale ===
  
To obtain the latest source code for the emulator, you will want to do something like the following:
+
Per ottenere gli ultimi sorgenti dell'emulatore, dovrai eseguire un comando simile al seguente:
 
<pre>
 
<pre>
 
$ svn checkout https://svn.openmoko.org/trunk/src/host/qemu-neo1973
 
$ svn checkout https://svn.openmoko.org/trunk/src/host/qemu-neo1973
 
$ cd qemu-neo1973
 
$ cd qemu-neo1973
 
</pre>
 
</pre>
Now, we're going to configure and build the emulator (Note [[#Requirements|Requirements]] below):
+
Ora configureremo l'emulatore (Vedere i [[#Requirements|requisiti]] qui sotto):
 
<pre>
 
<pre>
 
$ ./configure --target-list=arm-softmmu  # GCC 3.x will be required, see --cc=
 
$ ./configure --target-list=arm-softmmu  # GCC 3.x will be required, see --cc=
 
$ make
 
$ make
 
</pre>
 
</pre>
See other available options for the configure script by appending "--help".
+
Per vedere le possibili opzioni di configurazione dello script, basta aggiungere "--help".
Now you should have a working emulator under the name "arm-softmmu/qemu-system-arm". To run OpenMoko you will also need to somehow install OpenMoko on your virtual phone, which is totally clean of any software at this moment. There are several block devices to choose from, the best option is probably to do exactly what the Neo1973 manufacturer does before it ships the device to the final user. This process is described in [[Bootloader]], [[Kernel]], [[NAND bad blocks]] and [[Devirginator]] but you don't need to know all the details. Two scripts are provided to generate a firmware for your phone, as realistic as possible. First run
+
Ora dovresti avere un emulatore funzionante chiamato "arm-softmmu/qemu-system-arm". Per eseguire Openmoko avrai bisogno di installare Openmoko sul tuo telefono virtuale, attualmente è completamente privo di software. Ci son diversi modi tra cui scegliere, probabilmente l'opzione migliore è fare esattamente quello che fanno i produttori di Neo1973 prima di spedire il dispositivo all'utente finale. Questo processo è descritto in [[Bootloader/it|Bootloader]], [[Kernel/it|Kernel]], [[NAND bad blocks/it|NAND bad blocks]] e [[Devirginator/it|Devirginator]] ma non serve conoscere i dettagli. Vengono forniti due script per generare il firmware del telefono, nel modo più realistico possibile.
 +
Eseguire:
 
<pre>$ openmoko/download.sh</pre>
 
<pre>$ openmoko/download.sh</pre>
which will look up the list of latest available OpenMoko snapshot builds from buildhost.openmoko.org and choose the most recent [[u-boot]], Kernel, and root filesystem images, and download the images (unless they are already found in the openmoko/ directory). These binaries will be used by the next command:
+
che verificherà la lista degli ultimi snapshot Openmoko disponibili su buildhost.openmoko.org e sceglierà i più recenti [[u-boot/it|u-boot]], kernel, filesystem e ne otterrà l'immagine (altrimenti una versione probabilmente più vecchia è comunque presente nella directory openmoko/).Questi binari vanno utilizzati tramite il seguente comando:
 
<pre>$ openmoko/flash.sh</pre>
 
<pre>$ openmoko/flash.sh</pre>
which runs the emulator, loads u-boot into it and then uses u-boot's capability to program the Flash memory to install all the necessary parts of the system into the virtual Flash. It will also set up all the bootloading process including a boot menu (ENTER is [AUX] and SPACE is [POWER]), splash, u-boot environment and some default kernel parameters. If everything goes OK, the script should print a command which you can use to start using the emulator.
+
che esegue l'emulatore, carica u-boot e lo utilizza per installare tutte le parti necessarie nella memoria Flash virtuale. Configurerà anche il processo di boot, incluso il menu di avvio (ENTER è [AUX] e SPACE è [POWER]), lo sfondo, l'ambiente u-boot e alcuni parametri del kernel. Se tutto è andato bene, lo script dovrebbe stampare un comando in grado di avviare l'emulatore.
  
QEMU has '''*tons*''' of commandline switches and things that can be configured. You can look them up in [http://www.qemu.org/user-doc.html QEMU user docs]. You will probably want to use the "-snapshot" switch, among other ones. Saving and restoring emulation state at any point (unrelated to "-snapshot") should work as per QEMU user docs too.
+
QEMU ha '''*tonnellate*''' di opzioni e settaggi. Puoi trovarli in [http://www.qemu.org/user-doc.html QEMU user docs]. Probabilmente l'opzione "-snapshot" sarà la più richiesta. Permette di salvare e ripristinare lo stato dell'emulatore in qualsiasi momento (indipendente da "-snapshot"), per il suo funzionamento vedere la documentazione QEMU.
  
=== Pre-built binaries ===
+
=== Binari pre-costruiti ===
  
Win32 binaries shipped with firmware can be downloaded from [http://mdk.linux.org.tw/~jserv/openmoko/openmoko-emulator-win32-bin-20070625.zip openmoko-emulator-win32-bin-20070625.zip]. Tested on MS Windows XP and Vista Business.
+
Binari Win32, insieme al firmware, possono essere scaricati da
 +
[http://mdk.linux.org.tw/~jserv/openmoko/openmoko-emulator-win32-bin-20070625.zip openmoko-emulator-win32-bin-20070625.zip]. Testati su MS Windows XP e Vista Business.
  
== Requirements ==
+
== Prerequisiti ==
  
This QEMU tree has only been tested on GNU/Linux. To get graphical (not counting VNC) and/or audio output from the emulator you will need either SDL or Cocoa installed on your computer. To enable audio, see the available switches to the ./configure script.
+
Questo QEMU è stato testato solo su GNU/Linux. Per ottenere un output grafico (senza contare VNC) e/o sonoro dall'emulatore, sono necessari sia SDL che Cocoa installati sul computer. Per abilitare l'audio, vedere le opzioni disponibili nello script ./configure.
  
The scripts that sit in openmoko/ require lynx, wget, python and most GNU base utilities installed in standard locations. If you are using the flash.sh script, you will need to install the netpbm package to get the png conversion tools.
+
Lo script nella directory openmoko/ richiede lynx, wget, python e la maggior parte dei programmi base GNU installati nelle posizioni standard. Per utilizzare lo script flash.sh, è necessario installare netpbm per ottenere i programmi in grado di convertire i png.
  
All of the build-time and run-time requirements listed in [http://www.qemu.org/user-doc.html QEMU documentation] apply. This includes zlib, etc. On distributions that use binary packages, remember that you need the packages ending in '''-dev''' or '''-devel'''.
+
Tutti i prerequisiti, sia build-time che run-time, elencati in [http://www.qemu.org/user-doc.html QEMU documentation].
 +
Inclusi zlib, etc. Nelle distribuzioni che usano pacchetti, ricordarsi che sono necessari i pacchetti che terminano con '''-dev''' o '''-devel'''.
  
== QEMU and GNU debugger ==
+
== QEMU e il debugger GNU ==
  
QEMU lets you debug operating system kernels and bootloaders like you debug all other programs. To do this you will need a debugger that speaks the GDB remote debugging protocol - [http://sourceware.org/gdb/ GDB] is the obvious choice. Some cross toolchains come with GDB already set up. Otherwise building cross-GDB yourself is quick and easy (compared to building binutils and cross-gcc).
+
QEMU permette il debugging del kernel del sistema operativo e dei bootloader nello stesso modo in cui permette il debugging di qualsiasi altro programma. Per farlo è necessario un debugger in grado di comunicare tramite il "GDB remote debugging protocol" - [http://sourceware.org/gdb/ GDB] è la scelta più ovvia. Alcune configurazioni hanno già GDB installato. Altrimenti compilare cross-GDB è abbastanza semplice (rispetto a compilare binutils e cross-gcc).
  
To debug u-boot, load the file "u-boot" into gdb (not "u-boot.bin") that is produced by "make" when building u-boot. To debug a Linux kernel, load the file "vmlinux" from the main source directory into gdb. These files are in ELF format and contain all the symbol information and are not stripped of debugging data until you run "strip" on them, unlike "u-boot.bin" and "Image"/"zImage"/"uImage". Next, tell QEMU to enable the gdbserver by appending the "-s" switch or issuing "gdbserver" in the monitor. Use the command <pre>(gdb) target remote localhost:1234</pre> to make a connection to the emulator. From there you should be able to use all the usual GDB commands, including stepping instructions, setting breakpoints, watchpoints, inspecting stack, variables, registers and more. If gdb is running in the same directory from which it grabbed the ELF executable, the "edit" command should work so you can jump right to the source line which is executing.
+
Per debuggare u-boot, caricare il file "u-boot" in gdb (non "u-boot.bin"), questo file è creato da "make" durante la compilazione di u-boot. Per debuggare un kernel Linux, caricare il file "vmlinuz" dalla directory principale in gdb. Questi files sono nel formato ELF, contengono tutte le informazioni sui simboli e non sono pienamente debuggabili finché non si esegue "strip" su essi, a differenza di "u-boot.bin" e "Image"/"zImage"/"uImage". Successivamente bisogna dire a QEMU di abilitare il gdbserver tramite l'opzione "-s" o tramite "gdbserver" nel monitor. Usare il comando <pre>(gdb) target remote localhost:1234</pre> per connettersi all'emulatore. Ora dovremmo essere in grado di utilizzare i normali comandi gdb, incluse le istruzioni di stepping, breakpoints, watchpoints, visualizzazione dello stack, delle variabili, dei registri e altro. Se gdb viene eseguito nella stessa directory in cui si trova l'eseguibile ELF, il comando "edit" dovrebbe funzionare quindi saremo in grado di modificare il codice in esecuzione.
  
== Setting up USB connection ==
+
== Configurare le connessioni USB ==
  
It is possible (although not very straight forward, probably about the complexity of tun-tap networking) to connect the virtual, emulated Neo1973 to the Linux PC on which the emulator is running, and work with it as if a real Neo1973 was plugged into the computer's USB port, but no twiddling with cables is needed. If you're testing your applications on the Neo, it may be worth setting up this kind of connection because it lets you enable normal [[USB_Networking|networking between the PC and the phone and ssh into it]] (which is much more comfortable than typing commands into the OpenMoko's terminal emulator via on-screen keyboard). Here's what you will need in order to get this working:
+
Connettere il Neo1973 emulato al PC Linux su cui l'emulatore è in esecuzione, è possibile (anche se in modo non proprio diretto, probabilmente a causa della complessità del tun-tap networking) e funziona come se un Neo1973 reale fosse connesso alla porta USB del computer, senza giocare con cavi. Se stai testando la tua applicazione sul Neo, potrebbe valere la pena instaurare questo tipo di connessione perché permette il [[USB_Networking/it|networking tra il PC e ssh installato sul Neo]], che è molto più comodo rispetto all'inserire comandi dal terminale Openmoko emulato. Di seguito è descritto cosa è necessario fare per ottenere questa configurazione:
  
A Linux host with a 2.6 series kernel. The following drivers compiled-in or in modules: dummy_hcd, gadgetfs, usbnet, cdc_ether. Note that you need root access to perform most actions described here. Here's how to enable them in menuconfig.
+
Un host Linux con un kernel 2.6. I seguenti driver come modulo o inclusi nel kernel: dummy_hcd, gadgetfs, usbnet, cdc_ether. Nota che sono necessari privilegi di root per la maggior parte dei comandi successivi. Per abilitare i driver in "make menuconfig":
  
Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''Support for USB Gadgets'''
+
Trova ed abilita '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''Support for USB Gadgets'''
  
Find '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''USB Peripheral Controller''' and set it to '''Dummy HCD (DEVELOPMENT)'''
+
Trova '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''USB Peripheral Controller''' e impostalo come '''Dummy HCD (DEVELOPMENT)'''
  
Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''Gadget Filesystem (EXPERIMENTAL)''' (this one is good to have as a module)
+
Trova ed abilita '''Device Drivers''' -> '''USB support''' -> '''USB Gadget Support''' -> '''Gadget Filesystem (EXPERIMENTAL)''' (sarebbe meglio averlo come modulo)
  
Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Network Adapters''' -> '''Multi-purpose USB Networking Framework'''
+
Trova ed abilita '''Device Drivers''' -> '''USB support''' -> '''USB Network Adapters''' -> '''Multi-purpose USB Networking Framework'''
  
Find and enable '''Device Drivers''' -> '''USB support''' -> '''USB Network Adapters''' -> '''CDC Ethernet support (smart devices such as cable modems)'''
+
Trova ed abilita '''Device Drivers''' -> '''USB support''' -> '''USB Network Adapters''' -> '''CDC Ethernet support (smart devices such as cable modems)'''
  
These last two drivers are the same [[Getting Started with your Neo1973#By using Ethernet emulation over a USB cable|drivers that you need to work with a real Neo over USB network]]. After you've built the drivers, make sure that the copy of kernel headers in /usr/include/linux is up to date. In particular the file /usr/include/linux/usb_gadgetfs.h needs to be present and if your distribution came with headers older than 2.6.18 or so, then you need tell the package manager to update them, or you can do that manually with
+
Gli ultimi due driver sono gli stessi [[Getting Started with your Neo1973/it#Usando l'emulazione Telnet tramite un cavo USB|che servono per usare le reti USB con i Neo reali]]. Una volta ottenuti i drivers, assicurarsi che la copia degli header del kernel sia aggiornata. In particolare il file /usr/include/linux/usb_gadgetfs.h deve essere presente. Se la tua distribuzione fornisce gli headers 2.6.18 o antecedenti, dovrai aggiornarli tramite il gestore dei pacchetti, o manualmente tramite <pre> # cp -a /usr/src/linux/include/linux/* /usr/include/linux/</pre> (assumendo che il kernel si trovi in /usr/src/linux). Questo deve essere fatto prima di compilare qemu perché il sistema verifica la presenza degli headers e se non li trova disabilita la funzione USB Slave.
<pre> # cp -a /usr/src/linux/include/linux/* /usr/include/linux/</pre>
+
(assuming that your kernel sources are in /usr/src/linux). It is important that this is done before building qemu because the build system checks if these headers are functional and in case they aren't found it will disable the USB Slave functionality.
+
  
After building qemu and before running it, make sure that the modules are loaded into the kernel. I found it useful to load gadgetfs with the following command:
+
Dopo la compilazione di qemu e prima di eseguirlo, assicurarsi che i moduli sono caricati nel kernel. Ho trovato utile caricare gadgetfs con il seguente comando:
<pre> # modprobe gadgetfs default_uid=1000  # assuming my User ID is 1000</pre>
+
<pre> # modprobe gadgetfs default_uid=1000  # assumendo che il mio User ID sia 1000</pre>
and added the following line to my /etc/fstab:
+
e aggiungendo la seguente linea al file /etc/fstab:
 
<pre>gadget        /dev/gadget    gadgetfs  noauto,user,group        0  0</pre>
 
<pre>gadget        /dev/gadget    gadgetfs  noauto,user,group        0  0</pre>
Make sure that the mountpoint /dev/gadget exists:
+
Assicurarsi dell'esistenza del mountpoint /dev/gadget
 
<pre> # mkdir -p /dev/gadget</pre>
 
<pre> # mkdir -p /dev/gadget</pre>
After that the rest of the procedure can be performed from your regular user account. Mounting gadgetfs is done with:
+
Fatto questo il resto della procedura può essere eseguito come un utente regolare. gadgetfs viene montato tramite:
 
<pre> $ mount /dev/gadget</pre>
 
<pre> $ mount /dev/gadget</pre>
The "default_uid" parameter changes the ownership on all files under /dev/gadget to your own and since the files there are created and destroyed dynamically, there's no easy way to have that performed by ''udev''. Now running qemu as you usually do but appending "-usb -usbgadget" should enable the USB Slave functionality. The qemu monitor commands "info usbslave" and "usb_add gadget" will be useful. The former instruction asks the OS running under the emulator (OpenMoko) to describe its slave features (that's what ''lsusb'' does after a Neo1973 is connected to a PC). You can see the available USB configurations in this command's output. Since gadgetfs allows only one configuration, we will need to choose the desired configuration - most device have only one such configuration, in which case you can use just "usb_add gadget" to connect to host; CDC ethernet devices however usually include a second configuration for RNDIS networking (i.e. Ms Windows compatibility) and so does OpenMoko when using the g_ether driver. Hence, to get this right, wait for OpenMoko to fully boot up and execute the following in QEMU monitor:
+
Il parametro "default_uid" fa in modo che tutti i files sotto /dev/gadget diventino di proprietà dell'utente, siccome i files vengono creati e cancellati dinamicamente, non è facile ottenerlo tramite ''udev''. Ora possiamo eseguire qemu come al solito, aggiungendo "-usb -usbgadget" dovremmo abilitare la funzionalità USB Slave. Il comando "info usbslave" e "usb_add gadget" nel monitor potrebbero essere utili. L'istruzione precedente chiede al sistema operativo eseguito nell'emulatore (Openmoko) di descrivere le sue funzionalità (come ''lsusb'' dopo che un Neo1973 viene connesso al PC). Possiamo vedere le configurazioni USB disponibili nell'output di questo comando. Siccome gadgetfs permette una sola configurazione, dovremo scegliere quelle desiderata - la maggior parte dei dispositivi hanno solo una di queste configurazioni, in questo caso possiamo usare semplicemente "usb_add gadget" per connetterlo all'host; i dispositivi CDC ethernet solitamente includono una seconda configurazione per il networking RNDIS (i.e. compatibilità Ms Windows) e così fa anche Openmoko quando viene usato il dirver g_ether. Quindi, per il corretto funzionamento, aspettare che Openmoko sia caricato completamente ed eseguire i seguenti comandi nel monitor QEMU:
 
<pre>
 
<pre>
 
QEMU 0.9.0 monitor - type 'help' for more information
 
QEMU 0.9.0 monitor - type 'help' for more information
Line 158: Line 161:
 
(qemu) usb_add gadget:1
 
(qemu) usb_add gadget:1
 
</pre>
 
</pre>
The "1" in "usb_add gadget:N" is the number of the USB configuration that we want to use. If everything went correctly - you can check that in dmesg - you should now have a new network interface called ''usb0'' on the PC, through which you can talk to the OpenMoko running in QEMU:
+
Il valore "1" in "usb_add gadget:N" è il numero della configurazione USB che vogliamo usare. Se è tutto corretto - verificare tramite dmesg - dovresti avere un'interfaccia di rete chiamata ''usb0'' nel PC, attraverso cui è possibile comunicare con l'Openmoko in QEMU:
 
<pre>
 
<pre>
 
  $ dmesg | tail
 
  $ dmesg | tail
Line 301: Line 304:
 
root@fic-gta01:~$ uname -a
 
root@fic-gta01:~$ uname -a
 
Linux fic-gta01 2.6.20.7-moko8 #1 PREEMPT Wed Apr 25 11:13:52 UTC 2007 armv4tl unknown
 
Linux fic-gta01 2.6.20.7-moko8 #1 PREEMPT Wed Apr 25 11:13:52 UTC 2007 armv4tl unknown
 +
</pre>
 +
 +
<span id="bottom"></span>
 +
{{Languages|Openmoko_under_QEMU}}
 +
 +
[[Category:Emulation/it]]

Latest revision as of 12:18, 26 September 2008

QEMU può essere utilizzato in tre diversi modi per eseguire Openmoko. Dovresti scegliere la soluzione più adatta, a seconda del motivo per cui stai per usare l'emulatore.

  • PC - Openmoko può essere compilato per essere eseguito su una normale macchina i386, a 32 o a 64 bit. Probabilmente questa è la via più veloce per eseguire Openmoko se vuoi una anteprima sul suo aspetto e funzionamento. In questo caso QEMU verrà utilizzato unicamente per isolare l'installazione Openmoko dal resto del sistema o, se non stai usando un sistema UNIX, QEMU fornirà un modo non intrusivo e veloce per ottenere una macchina Linux. Altre informazioni si trovano in FAQ, qui e qui.
  • Integrator/CP - Questa è la macchina basata sul ARM di QEMU di difetto. Questo metodo va utilizzato con MACHINE="qemuarm" ed è sufficiente per eseguire l'immagine rootfs originale di Openmoko, nessun componente hardware tra Neo1973 Hardware verrà emulato, ad eccezione della CPU. Altre informazioni in FAQ.
  • Neo1973 - Nei repositori Openmoko è disponibile una versione di QEMU in grado di emulare la maggior parte dell'hardware Neo1973 ma non tutto per ora. Quando il progetto sarà più maturo verrà integrato nel ramo di sviluppo principale di QEMU.

Contents

[edit] Emulazione Neo1973

Questo metodo permette (ovviamente) di eseguire l'immagine rootfs originale di Openmoko, dovrebbe essere anche in grado di eseguire l'u-boot originale e le immagini del kernel, le stesse che usa un Neo1973 reale. Altra differenza rispetto al metodo Integrator/CP, è che in questo modo possiamo ottenere una risoluzione corretta dello schermo, alcune (false) letture della batteria e altre cose simili. Attualmente, le parti mancanti all'emulatore sono: AGPS e Bluetooth - il lavoro su queste parti procede. Anche senza esse, QEMU dovrebbe fornire un aiuto sostanziale agli sviluppatori nel debugging del kernel e di u-boot.

QEMU *non* può essere utilizzato, come probabilmente nemmeno altri emulatori, per misurare le prestazioni generali di Openmoko. L'esecuzione del codice in QEMU avviene alla massima velocità che il computer host è in grado di fornire, con un overhead dovuto alla necessità di tradurre il codice. Questo overhead non è uniforme per tutte le differenti istruzioni, quindi se il tuo Neo virtuale riporta circa 100 BogoMIPS (che è la velocità di un Neo reale), azioni differenti eseguite dall'emulatore potrebbero essere portate a termine a velocità diverse. Nella maggior parte dei casi, il Neo virtuale eseguirà più velocemente rispetto ad uno reale (le operazioni legate all'audio potrebbero essere un'eccezione).

[edit] Quale hardware è supportato

Approssimativamente, questa è la situazione di ogni componente che necessita emulazione, seguendo la pagina Neo1973 Hardware.

Hardware Stato Note utilizzo
Processore S3C2410A
ARM920T core Funziona Presente in QEMU.
Basic guts Funziona Comprende l'interfaccia GPIO, DMA, Interrupt Controller, Timers, NAND controller, MMC/SD host, I2C e IIS interfaces, Memory & Clock & Power management controllers, RAM.
Serial ports Funziona Usa "-serial" switch (potrebbe essere specificato diverse volte) per dire a QEMU dove mandare i serial input/output. Il modulo GSM andrà connesso a UART0.
RTC Funziona All'avvio QEMU verrà caricato con l'ora/data corrente - il kernel Neo1973 attualmente non lo usa come sorgente.
SPI Funziona Il kernel guest può utilizzarlo sia tramite interfaccia SPI che tramite raw GPIO bitbanging.
LCD Funziona Il LCD virtuale verrà visualizzato come in una finestra QEMU se "-nographic" non viene specificato.
ADC Funziona Gli eveti del mouse nella finestra QEMU, generano quello che gli eventi del touchscreen genererebbero su un Neo1973 e sono rimandati al sistema guest attraverso il on-chip ADC.
OHCI USB Funziona Compresa nel ramo principale di QEMU. Usare "-usb" per abilitare il controller e "usb_add" nel monitor QEMU per connettere nuovi device USB, virtuali o meno.
Slave USB Funziona Linux dummy HCD, unito alle API aggiuntive del filesystem, viene usato per fare in modo che il Neo virtuale appaia come se fosse realmente connesso all'host. Vedere Configurare connessioni USB. (Sperimentale)
Watchdog Funziona Questa è una delle periferiche meno importanti in S3C2410. Viene comunque usata da Linux per il riavvio della scheda.
Periferiche bus I2C
PCF50606 Funziona (Chiamato anche PMU) Falsifica la carica della batteria (fissa ad 88%), il tasto POWER, etc. Contiene anche RTC, non utilizzato da Linux.
LM4857 Funziona
WM8753L Funziona Il CODEC è connesso anche alla porta IIS della CPU. Le funzionalità audio di base sono supportate - vedere la documentazione QEMU per informazioni sul funzionamento dell'audio nell'emulatore. Il controllo del volume non funziona.
Altre periferiche
NAND Flash Funziona Comunque, per alcune parti non è confermata la completa compatibilità con l'hardware reale a causa della sua mancanza. Usare "-mtdblock flashimagefilenamehere" per indicare l'immagine a QEMU. Il file dovrebbe essere grande almeno 69206016 bytes.
JBT6K74-AS(PI) Funziona (Chiamato anche LCM) Cablato sul canale SPI 1
I tasti Funziona Il tasto "enter" corrisponde al tasto AUX, "spazio" al tasto POWER. Cablato su GPIO e PCF50606.
Scheda SD Funziona Questa parte è già compresa in QEMU. Usare "-sd limmaginedischedavaqui" per indicare l'immagine a QEMU. Si può anche utilizzare il monitor QEMU per i media rimovibili. Il lettore funziona ma a volte il controller dell'host ottiene errori nella dimensione dei blocchi se sottoposto a pesanti operazioni I/O, probabilmente a causa dei driver nel kernel. Le operazioni DMA non sono testate.
Bluetooth Funziona Un HCI Bluetooth generico (come il chip BlueCore4) è connesso all'hub USB interno (come il Delta DBFM dongle). Attualmente QEMU non emula altri device bluetooth, quindi si comporta come unico device nella piconet, i.e. non è molto utile. Potrà essere emulata una tastiera Bluetooth. Un dispositivo Bluetooth può comunque essere connesso all'emulatore (vedere la documentazione QEMU relativa all'USB).
GSM Funziona Un modem virtuale è connesso a UART0 e comprende un sottoinsieme (attualmente abbastanza limitato) di comandi AT. Ultimamente dovrebbe supportare la maggior parte delle funzionalità (comandi AT base, connessioni GPRS, chiamate e SMS). In questo modo tutta la parte del "sottosistema telefono" (CALYPSO, TWL3014, TRF6151) non ha bisogno di emulazione. C'è la possibilità di connettere un reale modem GSM alla porta seriale di QEMU.
AGPS Da fare Ci sono alcune ovvie difficoltà nell'emularlo ma si spera di riuscirci impostando il sistema ospite con delle coordinate fisse quando il chip sarà più conosciuto. Anche in questo caso, un chip reale può essere connesso alla porta seriale di QEMU,.

Lo sviluppo attuale è centrato sulla compatibilità GTA01Bv4; versioni precedenti possono essere emulate se necessario. La differenza tra le revisioni hardware attualmente si manifesta solo nel GPIO. L'emulazione hardware è implementata in modo pulito, usando le specifiche ufficiali dove possibile.

[edit] Come renderlo funzionante

[edit] Usando MokoMakefile

Questo è probabilmente il metodo più semplice per ottenere qemu-neo1973 visto che non sono necessari i processi di compilazione ed installazione. Vedere MokoMakefile per maggiori dettagli. (Notare che la compilazione completa di MokoMakefile dura diverse ore, a volte giorni, mentre questa procedura circa 15 minuti).

[edit] Configurazione manuale

Per ottenere gli ultimi sorgenti dell'emulatore, dovrai eseguire un comando simile al seguente:

$ svn checkout https://svn.openmoko.org/trunk/src/host/qemu-neo1973
$ cd qemu-neo1973

Ora configureremo l'emulatore (Vedere i requisiti qui sotto):

$ ./configure --target-list=arm-softmmu  # GCC 3.x will be required, see --cc=
$ make

Per vedere le possibili opzioni di configurazione dello script, basta aggiungere "--help". Ora dovresti avere un emulatore funzionante chiamato "arm-softmmu/qemu-system-arm". Per eseguire Openmoko avrai bisogno di installare Openmoko sul tuo telefono virtuale, attualmente è completamente privo di software. Ci son diversi modi tra cui scegliere, probabilmente l'opzione migliore è fare esattamente quello che fanno i produttori di Neo1973 prima di spedire il dispositivo all'utente finale. Questo processo è descritto in Bootloader, Kernel, NAND bad blocks e Devirginator ma non serve conoscere i dettagli. Vengono forniti due script per generare il firmware del telefono, nel modo più realistico possibile. Eseguire:

$ openmoko/download.sh

che verificherà la lista degli ultimi snapshot Openmoko disponibili su buildhost.openmoko.org e sceglierà i più recenti u-boot, kernel, filesystem e ne otterrà l'immagine (altrimenti una versione probabilmente più vecchia è comunque presente nella directory openmoko/).Questi binari vanno utilizzati tramite il seguente comando:

$ openmoko/flash.sh

che esegue l'emulatore, carica u-boot e lo utilizza per installare tutte le parti necessarie nella memoria Flash virtuale. Configurerà anche il processo di boot, incluso il menu di avvio (ENTER è [AUX] e SPACE è [POWER]), lo sfondo, l'ambiente u-boot e alcuni parametri del kernel. Se tutto è andato bene, lo script dovrebbe stampare un comando in grado di avviare l'emulatore.

QEMU ha *tonnellate* di opzioni e settaggi. Puoi trovarli in QEMU user docs. Probabilmente l'opzione "-snapshot" sarà la più richiesta. Permette di salvare e ripristinare lo stato dell'emulatore in qualsiasi momento (indipendente da "-snapshot"), per il suo funzionamento vedere la documentazione QEMU.

[edit] Binari pre-costruiti

Binari Win32, insieme al firmware, possono essere scaricati da openmoko-emulator-win32-bin-20070625.zip. Testati su MS Windows XP e Vista Business.

[edit] Prerequisiti

Questo QEMU è stato testato solo su GNU/Linux. Per ottenere un output grafico (senza contare VNC) e/o sonoro dall'emulatore, sono necessari sia SDL che Cocoa installati sul computer. Per abilitare l'audio, vedere le opzioni disponibili nello script ./configure.

Lo script nella directory openmoko/ richiede lynx, wget, python e la maggior parte dei programmi base GNU installati nelle posizioni standard. Per utilizzare lo script flash.sh, è necessario installare netpbm per ottenere i programmi in grado di convertire i png.

Tutti i prerequisiti, sia build-time che run-time, elencati in QEMU documentation. Inclusi zlib, etc. Nelle distribuzioni che usano pacchetti, ricordarsi che sono necessari i pacchetti che terminano con -dev o -devel.

[edit] QEMU e il debugger GNU

QEMU permette il debugging del kernel del sistema operativo e dei bootloader nello stesso modo in cui permette il debugging di qualsiasi altro programma. Per farlo è necessario un debugger in grado di comunicare tramite il "GDB remote debugging protocol" - GDB è la scelta più ovvia. Alcune configurazioni hanno già GDB installato. Altrimenti compilare cross-GDB è abbastanza semplice (rispetto a compilare binutils e cross-gcc).

Per debuggare u-boot, caricare il file "u-boot" in gdb (non "u-boot.bin"), questo file è creato da "make" durante la compilazione di u-boot. Per debuggare un kernel Linux, caricare il file "vmlinuz" dalla directory principale in gdb. Questi files sono nel formato ELF, contengono tutte le informazioni sui simboli e non sono pienamente debuggabili finché non si esegue "strip" su essi, a differenza di "u-boot.bin" e "Image"/"zImage"/"uImage". Successivamente bisogna dire a QEMU di abilitare il gdbserver tramite l'opzione "-s" o tramite "gdbserver" nel monitor. Usare il comando
(gdb) target remote localhost:1234
per connettersi all'emulatore. Ora dovremmo essere in grado di utilizzare i normali comandi gdb, incluse le istruzioni di stepping, breakpoints, watchpoints, visualizzazione dello stack, delle variabili, dei registri e altro. Se gdb viene eseguito nella stessa directory in cui si trova l'eseguibile ELF, il comando "edit" dovrebbe funzionare quindi saremo in grado di modificare il codice in esecuzione.

[edit] Configurare le connessioni USB

Connettere il Neo1973 emulato al PC Linux su cui l'emulatore è in esecuzione, è possibile (anche se in modo non proprio diretto, probabilmente a causa della complessità del tun-tap networking) e funziona come se un Neo1973 reale fosse connesso alla porta USB del computer, senza giocare con cavi. Se stai testando la tua applicazione sul Neo, potrebbe valere la pena instaurare questo tipo di connessione perché permette il networking tra il PC e ssh installato sul Neo, che è molto più comodo rispetto all'inserire comandi dal terminale Openmoko emulato. Di seguito è descritto cosa è necessario fare per ottenere questa configurazione:

Un host Linux con un kernel 2.6. I seguenti driver come modulo o inclusi nel kernel: dummy_hcd, gadgetfs, usbnet, cdc_ether. Nota che sono necessari privilegi di root per la maggior parte dei comandi successivi. Per abilitare i driver in "make menuconfig":

Trova ed abilita Device Drivers -> USB support -> USB Gadget Support -> Support for USB Gadgets

Trova Device Drivers -> USB support -> USB Gadget Support -> USB Peripheral Controller e impostalo come Dummy HCD (DEVELOPMENT)

Trova ed abilita Device Drivers -> USB support -> USB Gadget Support -> Gadget Filesystem (EXPERIMENTAL) (sarebbe meglio averlo come modulo)

Trova ed abilita Device Drivers -> USB support -> USB Network Adapters -> Multi-purpose USB Networking Framework

Trova ed abilita Device Drivers -> USB support -> USB Network Adapters -> CDC Ethernet support (smart devices such as cable modems)

Gli ultimi due driver sono gli stessi che servono per usare le reti USB con i Neo reali. Una volta ottenuti i drivers, assicurarsi che la copia degli header del kernel sia aggiornata. In particolare il file /usr/include/linux/usb_gadgetfs.h deve essere presente. Se la tua distribuzione fornisce gli headers 2.6.18 o antecedenti, dovrai aggiornarli tramite il gestore dei pacchetti, o manualmente tramite
 # cp -a /usr/src/linux/include/linux/* /usr/include/linux/
(assumendo che il kernel si trovi in /usr/src/linux). Questo deve essere fatto prima di compilare qemu perché il sistema verifica la presenza degli headers e se non li trova disabilita la funzione USB Slave.

Dopo la compilazione di qemu e prima di eseguirlo, assicurarsi che i moduli sono caricati nel kernel. Ho trovato utile caricare gadgetfs con il seguente comando:

 # modprobe gadgetfs default_uid=1000  # assumendo che il mio User ID sia 1000

e aggiungendo la seguente linea al file /etc/fstab:

gadget         /dev/gadget    gadgetfs   noauto,user,group         0   0

Assicurarsi dell'esistenza del mountpoint /dev/gadget

 # mkdir -p /dev/gadget

Fatto questo il resto della procedura può essere eseguito come un utente regolare. gadgetfs viene montato tramite:

 $ mount /dev/gadget

Il parametro "default_uid" fa in modo che tutti i files sotto /dev/gadget diventino di proprietà dell'utente, siccome i files vengono creati e cancellati dinamicamente, non è facile ottenerlo tramite udev. Ora possiamo eseguire qemu come al solito, aggiungendo "-usb -usbgadget" dovremmo abilitare la funzionalità USB Slave. Il comando "info usbslave" e "usb_add gadget" nel monitor potrebbero essere utili. L'istruzione precedente chiede al sistema operativo eseguito nell'emulatore (Openmoko) di descrivere le sue funzionalità (come lsusb dopo che un Neo1973 viene connesso al PC). Possiamo vedere le configurazioni USB disponibili nell'output di questo comando. Siccome gadgetfs permette una sola configurazione, dovremo scegliere quelle desiderata - la maggior parte dei dispositivi hanno solo una di queste configurazioni, in questo caso possiamo usare semplicemente "usb_add gadget" per connetterlo all'host; i dispositivi CDC ethernet solitamente includono una seconda configurazione per il networking RNDIS (i.e. compatibilità Ms Windows) e così fa anche Openmoko quando viene usato il dirver g_ether. Quindi, per il corretto funzionamento, aspettare che Openmoko sia caricato completamente ed eseguire i seguenti comandi nel monitor QEMU:

QEMU 0.9.0 monitor - type 'help' for more information
(qemu) info usbslave 
USB2.2 device 1457:5122:
Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
Product: RNDIS/Ethernet Gadget
Configuration 0: RNDIS
Configuration 1: CDC Ethernet
(qemu) 
(qemu) usb_add gadget:1

Il valore "1" in "usb_add gadget:N" è il numero della configurazione USB che vogliamo usare. Se è tutto corretto - verificare tramite dmesg - dovresti avere un'interfaccia di rete chiamata usb0 nel PC, attraverso cui è possibile comunicare con l'Openmoko in QEMU:

 $ dmesg | tail
<6>gadgetfs: bound to dummy_udc driver
<7>hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
<6>usb 3-1: new high speed USB device using dummy_hcd and address 3
<6>gadgetfs: connected
<7>usb 3-1: default language 0x0409
<7>usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
<6>usb 3-1: Product: RNDIS/Ethernet Gadget
<6>usb 3-1: Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
<6>usb 3-1: configuration #1 chosen from 1 choice
<7>usb 3-1: adding 3-1:1.0 (config #1, interface 0)
<7>usb 3-1:1.0: uevent
<7>cdc_ether 3-1:1.0: usb_probe_interface - got id
<7>cdc_ether 3-1:1.0: status ep3in, 16 bytes period 14
<7>usb 3-1: adding 3-1:1.1 (config #1, interface 1)
<7>usb 3-1:1.1: uevent
 $ su -
Password:
 # tail /var/log/everything/current
May  8 19:25:32 [kernel] gadgetfs: connected
May  8 19:25:32 [kernel] gadgetfs: disconnected
May  8 19:25:32 [kernel] gadgetfs: configuration #1
May  8 19:25:32 [kernel] usb0: register 'cdc_ether' at usb-dummy_hcd-1, CDC Ethernet Device, 52:e7:eb:76:0a:d0
 # lsusb -vvv
Bus 003 Device 003: ID 1457:5122  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1457 
  idProduct          0x5122 
  bcdDevice            2.12
  iManufacturer           1 Linux 2.6.20.7-moko8/s3c2410_udc
  iProduct                2 RNDIS/Ethernet Gadget
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           80
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          7 CDC Ethernet
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      6 Ethernet Networking
      bInterfaceProtocol      0 
      iInterface              5 CDC Communications Control
      CDC Header:
        bcdCDC               1.10
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Ethernet:
        iMacAddress                      3 52E7EB760AD0
        bmEthernetStatistics    0x00000000
        wMaxSegmentSize               1514
        wNumberMCFilters            0x0000
        bNumberPowerFilters              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              14
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass        10 Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass        10 Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              4 Ethernet Data
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1

 # ifconfig usb0 inet 192.168.0.200 netmask 255.255.255.0
 # exit
 $ 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 de:21:87:93:52:1c:6b:c7:69:29:6c:af:66:50:02:02.
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@fic-gta01:~$ uname -a
Linux fic-gta01 2.6.20.7-moko8 #1 PREEMPT Wed Apr 25 11:13:52 UTC 2007 armv4tl unknown

Personal tools

QEMU può essere utilizzato in tre diversi modi per eseguire OpenMoko. A seconda del motivo per cui stai per usare l'emulatore, dovresti scegliere la soluzione più adatta.

  • PC - OpenMoko può essere compilato per essere eseguito su una normale macchina i386, a 32 o a 64 bit e probabilmente questa è la via più veloce per eseguire OpenMoko se vuoi una anteprima su come appare e funziona. In questo caso QEMU verrà utilizzato unicamente per isolare l'installazione OpenMoko dal resto del sistema, o, se non stai usando un sistema UNIX, QEMU fornirà un modo non intrusivo e veloce per ottenere una macchina Linux. Altre informazioni possono essere trovate in FAQ, qui e qui.
  • Integrator/CP - Questa è la macchina ARM-based di default che QEMU utilizza. Questo metodo va utilizzato con MACHINE="qemuarm" ed è sufficiente per eseguire l'immagine rootfs originale di OpenMoko, nessun componente hardware tra Neo1973 Hardware verrà emulato, ad eccezione della CPU. Altre informazioni in FAQ.
  • Neo1973 - Nei repositories OpenMoko è disponibile una versione di QEMU in grado di emulare la maggior parte dell'hardware Neo1973 ma non tutto per ora. Quando il progetto sarà più maturo verrà integrato nel ramo di sviluppo principale di QEMU.

Emulazione Neo1973

Questo metodo permette (ovviamente) di eseguire l'immagine rootfs originale di OpenMoko, dovrebbe essere anche in grado di eseguire l'u-boot originale e le immagini del kernel, le stesse che usa un Neo1973 reale. Altra differenza rispetto al metodo Integrator/CP, è che in questo modo possiamo ottenere una risoluzione corretta dello schermo, alcune (false) letture della batteria e altre cose simili. Attualmente, le parti mancanti all'emulatore sono: AGPS e Bluetooth - il lavoro su questa parti procede. Anche con queste parti mancanti, QEMU dovrebbe fornire un aiuto sostanziale agli sviluppatori nel debugging del kernel e di u-boot.

QEMU *non* può essere utilizzato, e probabilmente nemmeno altri emulatori possono, per misurare le prestazioni generali di OpenMoko. L'esecuzione del codice in QEMU avviene alla massima velocità che il computer host è in grado di fornire, con un overhead dovuto alla necessità di tradurre il codice. Questo overhead non è uniforme per tutte le differenti istruzioni, quindi se il tuo Neo virtuale riporta circa 100 BogoMIPS (che è la velocità di un Neo reale), azioni differenti eseguite dall'emulatore potrebbero essere portate a termine a velocità diverse. Nella maggior parte dei casi, il Neo virtuale eseguirà più velocemente rispetto ad uno reale (le operazioni legate all'audio potrebbero essere un'eccezione).

Quale hardware è supportato

Approssimativamente, questa è la situazione di ogni componente che necessita emulazione, seguendo la pagina Neo1973 Hardware.

Hardware Stato Note utilizzo
S3C2410A Processor
ARM920T core Works Already in mainline QEMU.
Basic guts Work This includes GPIO interface, DMA, Interrupt Controller, Timers, NAND controller, MMC/SD host, I2C and IIS interfaces, Memory & Clock & Power management controllers, RAM.
Serial ports Works Use the "-serial" switch (maybe be specified multiple times) to tell QEMU where serial input/output should go to. GSM module will be connected on UART0.
RTC Works On start QEMU will load it with current time/date - the Neo1973 kernel doesn't use it for time/date source currently.
SPI Works The guest kernel can drive it using either the SPI interface or raw GPIO bitbanging.
LCD Works The virtual LCD will display as in QEMU window iff "-nographic" is not specified.
ADC Works Mouse events in QEMU window generate what would be touchscreen events on a Neo1973 and are passed to the guest OS through the on-chip ADC.
OHCI USB Works This part is in mainline QEMU. Use the "-usb" switch to enable the controller and "usb_add" in QEMU monitor to attach new virtual or physical USB devices.
Slave USB Works Linux's dummy HCD in conjunction with gadget filesystem API is used to make the virtual Neo appear as a real one connected to the host computer. See Setting up USB connection below. (Experimental)
Watchdog Works This is one of the less important on-chip peripherals in S3C2410. It is however used by Linux for rebooting the board.
I2C bus peripherals
PCF50606 Works (Aka PMU) Fakes the battery charge level (set at 88%), POWER button, etc. Also contains and RTC, also unused by Linux.
LM4857 Works
WM8753L Works The CODEC is also connect to the CPU's IIS port. Basic audio functionality is supported - see QEMU documentation on getting audio input/output from the emulator. Volume control has no effects.
Other peripherals
NAND Flash Works However, some pieces are not confirmed to be completely compatible with the real hardware because of lack thereof. Use "-mtdblock flashimagefilenamehere" switch to point QEMU to your flash image. The file should be at least 69206016 bytes big.
JBT6K74-AS(PI) Works (Aka LCM) Wired to the SPI channel 1
Buttons Work Enter is the AUX button, Space is the POWER button. Wired to on-chip GPIO and PCF50606.
SD card Works This part is already in mainline QEMU. Use the "-sd cardimagegoeshere" switch to point QEMU to the card image. The regular QEMU monitor commands for removable media can also be used. The card works, however the on-chip host controller gave block length errors on heavy I/O despite working as described in specification. I suspect the kernel driver. DMA operation is not tested.
Bluetooth Works A generic Bluetooth HCI (just like the BlueCore4 chip) is connected to internal USB hub (just like the Delta DBFM dongle). Currently qemu emulates no other bluetooth devices, so the dongle behaves as if there was no BT-enabled slaves around, being the only device on the piconet, i.e. is not really useful. Likely a Bluetooth keyboard will be emulated. A physical Bluetooth dongle can also be attached to the emulator (see USB documentation in QEMU).
GSM Works A fake modem is connected to UART0 understanding a (currently quite limited) subset of AT commands. Ultimately it should support as much functionality as possible (basic AT command set, fake GPRS connections, dialing and SMS send/receive). This way all parts of the phone subsystem (CALYPSO, TWL3014, TRF6151) will not have to be emulated. There is a possibility to wire a real GSM modem to QEMU's serial port.
AGPS To Do There are obvious difficulties emulating the chip, but hopefully it can be made to present the guest OS with some fixed coordinates later when more is known about the chip. Again a real chip could be connected to QEMU's serial port.

Current development is aiming for GTA01Bv4 compatibility; earlier revisions can also be emulated if needed. The differences between the hardware revisions currently only manifest themselves in GPIO wiring. Hardware emulation is implemented in a clean-room manner using official specifications where possible.

How to get it running

Using MokoMakefile

This is arguably the easiest way of building qemu-neo1973 since you won't need to deal with the compiling and flashing processes yourself. See MokoMakefile for details. (Please note that building all of MokoMakefile takes hours to days while the instructions below take on average 15 minutes to complete).

Manual setup

To obtain the latest source code for the emulator, you will want to do something like the following:

$ svn checkout https://svn.openmoko.org/trunk/src/host/qemu-neo1973
$ cd qemu-neo1973

Now, we're going to configure and build the emulator (Note Requirements below):

$ ./configure --target-list=arm-softmmu  # GCC 3.x will be required, see --cc=
$ make

See other available options for the configure script by appending "--help". Now you should have a working emulator under the name "arm-softmmu/qemu-system-arm". To run OpenMoko you will also need to somehow install OpenMoko on your virtual phone, which is totally clean of any software at this moment. There are several block devices to choose from, the best option is probably to do exactly what the Neo1973 manufacturer does before it ships the device to the final user. This process is described in Bootloader, Kernel, NAND bad blocks and Devirginator but you don't need to know all the details. Two scripts are provided to generate a firmware for your phone, as realistic as possible. First run

$ openmoko/download.sh

which will look up the list of latest available OpenMoko snapshot builds from buildhost.openmoko.org and choose the most recent u-boot, Kernel, and root filesystem images, and download the images (unless they are already found in the openmoko/ directory). These binaries will be used by the next command:

$ openmoko/flash.sh

which runs the emulator, loads u-boot into it and then uses u-boot's capability to program the Flash memory to install all the necessary parts of the system into the virtual Flash. It will also set up all the bootloading process including a boot menu (ENTER is [AUX] and SPACE is [POWER]), splash, u-boot environment and some default kernel parameters. If everything goes OK, the script should print a command which you can use to start using the emulator.

QEMU has *tons* of commandline switches and things that can be configured. You can look them up in QEMU user docs. You will probably want to use the "-snapshot" switch, among other ones. Saving and restoring emulation state at any point (unrelated to "-snapshot") should work as per QEMU user docs too.

Pre-built binaries

Win32 binaries shipped with firmware can be downloaded from openmoko-emulator-win32-bin-20070625.zip. Tested on MS Windows XP and Vista Business.

Requirements

This QEMU tree has only been tested on GNU/Linux. To get graphical (not counting VNC) and/or audio output from the emulator you will need either SDL or Cocoa installed on your computer. To enable audio, see the available switches to the ./configure script.

The scripts that sit in openmoko/ require lynx, wget, python and most GNU base utilities installed in standard locations. If you are using the flash.sh script, you will need to install the netpbm package to get the png conversion tools.

All of the build-time and run-time requirements listed in QEMU documentation apply. This includes zlib, etc. On distributions that use binary packages, remember that you need the packages ending in -dev or -devel.

QEMU and GNU debugger

QEMU lets you debug operating system kernels and bootloaders like you debug all other programs. To do this you will need a debugger that speaks the GDB remote debugging protocol - GDB is the obvious choice. Some cross toolchains come with GDB already set up. Otherwise building cross-GDB yourself is quick and easy (compared to building binutils and cross-gcc).

To debug u-boot, load the file "u-boot" into gdb (not "u-boot.bin") that is produced by "make" when building u-boot. To debug a Linux kernel, load the file "vmlinux" from the main source directory into gdb. These files are in ELF format and contain all the symbol information and are not stripped of debugging data until you run "strip" on them, unlike "u-boot.bin" and "Image"/"zImage"/"uImage". Next, tell QEMU to enable the gdbserver by appending the "-s" switch or issuing "gdbserver" in the monitor. Use the command
(gdb) target remote localhost:1234
to make a connection to the emulator. From there you should be able to use all the usual GDB commands, including stepping instructions, setting breakpoints, watchpoints, inspecting stack, variables, registers and more. If gdb is running in the same directory from which it grabbed the ELF executable, the "edit" command should work so you can jump right to the source line which is executing.

Setting up USB connection

It is possible (although not very straight forward, probably about the complexity of tun-tap networking) to connect the virtual, emulated Neo1973 to the Linux PC on which the emulator is running, and work with it as if a real Neo1973 was plugged into the computer's USB port, but no twiddling with cables is needed. If you're testing your applications on the Neo, it may be worth setting up this kind of connection because it lets you enable normal networking between the PC and the phone and ssh into it (which is much more comfortable than typing commands into the OpenMoko's terminal emulator via on-screen keyboard). Here's what you will need in order to get this working:

A Linux host with a 2.6 series kernel. The following drivers compiled-in or in modules: dummy_hcd, gadgetfs, usbnet, cdc_ether. Note that you need root access to perform most actions described here. Here's how to enable them in menuconfig.

Find and enable Device Drivers -> USB support -> USB Gadget Support -> Support for USB Gadgets

Find Device Drivers -> USB support -> USB Gadget Support -> USB Peripheral Controller and set it to Dummy HCD (DEVELOPMENT)

Find and enable Device Drivers -> USB support -> USB Gadget Support -> Gadget Filesystem (EXPERIMENTAL) (this one is good to have as a module)

Find and enable Device Drivers -> USB support -> USB Network Adapters -> Multi-purpose USB Networking Framework

Find and enable Device Drivers -> USB support -> USB Network Adapters -> CDC Ethernet support (smart devices such as cable modems)

These last two drivers are the same drivers that you need to work with a real Neo over USB network. After you've built the drivers, make sure that the copy of kernel headers in /usr/include/linux is up to date. In particular the file /usr/include/linux/usb_gadgetfs.h needs to be present and if your distribution came with headers older than 2.6.18 or so, then you need tell the package manager to update them, or you can do that manually with

 # cp -a /usr/src/linux/include/linux/* /usr/include/linux/

(assuming that your kernel sources are in /usr/src/linux). It is important that this is done before building qemu because the build system checks if these headers are functional and in case they aren't found it will disable the USB Slave functionality.

After building qemu and before running it, make sure that the modules are loaded into the kernel. I found it useful to load gadgetfs with the following command:

 # modprobe gadgetfs default_uid=1000  # assuming my User ID is 1000

and added the following line to my /etc/fstab:

gadget         /dev/gadget    gadgetfs   noauto,user,group         0   0

Make sure that the mountpoint /dev/gadget exists:

 # mkdir -p /dev/gadget

After that the rest of the procedure can be performed from your regular user account. Mounting gadgetfs is done with:

 $ mount /dev/gadget

The "default_uid" parameter changes the ownership on all files under /dev/gadget to your own and since the files there are created and destroyed dynamically, there's no easy way to have that performed by udev. Now running qemu as you usually do but appending "-usb -usbgadget" should enable the USB Slave functionality. The qemu monitor commands "info usbslave" and "usb_add gadget" will be useful. The former instruction asks the OS running under the emulator (OpenMoko) to describe its slave features (that's what lsusb does after a Neo1973 is connected to a PC). You can see the available USB configurations in this command's output. Since gadgetfs allows only one configuration, we will need to choose the desired configuration - most device have only one such configuration, in which case you can use just "usb_add gadget" to connect to host; CDC ethernet devices however usually include a second configuration for RNDIS networking (i.e. Ms Windows compatibility) and so does OpenMoko when using the g_ether driver. Hence, to get this right, wait for OpenMoko to fully boot up and execute the following in QEMU monitor:

QEMU 0.9.0 monitor - type 'help' for more information
(qemu) info usbslave 
USB2.2 device 1457:5122:
Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
Product: RNDIS/Ethernet Gadget
Configuration 0: RNDIS
Configuration 1: CDC Ethernet
(qemu) 
(qemu) usb_add gadget:1

The "1" in "usb_add gadget:N" is the number of the USB configuration that we want to use. If everything went correctly - you can check that in dmesg - you should now have a new network interface called usb0 on the PC, through which you can talk to the OpenMoko running in QEMU:

 $ dmesg | tail
<6>gadgetfs: bound to dummy_udc driver
<7>hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
<6>usb 3-1: new high speed USB device using dummy_hcd and address 3
<6>gadgetfs: connected
<7>usb 3-1: default language 0x0409
<7>usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
<6>usb 3-1: Product: RNDIS/Ethernet Gadget
<6>usb 3-1: Manufacturer: Linux 2.6.20.7-moko8/s3c2410_udc
<6>usb 3-1: configuration #1 chosen from 1 choice
<7>usb 3-1: adding 3-1:1.0 (config #1, interface 0)
<7>usb 3-1:1.0: uevent
<7>cdc_ether 3-1:1.0: usb_probe_interface - got id
<7>cdc_ether 3-1:1.0: status ep3in, 16 bytes period 14
<7>usb 3-1: adding 3-1:1.1 (config #1, interface 1)
<7>usb 3-1:1.1: uevent
 $ su -
Password:
 # tail /var/log/everything/current
May  8 19:25:32 [kernel] gadgetfs: connected
May  8 19:25:32 [kernel] gadgetfs: disconnected
May  8 19:25:32 [kernel] gadgetfs: configuration #1
May  8 19:25:32 [kernel] usb0: register 'cdc_ether' at usb-dummy_hcd-1, CDC Ethernet Device, 52:e7:eb:76:0a:d0
 # lsusb -vvv
Bus 003 Device 003: ID 1457:5122  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1457 
  idProduct          0x5122 
  bcdDevice            2.12
  iManufacturer           1 Linux 2.6.20.7-moko8/s3c2410_udc
  iProduct                2 RNDIS/Ethernet Gadget
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           80
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          7 CDC Ethernet
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      6 Ethernet Networking
      bInterfaceProtocol      0 
      iInterface              5 CDC Communications Control
      CDC Header:
        bcdCDC               1.10
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Ethernet:
        iMacAddress                      3 52E7EB760AD0
        bmEthernetStatistics    0x00000000
        wMaxSegmentSize               1514
        wNumberMCFilters            0x0000
        bNumberPowerFilters              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              14
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass        10 Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass        10 Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              4 Ethernet Data
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1

 # ifconfig usb0 inet 192.168.0.200 netmask 255.255.255.0
 # exit
 $ 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 de:21:87:93:52:1c:6b:c7:69:29:6c:af:66:50:02:02.
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@fic-gta01:~$ uname -a
Linux fic-gta01 2.6.20.7-moko8 #1 PREEMPT Wed Apr 25 11:13:52 UTC 2007 armv4tl unknown
</div>