FB Emulation (qemu) - suche helfende Hand

Status
Für weitere Antworten geschlossen.
Hehe, das funktioniert ja wirklich. Aber wie leite ich denn unter Windows die Standard-Fehlerausgabe ins Nirvana um?

MfG Oliver
 
> nul, soweit ich weiß.

Edit: Ach so, Fehlerausgabe. 2> nul.

Es klappt scheint's auch > nul 2>&1.
 
Hatte ich doch schon nachgetragen;-) : Bei mir klappte

"2> :NUL"

EDIT @Oliver: und danke für's mkfirm! Da hat man ja schon "fast" alles.
Wenn man nun noch das "Flash" beschreiben/verändern könnte...

Jörg
 
Tauschen kann man das ja auch. Jetzt muss man also nur noch ein tffs-Image am PC bearbeiten können. Das könnte man entweder über ein Kernelmodul (Source haben wir ja) oder über sowas wie Enriks mktffs.pl realisieren.

MfG Oliver
 
Ich habe übrigens noch immer zwischendurch das Problem, dass das eth0 "disabled" wird. Manchmal kommt es dann nach ein paar Minuten wieder, aber so richtig dolle ist das nicht (wenn man versucht, was für die GUI zu programmieren).
Ich werde mir wenn ich dazu komme mal den STP-Part im Kernel mal ansehen, vielleich kann man ja mal einen "special" Kernel-Hack für qemu bauen, um der Bridge das abzugewöhnen (wo der in der virtuellen Box nun wirklich unnütz ist). Es ist übrigens mit fast 100%-er Sicherneit der STP: Ich kann z.B. mit einem

ifconfig eth0 down; ifconfig eth0 up; ping 10.0.2.2

manchmal ein bis zwei Pings "durchbringen", ehe das Interface nach "learning" disabled wird...

Jög
 
Hi.
Hier mal ein paar Quotes von Stefan Weil.
1. Thema: Netzwerk funktioniert nicht
Die gute Nachricht ist, dass ich es bei mir nachvollziehen kann.
Die schlechte ist, dass ich dafür noch keine Abhilfe habe, weil ich die genaue Ursache nicht kenne.

Der Ethernet-Treiber in QEMU für AR7 ist alles andere als perfekt, da ich bis heute keine offizielle Doku für den Chipsatz habe. Potentielle Schwachpunkte sind das Pakethandling (Pakete gehen insbesondere beim Empfang gelegentlich verloren, was wegen der automatischen Fehlerkorrektur von TCP nicht weiter auffällt) und das Interface zum
(emulierten) physikalischen Netz (NIC), das normalerweise fest auf 100 MBit full duplex programmiert ist, aber je nach Kernel nicht immer so funktioniert.

Wenn Ihr Zeit habt, könnt Ihr mal mit einer "echten" FBOX ausprobieren, ob Abziehen und Stecken des Ethernet-Kabels den gleichen Effekt produziert. Falls ja, hat die NIC-Emulation noch eine Schwäche. Man kann dann wahlweise die Emulation verbessern, oder man macht den Kernel toleranter.

Die Boxen mit Switch verwenden in der Regel einen externen NIC (Switch-Hardware) und den 2. Ethernet-Port des AR7.
Zumindest mit dem Kernel von OpenWrt funktionieren sie.
Man muss dabei Qemu so aufrufen, dass zwei Netzwerke konfiguriert werden - das erste wird vom Kernel ignoriert, das zweite ist dann für die emulierte FBOX eth0.
2. Thema: eigener Kernel:
Empfehlenswert ist, zusätzlich zu den von AVM vorgesehenen Kernel-Optionen auch Debugsymbole einzuschalten, da dann symbolisches Debuggen mit einem Crossdebugger (mipsel-linux-gdb) sehr schön funktioniert. Auch in den Logmeldungen von Qemu für AR7 werden dann Funktionsnamen statt leerer Klammern [] angezeigt. Und natürlich kann man sich in einem selbstkompilierten Kernel wunderbar austoben :)

Ein MIPS-Linux-Kernel (auch der von AVM) erwartet ähnlich main in C eine Argumentenliste (char *argv[]) und Environmentvariablen (char *envp[]).

Qemu für AR7 kann diese aus einer Datei lesen. Dateiaufbau:

argv (jedes Element in eigener Zeile)
Leerzeile
envp (jeweils Name und Wert in eigener Zeile)

Ein Beispiel einer solchen Datei für FBOX WLAN steht in der Anlage.

