The following patch fixes the problem that DMA transfers are not performed when
the DCSR_STOPINTR bit is set.
--
Thorsten
Index: hw/pxa2xx_dma.c
===
RCS file: /sources/qemu/qemu/hw/pxa2xx_dma.c,v
retrieving revision 1.5
diff -u
Hi. The following patch adds support for Gumstix connex boards. A working flash
image (after unpacking) is
http://omnibus.uni-freiburg.de/~zitteret/files/qemu/flash.bz2
Comments?
--
Thorsten
Index: Makefile.target
===
RCS file:
On Thursday 15 November 2007, test test wrote:
--
-- dyngen: Unsupported ELF class
make[1]: *** [op.h] Error 1
--
--
What's the problem?
Is it possible to get networking to work with ME/98 as guest ?
No network device shows up in this case as in XP which works fine.
Command I use;
qemu -hda Win98.img -net nic,model=rtl8139 -net user
I believe you can do it similar to the way I did for isochronous
transfers in usb-linux.c.
Remember that using SUBMITURB and REAPURBNDELAY ioctls, you need to add
another signal and signal handler for the async bulk, and there might be
some issues in the ohci/uhci because they currently assume
I'm currently running into a problem when running recent Linux kernels as a
guest under QEMU with KQEMU kernel acceleration. My problem is that early in
the boot process the guest kernel panics, the host OS appears to be
unaffected. The panic can be different depending on the guest Linux
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is it possible to get networking to work with ME/98 as guest ?
No network device shows up in this case as in XP which works fine.
Command I use;
qemu -hda Win98.img -net nic,model=rtl8139 -net user
maybe because you have to download
Thanks Ben I understand.
For some silly and flawed reason I assumed that it was an emulation
driver from qemu recognized by windows.
Reason for my assumption happened, since I cannot delete the RTL driver
in WinXP and assumed it was somehow tied to qemu.
Obviously I am wrong.
Thanks for the
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 07/11/15 15:27:03
Modified files:
linux-user : main.c
Log message:
x86_64 fixes
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 07/11/15 15:37:50
Modified files:
linux-user : main.c
Log message:
force correct ppc64 cpu
CVSWeb URLs:
I have a couple of win98se guests that I keep around for testing and upgrade
tests and the like.
The current CVS code has no problem booting these images, but the first
time I do anything (like read the cdrom, or change directories in windows
explorer), the guest just hangs. This seems like a
I'm currently running into a problem when running recent Linux kernels as a
guest under QEMU with KQEMU kernel acceleration. My problem is that early in
the boot process the guest kernel panics, the host OS appears to be
unaffected. The panic can be different depending on the guest Linux
On 11/13/07, Robert Reif [EMAIL PROTECTED] wrote:
Add iommu version to sparc32. Also reset iommu after initialization.
Should the version be tied to CPU model instead of machine type? At
least for Turbosparc this seems to be the case. Older CPUs may have
separate chips for IU and IOMMU.
On 11/10/07, Robert Reif [EMAIL PROTECTED] wrote:
Blue Swirl wrote:
DPRINTF_ASI would be nice.
Here is a revised patch:
Thanks. The patch didn't apply completely. I noticed that there are
some too long lines, they should be wrapped. Module reset register
should be in a different patch.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/15 19:04:09
Modified files:
. : vl.c
Log message:
Init dumb display if no others available.
CVSWeb URLs:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi,
I am building qemu from CVS, on a sun4u machine. I have used the
following configure command to ensure a sun4m userland build:
../qemu/configure --prefix=/opt/qemu-cvs --sparc_cpu=v8
I get the following message confirming the use of
This seems great! But does this mean that QEMU has support for a subset of
the ARM11 cores?
Also, I'm curious about ARMs position to this. I know that there has been a
licence clause that prohibits you from modelling ARM v6 CPU if you download
the ARMARM for v6 on their homepage.
Is this
Add iommu version to sparc32. Also reset iommu after initialization.
Should the version be tied to CPU model instead of machine type? At
least for Turbosparc this seems to be the case.
On SMP systems the IOMMU is on the system board in a separate ASIC. On
single CPU systems the
So gcc puts the zero constant to .rodata.cst8 and generates code to
load the zero value from this location. This method is not supported
by dyngen for Sparc, but ARM uses similar method for all (?)
constants.
Not quite. ARM puts constant pools inline with the code, not in rodata. This
is a
Some may have experienced of having some Qemu builds crashing,
apparently at random places, but in a reproducable way.
I found one reason for this crashes: it appears that with the growth of
the op.c file, there may be cases where we could reach the inlining
limits of gcc. In such a case, gcc
This patch fixes the word order for 64 bit reads of the mxcc registers.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -p -u -r1.52 op_helper.c
---
Fix MXCC error register bit clearing.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -p -u -r1.52 op_helper.c
--- target-sparc/op_helper.c11 Nov 2007
Add new MXCC register.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -r1.52 op_helper.c
209a210,217
case 0x01c00c00: /* Module reset register */
Hi,
On 16/11/2007, J. Mayer [EMAIL PROTECTED] wrote:
Some may have experienced of having some Qemu builds crashing,
apparently at random places, but in a reproducable way.
I found one reason for this crashes: it appears that with the growth of
the op.c file, there may be cases where we could
Remove unnecessary masking of lower word with 0x.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -p -u -r1.52 op_helper.c
--- target-sparc/op_helper.c
From the slackbook WIKI;
http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu;
I quote below which relates to my questions:
My questions are as follows:
1) I know -hdc and -cdrom cannot be called at the same time, but i have
no luck getting an image to be mounted with -hdb or -hdd.
I soved (3) with this
qemu -hda WinXP_Home.img -kernel-kqemu -usb -usbdevice host:04b4:8613
-net nic,model=rtl8139 -net user
I can see the device and the intel hubs are running.
Amazing, it is the first VM I see that even tries to address USB except
for VMWARE.
The remainder of the
On Wed, 2007-11-14 at 09:03 -0700, Thayne Harbaugh wrote:
This patch deprecates tget/tput and replaces them with get_user() and
put_user() which perform proper locking. It also checks return codes
(in most places) and fails with EFAULT where appropriate.
This version doesn't depend on
Ben Taylor [EMAIL PROTECTED] wrote:
I have a couple of win98se guests that I keep around for testing and upgrade
tests and the like.
The current CVS code has no problem booting these images, but the first
time I do anything (like read the cdrom, or change directories in windows
29 matches
Mail list logo
