Re: [Qemu-devel] U-Boot patch for qemu -M mips
Thiemo Seufer wrote:
Vlad Lungu wrote:
Thiemo Seufer wrote:
Vlad Lungu wrote:
[snip]
+long int initdram(int board_type)
+{
+ /* Sdram is setup by assembler code */
+ /* If memory could be changed, we should return the true value
here */
+ return MEM_SIZE*1024*1024;
Qemu gets the amount of RAM passed via a command line switch, the
qemu-mips emulation sets up a Linux kernel like command line in
memory where u-boot could parse it from.
Does it, or just when you pass -kernel to it? I'll check.
Hm, you are right, it does that only for -kernel. Would it make sense
to change that in Qemu?
IDK. Maybe I can probe the RAM size in U-Boot , or if this does not work,
mips_r4k implements no probable memory controller, so this won't work.
I say let's stick it into a DIP-switch, so nobody can overwrite it by
mistake. And you don't have to parse it.
put some info somewhere (RAM, register,
emulated DIP-dwitch), like RAM size, endianness of the CPU.
Endianness is rather pointless. If your U-Boot binary doesn't explode
immediately you got the right endianness. :-)
It doesn't actually explode, it sort of almost hits the exception
handler and freezes there. I don't have a mipsel gdb at hand
to watch it, but it should be fun.
pc=EPC 0xbfc00380
ds 0006
STATUS0x0046
CAUSE 0x0428
CONFIG0 0x8082
CONFIG1 0x9e190c8b
Re: [Qemu-devel] RFC: cleanups in ELF loader
J. Mayer wrote: [snip] The thing I see is different is that the n32 ABI redefines elf_greg_t and elf_caddr_t as 32 bits. Maybe I missed something but those types seem not to be used by the ELF loader (or maybe I should look in a more recent kernel ;-) ). Then, I have seen no apparent issue with the patch and I'm quite sure that, even if it's not correct for some specific ABI, it would bring no regression. Agreed. Thiemo
Re: [Qemu-devel] RFC: BIOS filename option
J. Mayer wrote: Hi, This is a proposal to allow the user to select a BIOS file name on the command line. The goal is mainly to ease debug, for example when I want to try to run a firmware comming from a real machine instead of the default one. The only change is to add a -bios filename option, use the given file if any or use the default if none were given. Maybe the options would be better named as -biosfile Or it maybe a good idea to give a full path, not to concatenate the given name with the bios_dir prefix... Some may find this option is not so useful, as one can specify a directory to find the target BIOS. But I feel more confortable keeping all BIOS images together at the same place. I welcome this, especially since the various mips machine emulations may have several alternative BIOS implementations soon. Thiemo
Re: [Qemu-devel] U-Boot patch for qemu -M mips
Vlad Lungu wrote: [snip] put some info somewhere (RAM, register, emulated DIP-dwitch), like RAM size, endianness of the CPU. Endianness is rather pointless. If your U-Boot binary doesn't explode immediately you got the right endianness. :-) It doesn't actually explode, it sort of almost hits the exception handler and freezes there. I don't have a mipsel gdb at hand to watch it, but it should be fun. pc=EPC 0xbfc00380 ds 0006 STATUS0x0046 CAUSE 0x0428 CONFIG0 0x8082 CONFIG1 0x9e190c8b Try qemu-system-mipsel ... -d all, and watch /tmp/qemu.log. :-) Thiemo
Re: [Qemu-devel] U-Boot patch for qemu -M mips
Vlad Lungu wrote: [snip] put some info somewhere (RAM, register, emulated DIP-dwitch), like RAM size, endianness of the CPU. Endianness is rather pointless. If your U-Boot binary doesn't explode immediately you got the right endianness. :-) It doesn't actually explode, it sort of almost hits the exception handler and freezes there. I don't have a mipsel gdb at hand to watch it, but it should be fun. pc=EPC 0xbfc00380 ds 0006 STATUS0x0046 CAUSE 0x0428 CONFIG0 0x8082 CONFIG1 0x9e190c8b Try qemu-system-mipsel ... -d all, and watch /tmp/qemu.log. :-) Oh crap. Now I see the problem. Either I misread the 0.90 info reg or there's a difference in how it's handled. It dies on the first instruction anyway. Vlad
[Qemu-devel] CPU_TLB_BITS / CPU_TLB_SIZE
hi everyone! if i want to increase the size of my TLB (for emulating an i386 processor), is it enough to simply increase CPU_TLB_BITS (e.g. by one)?? Or are there any side effects to that I should be aware of? Thanks!
Re: [Qemu-devel] CPU_TLB_BITS / CPU_TLB_SIZE
Clemens Kolbitsch wrote: hi everyone! if i want to increase the size of my TLB (for emulating an i386 processor), is it enough to simply increase CPU_TLB_BITS (e.g. by one)?? IIRC CPU_TLB_BITS needs to be a 2^n value. Thiemo
Re: [Qemu-devel] CPU_TLB_BITS / CPU_TLB_SIZE
Clemens Kolbitsch wrote: On Thursday 04 October 2007 15:05:22 Thiemo Seufer wrote: Clemens Kolbitsch wrote: hi everyone! if i want to increase the size of my TLB (for emulating an i386 processor), is it enough to simply increase CPU_TLB_BITS (e.g. by one)?? IIRC CPU_TLB_BITS needs to be a 2^n value. sure that you don't confuse that with CPU_TLB_SIZE? Oh, right, I did confuse that. :-) Thiemo
Re: [Qemu-devel] CPU_TLB_BITS / CPU_TLB_SIZE
On Thursday 04 October 2007 15:05:22 Thiemo Seufer wrote: Clemens Kolbitsch wrote: hi everyone! if i want to increase the size of my TLB (for emulating an i386 processor), is it enough to simply increase CPU_TLB_BITS (e.g. by one)?? IIRC CPU_TLB_BITS needs to be a 2^n value. sure that you don't confuse that with CPU_TLB_SIZE? CPU_TLB_SIZE will always be a 2^n value because of its definition #define CPU_TLB_SIZE (1 CPU_TLB_BITS) but honestly, I don't know (that's why i asked in the first place ;-) ) can someone back up thiemo's opinion? (or can you give me a hint on where this constraint is necessary?) thanks!!
Re: [Qemu-devel] U-Boot patch for qemu -M mips TAKE 2
Now with board config file included, so it can be built :-)
Thiemo, I'll think about the memory size issue and get back to you on that.
How about a git repo for U-Boot, if this thing takes off?
Vlad
---
diff --git a/Makefile b/Makefile
index 85885b1..8f650d2 100644
--- a/Makefile
+++ b/Makefile
@@ -2444,6 +2444,12 @@ pb1000_config: unconfig
@echo #define CONFIG_PB1000 1 $(obj)include/config.h
@$(MKCONFIG) -a pb1x00 mips mips pb1x00
+qemu_mips_config : unconfig
+ @mkdir -p $(obj)include
+ @ $(obj)include/config.h
+ @echo #define CONFIG_QEMU_MIPS 1 $(obj)include/config.h
+ @$(MKCONFIG) -a qemu-mips mips mips qemu-mips
+
#
## MIPS64 5Kc
#
diff --git a/board/qemu-mips/Makefile b/board/qemu-mips/Makefile
new file mode 100644
index 000..23be447
--- /dev/null
+++ b/board/qemu-mips/Makefile
@@ -0,0 +1,45 @@
+#
+# (C) Copyright 2003-2006
+# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS = $(BOARD).o flash.o
+SOBJS = lowlevel_init.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB): $(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/qemu-mips/README b/board/qemu-mips/README
new file mode 100644
index 000..39570b1
--- /dev/null
+++ b/board/qemu-mips/README
@@ -0,0 +1,11 @@
+By Vlad Lungu [EMAIL PROTECTED] 2007-Oct-01
+
+Qemu is a full system emulator. See
+
+http://fabrice.bellard.free.fr/qemu
+
+Limitations comments
+--
+Supports the -m mips configuration of qemu: serial,NE2000,IDE.
+Support is big endian only for now (or at least this is what I tested).
+Derived from au1x00 with a lot of things cut out.
diff --git a/board/qemu-mips/config.mk b/board/qemu-mips/config.mk
new file mode 100644
index 000..61269ce
--- /dev/null
+++ b/board/qemu-mips/config.mk
@@ -0,0 +1,11 @@
+
+#
+# Qemu -M mips system emulator
+# See http://fabrice.bellard.free.fr/qemu
+#
+
+# ROM version
+TEXT_BASE = 0xbfc0
+
+# RAM version
+#TEXT_BASE = 0x80001000
diff --git a/board/qemu-mips/flash.c b/board/qemu-mips/flash.c
new file mode 100644
index 000..d419f41
--- /dev/null
+++ b/board/qemu-mips/flash.c
@@ -0,0 +1,43 @@
+/*
+ * (C) Copyright 2003
+ * Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#if 0
+flash_info_t flash_info[CFG_MAX_FLASH_BANKS]; /* info for FLASH chips */
+#endif
+/*---
+ * flash_init()
+ *
+ * sets up flash_info and returns size of FLASH (bytes)
+ */
+unsigned long flash_init (void)
+{
+ printf (Skipping flash_init\n);
+ return (0);
+}
+
+int write_buff (/*flash_info_t */ void * info, uchar * src, ulong addr, ulong
[Qemu-devel] Pending Disk I/O requests during live VM migration
Hello I am trying to implement functionality in fully-virtualized xen wherein the responses to the pending disk I/O requests during live VM migration get trasnsferred to the new VMM form the old VMM. Specifically, I am looking at IDE disk (tools/ioemu/hw/ide.c) Basically, ide.c:pci_ide_save() saves the state of the IDE disk in a QEMUFile and this file is sent over the network (can somebody point me to the code where this happens ??)) so that the new VMM (where the VM has migrated) invokes ide.c:pci_ide_load() to retrieve the IDE Disk contents form the file. As of now, the pending disk I/O requests do not get saved in this file so these pending disk I/O requests are not available when executing pci_ide_load(). I am still trying to figure out where the pending Disk I/O requests get stored in the VMM so that during live VM migration, these requests can be put in the QEMUFile (As mentioned above) so that they can be reissued by the new VMM. Much better would be to send the responses to these pending disk I/O requests from the old to new VMM. Can somebody help me out with this as I am newbie here?? register_savevm() in ioemu/vl.c is simply used to register the save load handlers. register_savevm() is called in ioemu/hw/ide.c:pci_piix_ide_init() to register pci_ide_save() and pci_ide_load() as the save load handlers for IDE disks... qemu_savevm() in ioemu/vl.c walks the list of the registered save handlers whereas qemu_loadvm() in vl.c expects a load handler to have been registered for the corresponding save handlers for each chunk of the save file. Any help in locating the code would be greatly appreciated. -Kaushik
Re: [Qemu-devel] QEMU/MIPS dyntick kernel
On Thu, Oct 04, 2007 at 03:59:42AM +0200, J. Mayer wrote: As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a try on QEMU/MIPS, and unfortunately it doesn't work correctly. Aurelien is talking about a kernel option... I tried to disactivate dynticks, just commenting the entry in alarm_timers structure. Since then, I can notice that the emulated ... and I think you're talking about a qemu option with the same name. -- Daniel Jacobowitz CodeSourcery
Re: [Qemu-devel] Pending Disk I/O requests during live VM migration
On 10/4/07, Kaushik Bhandankar [EMAIL PROTECTED] wrote: I am trying to implement functionality in fully-virtualized xen wherein the responses to the pending disk I/O requests during live VM migration get trasnsferred to the new VMM form the old VMM. Specifically, I am looking at IDE disk (tools/ioemu/hw/ide.c) You should ask Xen related questions in xen lists. At least in Qemu pending I/O are flushed before VM save in vl.c:5522.
Re: [Qemu-devel] U-Boot patch for qemu -M mips TAKE 2
Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Now with board config file included, so it can be built :-) Thiemo, I'll think about the memory size issue and get back to you on that. How about a git repo for U-Boot, if this thing takes off? We actually have already a lot of them - the master repo and the custodian repositories. Logically, your code should go into the MIPS repo. I think you should start posting on the U-Boot mailing list instead of sending to mydirectaddress;see http://www.denx.de/wiki/UBoot/WebHome for details. Actually, this was directed at the Qemu list. But thanks for the offer. I suppose they could just point to your repo in the source release/dev tree and store the corresponding source snapshot when doing a binary release with information included in the README, and it would be kosher Re: GPL. BTW: Your code has a few minor coding style violations (indentation by spaces instead of TAB), and the signed-off-ny line is missing. Might be. I use joe/mcedit/vi in random order to edit source files, that's the source of the spaces, and the patch was rather informal so no signoff. I'll re-branch and do a 3-part (GOT,NE2000,qemu) patchset . Vlad
Re: [Qemu-devel] Pending Disk I/O requests during live VM migration
Blue Swirl wrote: On 10/4/07, Kaushik Bhandankar [EMAIL PROTECTED] wrote: I am trying to implement functionality in fully-virtualized xen wherein the responses to the pending disk I/O requests during live VM migration get trasnsferred to the new VMM form the old VMM. Specifically, I am looking at IDE disk (tools/ioemu/hw/ide.c) You should ask Xen related questions in xen lists. At least in Qemu pending I/O are flushed before VM save in vl.c:5522. Thanks Blue... somebody in the xen-devel list suggested to mail this list about it Anyway, I have some IDE related questions which somebody on this list might answer 1) I guess the IDE disk code is in ioemu/hw/ide.c. But where is the IDE disk controller code located ?? 2) I do not really understand BMDMA in ioemu/hw/ide.c. google doesnt seem to be helping much here. Any documentation about the QEMU IDE disks would be greatly appreciated. 3) vl.c:5522 seems to be not the correct code (I guess our vl.c codes are different).. Could you point me to the routine in vl.c where the pending disk IO requests are flushed before VM save (I guess the VM save happens in qemu_savevm_state() in vl.c wherein it invokes all the registered save handlers)? 4) Somebody told me that the pending disk IO requests are stored somewhere in quemu's I/O disk model but I am not sure exactly whereCan somebody help me with this ? Thanks, Kaushik
Re: [Qemu-devel] Pending Disk I/O requests during live VM migration
On 10/4/07, Kaushik Bhandankar [EMAIL PROTECTED] wrote: 1) I guess the IDE disk code is in ioemu/hw/ide.c. But where is the IDE disk controller code located ?? Same file, see ide_ioport_write(). 2) I do not really understand BMDMA in ioemu/hw/ide.c. google doesnt seem to be helping much here. Any documentation about the QEMU IDE disks would be greatly appreciated. No idea. 3) vl.c:5522 seems to be not the correct code (I guess our vl.c codes are different).. Could you point me to the routine in vl.c where the pending disk IO requests are flushed before VM save (I guess the VM save happens in qemu_savevm_state() in vl.c wherein it invokes all the registered save handlers)? It's in: void do_savevm(const char *name) 4) Somebody told me that the pending disk IO requests are stored somewhere in quemu's I/O disk model but I am not sure exactly whereCan somebody help me with this ? Qemu uses asynchronous IO, grepping aio or AIO should find something.
[Qemu-devel] Two small Solaris x86-64 patches
Included are two small patches for configure and Makefile.target to
allow QEMU to configure and build correctly on a Solaris x86-64 platform.
Ben--- qemu.ORIG/configure 2007-09-29 21:58:31.0 -0400
+++ qemu/configure 2007-10-04 12:52:30.776801000 -0400
@@ -575,7 +575,7 @@
#undef main /* We don't want SDL to override our main() */
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -594,7 +594,7 @@
sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
fi
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
sdl_static=yes
fi
fi # static link
--- qemu.ORIG/Makefile.target 2007-09-29 21:58:31.0 -0400
+++ qemu/Makefile.target2007-10-04 12:56:59.655018000 -0400
@@ -129,7 +129,11 @@
endif
ifeq ($(ARCH),x86_64)
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ ifeq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAG+=-m64
+ else
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifeq ($(ARCH),ppc)
@@ -544,6 +548,13 @@
endif
endif
+ifeq ($(ARCH),x86_64)
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
+endif
+
ifdef CONFIG_WIN32
SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole
endif
Re: [Qemu-devel] U-Boot patch for qemu -M mips TAKE 2
In message [EMAIL PROTECTED] you wrote: Now with board config file included, so it can be built :-) Thiemo, I'll think about the memory size issue and get back to you on that. How about a git repo for U-Boot, if this thing takes off? We actually have already a lot of them - the master repo and the custodian repositories. Logically, your code should go into the MIPS repo. I think you should start posting on the U-Boot mailing list instead of sending to mydirectaddress;see http://www.denx.de/wiki/UBoot/WebHome for details. BTW: Your code has a few minor coding style violations (indentation by spaces instead of TAB), and the signed-off-ny line is missing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] To IBM, 'open' means there is a modicum of interoperability among some of their equipment.- Harv Masterson
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/04 19:47:09 Modified files: . : vl.c Log message: (int64_t)UINT64_MAX is -1 and should not be assigned to nearest_delta_us, patch by Dan Kenigsberg. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.343r2=1.344
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/04 19:59:04 Modified files: . : vl.c Log message: Remove redundant qemu_rearm_alarm_timer() in qemu_del_timer, patch by Dan Kenigsberg. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.344r2=1.345
[Qemu-devel] qemu Makefile.target hw/sh7750.c hw/sh7750_regn...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/04 21:53:55 Modified files: . : Makefile.target hw : sh7750.c sh7750_regnames.c sh7750_regs.h Added files: hw : sh_intc.c sh_intc.h Log message: sh775x interrupt controller by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.203r2=1.204 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh7750.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh7750_regnames.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh7750_regs.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh_intc.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh_intc.h?cvsroot=qemurev=1.1
[Qemu-devel] qemu usb-linux.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/04 22:55:53 Modified files: . : usb-linux.c Log message: Quiet warnings introduced with the USB iso support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/usb-linux.c?cvsroot=qemur1=1.13r2=1.14
[Qemu-devel] qemu usb-linux.c hw/usb-uhci.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/04 22:47:34 Modified files: . : usb-linux.c hw : usb-uhci.c Log message: USB iso transfers support for the linux redirector and for UHCI, by Arnon Gilboa. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/usb-linux.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-uhci.c?cvsroot=qemur1=1.19r2=1.20
Re: [Qemu-devel] [PATCH] USB Webcam Redirection
Hi,
On 24/09/2007, Arnon Gilboa [EMAIL PROTECTED] wrote:
Attached is an updated patch for supporting isochronous transfers in
redirected host USB devices. The initial goal was supporting USB 1.1 Webcam.
Tested on WinXP guest with several Webcams. Works on USB 1.1 Webcams, as
well as most USB 2.0 Webcams (backward compatibility) on low resolutions.
Some jitter is visible in the video stream, and it will be fixed.
Notice USE_ASYNCIO, which defines whether to use signal based async io or
polling for receiving urbs. Currently it is disabled, so polling is used,
but it does not seem to affect the performance because it uses the
non-blocking USBDEVFS_REAPURBNDELAY ioctl. In order to use the signal based
async io, the patch to usb-uhci.c should be applied.
The patch includes parts of previous patches posted in Qemu-devel:
usb_host_update_interfaces (from
qemu-0.9.0-usb-multi-configs.patch),
usb_linux_update_endp_table (qemu-usb-host-async.patch) as well as some
other lines of code.
I am currently working on the ehci emulation for fully supporting USB 2.0
isochronous devices.
Waiting for your comments,
I pushed both patches into CVS, but I haven't tested it with any
devices with ISO endpoints yet, so please do. I made some identifiers
static and also removed the first qemu_free to avoid double freeing
in:
ret = usb_linux_update_endp_table(dev);
if (ret) {
qemu_free(dev);
goto fail;
}
...
fail:
if (dev)
qemu_free(dev);
Regards
[Qemu-devel] qemu/hw pl110.c pl110_template.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/10/04 23:45:32 Modified files: hw : pl110.c pl110_template.h Log message: Implement PL110 byte order config bit (original patch by Richard Purdie). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl110.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl110_template.h?cvsroot=qemur1=1.4r2=1.5