Qemu-Aufruf: qemu-system-mipsel mit üblichen Parametern, zusätzlich -kernel <Pfad für vmlinux> -append <Pfad für Datei mit Parametern>
MfG Oliver
 

Anhänge

  • fbox-08.04.34.zip
    607 Bytes · Aufrufe: 66
Zum "Netzproblem": Ich hatte ja den Spanning-Tree in Verdacht, den konnte ich aber ausschließen:
- Das Problem tritt auch auf, wenn ich die Bridge deaktiviere und nur das eth0 nutze
- Mit vielen printk's im Kernel konnte ich das zurückverfolgen bis zur "Abarbeitung von Device Events" (ich schaue das morgen nochmal nach, wie das genau hieß).
Es sieht jedenfalls so aus, dass ständig "device-changes" erzeugt werden, die dann manchmal (oder oft) das Interface "runterziehen".
Wenn ich wüsste wo, würde ich ja das "Link-State-Ändern" abschalten, schließlich sollte es eigentlich unmöglich sein, ein virtuelles Kabel herauszuziehen ;-)

Ich liefere morgen nach, bis wohin ich das genau zurückverfolgt hatte. War eine "event-queue" in net/core/dev.c wenn ich mich recht entsinne...


Jörg

EDIT: Was ich rausgefunden hatte:
Es wird für das Ethernet-Interface ständig "netdev_state_change(dev)" aufgerufen, was in dev.c definiert ist. Der Aufruf geschieht aus "linkwatch_run_queue()", das wiederum von "linkwatch_event()" aufgerufen wird, beides in linkwatch.c definiert. Wo/wie die Events in diese Queue kommen, da bin ich dann nicht mehr weitergekommen...
 
Zuletzt bearbeitet:
Ich habe es jetzt auch geschafft, sogar mit eine GCC 4.1.2 (von Suse 10.2) auf einem 64-Bit Athlon.
Wenn die Flash-Datei nicht exakt 8MB groß ist, wird sie kommentarlos ignoriert, und damit kommt man nicht weit.

Ansonsten sieht es interessant aus. Wenn jetzt noch die Hardware-Emulation für ISDN, DSL und USB etwas verbessert wird, ist es schon fast vollständig.

Außerdem habe ich das memread.c etwas umgeschrieben, so daß es etwas effizienter ist, speziell, wenn man die Ausgabe gleich über Netzwerk weiterleiten will.

Gibt es eine einfache Möglichkeit, bei einem unbekannten Speicherzugriff in ar7_io_memread oder ar7_io_memwrite in den DEbugger zu springen?
 
Wie hast du denn das mit dem 4-er GCC hinbekommen? Einfach die "Weigerung" rausgenommen? Oder noch was gepatched?

Danke!

Jörg
 
Code:
./configure --target-list=mipsel-softmmu --disable-vnc-tls [B]--disable-gcc-check[/B] --disable-gfx-check --disable-alsa --disable-fmod --disable-coreaudio --disable-sdl --disable-oss
Ich habe gerade die Unterschiede zwischen meiner Lokalen Version und dem SVN durchgeschaut, aber das sind nur wenige Änderungen, die mit Suche nach dem oben genannten Flash-Problem zu tun haben.

Leider steht auch nirgends, was das Problem mit dem GCC 4 Compiler sein soll. Vielleicht hat sich das Problem ja inzwischen schon gelöst.

--disable-oss funktioniert übrigens nicht. Bisher habe ich keine Verwendung für eine Audioausgabe an einer Fritzbox, daher hätte ich auch auf OSS gern verzichtet.

Ich habe auch memread.c angehängt. Es enthält mehr Überprüfungen und Fehlermeldungen und liest in größeren Blöcken aus.
Code:
/* memread - read physical memory in a running Linux system
 *
 * Copyright (C) 2006 Stefan Weil
 *
 * This code is licensed under the terms of the GNU Public License (GPL).
 */

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

#if !defined(O_BINARY)
# define O_BINARY 0
#endif

static void
memread(unsigned long offset, unsigned long length)
{
        const char *filename = "/dev/mem";
        off_t pos;
        int f = open(filename, O_RDONLY | O_BINARY);
        if (f < 0) {
          perror (filename);
          return;
        }
        pos = lseek(f, offset, SEEK_SET);
        if ((unsigned long)pos != offset) {
          perror ("lseek");
          return;
        }
        while (length > 0) {
          char buf[0x10000];
          size_t len = length > sizeof (buf) ? sizeof (buf) : length;
          ssize_t res = read (f, buf, len);
          if (res < 0) {
            perror ("read");
            return;
          }
          if (res == 0) {
            perror ("eof");
            return;
          }
          if (write (1, buf, res) != res) {
            perror ("write");
            return;
          }
          length -= res;
        }
        close(f);
}

