FB Emulation (qemu) - suche helfende Hand

[dileks]

32-Bit CPU in Verbindung mit GCC4.

Kann ich laut [1] bestätigen:

[...]
Installation

Den neuesten Stand des gepatchten QEMU erhält man über Subversion

svn checkout svn://svn.berlios.de/ar7-firmware/qemu/trunk

Zum Übersetzen benötigt man gcc-3.3 (gcc-4.x ist nicht geeignet!):

./configure --cc=gcc-3.3 --target-list=mipsel-softmmu
make
[...]

Web-Link:
----------
[1]http://ar7-firmware.berlios.de/wiki/index.php/QEMU

 

[kriegaex]

Ich habe QEMU aus diesem Trunk ausgecheckt, so steht es ja auch im PDF-Tutorial.

Ich habe eine 64-bit-CPU, aber eine 32-bit-Ditribution installiert, weil das angeblich zuverlässiger funktioniert. Keine Ahnung, außerhalb der VM setze ich seit zwei Wochen Linux erstmals nativ als Arbeitssystem ein.

Im PDF und weiter oben im Thread wird angegeben, daß mit einem bestimmten Configure-Schalter, den ich auch benutzt habe, QEMU mit GCC 4 gebaut werden könne. Evtl. könnte man die Anleitung korrigieren.

Edit - Zusatzfrage: Mit gcc-3.3 läuft das Kompilieren durch. Geht auch gcc-3.4 statt 3.3?

 

[RalfFriedl]

Ich hätte es etwas deutlicher schreiben sollen. Es geht nicht darum, ob Deine CPU 64 Bit kann oder nicht, sondern ob sie als 32-Bit oder als 64-Bit CPU verwendet wird.

Der Unterschied zwischen 32-Bit Modus und 64-Bit Modus ist nicht nur, daß die Register doppelt so breit sind, es gibt auch doppelt so viele, also 16 statt 8. Von diesen Registern sind einige für spezielle Aufgaben belegt, so daß im 32-Bit Modus nicht mehr viele zur freien Verwendung übrig bleiben.

qemu verwendet auch einige weitere Register mit fester Belegung, und GCC4 hat dann in manchen Fällen kein Register mehr frei, was zu der Fehlermeldung führt. Details gibt es irgendwo bei qemu, aber ich weiß nicht mehr genau wo.

Mit der configure Option kann man die Überprüfung auf GCC4 weg lassen, aber GCC4 in Verbindung mit i386 Befehlssatz funktioniert trotzdem nicht. GCC4 mit 64-Bit Befehlssatz und dort insbesondere mit der Anzahl der vorhandenen Register funktioniert.

gcc-3.3 oder gcc-3.4: Du kannst es ausprobieren. Aber wenn Du schon eine funktionierende Version hast, kannst Du die ja auch verwenden.

 

[kriegaex]

Danke, Ralf. @MaxMuster: Kannst Du Dein PDF entsprechend erweitern, damit das sauber unterschieden wird mit 32/64 bit, also wann GCC 4 überhaupt gehen kann und wann nicht?

Nächstes Problem: Ich habe einen Speicherabzug meiner W701V gemacht, die ich momentan mit ds26-pre15.3 und einer 7170-Firmware (29.04.40) nach JPaschers neuer S2F-Methode betreibe. Beim Hochfahren hängt die virtuelle Box und ich muß QEMU killen, weil es dauerhaft fast 100% Last zieht.

kriegaex@xander:~/src/qemu-ar7/trunk$ mipsel-softmmu/qemu-system-mipsel \
>     -M fbox-8mb -L ~/fritz-mtdblocks/w701v /dev/null -parallel none -nographic \
>     -redir tcp:2323::23 -redir tcp:8080::80 -redir tcp:8181::81 \
>     2> /dev/null
ram_offset (internal RAM) = 2000000

(AVM) EVA Revision: 1.203 Version: 1203
(C) Copyright 2005 AVM Date: Feb  7 2007 Time: 19:03:32 (0) 2 0-11011

[FLASH:] MACRONIX Top-Flash 8MB
[FLASH:](Eraseregion [0] 127 sectors a 64kB)
[FLASH:](Eraseregion [1] 8 sectors a 8kB)
[SYSTEM:] AR7 on 150MHz/125MHz

Eva_W701V >AVM decompress Kernel:
.............done
start kernel
[ohio_pre_init] System Clk = 12500000 Hz

