[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 20:26:38 Modified files: target-sparc : translate.c Log message: Fix Sparc64 prefetcha op CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.58&r2=1.59
Re: [Qemu-devel] qemu/hw pixel_ops.h
> How about moving these and pixel_ops to sdl.c and other output > drivers? Then the emulated devices didn't have to know about output > device. They should also be independent of the output device (as they are now). Paul
[Qemu-devel] qemu Makefile.target qemu-doc.texi vl.c hw/usb....
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/06/10 19:21:04 Modified files: . : Makefile.target qemu-doc.texi vl.c hw : usb.h Added files: hw : usb-wacom.c Log message: Wacom PenPartner tablet (virtual USB device). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.183&r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.149&r2=1.150 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.305&r2=1.306 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb.h?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-wacom.c?cvsroot=qemu&rev=1.1
Re: [Qemu-devel] qemu/hw pixel_ops.h
On 6/10/07, Paul Brook <[EMAIL PROTECTED]> wrote: On Sunday 10 June 2007, Stuart Brady wrote: > On Sun, Jun 10, 2007 at 04:35:21PM +, Blue Swirl wrote: > > Log message: > > Add hw/pixel_ops.h > > Are there any thoughts on moving vga_draw_line_glyph* out of > vga_template.h? Sounds like a good idea (in principle) to me. I suspect you'd want to move vga_template and chunks of of code from vga.c into a common blit routine. The ARM pl110 CLCDC emulation could also benefit from this. How about moving these and pixel_ops to sdl.c and other output drivers? Then the emulated devices didn't have to know about output device.
Re: [Qemu-devel] qemu/hw pixel_ops.h
On Sunday 10 June 2007, Stuart Brady wrote: > On Sun, Jun 10, 2007 at 04:35:21PM +, Blue Swirl wrote: > > Log message: > > Add hw/pixel_ops.h > > Are there any thoughts on moving vga_draw_line_glyph* out of > vga_template.h? Sounds like a good idea (in principle) to me. I suspect you'd want to move vga_template and chunks of of code from vga.c into a common blit routine. The ARM pl110 CLCDC emulation could also benefit from this. Paul
Re: [Qemu-devel] qemu/hw pixel_ops.h
Am 10.06.2007 um 19:02 schrieb Blue Swirl: Thanks, I split the patch and didn't notice that some parts didn't survive the splitting. It should be fixed with the commit. Thank you! If this was only a splitting/committing issue then I'll assume I can still apply big_endian_display4.diff against 0.9.0; works so far anyway. Andreas
Re: [Qemu-devel] qemu/hw pixel_ops.h
On Sun, Jun 10, 2007 at 04:35:21PM +, Blue Swirl wrote: > Log message: >Add hw/pixel_ops.h Are there any thoughts on moving vga_draw_line_glyph* out of vga_template.h? While I'm not *entirely* certain that my ZX Spectrum emulation patch[1] would be accepted :-), it seems conceivable that moving these functions out of vga_template.h would be useful to others at some point, so I'd be happy to submit a patch for this. (It would have to be #includable from vga.c or vga_template.h, so obviously this can't go in pixel_ops.h.) -- Stuart Brady [1] That's one d*mn fast Speccy, btw. :-)
Re: [Qemu-devel] qemu qemu-doc.texi hw/vga.c
On 6/10/07, Blue Swirl <[EMAIL PROTECTED]> wrote: Modified files: . : qemu-doc.texi hw : vga.c Log message: Fix patch splitting lossage in vga.c Sorry, I forgot that I was editing the doc.
Re: [Qemu-devel] [PATCH] Change variable "name" to avoid shadow warnings
On 6/10/07, Stefan Weil <[EMAIL PROTECTED]> wrote: Maybe it would be a good idea to add more warnings to the QEMU compiler options. The current option -Wall (in files Makefile.target, configure) does not activate all warnings. I think that especially -Wshadow should be added because code with shadowed variables is more difficult to read and maintain (and potentially contains more bugs). I'd vote for -Wcast-align, but I'd be happy with any stricter set of warnings.
Re: [Qemu-devel] qemu/hw pixel_ops.h
On 6/10/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Replacing my local files with HEAD I get the following errors: /Users/andreas/Q/tmp/qemu/hw/vga.c:1317: error: `vga_draw_line15_15bgr' undeclared here (not in a function) Thanks, I split the patch and didn't notice that some parts didn't survive the splitting. It should be fixed with the commit.
Re: [Qemu-devel] network usage causes kernel warning/stack-dump in virtual Linux host
Am 10.06.2007 um 18:35 schrieb Rolf Fokkens: Sorry - immidiately after being absolutely sure about this, the same problem also occured with rtl8139 emulation. Well, it's an issue anyhow. Rolf Rolf Fokkens wrote: On both qemu (no-kqemu) and qemu-kvm (no-kvm or with kvm) release 0.9.0 the following happens when using ne2000 (default) emulation: UG: waring at kernel/softirq.c:138/local_bh_enable() (Not tainted) [] local_bh_enable+/0x92 [..] cond_resched_sof+0x2c/0x42 [..] release_sock+0x4f/0 9d [..] inet_stream_connect+0x116/0x1ff [..] autoremove_wake_function+0x0/0x35 [..] sys_connect+0x82/0xad [..] d_instantiate+0x5c/ x60 [..] sock_attach_fd+0x70/0xcf [..] selinux_file_alloc_security+0x1f/0x40 [..] get_empty_filp+0x99/0x151 [..] __sock_create+0x16e/0x1a8 [..] fd_install+0x1e/0x47 [..] sock_map_fd+0x41/0x47 [..] sys_socketcall+0xac/0x261 [..] syscall_call+0x7/0xb The virtual host runs fedora 7, kernel-2.6.21-1.3194.fc7. When using windows-XP as a virtual host a network hang also occurs, but I have no details about it. The mentioned problems (for both Linux and Windows XP) do not occur when using rtl8139 emulation. The problem might rather be Fedora 7 itself - someone recently reported they changed some of their ATA libraries and with the recent Fedora and QEMU CVS updates it no longer boots at all for me... NE2000 appears to work fine on my other guests. Andreas
[Qemu-devel] qemu qemu-doc.texi hw/vga.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 17:01:00 Modified files: . : qemu-doc.texi hw : vga.c Log message: Fix patch splitting lossage in vga.c CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.148&r2=1.149 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vga.c?cvsroot=qemu&r1=1.54&r2=1.55
Re: [Qemu-devel] qemu/hw pixel_ops.h
Am 10.06.2007 um 18:35 schrieb Blue Swirl: CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 16:35:21 Added files: hw : pixel_ops.h Log message: Add hw/pixel_ops.h CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pixel_ops.h? cvsroot=qemu&rev=1.1 Replacing my local files with HEAD I get the following errors: /Users/andreas/Q/tmp/qemu/hw/vga.c:1317: error: `vga_draw_line15_15bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1317: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1317: error: (near initialization for `vga_draw_line_table[47]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1318: error: `vga_draw_line15_16bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1318: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1318: error: (near initialization for `vga_draw_line_table[48]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1325: error: `vga_draw_line16_15bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1325: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1325: error: (near initialization for `vga_draw_line_table[54]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1326: error: `vga_draw_line16_16bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1326: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1326: error: (near initialization for `vga_draw_line_table[55]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1333: error: `vga_draw_line24_15bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1333: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1333: error: (near initialization for `vga_draw_line_table[61]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1334: error: `vga_draw_line24_16bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1334: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1334: error: (near initialization for `vga_draw_line_table[62]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1341: error: `vga_draw_line32_15bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1341: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1341: error: (near initialization for `vga_draw_line_table[68]') /Users/andreas/Q/tmp/qemu/hw/vga.c:1342: error: `vga_draw_line32_16bgr' undeclared here (not in a function) /Users/andreas/Q/tmp/qemu/hw/vga.c:1342: error: initializer element is not constant /Users/andreas/Q/tmp/qemu/hw/vga.c:1342: error: (near initialization for `vga_draw_line_table[69]') Those did not surface when testing the patch...
Re: [Qemu-devel] Sparc32 network problems
On 6/10/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Am 10.06.2007 um 17:49 schrieb Blue Swirl: > On 6/9/07, Andreas Färber <[EMAIL PROTECTED]> wrote: >> Is Debian correct is saying that TCX supports 8-bit only? Don't we >> have 15, 16 and 32 bit there, too? >> I modified xorg.conf to use suntcx instead of sunffb; depths of 24, >> 16 and 15 did not work, with 8 bit I got the Blue Swirl. ;-) Looks a >> little ugly at 8bpp, and without Lance working I can't use XDMCP or >> VNC instead. > > I'm not sure if there is anything else besides the 8 and 24-bit modes, > only those are implemented. Does that mean the 15, 16, 32 is dependent on the host? No, my understanding is that TCX doesn't have those modes at all. > To get the 24-bit mode you have to add -g > 1024x768x24 to the command line. Otherwise the device is the 8-bit > version. Then please add this to the documentation! That currently only mentions -g WxH for the size (and when I last tried with a lower size it resulted in the text being cut off). Good point. The resolution is currently hardcoded in OpenBIOS.
Re: [Qemu-devel] network usage causes kernel warning/stack-dump in virtual Linux host
Sorry - immidiately after being absolutely sure about this, the same problem also occured with rtl8139 emulation. Well, it's an issue anyhow. Rolf Rolf Fokkens wrote: On both qemu (no-kqemu) and qemu-kvm (no-kvm or with kvm) release 0.9.0 the following happens when using ne2000 (default) emulation: UG: waring at kernel/softirq.c:138/local_bh_enable() (Not tainted) [] local_bh_enable+/0x92 [..] cond_resched_sof+0x2c/0x42 [..] release_sock+0x4f/0 9d [..] inet_stream_connect+0x116/0x1ff [..] autoremove_wake_function+0x0/0x35 [..] sys_connect+0x82/0xad [..] d_instantiate+0x5c/ x60 [..] sock_attach_fd+0x70/0xcf [..] selinux_file_alloc_security+0x1f/0x40 [..] get_empty_filp+0x99/0x151 [..] __sock_create+0x16e/0x1a8 [..] fd_install+0x1e/0x47 [..] sock_map_fd+0x41/0x47 [..] sys_socketcall+0xac/0x261 [..] syscall_call+0x7/0xb The virtual host runs fedora 7, kernel-2.6.21-1.3194.fc7. When using windows-XP as a virtual host a network hang also occurs, but I have no details about it. The mentioned problems (for both Linux and Windows XP) do not occur when using rtl8139 emulation.
[Qemu-devel] qemu/hw pixel_ops.h
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 16:35:21 Added files: hw : pixel_ops.h Log message: Add hw/pixel_ops.h CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pixel_ops.h?cvsroot=qemu&rev=1.1
[Qemu-devel] ne2000 emulation causes kernel warning/stack-dump in virtual Linux host
On both qemu (no-kqemu) and qemu-kvm (no-kvm or with kvm) release 0.9.0 the following happens when using ne2000 (default) emulation: UG: waring at kernel/softirq.c:138/local_bh_enable() (Not tainted) [] local_bh_enable+/0x92 [..] cond_resched_sof+0x2c/0x42 [..] release_sock+0x4f/0 9d [..] inet_stream_connect+0x116/0x1ff [..] autoremove_wake_function+0x0/0x35 [..] sys_connect+0x82/0xad [..] d_instantiate+0x5c/ x60 [..] sock_attach_fd+0x70/0xcf [..] selinux_file_alloc_security+0x1f/0x40 [..] get_empty_filp+0x99/0x151 [..] __sock_create+0x16e/0x1a8 [..] fd_install+0x1e/0x47 [..] sock_map_fd+0x41/0x47 [..] sys_socketcall+0xac/0x261 [..] syscall_call+0x7/0xb The virtual host runs fedora 7, kernel-2.6.21-1.3194.fc7. When using windows-XP as a virtual host a network hang also occurs, but I have no details about it. The mentioned problems (for both Linux and Windows XP) do not occur when using rtl8139 emulation.
Re: [Qemu-devel] Sparc32 network problems
Am 10.06.2007 um 17:49 schrieb Blue Swirl: On 6/9/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Is Debian correct is saying that TCX supports 8-bit only? Don't we have 15, 16 and 32 bit there, too? I modified xorg.conf to use suntcx instead of sunffb; depths of 24, 16 and 15 did not work, with 8 bit I got the Blue Swirl. ;-) Looks a little ugly at 8bpp, and without Lance working I can't use XDMCP or VNC instead. I'm not sure if there is anything else besides the 8 and 24-bit modes, only those are implemented. Does that mean the 15, 16, 32 is dependent on the host? To get the 24-bit mode you have to add -g 1024x768x24 to the command line. Otherwise the device is the 8-bit version. Then please add this to the documentation! That currently only mentions -g WxH for the size (and when I last tried with a lower size it resulted in the text being cut off). Andreas
Re: [Qemu-devel] qemu Makefile.target hw/tcx.c hw/vga.c
Am 10.06.2007 um 18:06 schrieb Blue Swirl: CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 16:06:20 Modified files: . : Makefile.target hw : tcx.c vga.c Log message: Merge TCX and VGA pixel operations CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target? cvsroot=qemu&r1=1.182&r2=1.183 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c? cvsroot=qemu&r1=1.17&r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vga.c? cvsroot=qemu&r1=1.52&r2=1.53 hw/pixel_ops.h is missing! ;-)
[Qemu-devel] qemu cocoa.m sdl.c hw/tcx.c hw/vga.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 16:07:38 Modified files: . : cocoa.m sdl.c hw : tcx.c vga.c Log message: Attempt to fix incorrect colours on some BGR displays CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cocoa.m?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/sdl.c?cvsroot=qemu&r1=1.39&r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vga.c?cvsroot=qemu&r1=1.53&r2=1.54
[Qemu-devel] qemu Makefile.target hw/tcx.c hw/vga.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/06/10 16:06:20 Modified files: . : Makefile.target hw : tcx.c vga.c Log message: Merge TCX and VGA pixel operations CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.182&r2=1.183 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c?cvsroot=qemu&r1=1.17&r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vga.c?cvsroot=qemu&r1=1.52&r2=1.53
Re: [Qemu-devel] Sparc32 network problems
On 6/9/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Is Debian correct is saying that TCX supports 8-bit only? Don't we have 15, 16 and 32 bit there, too? I modified xorg.conf to use suntcx instead of sunffb; depths of 24, 16 and 15 did not work, with 8 bit I got the Blue Swirl. ;-) Looks a little ugly at 8bpp, and without Lance working I can't use XDMCP or VNC instead. I'm not sure if there is anything else besides the 8 and 24-bit modes, only those are implemented. To get the 24-bit mode you have to add -g 1024x768x24 to the command line. Otherwise the device is the 8-bit version.
Re: [Qemu-devel] Sparc32 network problems
On 6/9/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Am 09.06.2007 um 10:05 schrieb Blue Swirl: >> Maybe the bgr detection logic in sdl.c is flawed. Is this patch >> any better? > > Except that on OSX the correct place to fix this would be in > cocoa.m, right? For qemu yes. Works fine on ppc (and if ds->bgr is manually set to 1, shows the blue-footed penguin on ppc). [If the ds->bgr initialization is omitted it hangs with a black screen and the spinning color wheel. That's strange since bgr == 0 would be okay and any other value should lead to a blue-footed penguin only.] OK, I'll apply the patch. For Q's interface I derived a patch against host-cocoa/cocoaQemu.m. That works fine on OS X i386 and ppc hosts. > Is there some better way to detect BGR than using the host endianness > like in this version? I have no idea... But are you sure that we do not need 8-bit bgr? Q's patch inverted that, too. How would I test that? I think there in 8-bit mode the colours come from the palette indexed by the pixel value, not directly from the pixel value.
[Qemu-devel] [PATCH] Change variable "name" to avoid shadow warnings
Maybe it would be a good idea to add more warnings to the
QEMU compiler options. The current option -Wall (in files
Makefile.target, configure) does not activate all warnings.
I think that especially -Wshadow should be added because code
with shadowed variables is more difficult to read and maintain
(and potentially contains more bugs).
The current QEMU code is full of shadowed variables.
My patch only removes some of them by renaming
"name" into "relname" in dyngen.c.
Stefan
Index: dyngen.c
===
RCS file: /sources/qemu/qemu/dyngen.c,v
retrieving revision 1.52
diff -u -b -B -r1.52 dyngen.c
--- dyngen.c 8 May 2007 22:51:41 - 1.52
+++ dyngen.c 9 Jun 2007 17:48:09 -
@@ -1845,7 +1845,7 @@
/* patch relocations */
#if defined(HOST_I386)
{
-char name[256];
+char relname[256];
int type;
int addend;
int reloc_offset;
@@ -1868,18 +1868,18 @@
continue;
}
-get_reloc_expr(name, sizeof(name), sym_name);
+get_reloc_expr(relname, sizeof(relname), sym_name);
addend = get32((uint32_t *)(text + rel->r_offset));
#ifdef CONFIG_FORMAT_ELF
type = ELF32_R_TYPE(rel->r_info);
switch(type) {
case R_386_32:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = %s + %d;\n",
-reloc_offset, name, addend);
+reloc_offset, relname, addend);
break;
case R_386_PC32:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = %s - (long)(gen_code_ptr + %d) + %d;\n",
-reloc_offset, name, reloc_offset, addend);
+reloc_offset, relname, reloc_offset, addend);
break;
default:
error("unsupported i386 relocation (%d)", type);
@@ -1902,11 +1902,11 @@
switch(type) {
case DIR32:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = %s + %d;\n",
-reloc_offset, name, addend);
+reloc_offset, relname, addend);
break;
case DISP32:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = %s - (long)(gen_code_ptr + %d) + %d -4;\n",
-reloc_offset, name, reloc_offset, addend);
+reloc_offset, relname, reloc_offset, addend);
break;
default:
error("unsupported i386 relocation (%d)", type);
@@ -1919,7 +1919,7 @@
}
#elif defined(HOST_X86_64)
{
-char name[256];
+char relname[256];
int type;
int addend;
int reloc_offset;
@@ -1927,22 +1927,22 @@
if (rel->r_offset >= start_offset &&
rel->r_offset < start_offset + copy_size) {
sym_name = strtab + symtab[ELFW(R_SYM)(rel->r_info)].st_name;
-get_reloc_expr(name, sizeof(name), sym_name);
+get_reloc_expr(relname, sizeof(relname), sym_name);
type = ELF32_R_TYPE(rel->r_info);
addend = rel->r_addend;
reloc_offset = rel->r_offset - start_offset;
switch(type) {
case R_X86_64_32:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = (uint32_t)%s + %d;\n",
-reloc_offset, name, addend);
+reloc_offset, relname, addend);
break;
case R_X86_64_32S:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = (int32_t)%s + %d;\n",
-reloc_offset, name, addend);
+reloc_offset, relname, addend);
break;
case R_X86_64_PC32:
fprintf(outfile, "*(uint32_t *)(gen_code_ptr + %d) = %s - (long)(gen_code_ptr + %d) + %d;\n",
-reloc_offset, name, reloc_offset, addend);
+reloc_offset, relname, reloc_offset, addend);
break;
default:
error("unsupported X86_64 relocation (%d)", type);
@@ -1953,7 +1953,7 @@
#elif defined(HOST_PPC)
{
#ifdef CONFIG_FORMAT_ELF
-char name[256];
+char relname[256];
int t
[Qemu-devel] qemu/hw gt64xxx.c mips_malta.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/10 15:08:43 Modified files: hw : gt64xxx.c mips_malta.c Log message: More PCI mapping/remapping for Gallileo. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.38&r2=1.39
Re: [Qemu-devel] [PATCH] Add a 7 segments + led display
On Saturday 09 June 2007, Hervé Poussineau wrote: > Hi, > > This patch adds a 7-segments + led display device emulation to Qemu. > A picture of the original thing can be found at > http://www.sensi.org/~alec/mips/images/acer_pica_io_3.jpg > Use the device in the MIPS PICA 61 machine. > +color_on = 0xffaa; > +color_led = 0xff00ff00; /* green */ > +color_led = 0x; /* black */ These are wrong for anything other than 32-bit color. Paul
[Qemu-devel] qemu exec.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/06/10 14:07:13 Modified files: . : exec.c Log message: Flush the debug log when qemu Aborts (patch by Herve Poussineau) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.99&r2=1.100
[Qemu-devel] qemu/target-arm translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/06/10 13:53:18 Modified files: target-arm : translate.c Log message: Use the same offset for all STR and STM instructions that store r15, as specified in ARM ARM (patch from Chris McNett). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu&r1=1.51&r2=1.52