int
main(int argc, char *argv[])
{
        if (argc == 3) {
                unsigned long offset = strtoul(argv[1], 0, 0);
                unsigned long length = strtoul(argv[2], 0, 0);
                memread(offset, length);
                return 0;
        }
        fprintf (stderr, "%s offset length\n", argv[0]);
        return 1;
}
 
Danke für den Hinweis! Einen Fehler hatte ich noch
Code:
usb-linux.c:130: error: ‘struct usbdevfs_bulktransfer’ has no member named ‘data’
den konnte ich aber dank dieses Hinweises noch beheben:
Code:
Index: usb-linux.c
===================================================================
RCS file: /sources/qemu/qemu/usb-linux.c,v
retrieving revision 1.10
diff -u -p -r1.10 usb-linux.c
--- usb-linux.c 10 Dec 2006 22:11:04 -0000      1.10
+++ usb-linux.c 29 Aug 2007 11:45:13 -0000
@@ -26,6 +26,7 @@
 #if defined(__linux__)
 #include <dirent.h>
 #include <sys/ioctl.h>
+#define __user
 #include <linux/usbdevice_fs.h>
 #include <linux/version.h>


Jörg
 
__user wird bei mir in /usr/include/linux/compiler.h (aus glibc-devel-2.4-25) definiert und das wurde wohl auch schon indirekt eingelesen, da bei mir keine derartige Meldung kam.

Über Deinen Link habe ich aber auch einen Hinweis auf das Problem mit GCC 4 gefunden. Es scheint dabei um die Anzahl der Register zu gehen.
von hier:
The inherent problem is, that qemu uses 64bit entities in some places (sometimes structs), which GCC (4.x) manages to place in registers, i.e. needs 2 hardregs. But it sometimes just so happens that an instruction needing such DImode reg also has a memory operand with an indexed address (reg plus reg), hence two hardregs more. But qemu by default leaves just three free registers for compiling op.c --> boom.
Vielleicht wäre das Problem besser "GCC 4 auf i386" genannt worden.

In der 64-Bit CPU gibt es doppelt so viele Register, außerdem werden nicht zwei Register für einen 64-Bit Wert benötigt. Vielleicht ging es deswegen ohne Probleme.
 
Zuletzt bearbeitet:
Ja, der Thread da war interessant...
Ich denke aber, dass es evtl auch auf 32-Bittern nun läuft, wenn ich so einige Changes im qemu lese, liest sich da einiges in diese Richtung:
Code:
2007-09-20 17:21  blueswir1

        * target-sparc/op.c:  Fix tadd op generation with GCC 4.x
[...]
2007-07-26 22:41  balrog

        * configure: gcc32 may well be a 4.x version for a 32bit target, so
          add an additional check, hopefully not too strict.  Probe also
          gcc-3.3.6 to make Gentoo users happy.

Wie dem auch sei, erstaunlich fand ich aber doch, dass "meine Suse" (ebenfalls 10.2-er x64) so eine "Heulsuse" ist und deine nicht ;-)
Aber wer weiß, da ich ja immer mal wieder was "austausche" und "dazuinstalliere", kann das natürlich auch daran liegen ..

Das Binary funktioniert jedenfalls.

Jörg
 
Zuletzt bearbeitet:
MaxMuster schrieb:
Wie dem auch sei, erstaunlich fand ich aber doch, dass auf "meine Suse" (ebenfalls 10.2-er x64) so eine "Heulsuse" ist und deine nicht ;-)
Ich glaube, ich habe auch dafür die Erklärung:
Ich habe von 10.1 einige Pakete aktualisiert, aber anscheinend nicht alle. Ich war davon ausgegangen, daß zumindest alles, was Compiler und Libraries betrifft, von 10.2 stammt, aber wie bereits geschrieben, ist glibc-devel-2.4-25 installiert, während bei 10.2 glibc-devel-2.5-25 dabei ist, und da ist die Datei /usr/include/linux/compiler.h nicht drin, dafür ist sie in linux-kernel-headers-2.6.18.2-3.
 
Ich muss das auf jeden Fall beobachten: Der erste Test hat jetzt eine halbe Stunde lang das Ethernetinterface nicht "runtergefahren". Vermutlich nur Zufall, aber nett, gleich so beim ersten Mal.
[OT] Der 10.3 RC1 Download ist gerade fertig geworden [/OT]