LINUX started...
Linux version 2.6.13.1-ohio () (gcc version 3.4.6) #1 Thu Nov 15 22:19:52 CET 2007
memsize=32 MByte
flashsize=8 MByte
&_end=0x9423bc64 PFN_ALIGN(&_end)=0x9423c000 CPHYSADDR(PFN_ALIGN(&_end))=0x1423c000 memsize=0x2000000
CPU revision is: 00018448
[ohio_gpio_init]
Determined physical RAM map:
 memory: 0023c000 @ 14000000 (reserved)
 memory: 01dc4000 @ 1423c000 (usable)
On node 0 totalpages: 8192
[alloc_node_mem_map] reduce size from 2883616 Bytes to  262176 Bytes
[alloc_node_mem_map]: (org) sizeof(mem_map) = 262176 mem_map=0x9423f000-0x9427f020
[alloc_node_mem_map]: sizeof(mem_map) = 2883616 mem_map=0x93fbf000-0x9427f020
zone=0 zone_size[j]=0x90112
realsize=8192
  DMA zone: 8192 pages, LIFO batch:3
zone=1 zone_size[j]=0x0
realsize=0
  Normal zone: 0 pages, LIFO batch:1
zone=2 zone_size[j]=0x0
realsize=0
  HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: init=/etc/init.d/rc.nfsroot idle=4 mini_fo=ram  console=ttyS0,38400n8r
[ld_mmu_r4xx0] memcpy((void *)(CAC_BASE   + 0x100), &except_vec2_generic, 0x30)
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB, 4-way, linesize 16 bytes.
Synthesized TLB refill handler (20 instructions). Base=0x9420ea94
TLB synthesizer field overflow (simm)
Synthesized TLB load handler fastpath (34 instructions) Base=0x94212620.
TLB synthesizer field overflow (simm)
Synthesized TLB store handler fastpath (34 instructions) Base=0x94212820.
TLB synthesizer field overflow (simm)
Synthesized TLB modify handler fastpath (33 instructions) Base=0x94212a20.
PID hash table entries: 256 (order: 8, 4096 bytes)
CPU frequency 176.64 MHz
Using 88.320 MHz high precision timer.
[setup_irq]: irq 255 irqaction->handler 0x94042fd0 (no_action+0x0/0x8 )
[register_console] enable commandline console 0
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 30104k/30480k available (1605k kernel code, 320k reserved, 390k data, 116k init, 0k highmem)
totalram_pages= 7540
Calibrating delay loop...

Und gleich noch eine Frage: Wie muß ich minicom starten, damit ich an der emulierten seriellen Konsole etwas eingeben kann? Update: Das noch aktivierte NFS-Root wird wohl auch Probleme bereiten, wenngleich noch nicht zu diesem Zeitpunkt. Das könnte ich über serielle Konsole deaktivieren. Ralf und Oliver wissen, wovon ich rede, die 15.2-Nutzer ignorieren die Anmerkung bitte einfach.

 

[RalfFriedl]

Dein Terminal ist direkt mit der emulierten seriellen Konsole verbunden, Du brauchst kein minicom.

Du hast ja schon die Ausgabe der emulierten seriellen Konsole gezeigt, wenn der Prompt vom Bootloader kommt, kannst Du auch direkt Kommandos eingeben.

Bei mir läuft er durch, da kann ich im Moment nicht weiter helfen. Ich verwende aber GCC4 auf einem 64-Bit System.

Mit Netzwerk wirst Du nicht weit kommen, aber wenn das Image vollständig ist, sollte es lokal weiter laufen.

 

[MaxMuster]

Beim Hochfahren hängt die virtuelle Box und ich muß QEMU killen, weil es dauerhaft fast 100% Last zieht.

Das hatte ich mit dem gestern gebauten Binary auch erst gedacht (daher mein Hinweis, dass nich aller Versionen "hochlaufen") da das Fenster im Hintergrund beim Schreiben noch offen war, merkte ich, dass es irgendwann dann doch einen BogoMips Wert fand und weiterlief...

Jörg

Ich könnte dir bei Bedarf mal einen älteren Stand schicken...

 

[RalfFriedl]

Es gibt ja ein SVN. Ich habe Revision 826. Nicht mehr die neueste, aber bisher keine Probleme damit.

Bei "Calibrating delay loop..." kommt bei mir keine erkennbare Verzögerung. Daß es dann irgendwann doch weiter läuft ist dann erst recht seltsam. Vielleicht ein Problem mit dem simulierten Timer?

Was für ein BogoMips Wert kommt denn heraus, wenn es erst nach einer deutlichen Verzögerung weiter läuft?

 

[MaxMuster]

Was für ein BogoMips Wert kommt denn heraus, wenn es erst nach einer deutlichen Verzögerung weiter läuft?

