Re: [Qemu-devel] MIPS patches, was: MIPS single stepping
Dirk Behme wrote: Thiemo Seufer wrote: Stefan Weil wrote: Great, it works fine. Thanks :) FWIW, I have some rather massive MIPS update (e.g. MIPS32R2 support) in the works and hope to get it finished enough the next days to make a quilt patchset of it. I plan to integrate the other MIPS patches into it for the time being. My list of MIPS patches: MIPS Bugs: = 1. [PATCH] Fix overflow conditions for MIPS add / subtract http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00270.html *OR* [PATCH] Fix test for two's complement overflow http://lists.gnu.org/archive/html/qemu-devel/2006-02/msg00154.html (not sure which is the prefered one. Are both equal?) 2. [PATCH] MIPS CP0 not usable in kernel mode? http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00148.html 3. [PATCH] MIPS single stepping http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00336.html MIPS Improvements: == 1. [PATCH] Huge TLB performance improvement http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00034.html 2. [PATCH] Add MIPS ELF loader http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00185.html 3. [PATCH][MIPS] add lwu instruction http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00326.html 4. [PATCH][MIPS] add basic FPU support http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00327.html Anything missing? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel You might want to include my patch adding some sockets-related syscalls. Raph ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] MIPS patches, was: MIPS single stepping
On Thu, 20 Apr 2006, Dirk Behme wrote: Thiemo Seufer wrote: FWIW, I have some rather massive MIPS update (e.g. MIPS32R2 support) in the works and hope to get it finished enough the next days to make a quilt patchset of it. I plan to integrate the other MIPS patches into it for the time being. Excellent news, Thiemo! :-) My list of MIPS patches: ... 4. [PATCH][MIPS] add basic FPU support http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00327.html Thanks for that list, Dirk. FYI, I continued work on that one and will soonish be posting an updated version which actually will do some more CP1 ops (cvt, trunc, add/sub/mul/div, m*c1, c, bc1*) as well as handling better the Status.FR setting, etc. Regards, Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Hi Alex, I've written to the qemu-devel list, no answers. I copied the list. You could find my qemu.log there: http://www.nwpi.ru/~alec/mips/qemu_log.txt It goes into infinity exception loop. The command string was I'm not quite sure why but you're getting a RI exception on the address 0xbfc8 wich is the move k0, zero in the delay slot. I don't see a problem in the code, but have you tried this sequence? move k0, zero j0xbfc00400 nop Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Marius Groeger wrote: Hi Alex, I've written to the qemu-devel list, no answers. I copied the list. You could find my qemu.log there: http://www.nwpi.ru/~alec/mips/qemu_log.txt It goes into infinity exception loop. The command string was I'm not quite sure why but you're getting a RI exception on the address 0xbfc8 wich is the move k0, zero in the delay slot. I don't see a problem in the code, but have you tried this sequence? move k0, zero j 0xbfc00400 nop Is the move implemented as addiu or as daddiu? The latter would RI. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Thiemo Seufer [EMAIL PROTECTED] wrote: You could find my qemu.log there: http://www.nwpi.ru/~alec/mips/qemu_log.txt It goes into infinity exception loop. I'm not quite sure why but you're getting a RI exception on the address 0xbfc8 wich is the move k0, zero in the delay slot. I don't see a problem in the code, but have you tried this sequence? move k0, zero j0xbfc00400 nop Is the move implemented as addiu or as daddiu? The latter would RI. Oh! It was daddu (gcc -mips3) opcode. Thank you! Can someone add a path to make a log more readable (exception cause decode). The disassembler should be improved too, to mark a 64-bit opcodes as invalid for MIPS32... -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] RE: Qemu-devel Digest, Vol 37, Issue 54
Date: Tue, 18 Apr 2006 21:54:42 +0200 From: Stefan Weil [EMAIL PROTECTED] Subject: [Qemu-devel] Flash simulation To: qemu-devel@nongnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed A typical embedded system (and also most standard PCs) contains flash memory. Full system emulation should also emulate flash behaviour - not only read accesses but also flash type discovery and flash programming. Is there an easy way to realise flash memory emulation with Qemu? Must I write this emulation from scratch? Hints how this might be done are welcome. The QEMU memory interface is capable of supporting Flash emulation. As far as I know, no ready solutions exist, so you need to do this from scratch. The data sheet of the Flash device you want to emulate documents the commands the device understands. You need to implement the finite state machine which interprets those commands. A high-fidelity emulation will also simulate Flash erase and programming times. Regards, Konrad Schwarz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
move k0, zero j0xbfc00400 nop Is the move implemented as addiu or as daddiu? The latter would RI. Oh! It was daddu (gcc -mips3) opcode. Another issue: mtc0 zero, C0_CAUSE === IN: 0xbfc00424: mtc0 zero,$13 OP: 0x: save_pc 0xbfc00424 0x0001: raise_exception 0x11 0x0002: reset_T0 0x0003: exit_tb 0x0004: end 3 OUT: [size=24] 0x08a96a90: movl $0xbfc00424,0x80(%ebp) 0x08a96a9a: push $0x11 0x08a96a9f: call 0x8080fe8 0x08a96aa4: pop%eax 0x08a96aa5: xor%ebx,%ebx 0x08a96aa7: ret do_raise_exception_err: 17 0 do_interrupt enter: PC bfc00424 EPC cause -1 excp 17 do_interrupt: PC bfc00380 EPC bfc00424 cause 11 excp 17 S 0040 C 042c A D pc=0xbfc00380 HI=0x LO=0x ds 0004 0 GPR00: r0 at 0040 v0 0040 v1 GPR04: a0 a1 a2 a3 GPR08: t0 00018000 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x0042 Cause 0x042c EPC0xbfc00424 Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: 0xbfc00380: j 0xbfc019c0 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch to make configure /bin/sh compatible
Solaris 10 does have standards complaint shells. The problem is finding them. :-7 Check out 'man standards' or this link: http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3v?a=view In the utilities section it discusses which shells exist on the system, and which standards they support. I found I had the best luck with /bin/xpg4/sh for configure. Nathan -- Message: 6 Date: Fri, 14 Apr 2006 18:38:27 +0100 (BST) From: Michael McConnell [EMAIL PROTECTED] Subject: Re: [Qemu-devel] Patch to make configure /bin/sh compatible To: qemu-devel@nongnu.org Message-ID: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Apr 2006, Thiemo Seufer wrote: Ben Taylor wrote: This is a patch to make configure truly /bin/sh compatible, as well as changing some logic to remove echo -n for output to files, as echo -n is not consistent among environments. This is against the latest cvs branch, and I appreciate any feedback. [snip] @@ -294,7 +295,7 @@ target_list=i386-user arm-user armeb-user sparc-user ppc-user mips-user mipsel-user $target_list fi else -target_list=$(echo $target_list | sed -e 's/,/ /g') +target_list=`echo $target_list | sed -e 's/,/ /g'` A standard-conforming /bin/sh should be capable of handling this. I've seen various /bin/sh (and ksh) versions that will accept the `` form but not the $(...) form. It's bitten me a few times too. -- Michael Soruk McConnell Eridani Star System ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu and SPARC(Solaris-10)?
I recall (vaguely) that some one was able to compile and run qemu under Solaris-10 on SPARC? I would like to have the details too. -ishwar ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] current CVS + kqemu + win2kpro problems?
I am running the current CVS (with the vnc and ide-dma win2k-hack patches applied), and kqemu 1.3.0-pre5 on a debian-sarge (3.1) release with kernel 2.6.12-1-k7. I have a (very old) original win2k pro install iso, and after I get service pack 3 and 4 installed, I've gotten into a situation where I can download the win2k service pack rollup 1, and then the guest OS/machine will spontaneously reboot. How do I go about sending in a usefull bug report for this? Has anyone done a win2k install on the current cvs? -- -- Troy Benjegerdes'da hozer'[EMAIL PROTECTED] Somone asked me why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shultz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] New usb tablet and numlock
Hi all, I'm enjoying the new usb tablet device under windows 98. When the grabless mode is enabled, I notice that the numlock keys can get out of sync. Anyone else seeing this? For instance, if I have numlock enabled and then start qemu with tablet support, my win98 thinks numlock is off when I move the mouse into the window (even though numlock LED is on). I have to toggle numlock off (LED off) to get the win98 host to think numlock is on. Unrelated, I also have a general USB issue which makes me almost not use it. If I run qemu without -usb option then an idle win98 guest with linux host puts a load of about 5% on my 800Mhz processor. When I run with -usb the idle is 60% minimum. Anyone have some suggestions of were code could be optimized for idle periods? Thanks for th great program! Chris ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
[EMAIL PROTECTED] wrote: With this patch applied I could detect a USB Epson Scanner and a USB Epson Printer from Windows 98 + XP and I could even print pages with the printer (see known problems below). reasons for this patch: I was looking for a way to address my USB printer with windows while working on linux. As I started the work I had to recognize that my printer was not even detected under qemu. So I started to work on it. Are you sure such vast changes are necessary? What was it exactly that happened when you attached the printer/scanner? I'd be interested in seeing a packet log without all the changes that seem to break stuff. changes I made: First I eliminated all potential error sources, which could be avoided. One of these sources where the 1. usb-hub - which I transfered to an extra file usb-hub.c, then I added the usb-libusb.c devices directly to the UHCI controller this introduced the changes of 2) 2. I enhanced the usb add device potentialities so that you should be able to add a device to the UHCI controller. This device can be a usb hub or a usb device. Behind this device you can add another hub or device ... (remember this feature is now theoretically possible but not tested yet), this let to a new usb syntax: #$ qemu -usb controller=uhci,busnum=001 device=host:2:3,addto=001:001 (the short form is: #$ qemu -usb controller=uhci -usb device=host:2:3) so you can build up a complete usb tree. 3. I changed the usb_generic_handle_packet() function and implemented a state machine, which is able to handle the usb packets correct. 4. I changed the linux standard usb-host library to libusb. I personally will always prefer a portable solution if possible. 5. I changed large parts of usb-libusb.c. Some changes were made because I found the source very awkward, some others because I fixed errors and some because I changed the general usb api (see item 2). 6. I tried to join as many usb functions as possible to the usb related files. So that hopefully nobody has to change 15 files again. 7. I made minor changes to usb-uhci - mainly I applied the new api and changed the handling of special messages like usb_reset or usb_attach 8. I made the necessary changes to usb-hid.c and usb-hub.c 9. I wrote a lot of source comments I'm in favor of a new api but with only one controller there is almost no point in doing this yet. It may make more sense to either be able to specify either grabbing all or a few interfaces to proxy to the guest. Also, libusb is ok for a generic handler, but there is no way you'll get someone to jump through all the hoops necessary to get usb working under windows with libusb-win32 or even mac os x. On win32 host you have to manually create an inf file with the PID/VID and then install that for every device you try to use. It's not a good idea to use the filter driver unless the corresponding host driver is unbinded (especially for mass storage). On mac os x you would supposedly creates codeless kernel extensions with the PID/VID to unbind the device. That could be done through scripts, but none exist. Also keep in mind the people here probably don't know about the all-in-one patch on my webserver. I've never posted about it here except for on the user forums. this patch breaks some things: Sorry guys but I could not fix all of it, so I need your help, I didn't want to destroy anybodys work, but the new api makes it necessary to change some files: 1. usb-linux.c and usb-bsd.c will not work without adoption of the new api 2. I did not test usb-hid and usb-hub I'll try to look at the patch this weekend. known problems: 1. under linux the uhci controller reports an error if no usb device is connected 2. the printer and the scanner are recognized under Windows 98/XP and Linux, but the scanner goes into STALL state as soon as a packet in usb_write_bulk() or usb_read_bulk() 3. the libusb usb_host_reset() function does not work as expected and I don't know why (i have commented out this part of the source) The reset function in libusb causes the device to have a new address when it reconnects therefore forcing you to rescan and open the device again. Perhaps this is the problem. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] New usb tablet and numlock
Chris Bagwell wrote: Hi all, I'm enjoying the new usb tablet device under windows 98. When the grabless mode is enabled, I notice that the numlock keys can get out of sync. Anyone else seeing this? For instance, if I have numlock enabled and then start qemu with tablet support, my win98 thinks numlock is off when I move the mouse into the window (even though numlock LED is on). I have to toggle numlock off (LED off) to get the win98 host to think numlock is on. This is probably because numlock is not sent to the guest unless you are in grab mode. You can still get into that mode by using ctrl-alt. There's an interesting usability question here. What keys should be passed to the guest? Should alt-tab be passed? Should num-lock/caps-lock be passed? It would be pretty easy to hack up a patch that grabbed the keyboard on mouse in and released it on mouse out in grabless mode. The only question in my mind is would this be acceptable from the users perspective? Regards, Anthony Liguori Unrelated, I also have a general USB issue which makes me almost not use it. If I run qemu without -usb option then an idle win98 guest with linux host puts a load of about 5% on my 800Mhz processor. When I run with -usb the idle is 60% minimum. Anyone have some suggestions of were code could be optimized for idle periods? Thanks for th great program! Chris ___ 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
Re: [Qemu-devel] Large USB patch
Hello Lonnie, First, thank you for the answer. Lonnie Mendez wrote: [EMAIL PROTECTED] wrote: printer was not even detected under qemu. So I started to work on it. Are you sure such vast changes are necessary? What was it exactly that happened when you attached the printer/scanner? I'd be interested in seeing a packet log without all the changes that seem to break stuff. Yes I am absolutly sure we need this changes. The usb protocoll is a very sophisticated work. There is an exactly defined sequence in which packets are send. (I have made some small documentation about this: http://217.20.126.200/tino/usb-order-of-events.pdf http://217.20.126.200/tino/usb-order-of-events.odg) If you do not keep track of this, you will never be able to get most devices running. The qemu-specialcase-1.patch is the result of ignoring these sequence. At the moment I'm not even sure, if we have to implement the states in which a device is in (I mean default state, adress state ... USB Spec. 1.1 chapter 9). changed the handling of special messages like usb_reset or usb_attach 8. I made the necessary changes to usb-hid.c and usb-hub.c 9. I wrote a lot of source comments I'm in favor of a new api but with only one controller there is almost no point in doing this yet. Sorry I can't agree on that point with you. We will get more controller/devices if we can provide an easy api for implementing them. I would really be interrested to see an EHCI Controller - maybe I will even implement it by myself. It may make more sense to either be able to specify either grabbing all or a few interfaces to proxy to the guest. Also, libusb is ok for a generic handler, but there is no way you'll get someone to jump through all the hoops necessary to get usb working under windows with libusb-win32 or even mac os x. On win32 host you have to manually create an inf file with the PID/VID and then install that for every device you try to use. It's not a good idea to use the filter driver unless the corresponding host driver is unbinded (especially for mass storage). On mac os x you would supposedly creates codeless kernel extensions with the PID/VID to unbind the device. That could be done through scripts, but none exist. On that point you have probably misunderstood me. I dont want to liquidate any native usb-host files. On the contrary, with that patch it is easier to get more such native interfaces running. We could even implement on some platforms more than one interface. I for instance would like it, if I could have libusb and linux native support enabled at the same time so I could make such things like: $ qemu -usb controller=uhci -usb device=libusb:002:003,addto=001:001 -usb device=linux:001:002,addto=001:002 and it should now not be so difficult to implement. Also keep in mind the people here probably don't know about the all-in-one patch on my webserver. I've never posted about it here except for on the user forums. this patch breaks some things: I'll try to look at the patch this weekend. Thanks known problems: The reset function in libusb causes the device to have a new address when it reconnects therefore forcing you to rescan and open the device again. Perhaps this is the problem. Yes I know this and I implemented it. But it does still not work. We get a STALL on the devices when the code is enabled. With kind regards Tino H. Seifert ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