Jörg
 
Ein kleines "HowTo"

Hallo zusammen,

ich habe mal versucht, das ganze, was hier zusammengetragen wurde, in einem Dokument zusammenzufassen...
Anregungen nehme ich gern entgegen

Jörg

EDIT Alten Anhang gelöscht. Überarbeitetes Dokument gibt es hier
 
Zuletzt bearbeitet:
Speicher für QEMU auslesen: Shell-Kommando statt memread.c

Vereinfachungsvorschlag für Abschnitt 2 ("Vorbereitung: Firmware auslesen"): Lassen wir doch einfach das C-Programm weg und benutzen die Shell, indem wir mit cat arbeiten, und zwar am besten aus der Rudi-Shell heraus mit angekreuztem Download-Schalter, dann wird erst gar kein Speicher auf der Box belegt. Einfach folgenden Befehl ausführen:
Code:
cat /dev/mtdblock3 /dev/mtdblock2 /dev/mtdblock4 /dev/mtdblock5
Die zum Download angebotene Datei unter einem beliebigem Namen speichern - fertig! Das Ergebnis ist aufs Bit identisch mit dem Ergebnis von memread, wie md5sum beweist. Kein Kompilieren, keine speziellen Parameter für unterschiedliche Boxen.
 
Zuletzt bearbeitet:
Probleme beim Bauem von QEMU laut Skript

Ausnahmsweise ein Doppel-Post, weil völlig anderes Thema:

Mini-Fehler im Skript: Im configure-Aufruf ist ein kleiner Tippfehler: Es muß --disable-sdl (zwei Minuszeichen) heißen. Außerdem wäre ein Backslash ("\") als Zeichen für eine fortgesetzte Zeile besser als "//", dann könnte man die Zeilen gleich kopieren, wie sie sind.

Fehler beim Kompilieren: Unter/mit
  • Linux xander 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
  • GNU Make 3.81
  • gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
habe ich die Probleme, welche man ausschnittsweise hier und vollständig im Make-Log im Anhang sehen kann. Hat da jemand eine Idee?
Code:
/home/kriegaex/src/qemu-ar7/trunk/target-mips/exec.h: In Funktion »cpu_halted«:
/home/kriegaex/src/qemu-ar7/trunk/target-mips/exec.h:212: Warnung: Deklaration von »env« überdeckt eine globale Deklaration
/home/kriegaex/src/qemu-ar7/trunk/target-mips/exec.h:11: Warnung: Verdeckte Deklaration ist hier
/home/kriegaex/src/qemu-ar7/trunk/target-mips/exec.h: In Funktion »compute_hflags«:
/home/kriegaex/src/qemu-ar7/trunk/target-mips/exec.h:224: Warnung: Deklaration von »env« überdeckt eine globale Deklaration
/home/kriegaex/src/qemu-ar7/trunk/target-mips/exec.h:11: Warnung: Verdeckte Deklaration ist hier
/home/kriegaex/src/qemu-ar7/trunk/target-mips/op_mem.c: In Funktion »op_suxc1_user«:
/home/kriegaex/src/qemu-ar7/trunk/target-mips/op_mem.c:415: Fehler: in Klasse »GENERAL_REGS« konnte kein Register für Überlauf gefunden werden
/home/kriegaex/src/qemu-ar7/trunk/target-mips/op_mem.c:415: Fehler: dies ist der Befehl:
(insn:HI 38 37 39 2 ../cpu-all.h:344 (set (mem:DI (plus:SI (reg/v:SI 59 [ addr ])
                (reg:SI 71 [ <variable>.addend ])) [0 S8 A64])
        (reg/v:DI 60 [ v ])) 80 {*movdi_2} (insn_list:REG_DEP_TRUE 37 (nil))
    (expr_list:REG_DEAD (reg/v:DI 60 [ v ])
        (expr_list:REG_DEAD (reg/v:SI 59 [ addr ])
            (expr_list:REG_DEAD (reg:SI 71 [ <variable>.addend ])
                (nil)))))
/home/kriegaex/src/qemu-ar7/trunk/target-mips/op_mem.c:415: durch frühere Fehler verwirrt, Abbruch
make[1]: *** [op.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/kriegaex/src/qemu-ar7/trunk/mipsel-softmmu'
make: *** [subdir-mipsel-softmmu] Fehler 2
 

Anhänge

  • make.log.bz2
    8.2 KB · Aufrufe: 3
Status
Für weitere Antworten geschlossen.
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.