... müsste ich am Montag auf dem "Arbeitsrechner" mal schauen. Ich hatte zwar extra nochmal hochgescrollt und nachgelesen, aber in meinem Alter ;-). Ich meine 510 oder 150 (?) gelesen zu haben?!? ...

Jörg

 

[kriegaex]

Dein Terminal ist direkt mit der emulierten seriellen Konsole verbunden, Du brauchst kein minicom.

Leider geht es trotzdem nicht, sonst hätte ich nicht gefragt. Ich habe es auch mal außerhalb von screen, in dem meine Terminalsitzungen normalerweise immer laufen, probiert, aber kein Unterschied.

Edit: Ich habe es mal im Hintergrund für eine Viertelstunde laufen lassen. Wie lange es tatsächlich gedauert hat, weiß ich nicht genau, aber irgendwann stand da:

Calibrating delay loop... 1032.19 BogoMIPS (lpj=5160960)
loops_per_jiffy=5160960
Mount-cache hash table entries: 512
Checking for 'wait' instruction... [speedup] idle_mode = 4
 with idle values available.
NET: Registered protocol family 16
Can't analyze prologue code at 9418fb7c

Und dort hängt er seitem auch wieder eine Ewigkeit.
(...)
Aha, jetzt geht's dort auch weiter, er erkennt natürlich das NFS-Root nicht und bootet als Fallback normal aus dem Flash. Hm, kann man diese Erkennungen, wo er hängen bleibt, irgendwie beschleunigen?

 

[MaxMuster]

Hm, kann man diese Erkennungen, wo er hängen bleibt, irgendwie beschleunigen?

Ich meine im Change-Log (recht weit zurück) gelesen zu haben, dass das Hängen bei Calibrating delay loop mit selbstmodifizierendem Code zusammenhing und dass Stefan Weil das gefixt hatte, weil die Fritzboxen sonst garnicht hochliefen. Vielleicht ist das jetzt "ähnlich" wieder da? Auf jeden Fall sollte es mit einer älteren Revision laufen.

Ansonsten hier eine "überarbeitete" Version, auch im "Quelltext" (Open Office Dokument), falls jemand Interesse hat...

Jörg

 

[kriegaex]

Danke für den Tip mit SVN-Revision 826. Damit kann ich an der EVA-Konsole etwas eingeben und der Start geht auch schnell. Allerdings komme ich durch die im Tutorial genannten Kommandos

ifconfig lan 10.0.2.15
route add default gw 10.0.2.2
echo nameserver 10.0.2.3 >/etc/resolv.conf
ping 10.0.2.2

nicht zu einem funktionierenden Netzwerk. Wie kann ich überprüfen, ob das Netzwerk funktioniert, außer einen Ping von innen nach außen bzw. einen Connect auf einem der getunnelten Ports von außen nach innen zu probieren? Kann ich irgendwie das instabile Netzwerk herunter- und wieder hochfahren? Im Grunde müßte ich ja AVM-Web, DS-Web, Telnet und SSH erreichen können, denn meine VM habe ich so gestartet:

mipsel-softmmu/qemu-system-mipsel \
    -M fbox-8mb -L ~/fritz-mtdblocks/w701v /dev/null -parallel none -nographic \
    -redir tcp:2323::23 \
    -redir tcp:8080::80 \
    -redir tcp:8181::81 \
    -redir tcp:2222::22 \
    2> /dev/null

 

[MaxMuster]

Vermutlich hast du irgendwo im Log (oder in dmesg) ein

lan: port 1(eth0) entering disabled state

oder sowas in der Art. Dann hilft nur "so oft versuchen, bis es klappt". Rein subjektiv würde ich sagen, klappt es "besser", wenn die emulierte Box mit den "richtigen" IPs hochfährt...

Wie gesagt, die "LAN-Emulation" ist noch sehr Buggy. Aber für solche Dinge wie "Firmware-Test" ist das gut (sofern man es schafft, die benötigten Dateien drauf zu bekommen). Zur Not kannst du bei einer emulierten 7170 ja die benötigten Dateien in die Firmware packen und diese dann integrieren...

Jörg

EDIT Manchmal hat bei mir ein

ifconfig eth0 down; ifconfig eth0 up; ping 10.0.2.2

was gebracht.

 

[kriegaex]

Genau Letzteres hatte ich auch versucht. Steht irgendwo genauer, was genau zu tun ist, damit die VM die "richtigen" IPs hat? Muß ich my_ipaddr in EVA ändern, irgendwas in ar7.cfg (was? wie?) anpassen? QEMU hört jedenfalls auf den in die VM weiterzuleitenden Ports, wie lsof auf dem Host zeigt. Es liegt also an der Netzwerk-Konfiguration (bzw. -Emulation) innerhalb der VM. Und was ist gemeint mit "immer wieder versuchen"? Immer wieder rebooten?

