Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
Mike Kronenberg wrote: While testing with Quartzdebug, I realized, that qemu is updating always the whole screenwidth even if only the mouse is moved... is this a qemu problem, or is this the default windows behaviour? VGA framebuffer operations come in as memory operations. They're tracked by watching what memory gets dirtied. This can only operate at a page-granularity so this results in scan-line granularity updates. The VNC front-end goes to great lengths to keep a shadowed framebuffer and reduce these updates to a smaller update region. You could possibly look at refactoring that code. However... I would be amazed if screen updates on OS X are so slow that it would make a difference if updates are in scanline granularities. The copying latency is nothing compared to the other latencies in QEMU. A modern processor can move memory at an extremely high speed. At a refresh rate of 30 times per second, this is only ~4MB of data for mouse movements. A typical processor can easily handle many GB of data per second. Regards, Anthony Liguori Mike [1] http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/tq_image_data/chapter_6_section_2.html#//apple_ref/doc/uid/TP40001098-CH227-BBCFFDBB
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
On 30/01/2008, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > Hi, > > On Wed, 30 Jan 2008, Mike Kronenberg wrote: > > > Offtoppic about updated regions in Windows: While testing with > > Quartzdebug, I realized, that qemu is updating always the whole > > screenwidth even if only the mouse is moved... is this a qemu problem, > > or is this the default windows behaviour? > > As far as I remember, this is a QEmu "problem". It only marks lines as > dirty, not pixels. In addition lines are not marked dirty because they have a dirty pixel in them but because they have a pixel in a dirty page. That means more lines are updated than those containing dirty pixels. Cheers
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
On Jan 30, 2008, at 9:30 PM, Mike Kronenberg wrote: Unfortunateley, there is no "official" direct access to the framebuffer anymore, since apple depreciated QuickDraw. [1] Well, you can using OpenGL and Apple's Extension have a nearly direct VRAM access, the idea is to use glEnable( GL_UNPACK_CLIENT_STORAGE_APPLE ); glPixelStorei( GL_UNPACK_CLIENT_STORAGE_APPLE, GL_TRUE ); and glTexParameteri( VLCGL_TARGET, GL_TEXTURE_STORAGE_HINT_APPLE, GL_STORAGE_SHARED_APPLE ); On the texture on which you want to draw. See: http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/chapter_10_section_2.html Pierre.
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and booting a linux kernel. I could literally see every like getting repainted (which btw did not happen with my quick hacky version I sent to the list some time ago). You did not notice the effect with Your implementation, because the the whole screen is redrawn every time. With this implementation, only the parts requested by qemu are updated. If You take a dosprompt, every line that moves up, triggers a redraw (only for the specific line) - this is why you notice the redraw. You can test this easily with the Quartz debugger. But never the less, overall speed is much faster with partial redraw, than if You redraw the whole screen every time. Mike smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
Hi, On Wed, 30 Jan 2008, Mike Kronenberg wrote: > Offtoppic about updated regions in Windows: While testing with > Quartzdebug, I realized, that qemu is updating always the whole > screenwidth even if only the mouse is moved... is this a qemu problem, > or is this the default windows behaviour? As far as I remember, this is a QEmu "problem". It only marks lines as dirty, not pixels. Ciao, Dscho
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
On 30.01.2008, at 19:59, Alexander Graf wrote: On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote: This is a complete rewrite of cocoa.m to support Core Graphics. As mentioned in earlier threads, the QuickDraw API is depreciated starting with OS X 10.4. Now with OS X 10.5 it won't even compile QuickDraw code on x86_64. This implementation of cocoa.m has the following features: [new] partial drawing of the window as needed, implemented with CG. [new] fullscreen support [new] tablet support [new] View menu and item to enter Fullscreen (cmd-f) [new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- tec.html in the OS X "Help Viewer" [new] -name is shown in Title-bar of window [fix] Application menu creation for 10.4+ (API is private as of 10.4) [fix] Mouse-clicks on the guests window widgets are no longer intercepted [fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide QEMU (cmd-h), quit QEMU (cmd-q)) It should compile on ppc/intel starting form 10.3 (10.2 with the known workarounds). Please test and comment I'm sorry that I didn't find the time to test this implementation before. It's damn slow. I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and booting a linux kernel. I could literally see every like getting repainted (which btw did not happen with my quick hacky version I sent to the list some time ago). I think the major problem is that too much is being done during drawRect. If I understand the code correctly, you create CGImage objects on every repaint, which is prone to be slow. Why not simply reuse the framebuffer qemu provides anyway and leave everything else to CG? Alex Hi Alex, yes, as stated earlyer, it is slower than Quickdraw, especially if the whole screen is redrawn. Overal emulation speed for GUI apps is faster, dough, as only small portions of the screen are redrawn. Unfortunateley, there is no "official" direct access to the framebuffer anymore, since apple depreciated QuickDraw. [1] This way, there is no sharing/direct mapping of the cg framebuffer and qemu screenbuffer anymore. Every time, a section needs display, that part of the qemu screenbuffer is mapped to a cg image and then copied on top of the CG stack. CG is fully OpenGL based, so basically, if it needs to refresh an area, it has to load the area as texture, hence the copy. Offtoppic about updated regions in Windows: While testing with Quartzdebug, I realized, that qemu is updating always the whole screenwidth even if only the mouse is moved... is this a qemu problem, or is this the default windows behaviour? Mike [1] http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/tq_image_data/chapter_6_section_2.html#/ /apple_ref/doc/uid/TP40001098-CH227-BBCFFDBB smime.p7s Description: S/MIME cryptographic signature
[Qemu-devel] QEMU and gdb
Hi all, I would like to debug QEMU with gdb. When starting qemu (x86) inside gdb, SDL window never appears, it there a way to fix it ? thx by advance, -- Pierre FICHEUX -/- CTO OW/OS4I, France -\- [EMAIL PROTECTED] http://www.os4i.com http://www.ficheux.org I would love to change the world, but they won't give me the source code
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
On Jan 30, 2008, at 7:59 PM, Alexander Graf wrote: On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote: This is a complete rewrite of cocoa.m to support Core Graphics. As mentioned in earlier threads, the QuickDraw API is depreciated starting with OS X 10.4. Now with OS X 10.5 it won't even compile QuickDraw code on x86_64. This implementation of cocoa.m has the following features: [new] partial drawing of the window as needed, implemented with CG. [new] fullscreen support [new] tablet support [new] View menu and item to enter Fullscreen (cmd-f) [new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- tec.html in the OS X "Help Viewer" [new] -name is shown in Title-bar of window [fix] Application menu creation for 10.4+ (API is private as of 10.4) [fix] Mouse-clicks on the guests window widgets are no longer intercepted [fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide QEMU (cmd-h), quit QEMU (cmd-q)) It should compile on ppc/intel starting form 10.3 (10.2 with the known workarounds). Please test and comment I'm sorry that I didn't find the time to test this implementation before. It's damn slow. I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and booting a linux kernel. I could literally see every like getting repainted (which btw did not happen with my quick hacky version I sent to the list some time ago). I think the major problem is that too much is being done during drawRect. If I understand the code correctly, you create CGImage objects on every repaint, which is prone to be slow. Why not simply reuse the framebuffer qemu provides anyway and leave everything else to CG? I just reread my mail again and realized that I didn't say anything positive. Sorry about that. It's great to see someone working on Mac OS X support and thanks a lot for writing a compatible implementation of cocoa.m that works with every Mac OS X version out there. Alex
Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote: This is a complete rewrite of cocoa.m to support Core Graphics. As mentioned in earlier threads, the QuickDraw API is depreciated starting with OS X 10.4. Now with OS X 10.5 it won't even compile QuickDraw code on x86_64. This implementation of cocoa.m has the following features: [new] partial drawing of the window as needed, implemented with CG. [new] fullscreen support [new] tablet support [new] View menu and item to enter Fullscreen (cmd-f) [new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- tec.html in the OS X "Help Viewer" [new] -name is shown in Title-bar of window [fix] Application menu creation for 10.4+ (API is private as of 10.4) [fix] Mouse-clicks on the guests window widgets are no longer intercepted [fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide QEMU (cmd-h), quit QEMU (cmd-q)) It should compile on ppc/intel starting form 10.3 (10.2 with the known workarounds). Please test and comment I'm sorry that I didn't find the time to test this implementation before. It's damn slow. I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and booting a linux kernel. I could literally see every like getting repainted (which btw did not happen with my quick hacky version I sent to the list some time ago). I think the major problem is that too much is being done during drawRect. If I understand the code correctly, you create CGImage objects on every repaint, which is prone to be slow. Why not simply reuse the framebuffer qemu provides anyway and leave everything else to CG? Alex
[Qemu-devel] [PATCH] x86 Multiboot support (extended)
Hi, this patch implements x86 Multiboot support for the -kernel way of booting the virtual machine. Multiboot is a new approach to get rid of different bootloaders, providing a unified interface for the kernel. It supports command line options and kernel modules. The two probably best known projects using multiboot to boot are Xen and GNU Hurd. I have only tested Xen and a modified mach bootloader that makes use of multiboot so far. This implementation should be mostly feature-complete. I have not implemented VBE extensions, but as no system uses them currently it does not really hurt. To use multiboot, specify the kernel as -kernel option. Modules should be given as -initrd options, seperated by a comma (,). The -append option is also supported. Please bear in mind that grub also does gzip decompression, which does not occur with this multiboot implementation. To run existing images, please ungzip them first. Comments are welcome. Regards, Alex qemu-multiboot.patch Description: Binary data
Re: [Qemu-devel] Re: [kvm-devel] [PATCH] Making SLIRP code more 64-bit clean
On 1/30/08, Scott Pakin <[EMAIL PROTECTED]> wrote: > Zhang, Xiantao wrote: > > Scott Pakin wrote: > >> The attached patch corrects a bug in qemu/slirp/tcp_var.h that defines > >> the seg_next field in struct tcpcb to be 32 bits wide regardless of > >> 32/64-bitness. seg_next is assigned a pointer value in > >> qemu/slirp/tcp_subr.c, then cast back to a pointer in > >> qemu/slirp/tcp_input.c and dereferenced. That produces a SIGSEGV on > >> my system. > > > > > > I still hit it on IA64 platform with your patch, once configured with > > slirp. > > Okay, here's a more thorough patch that fixes *all* of the "cast from/to > pointer to/from integer of a different size" mistakes that gcc warns > about. Does it also solve the SIGSEGV problem on IA64? The SLIRP code is much, much more subtle than that. Please see this thread: http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00542.html
[Qemu-devel] Re: [kvm-devel] [PATCH] Making SLIRP code more 64-bit clean
Zhang, Xiantao wrote:
Scott Pakin wrote:
The attached patch corrects a bug in qemu/slirp/tcp_var.h that defines
the seg_next field in struct tcpcb to be 32 bits wide regardless of
32/64-bitness. seg_next is assigned a pointer value in
qemu/slirp/tcp_subr.c, then cast back to a pointer in
qemu/slirp/tcp_input.c and dereferenced. That produces a SIGSEGV on
my system.
I still hit it on IA64 platform with your patch, once configured with
slirp.
Okay, here's a more thorough patch that fixes *all* of the "cast from/to
pointer to/from integer of a different size" mistakes that gcc warns
about. Does it also solve the SIGSEGV problem on IA64?
-- Scott
== BEGIN tcp_int32_pointer_cast.patch ==
diff -Naur kvm-60-ORIG/qemu/exec-all.h kvm-60/qemu/exec-all.h
--- kvm-60-ORIG/qemu/exec-all.h 2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/exec-all.h 2008-01-29 19:19:45.0 -0700
@@ -169,7 +169,7 @@
#ifdef USE_DIRECT_JUMP
uint16_t tb_jmp_offset[4]; /* offset of jump instruction */
#else
-uint32_t tb_next[2]; /* address of jump generated code */
+uintptr_t tb_next[2]; /* address of jump generated code */
#endif
/* list of TBs jumping to this one. This is a circular list using
the two least significant bits of the pointers to tell what is
diff -Naur kvm-60-ORIG/qemu/slirp/ip.h kvm-60/qemu/slirp/ip.h
--- kvm-60-ORIG/qemu/slirp/ip.h 2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/ip.h 2008-01-29 19:13:09.0 -0700
@@ -183,23 +183,9 @@
#defineIP_MSS 576 /* default maximum segment size
*/
-#ifdef HAVE_SYS_TYPES32_H /* Overcome some Solaris 2.x junk */
-#include
-#else
-#if SIZEOF_CHAR_P == 4
typedef caddr_t caddr32_t;
-#else
-typedef u_int32_t caddr32_t;
-#endif
-#endif
-
-#if SIZEOF_CHAR_P == 4
typedef struct ipq *ipqp_32;
typedef struct ipasfrag *ipasfragp_32;
-#else
-typedef caddr32_t ipqp_32;
-typedef caddr32_t ipasfragp_32;
-#endif
/*
* Overlay for ip header used by other protocols (tcp, udp).
diff -Naur kvm-60-ORIG/qemu/slirp/misc.c kvm-60/qemu/slirp/misc.c
--- kvm-60-ORIG/qemu/slirp/misc.c 2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/misc.c2008-01-29 11:36:15.0 -0700
@@ -97,39 +97,6 @@
our_addr.s_addr = loopback_addr.s_addr;
}
-#if SIZEOF_CHAR_P == 8
-
-struct quehead_32 {
- u_int32_t qh_link;
- u_int32_t qh_rlink;
-};
-
-inline void
-insque_32(a, b)
- void *a;
- void *b;
-{
- register struct quehead_32 *element = (struct quehead_32 *) a;
- register struct quehead_32 *head = (struct quehead_32 *) b;
- element->qh_link = head->qh_link;
- head->qh_link = (u_int32_t)element;
- element->qh_rlink = (u_int32_t)head;
- ((struct quehead_32 *)(element->qh_link))->qh_rlink
- = (u_int32_t)element;
-}
-
-inline void
-remque_32(a)
- void *a;
-{
- register struct quehead_32 *element = (struct quehead_32 *) a;
- ((struct quehead_32 *)(element->qh_link))->qh_rlink = element->qh_rlink;
- ((struct quehead_32 *)(element->qh_rlink))->qh_link = element->qh_link;
- element->qh_rlink = 0;
-}
-
-#endif /* SIZEOF_CHAR_P == 8 */
-
struct quehead {
struct quehead *qh_link;
struct quehead *qh_rlink;
diff -Naur kvm-60-ORIG/qemu/slirp/slirp.h kvm-60/qemu/slirp/slirp.h
--- kvm-60-ORIG/qemu/slirp/slirp.h 2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/slirp.h 2008-01-29 11:37:19.0 -0700
@@ -265,13 +265,8 @@
void lprint _P((const char *, ...));
-#if SIZEOF_CHAR_P == 4
-# define insque_32 insque
-# define remque_32 remque
-#else
- inline void insque_32 _P((void *, void *));
- inline void remque_32 _P((void *));
-#endif
+#define insque_32 insque
+#define remque_32 remque
#ifndef _WIN32
#include
diff -Naur kvm-60-ORIG/qemu/slirp/tcp_var.h kvm-60/qemu/slirp/tcp_var.h
--- kvm-60-ORIG/qemu/slirp/tcp_var.h2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/tcp_var.h 2008-01-28 21:12:22.0 -0700
@@ -40,11 +40,7 @@
#include "tcpip.h"
#include "tcp_timer.h"
-#if SIZEOF_CHAR_P == 4
- typedef struct tcpiphdr *tcpiphdrp_32;
-#else
- typedef u_int32_t tcpiphdrp_32;
-#endif
+typedef struct tcpiphdr *tcpiphdrp_32;
/*
* Tcp control block, one per tcp; fields:
@@ -178,11 +174,7 @@
* port numbers (which are no longer needed once we've located the
* tcpcb) are overlayed with an mbuf pointer.
*/
-#if SIZEOF_CHAR_P == 4
typedef struct mbuf *mbufp_32;
-#else
-typedef u_int32_t mbufp_32;
-#endif
#define REASS_MBUF(ti) (*(mbufp_32 *)&((ti)->ti_t))
#ifdef LOG_ENABLED
=== END tcp_int32_pointer_cast.patch ===
Re: [Qemu-devel] Under WinXP, Solaris installation does not work in qemu 0.9.1 but does work in qemu 0.9.0
> P4 3.40GHz > WinXP Professional SP2 > > Solaris Express Developer Edition 2/07 DVD iso image > (I have 2/07 but latest version is 9/07 > http://www.sun.com/software/solaris/solaris-express/get.jsp) > > qemu-0.9.1: ... > Small comment - normal setup goes almost without delay, but > errors appear[*] after 1 or 2 minutes delay (and continue to appear by the > same "blocks" with the same interval > [*] WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED] > (ata1): > timeout: abort requested, target=0 lun=0 Workaround is to disable the use of DMA data transfers for the Solaris ata driver. Edit the boot entry in the initial grub menu and append ",ata-dma-enabled=0" at the end of the line starting with "kernel ...". The kernel command should look similar to this: kernel /boot/platform/i86pc/kernel/unix -B install_media=cdrom,ata-dma-enabled=0
[Qemu-devel] Under WinXP, Solaris installation does not work in qemu 0.9.1 but does work in qemu 0.9.0
P4 3.40GHz WinXP Professional SP2 Solaris Express Developer Edition 2/07 DVD iso image (I have 2/07 but latest version is 9/07 http://www.sun.com/software/solaris/solaris-express/get.jsp) qemu-0.9.1: -probably all binaries versions from the http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=4235 -builded by myself too http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=4269 qemu-0.9.0: binaries from http://www1.interq.or.jp/~t-takeda/qemu/ accelerator module: directly from the project site http://fabrice.bellard.free.fr/qemu/kqemu-1.3.0pre11.tar.gz -- I do not know how to get text from qemu window so I attached screenshots. Small comment - normal setup goes almost without delay, but errors appear after 1 or 2 minutes delay (and continue to appear by the same "blocks" with the same interval PS -- may be small bug: "qemu-img.exe create img 7G" - creates 7GB file "qemu-img.exe create img 9G" - creates 9GB file but "qemu-img.exe create img 8G" - creates _zero_ file ??? but "qemu-img.exe create img 8000M" - creates 8Gb file I have checked probably all binaries versions from the http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=4235 PPS Sorry for my poor English -- With best regards Dmitry Bolshakov <><>
[Qemu-devel] QEMU support for ARM architectures
Hello I want to simulate an ARM1176 based system and I was thinking of using QEMU. I wanted to know what ARM11 features are actually supported by the emulator because I did not find this specified clearly. Can anyone shed some light on what features are supported by the current QEMu release. I'm particularly interested in the following. a.. ARMv6 instruction set b.. ARM thumb 2 c.. SIMD d.. ARM Thumb e.. integer pipeline size, f.. simulation of load store and arithmetic pipelines g.. level of MMU functionality simulated Thank you. Gabi
Re: [Qemu-devel] [PATCH] Fix lock_iovec
On [Wed, 30.01.2008 19:56], Mulyadi Santosa wrote: > Hi... > > On Jan 29, 2008 11:59 PM, Kirill A. Shutemov <[EMAIL PROTECTED]> wrote: > > Do not stop iovec conversion on iov_base == NULL if iov_len is 0 > "is 0" or "is not 0"? For now, iovec conversion stops on iov_base == NULL, but NULL in iov_base is correct if iov_len is 0. -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys Ltd, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature
Re: [OT] Re: [Qemu-devel] [PATCH] Remove broken MIPS PICA 61 machine
Marius Groeger, le Wed 30 Jan 2008 14:41:17 +0100, a écrit : > On Wed, 30 Jan 2008, Hervé Poussineau wrote: > > > I didn't know how to do a patch which removes the file > > hw/mips_pica61.c, so this file will have to be removed manually by > > the committer. > > One work-around for that is to do: > > $ cvs diff ... > my.diff > $ diff -pu hw/mips_pica61.c /dev/null >> my.diff Another way is to use cvsdo: cvsdo rm hw/mips_pica61.c and then cvs diff will dump the removal. Samuel
[OT] Re: [Qemu-devel] [PATCH] Remove broken MIPS PICA 61 machine
On Wed, 30 Jan 2008, Hervé Poussineau wrote: > I didn't know how to do a patch which removes the file > hw/mips_pica61.c, so this file will have to be removed manually by > the committer. One work-around for that is to do: $ cvs diff ... > my.diff $ diff -pu hw/mips_pica61.c /dev/null >> my.diff Tedious for more than a couple of files, and still requires the committer to issue a "cvs remove", but at least it makes the diff more complete. Regards Marius
Re: [Qemu-devel] [PATCH] Fix lock_iovec
Hi... On Jan 29, 2008 11:59 PM, Kirill A. Shutemov <[EMAIL PROTECTED]> wrote: > Do not stop iovec conversion on iov_base == NULL if iov_len is 0 "is 0" or "is not 0"? regards, Mulyadi.
[Qemu-devel] [PATCH] Fix lock_iovec
Do not stop iovec conversion on iov_base == NULL if iov_len is 0 --- linux-user/syscall.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index d099e97..5dc6594 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -1028,7 +1028,7 @@ static abi_long lock_iovec(int type, struct iovec *vec, abi_ulong target_addr, base = tswapl(target_vec[i].iov_base); vec[i].iov_len = tswapl(target_vec[i].iov_len); vec[i].iov_base = lock_user(type, base, vec[i].iov_len, copy); - if (!vec[i].iov_base) + if (!vec[i].iov_base && vec[i].iov_len) goto fail; } unlock_user (target_vec, target_addr, 0); -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys Ltd, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature
[Qemu-devel] [PATCH] Remove broken MIPS PICA 61 machine
Hi,
This patch removes the MIPS Pica 61 machine and the RTC memory-mapped
interface. Those don't work.
I didn't know how to do a patch which removes the file hw/mips_pica61.c,
so this file will have to be removed manually by the committer.
Hervé
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.240
diff -u -r1.240 Makefile.target
--- Makefile.target 14 Jan 2008 22:09:11 - 1.240
+++ Makefile.target 30 Jan 2008 07:58:33 -
@@ -470,7 +470,7 @@
VL_OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc405_uc.o ppc405_boards.o
endif
ifeq ($(TARGET_BASE_ARCH), mips)
-VL_OBJS+= mips_r4k.o mips_malta.o mips_pica61.o mips_mipssim.o
+VL_OBJS+= mips_r4k.o mips_malta.o mips_mipssim.o
VL_OBJS+= mips_timer.o mips_int.o dma.o vga.o serial.o i8254.o i8259.o
VL_OBJS+= jazz_led.o
VL_OBJS+= ide.o gt64xxx.o pckbd.o ps2.o fdc.o mc146818rtc.o usb-uhci.o acpi.o
ds1225y.o
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.401
diff -u -r1.401 vl.c
--- vl.c23 Jan 2008 19:01:12 - 1.401
+++ vl.c30 Jan 2008 10:20:28 -
@@ -7935,7 +7935,6 @@
#elif defined(TARGET_MIPS)
qemu_register_machine(&mips_machine);
qemu_register_machine(&mips_malta_machine);
-qemu_register_machine(&mips_pica61_machine);
qemu_register_machine(&mips_mipssim_machine);
#elif defined(TARGET_SPARC)
#ifdef TARGET_SPARC64
Index: hw/boards.h
===
RCS file: /sources/qemu/qemu/hw/boards.h,v
retrieving revision 1.7
diff -u -r1.7 boards.h
--- hw/boards.h 28 Dec 2007 20:59:23 - 1.7
+++ hw/boards.h 30 Jan 2008 07:58:21 -
@@ -39,9 +39,6 @@
/* mips_malta.c */
extern QEMUMachine mips_malta_machine;
-/* mips_pica61.c */
-extern QEMUMachine mips_pica61_machine;
-
/* mips_mipssim.c */
extern QEMUMachine mips_mipssim_machine;
Index: hw/mc146818rtc.c
===
RCS file: /sources/qemu/qemu/hw/mc146818rtc.c,v
retrieving revision 1.16
diff -u -r1.16 mc146818rtc.c
--- hw/mc146818rtc.c16 Dec 2007 23:41:11 - 1.16
+++ hw/mc146818rtc.c30 Jan 2008 07:59:35 -
@@ -496,110 +496,3 @@
register_savevm("mc146818rtc", base, 1, rtc_save, rtc_load, s);
return s;
}
-
-/* Memory mapped interface */
-static uint32_t cmos_mm_readb (void *opaque, target_phys_addr_t addr)
-{
-RTCState *s = opaque;
-
-return cmos_ioport_read(s, (addr - s->base) >> s->it_shift) & 0xFF;
-}
-
-static void cmos_mm_writeb (void *opaque,
-target_phys_addr_t addr, uint32_t value)
-{
-RTCState *s = opaque;
-
-cmos_ioport_write(s, (addr - s->base) >> s->it_shift, value & 0xFF);
-}
-
-static uint32_t cmos_mm_readw (void *opaque, target_phys_addr_t addr)
-{
-RTCState *s = opaque;
-uint32_t val;
-
-val = cmos_ioport_read(s, (addr - s->base) >> s->it_shift) & 0x;
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap16(val);
-#endif
-return val;
-}
-
-static void cmos_mm_writew (void *opaque,
-target_phys_addr_t addr, uint32_t value)
-{
-RTCState *s = opaque;
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap16(value);
-#endif
-cmos_ioport_write(s, (addr - s->base) >> s->it_shift, value & 0x);
-}
-
-static uint32_t cmos_mm_readl (void *opaque, target_phys_addr_t addr)
-{
-RTCState *s = opaque;
-uint32_t val;
-
-val = cmos_ioport_read(s, (addr - s->base) >> s->it_shift);
-#ifdef TARGET_WORDS_BIGENDIAN
-val = bswap32(val);
-#endif
-return val;
-}
-
-static void cmos_mm_writel (void *opaque,
-target_phys_addr_t addr, uint32_t value)
-{
-RTCState *s = opaque;
-#ifdef TARGET_WORDS_BIGENDIAN
-value = bswap32(value);
-#endif
-cmos_ioport_write(s, (addr - s->base) >> s->it_shift, value);
-}
-
-static CPUReadMemoryFunc *rtc_mm_read[] = {
-&cmos_mm_readb,
-&cmos_mm_readw,
-&cmos_mm_readl,
-};
-
-static CPUWriteMemoryFunc *rtc_mm_write[] = {
-&cmos_mm_writeb,
-&cmos_mm_writew,
-&cmos_mm_writel,
-};
-
-RTCState *rtc_mm_init(target_phys_addr_t base, int it_shift, qemu_irq irq)
-{
-RTCState *s;
-int io_memory;
-
-s = qemu_mallocz(sizeof(RTCState));
-if (!s)
-return NULL;
-
-s->irq = irq;
-s->cmos_data[RTC_REG_A] = 0x26;
-s->cmos_data[RTC_REG_B] = 0x02;
-s->cmos_data[RTC_REG_C] = 0x00;
-s->cmos_data[RTC_REG_D] = 0x80;
-s->base = base;
-
-rtc_set_date_from_host(s);
-
-s->periodic_timer = qemu_new_timer(vm_clock,
- rtc_periodic_timer, s);
-s->second_timer = qemu_new_timer(vm_clock,
- rtc_update_second, s);
-s->second_timer2 = qemu_new_timer(vm_clock,
- rtc_update_second2, s);
-
