Re: [Qemu-devel] qemu on Cygwin
Hi, Sent: Sunday, February 04, 2007 2:16 AM Alexander Voropay wrote: > "Johannes Schindelin" <[EMAIL PROTECTED]> wrote: > >>> Did anyone try the latest CVS qemu on Cygwin ? > >> AFAICT this is due to SDL. I did not succeed in compiling any SDL related >> stuff in cygwin, but then, I did not really try, since the MinGW >> compilation is easy enough. > > I've successfully compiled SDL 1.2.11 on the fresh-installed Cygwin 1.5.24. > The following test SDL application works: > http://www.cse.nd.edu/courses/cse20211/www/code/sdl.html > > The SDL/test contains a bunch of SDL testing applications. > Most of them works too, even sound- and OpenGL related. > sdl-config adds -mno-cygwin option so that SDL on Cygwin uses MinGW compiler. An attached patch makes compile on Cygwin. But I have to downgrade mingw-runtime from 3.11 to 3.10. Regards, Kazu qemu-20070204-cygwin.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] MinGW's runtime library
Hi, FYI, MinGW's runtime library mingw-runtime-3.11.tar.gz doesn't work with QEMU. For example, when I installed MinGW-5.1.2.exe or MinGW-5.1.3.exe (gcc-3.4.2) to build QEMU, Windows 2000 guest doesn't boot because of this library. It stopped with "unhandled win32 exception". When I downgrade the library to mingw-runtime-3.10.tar.gz, it works fine. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Please help build qemu/darwin-user on Mac Intel
Hi Ilya, I just built from CVS before I zipped up the patches, here is the order I applied them: #gcc4 patches patch -p1 -u < ../patches/qemu-0.8.3-gcc4.patch patch -p1 -u < ../patches/qemu-0.7.2-dyngen-check-stack-clobbers.patch patch -p1 -u < ../patches/qemu-0.7.2-gcc4-opts.patch patch -p1 -u < ../patches/qemu-0.8.0-gcc4-hacks.patch #OS X86 patches patch -p1 -u < ../patches/qemu-0.8.3-enforce-16byte-stack-boundary.patch patch -p1 -u -f < ../patches/qemu-0.8.3-i386-FORCE_RET.patch patch -p1 -u < ../patches/qemu-0.8.3-osx-intel-port.patch patch -p1 -u < ../patches/qemu-0.8.0-osx-bugfix.patch notice the force -f for the FORCE_RET patch :). I had to update the old patches, because of changes like the updated defines for return(). Especially qemu-0.7.0-gcc4.patch does fail to apply because of that and was replaced with qemu-0.8.3-gcc4.patch. then I configured with ./configure --prefix=../products/i386 --enable-cocoa --enable-adlib -- disable-gcc-check --target-list=i386-softmmu Jep, I did not test with other targets. Mike On 04.02.2007, at 08:37, Ilya Shar wrote: Hi Mike, Thanks a lot for the patches. I applied them (together with qemu-0.7.0-gcc4.patch, which appears to be necessary although it's not in the archive you created) but in the middle of the build dyngen rejects op.o: ../dyngen -c -o opc.h op.o dyngen: Unable to replace ret with jmp in op_bsfl_T0_cc make[1]: *** [opc.h] Error 1 Did I mess up somewhere or there is something wrong with the patches? Thanks again for your help! Ilya --- Mike Kronenberg <[EMAIL PROTECTED]> wrote: Hi, we have decided to wait for the next qemu release until we update the patches for kju, as qemu dev has picked up speed, which is good. Never the less, you can grab the patches for qemu cvs (OS X Intel) here: http://www.kberg.ch/qemu/cvspatches20070202.zip Best Regards Mike On 03.02.2007, at 08:47, Pierre d'Herbemont wrote: Hi, On 3 févr. 07, at 02:37, Ilya Shar wrote: I am trying to build i386-darwin-user to run it on an x86 Mac. I'm on Mac OS 10.4 Intel with gcc 3.3 and I'm getting compiler errors right away: $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/darwine Ilya, qemu's CVS has the most up-to-date version of darwin-user now, so you should use it intead of the version which is in the darwine's cvs. Moreover to compile qemu on intel you'll need a few patche. The team behind Q.app has collected them for you [1]. Also I am not sure that gcc 3.3 can build Mac Intel binaries that are compliant with the current Mac OS X x86 ABI. So you may also need the gcc 4.0 patches that you should find in [1]. Pierre. [1] http://www.kju-app.org/proj/browser/trunk/patches ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel __ __ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu cpu-exec.c dyngen-exec.h hostregs_helper.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/02/04 13:37:44 Modified files: . : cpu-exec.c dyngen-exec.h Added files: . : hostregs_helper.h Log message: Fix 64-bit host register corruption. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.91&r2=1.92 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen-exec.h?cvsroot=qemu&r1=1.30&r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/hostregs_helper.h?cvsroot=qemu&rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointer truncation?)
On Saturday 03 February 2007 18:12, Gwenole Beauchesne wrote: > Hi, > > > Hmm. All I can say is the upper half of rbx (which holds T0) gets > > spilled on FreeBSD-current/amd64 hosts unless saving and restoring > > the full 64 bit of it... > > That's also what I got with VirtualBox on x86_64. Here is an update to > the patch I posted yesterday and that applies to current QEMU CVS > instead. I rewrote it a bit and applied to CVS. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Tracing memory accesses by emulated systems
Hello, I would like to trace all "physical" memory read/write operations for x86_64, but I have to admit that I'm not sure where exactly this has to be implemented. Could somebody give me some hints where and how I could do that? (or is there already a patch that does this? on irc somebody suggested that something like that could exist, but I was not able to find it) Regards Christian Leber -- http://rettetdieti.vde-uni-mannheim.de/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Tracing memory accesses by emulated systems
Am Sonntag, den 04.02.2007, 17:17 +0100 schrieb Christian Leber: > Hello, > > I would like to trace all "physical" memory read/write operations for x86_64, > but I have to admit that I'm not sure where exactly this has to be > implemented. > > Could somebody give me some hints where and how I could do that? > (or is there already a patch that does this? on irc somebody suggested > that something like that could exist, but I was not able to find it) > > Regards > > Christian Leber hello christian! i'm not sure if it applies for 64bit (but i'd assume it does). afaik the easiest way to catch "all" (dma operations are not covered there - i think) memory accesses is via the ld*,st* macros in softmmu_helper.h and softmmu_header.h. at least this is the way i did that. cheers m. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] parport EPP support for Linux
Hi.
With the attached patch I am able to use Kodak Advantix FD 300 APS
scanner from Win98 when hosted under Linux ix86. It adds EPP support
and fixes some register bits to match real hw so port identification
works better.
I tried to separate the linux dependencies with #ifdef __linux__, but
can not test this does not break compilation for other ports of qemu.
Suggestions are welcome, but I also welcome you to make the
enhancements yourself. This is good enough for me.
I hope it is good enough for inclusion in Qemu. It applies and was
tested against current CVS.
Marko
diff --git a/hw/parallel.c b/hw/parallel.c
index cba9561..44c1a28 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -2,6 +2,7 @@
* QEMU Parallel PORT emulation
*
* Copyright (c) 2003-2005 Fabrice Bellard
+ * Copyright (c) 2007 Marko Kohtala
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
@@ -22,9 +23,22 @@
* THE SOFTWARE.
*/
#include "vl.h"
+#include
//#define DEBUG_PARALLEL
+#ifdef DEBUG_PARALLEL
+#define pdebug(fmt, arg...) printf("pp: " fmt, ##arg)
+#else
+#define pdebug(fmt, arg...) ((void)0)
+#endif
+
+#define PARA_REG_DATA 0
+#define PARA_REG_STS 1
+#define PARA_REG_CTR 2
+#define PARA_REG_EPP_ADDR 3
+#define PARA_REG_EPP_DATA 4
+
/*
* These are the definitions for the Printer Status Register
*/
@@ -33,24 +47,33 @@
#define PARA_STS_PAPER 0x20 /* Out of paper */
#define PARA_STS_ONLINE 0x10 /* Online */
#define PARA_STS_ERROR 0x08 /* Error complement */
+#define PARA_STS_TMOUT 0x01 /* EPP timeout */
/*
* These are the definitions for the Printer Control Register
*/
+#define PARA_CTR_DIR 0x20 /* Direction (1=read, 0=write) */
#define PARA_CTR_INTEN 0x10 /* IRQ Enable */
#define PARA_CTR_SELECT 0x08 /* Select In complement */
#define PARA_CTR_INIT 0x04 /* Initialize Printer complement */
#define PARA_CTR_AUTOLF 0x02 /* Auto linefeed complement */
#define PARA_CTR_STROBE 0x01 /* Strobe complement */
+#define PARA_CTR_SIGNAL (PARA_CTR_SELECT|PARA_CTR_INIT|PARA_CTR_AUTOLF|PARA_CTR_STROBE)
+
struct ParallelState {
-uint8_t data;
-uint8_t status; /* read only register */
+uint8_t dataw;
+uint8_t datar;
+uint8_t status;
uint8_t control;
+uint8_t addr;
+int mode;
int irq;
int irq_pending;
CharDriverState *chr;
int hw_driver;
+int epp_timeout;
+uint32_t last_read_offset; /* For debugging */
};
static void parallel_update_irq(ParallelState *s)
@@ -61,96 +84,346 @@ static void parallel_update_irq(ParallelState *s)
pic_set_irq(s->irq, 0);
}
-static void parallel_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static int hw_mode(ParallelState *s, uint16_t mode)
+{
+if (s->mode != mode) {
+ int m = mode;
+ if (qemu_chr_ioctl(s->chr, CHR_IOCTL_PP_SETMODE, &m) < 0)
+ return 0;
+ s->mode = mode;
+}
+return 1;
+}
+
+static void
+parallel_ioport_write_sw(void *opaque, uint32_t addr, uint32_t val)
{
ParallelState *s = opaque;
+pdebug("write addr=0x%02x val=0x%02x\n", addr, val);
+
addr &= 7;
-#ifdef DEBUG_PARALLEL
-printf("parallel: write addr=0x%02x val=0x%02x\n", addr, val);
-#endif
switch(addr) {
-case 0:
-if (s->hw_driver) {
-s->data = val;
-qemu_chr_ioctl(s->chr, CHR_IOCTL_PP_WRITE_DATA, &s->data);
-} else {
-s->data = val;
-parallel_update_irq(s);
-}
+case PARA_REG_DATA:
+ s->dataw = val;
+ parallel_update_irq(s);
break;
-case 2:
-if (s->hw_driver) {
-s->control = val;
-qemu_chr_ioctl(s->chr, CHR_IOCTL_PP_WRITE_CONTROL, &s->control);
-} else {
-if ((val & PARA_CTR_INIT) == 0 ) {
-s->status = PARA_STS_BUSY;
-s->status |= PARA_STS_ACK;
-s->status |= PARA_STS_ONLINE;
-s->status |= PARA_STS_ERROR;
-}
-else if (val & PARA_CTR_SELECT) {
-if (val & PARA_CTR_STROBE) {
-s->status &= ~PARA_STS_BUSY;
-if ((s->control & PARA_CTR_STROBE) == 0)
-qemu_chr_write(s->chr, &s->data, 1);
-} else {
-if (s->control & PARA_CTR_INTEN) {
-s->irq_pending = 1;
-}
-}
-}
-parallel_update_irq(s);
-s->control = val;
-}
+case PARA_REG_CTR:
+ if ((val & PARA_CTR_INIT) == 0 ) {
+ s->status = PARA_STS_BUSY;
+ s->status |= PARA_STS_ACK;
+ s->status |= PARA_STS_ONLINE;
+ s->status |= PARA_STS_ERROR;
+ }
+ else if (val & PARA_CTR_SELECT) {
+ if (val & PARA_CTR_STROBE) {
+ s->status &= ~PARA_STS_BUSY;
+ if ((s->control & PARA_CTR_STROBE) == 0)
+ qemu_chr_write(s->chr, &s->dataw, 1);
+ } else {
+ if (s->control & PARA_
[Qemu-devel] Re: [PATCH] parport EPP support for Linux
Darn.
I managed to send an older version of the patch.
Here is the latest. Sorry for the junk.
Marko
On 2/4/07, Marko Kohtala <[EMAIL PROTECTED]> wrote:
Hi.
With the attached patch I am able to use Kodak Advantix FD 300 APS
scanner from Win98 when hosted under Linux ix86. It adds EPP support
and fixes some register bits to match real hw so port identification
works better.
I tried to separate the linux dependencies with #ifdef __linux__, but
can not test this does not break compilation for other ports of qemu.
Suggestions are welcome, but I also welcome you to make the
enhancements yourself. This is good enough for me.
I hope it is good enough for inclusion in Qemu. It applies and was
tested against current CVS.
Marko
diff --git a/hw/parallel.c b/hw/parallel.c
index cba9561..bd61e5e 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -2,6 +2,7 @@
* QEMU Parallel PORT emulation
*
* Copyright (c) 2003-2005 Fabrice Bellard
+ * Copyright (c) 2007 Marko Kohtala
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
@@ -25,6 +26,18 @@
//#define DEBUG_PARALLEL
+#ifdef DEBUG_PARALLEL
+#define pdebug(fmt, arg...) printf("pp: " fmt, ##arg)
+#else
+#define pdebug(fmt, arg...) ((void)0)
+#endif
+
+#define PARA_REG_DATA 0
+#define PARA_REG_STS 1
+#define PARA_REG_CTR 2
+#define PARA_REG_EPP_ADDR 3
+#define PARA_REG_EPP_DATA 4
+
/*
* These are the definitions for the Printer Status Register
*/
@@ -33,24 +46,33 @@
#define PARA_STS_PAPER 0x20 /* Out of paper */
#define PARA_STS_ONLINE 0x10 /* Online */
#define PARA_STS_ERROR 0x08 /* Error complement */
+#define PARA_STS_TMOUT 0x01 /* EPP timeout */
/*
* These are the definitions for the Printer Control Register
*/
+#define PARA_CTR_DIR 0x20 /* Direction (1=read, 0=write) */
#define PARA_CTR_INTEN 0x10 /* IRQ Enable */
#define PARA_CTR_SELECT 0x08 /* Select In complement */
#define PARA_CTR_INIT 0x04 /* Initialize Printer complement */
#define PARA_CTR_AUTOLF 0x02 /* Auto linefeed complement */
#define PARA_CTR_STROBE 0x01 /* Strobe complement */
+#define PARA_CTR_SIGNAL (PARA_CTR_SELECT|PARA_CTR_INIT|PARA_CTR_AUTOLF|PARA_CTR_STROBE)
+
struct ParallelState {
-uint8_t data;
-uint8_t status; /* read only register */
+uint8_t dataw;
+uint8_t datar;
+uint8_t status;
uint8_t control;
+uint8_t addr;
+int mode;
int irq;
int irq_pending;
CharDriverState *chr;
int hw_driver;
+int epp_timeout;
+uint32_t last_read_offset; /* For debugging */
};
static void parallel_update_irq(ParallelState *s)
@@ -61,96 +83,351 @@ static void parallel_update_irq(ParallelState *s)
pic_set_irq(s->irq, 0);
}
-static void parallel_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+#ifdef __linux__
+#include
+static int hw_mode(ParallelState *s, uint16_t mode)
+{
+if (s->mode != mode) {
+ int m = mode;
+ if (qemu_chr_ioctl(s->chr, CHR_IOCTL_PP_SETMODE, &m) < 0)
+ return 0;
+ s->mode = mode;
+}
+return 1;
+}
+#endif
+
+static void
+parallel_ioport_write_sw(void *opaque, uint32_t addr, uint32_t val)
{
ParallelState *s = opaque;
+pdebug("write addr=0x%02x val=0x%02x\n", addr, val);
+
+addr &= 7;
+switch(addr) {
+case PARA_REG_DATA:
+ s->dataw = val;
+ parallel_update_irq(s);
+break;
+case PARA_REG_CTR:
+ if ((val & PARA_CTR_INIT) == 0 ) {
+ s->status = PARA_STS_BUSY;
+ s->status |= PARA_STS_ACK;
+ s->status |= PARA_STS_ONLINE;
+ s->status |= PARA_STS_ERROR;
+ }
+ else if (val & PARA_CTR_SELECT) {
+ if (val & PARA_CTR_STROBE) {
+ s->status &= ~PARA_STS_BUSY;
+ if ((s->control & PARA_CTR_STROBE) == 0)
+ qemu_chr_write(s->chr, &s->dataw, 1);
+ } else {
+ if (s->control & PARA_CTR_INTEN) {
+ s->irq_pending = 1;
+ }
+ }
+ }
+ parallel_update_irq(s);
+ s->control = val;
+break;
+}
+}
+
+static void parallel_ioport_write_hw(void *opaque, uint32_t addr, uint32_t val)
+{
+ParallelState *s = opaque;
+uint8_t parm = val;
+
+/* Sometimes programs do several writes for timing purposes on old
+ HW. Take care not to waste time on writes that do nothing. */
+
+s->last_read_offset = ~0U;
+
addr &= 7;
-#ifdef DEBUG_PARALLEL
-printf("parallel: write addr=0x%02x val=0x%02x\n", addr, val);
-#endif
switch(addr) {
-case 0:
-if (s->hw_driver) {
-s->data = val;
-qemu_chr_ioctl(s->chr, CHR_IOCTL_PP_WRITE_DATA, &s->data);
-} else {
-s->data = val;
-parallel_update_irq(s);
-}
+case PARA_REG_DATA:
+if (s->dataw == val)
+ return;
+ pdebug("wd%02x\n", val);
+ qemu_chr_ioctl(s->chr, CHR_IOCTL_PP_WRITE_DATA, &parm);
+ s->dataw = val;
break;
-case 2:
-if (s->hw_driver) {
-s->control = val;
-qemu_chr_ioctl(s->chr, CHR_IOCTL_P
Re: [Qemu-devel] [PATCH] parport EPP support for Linux
Marko Kohtala wrote: Hi. With the attached patch I am able to use Kodak Advantix FD 300 APS scanner from Win98 when hosted under Linux ix86. It adds EPP support and fixes some register bits to match real hw so port identification works better. I tried to separate the linux dependencies with #ifdef __linux__, but can not test this does not break compilation for other ports of qemu. Suggestions are welcome, but I also welcome you to make the enhancements yourself. This is good enough for me. I hope it is good enough for inclusion in Qemu. It applies and was tested against current CVS. I don't understand why you need a #ifdef __linux__ in parallel.c. Normally, the qemu character device should suffice to do the appropriate abstraction. Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] parport EPP support for Linux
Fabrice Bellard: Marko Kohtala wrote: Hi. With the attached patch I am able to use Kodak Advantix FD 300 APS scanner from Win98 when hosted under Linux ix86. It adds EPP support and fixes some register bits to match real hw so port identification works better. I tried to separate the linux dependencies with #ifdef __linux__, but can not test this does not break compilation for other ports of qemu. I don't understand why you need a #ifdef __linux__ in parallel.c. Normally, the qemu >character device should suffice to do the appropriate abstraction. I did not find appropriate abstraction. Linux parallel device needs to do a read() on the device. A read() on the parallel port device executes EPP read cycle on the parallel port to read from the device attached to it. Poll() does not execute such cycles, but it only signals read if the port makes an interrupt, and therefore the current poll() based character device abstraction does not work. So there are few read() and write() calls in the code. Also the parallel port device IEEE mode settings use some constants from linux/parport.h. These are needed to tell the device execute EPP data or address cycles on reads and writes. I am too new with qemu to say how to develop the qemu character device abstraction for these requirements. Marko ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Signal handling for i386-darwin-user on Mac Intel
Thanks to pointers/patches from Mike and Pierre, I can build i386-darwin-user binary. There is a glitch though with signal-handling. The following fragment in cpu_signal_handler() in cpu-exec.c pc = uc->uc_mcontext.gregs[REG_EIP]; trapno = uc->uc_mcontext.gregs[REG_TRAPNO]; appears to be Linux-specific and gives compilation errors on a Mac: /Users/ilya/tmp/feb4/qemu_cvs_user/qemu/cpu-exec.c: In function 'cpu_x86_signal_handler': /Users/ilya/tmp/feb4/qemu_cvs_user/qemu/cpu-exec.c:1307: error: request for member 'gregs' in something not a structure or union /Users/ilya/tmp/feb4/qemu_cvs_user/qemu/cpu-exec.c:1307: error: 'EIP' undeclared (first use in this function) ... When I dummy-out cpu_signal_handler() the binary compiles, but I cannot run anything because the signals are not handled. Is there a patch/solution to this? Thanks again for your help! Ilya Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