Andere Frage: Kann ich die Änderungen am Environment und am TFFS irgendwie persistent machen, so daß sie wieder da sind, wenn ich die VM anhalte und später neu starte? So eine Art Overlay, wie man es von mini_fo oder unionfs kennt?

 

[MaxMuster]

Also, die IPs sind tatsächlich in der ar7.cfg, die müsstest du da ändern, einmal hier (bei "Internet über LAN / bestehende Verbindung mitbenutzen", sonst kannst du m.W. kein "anderes" Defaultgateway über die ar7.cfg setzten, und müsstest das von Hand tun):

ar7cfg {
        mode = dsldmode_bridge;
        tsdisabled = no;
        igddenabled = yes;
        igdd_control_enabled = no;
        wan_bridge_with_dhcpc = no;
        [B]wan_bridge_gateway = 10.0.2.2;[/B]
        dhcpc_use_static_dns = yes;

und etwas später hier (bei "alle IPs in gleichem Subnetz", dann ist es das lan, sonst z.B. bei eth0):

       brinterfaces {
                name = "lan";
                dhcp = no;
                [B]ipaddr = 10.0.2.15[/B];
                netmask = 255.0.0.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0", "usbrndis", "eth1", "tiwlan0", "wdsup0",

Alternativ könntest du das in der debug.cfg erledigen lasssen


Jörg

EDIT: Zum "Abspeichern": Irgendwie macht qemu das intern ja (solange der Emulator läuft, kan man ja auch "das Flash verändern"). Bislang kenne ich da aber noch nichts.

 

[kriegaex]

Das zeigt offenbar auch keine Wirkung.

 

[RalfFriedl]

Es steht irgendwo, daß Änderungen am Flash in der VM nicht persistent sind.

Netzwerk hat bei mir auch noch nie funktioniert, ich habe es aber auch nicht ausgiebig probiert.

 

[MaxMuster]

Also bei meiner "alten Box" geht es meistens, Ich habe es einmal mit einem 7170 Image probiert, damit habe ich es nicht hinbekommen. Vielleicht ist hier sonst noch einer, der es mit den "neueren" Boxen hinbekommen hat?
Was mir noch einfällt: Irgendwo meine ich im Changelog oder so gelesen zu haben, dass das "normale" Ethernet und der "Switch" der neueren Boxen an unterschiedlichen Ports des ar7 hängen und unterschiedlich anzusprechen sind. Das könnte es ja auch sein...

Wenn ich Montag etwas Zeit habe, suche ich da nochmal nach.

Jörg

 

[kriegaex]

Das Netzwerk wäre mir wirklich wichtiger, aber zu den Flash-Änderungen: QEMU hat ja auch ein paar Schalter für irgendwelche Snapshots. Evtl. weiß ja jemand, ob man damit etwas erreichen kann. Innerhalb der VM kann man ja zu einer Art Kommando-Modus mit diversen Befehlen umschalten, ich kenne mich da nur nicht aus.

 

[RalfFriedl]

Ich habe auch so etwas in Erinnerung, daß der Switch nicht oder nicht richtig emuliert wird. Bisher habe ich auch nur Firmware von Boxen mit Switch im Emulator probiert.

 

[kriegaex]

@Oliver: Weiter oben hast Du den Maintainer der ar7-Version zitiert, als stündest Du mit ihm direkt im Kontakt. Kannst Du ihm evtl. mitteilen, daß wir noch immer Probleme mit dem Switch haben und ihn fragen, wieso in Rev. #826 die Box hochfährt, in der aktuellen SVN-Version aber "Calibrating delay loop..." Minuten dauert und auch ein deutlicher Hänger bei "NET: Registered protocol family 16" -> "Can't analyze prologue code at 9418fb7c" ist? Vielleicht hilft ihm diese Info, uns zu helfen. Evtl. hat er auch Ideen, wie man mit anderen "-net" Parametern eine bessere Funktion erreichen kann.

Anstatt in einem virtuellen LAN kann so eine QEMU-VM mit einem Tap-Device offenbar auch direkt ins lokale Netz eingebunden werden, zumindest bei anderen Gast-Plattformen. Ich bin leider Netzwerk-Noob, aber evtl. würde es sich für die Experten mal lohnen, die Start-Parameter zur Netzwerkkonfiguration anzuschauen bzw. auszutesten.