qemu serielle schnittstelle forwarden

kong

kong

Well-Known Member
Hallo, noch ein qemu-Problem:
Ich habe ein WindowsNT in qemu laufen und will das eigentlich nur um meinen bei ebay günstig erstandenen Psion Revo zu verbinden -- die Software gibt es nur für Windows, für Linux gibt es auch was, aber Linux ist keine Option weil amd64 port von OpenBSD 4.4; aber: wenn jemand was besseres weiß um an die Daten aus einem Psion Revo zu kommen, dann bin ich freilich auch dankbar.
Dafür muss nun das Windows auf den seriellen Anschluss zugreifen können, und wenn ich die qemu-Doku richtig verstanden habe sollte das mit
Code: 
qemu -serial /dev/tty00 ...
gehen. Geht aber nicht, sondern qemu weigert sich zu starten und meldet: "could not open /dev/tty00" Also habe ich sämmtliche tty0[0-3] und auch cua0[0-3] durchprobiert, ich dachte eigentlich es müsste 02 sein, weil meine dmesg folgendes über die com-Anschlüsse sagt:
Code: 
puc0 at pci4 dev 0 function 0 "NetMos Nm9835" rev 0x01: ports: 2 com, 1 lpt
com2 at puc0 port 0 apic 4 int 16 (irq 10): ns16550a, 16 byte fifo
com3 at puc0 port 1 apic 4 int 16 (irq 10): ns16550a, 16 byte fifo
Mein user ist in der dialer-group, also sollte es daran nicht liegen -- oder?
Mache ich was falsch?, Weiß jemand Rat?

Grüße, Stefan
 
Nein, siehe OpenBSD FAQ 9.4; das geht nur mit dem i386-Port. Die PLP-tools (http://sourceforge.net/project/showfiles.php?group_id=8797) weigern sich außerdem bei mir zu kompilieren, obwohl sie Plattformunabhängig sein sollten, und ich bin zu blöd den Fehler zu beheben, aber wenn jemand was damit anfangen kann, hier der Fehler:

Code: 
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../intl -I/usr/local/include -g -O2 -MT psitime.lo -MD -MP -MF .deps/psitime.Tpo -c psitime.cc  -fPIC -DPIC -o .libs/psitime.o
psitime.cc: In function `std::ostream& operator<<(std::ostream&, const 
   PsiTime&)':
psitime.cc:184: error: cannot convert `const long int*' to `const time_t*' for 
   argument `1' to `tm* localtime(const time_t*)'
psitime.cc: In function `long long unsigned int evalOffset(psi_timezone_t, int, 
   bool)':
psitime.cc:223: error: invalid conversion from `char*(*)(int, int)' to `long 
   long int'
psitime.cc:232: error: invalid operands of types `s_int64_t' and `char*()(int, 
   int)' to binary `operator-'
psitime.cc:232: error:   in evaluation of `operator-=(s_int64_t, char*()(int, 
   int))'
*** Error code 1

Grüße, Stefan
 
psion verbingden gelößt

Also falls es jemanden interessiert: den Psion Revo mit OpenBSD verbinden geht mit ppp über die Konsole, oder direkt indem man sich ein getty auf die Konsole macht und dann mit "Hermes" - epoc Terminal-Emulation - auf dem PC einloggt. Das Hermes findet man hier: http://www.psion-user-club.at/d_www2.html
Man muß es halt vorher mit einer Windows Box installieren, oder über ppp (Psion darüber durch den eigenen Computer mit Internet verbinden, dann das Ding per mail irgendwohin schicken und die mail mit dem epoc-mailprogramm abrufen.) Auf der verlinkten Seite gibt es außerdem einen Texteditor für epoc: Schon kann man unterwegs an einem Latex-Artikel arbeiten und ihn später daheim kompilieren.
 
kommst du mit minicom auf die serielle schnittstelle?
was passiert bei einem

Code: 
% echo hallo >/dev/tty00
?
 
Also bei mir sind die Seriellen Anschlüsse auf einer pcix-Karte, daher gibt es nur tty02 und tty03. tty03 ist mit dem Revo verbunden, tty02 mit einer alten Sun Fire v120. Minicom habe ich jetzt nicht extra installiert, ich nehme immer tip, also um deine Fragen zu beantworten:
Code: 
kong:1$ echo hallo >/dev/tty03
^C/bin/ksh: cannot create /dev/tty03: Interrupted system call

kong:2$ tip SunFire
connected


LOMlite console
Please login: ~
[EOT]
kong:3$ tip tty03
connected
èèèìèèìèèììèèìèèèìèèèè~
[EOT]
Das echo hallo hört nicht auf bis ich manuell ^C drücke, dann spuckt es die Meldung aus. Die Karte funktioniert offenbar an sich, zumal ich zur lom-Konsole der Sun komme. Wenn ich den Psion antippe beginnt es diese es und is auszuspucken und hört nicht auf bis ich die Verbindung trenne.

Grüße, Stefan

P.s: Ich werde nochmal mit den Optionen in /etc/remote spielen, an der baudrate dürfte es jedenfalls nicht liegen, aber ich denke mal der Psion hat gar keine brauchbare Konsole offen, melde mich falls doch.
 
Zuletzt bearbeitet:
Also, das beste was ich hinkriege sind lauter "4C!"s:
Code: 
kong:26$ tip tty03 
connected
!4C!4C!4C!4C!4C!4C!4C!4C!4C~
[EOT]
Und hier die entsprechendened Zeilen der /etc/remote:
Code: 
tty03:\
        :dv=/dev/tty03:tc=direct:br#115200:
"tc=direct" macht nichts weiter als ":dc:", die baudrate habe ich einfach aus den modem-Einstellungen des Psion übernommen, da gibt es eine Option "direkte Verbindung" und die habe ich eingestellt.
 
zusaetzlich zur baudrate gibt es noch die parameter fuer datenbits, stop-bits und die parity.
aber das ist jetzt voellig wurst.

so wie das aussieht funktioniert deine serielle schnittstelle. die parameter wird wenn dann qemu setzen.
da ist scheinbar was anderes faul. ich wuerde dir raten wirklich mal einen blick auf die quellen zu werfen, was -serial da genau treibt.


edit: bingo. die manpage sagt mir gerade
Code: 
       -serial dev
           Redirect the virtual serial port to host character
           device dev. The default device is "vc" in graphical
           mode and "stdio" in non graphical mode.
(...)
           "/dev/XXX"
               [Linux only] Use host tty, e.g. /dev/ttyS0. The
               host serial port parameters are set according to
               the emulated ones.
 
Ok, ist ja peinlich, dass ich das überlesen habe. Genau an der Stelle dachte ich nämlich "super, das ist was ich suche". Also geht wohl nur mit Linux.
Was allerdings funktioniert ist wohl das qemu-serielle Signal an eine named Pipe zu leiten, also etwa:
Code: 
qemu -serial pipe:meinfifo ...
Jetzt ist meine Frage (kann es gerade nicht probieren): Kann ich nicht einfach dann noch zusätzlich:
Code: 
ln -s /dev/tty03 /meinfifo
machen, und ich habe die Beschränkung umgangen? Oder ist das nicht so einfach?

Grüße und danke schonmal, Stefan
 
Nein, geht natürlich nicht so einfach (manpage von ln zu lesen hat gereicht: man kann gar nicht vorhandene Dateien miteinander verlinken).
Für linux gibt es wohl einen serial-logger, mit dem sowas möglich ist; siehe: http://linuxforen.de/forums/showthread.php?t=141201
Ansonsten hat wohl dettus recht, das geht halt nicht ohne sich mit den qemu-sourcen zu befassen. Melde mich falls ich Lösung finde.
s.
 
Hallo,

ich weiß, der Thread ist alt, aber
1) findet Google alles und
2) hatte ich ein ähnliches Problem

Wenn man ein virtuelles System z.B. für eine embedded Plattform (also ohne Grafik, Keyboard, etc.) emulieren möchte, kann man z.B. für NetBSD folgendes nutzen:

consdev com0; boot netbsd

qemu [..] -serial telnet:localhost:4444,server

Mit der seriellen Schnittstelle kann man sich dann vom Host aus mit "telnet localhost 4444" verbinden.

Nochmals Entschuldigung fürs Ausgraben, aber vllt. ist es für den ein oder anderen hilfreich. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben