RE: [Qemu-devel] armv6 support
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ngnu.org] On Behalf Of Paul Brook Sent: den 23 februari 2007 23:55 To: qemu-devel@nongnu.org Cc: Osvaldo Santana; Rodrigo Vivi; [EMAIL PROTECTED] Subject: Re: [Qemu-devel] armv6 support On Friday 23 February 2007 20:09, Rodrigo Vivi wrote: Hi all, Is there someone working on armv6 support? I'm very interested to help this development... I already have ARMv6 and ARMv7 implemented, but am unable to release the code. See: http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00202.html We (CodeSourcery) are negotiating with ARM to have this restriction lifted, but it's slow going. If you want to see ARMv6 support in QEMU please contact ARM directly and encourage them to sort the legal issues out. Paul Would you be able to share the code with someone that has an appropriate license with ARM? Magnus ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
On Sun, 25 Feb 2007, Ben Taylor wrote: As I seem to have hit a wall with the ES1370 driver in qemu not working on Solaris, I have modified configure to allow Solaris to use OpenSoundSystems audio. Is there any interest in having a default audio setting for SDL so that you won't have to always put QEMU_SDL_AUDIO=oss before you start qemu? I don't quite get what does not work OSS or ES1370? An aside. To the best of my knowledge OSS on Solaris, Net/OpenBSD (FreeBSDs OSS is fine though) is not your usual OSS but some reduced version which among other things only allows one open per device (meaning that to do both DAC/ADC one has to use single file descriptor) From where i stand SDL as the default is a bad idea. -- vale ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
Hi Malc, malc [EMAIL PROTECTED] wrote: On Sun, 25 Feb 2007, Ben Taylor wrote: As I seem to have hit a wall with the ES1370 driver in qemu not working on Solaris, I have modified configure to allow Solaris to use OpenSoundSystems audio. Is there any interest in having a default audio setting for SDL so that you won't have to always put QEMU_SDL_AUDIO=oss before you start qemu? I don't quite get what does not work OSS or ES1370? Using a precompiled version of qemu from opensolaris.org, that binary didn't work with a Solaris Nevada guest with OSS audio running on a Solaris Nevada host running native audio. I think its a problem with the precompiled version of qemu I was using. After I got the OSS version runnning on a different system with OSS, I went back and recompiled the CVS code (enabling the debugging) and the audio worked (though the debugging makes the timing of the sound choppy). Once recompiled without debugging, it worked just fine. I apologize for the false alarm. An aside. To the best of my knowledge OSS on Solaris, Net/OpenBSD (FreeBSDs OSS is fine though) is not your usual OSS but some reduced version which among other things only allows one open per device (meaning that to do both DAC/ADC one has to use single file descriptor) I have no idea. I know it worked, but wouldn't know how to test for that case you are talking about. From where i stand SDL as the default is a bad idea. Solaris without OSS audio doesn't have any other options. There is no ALSA, and AFAIK, there isn't an fmod either. However, I still think it is probably a good idea to have the QEMU_SDL_AUDIO device default to the audio subsystem that is defined (or defaulted to). Thoughts? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
On Mon, 26 Feb 2007, Ben Taylor wrote: [..snip..] From where i stand SDL as the default is a bad idea. Solaris without OSS audio doesn't have any other options. There is no ALSA, and AFAIK, there isn't an fmod either. However, I still think it is probably a good idea to have the QEMU_SDL_AUDIO device default to the audio subsystem that is defined (or defaulted to). Thoughts? I'm somewhat lost, there's no QEMU_SDL_AUDIO, furthermore there's no way to tell SDL what subsystem to use other than setting the environment variable. And to reiterate the point: NetBSD, OpenBSD and Solaris do not have full fledged OSS, they provide a wrapper that implements some basic functionality. The native thing for them is SUN audio[1] (more or less). And there's no QEMU driver for that. Options for those system include: OSS wrapper provided with the system, 4Front drivers and SDL (if it can use /dev/audio at all). Only 4Front's solution will allow DAC/ADC because it is basically full blown OSS implementation. Unless, ofcourse, native `/dev/audio' QEMU driver is written. [1] http://docs.sun.com/app/docs/doc/816-0222/6m6nmlssf?q=audioa=view -- vale ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
malc [EMAIL PROTECTED] wrote: On Mon, 26 Feb 2007, Ben Taylor wrote: [..snip..] From where i stand SDL as the default is a bad idea. Solaris without OSS audio doesn't have any other options. There is no ALSA, and AFAIK, there isn't an fmod either. However, I still think it is probably a good idea to have the QEMU_SDL_AUDIO device default to the audio subsystem that is defined (or defaulted to). Thoughts? I'm somewhat lost, there's no QEMU_SDL_AUDIO, furthermore there's no way to tell SDL what subsystem to use other than setting the environment variable. Sorry. I had a brain fart. I meant QEMU_AUDIO_DRV. And after looking at the code, it appears to be smart enough to pick the right audio subsystem. I just remember having to fiddle with QEMU_AUDIO_DRV when I was trying to figure out a previous problem with audio occurred (like 18 months ago) And to reiterate the point: NetBSD, OpenBSD and Solaris do not have full fledged OSS, they provide a wrapper that implements some basic functionality. The native thing for them is SUN audio[1] (more or less). And there's no QEMU driver for that. Options for those system include: OSS wrapper provided with the system, 4Front drivers and SDL (if it can use /dev/audio at all). Well, it appears to use SDL in that case where there is no OSS. Only 4Front's solution will allow DAC/ADC because it is basically full blown OSS implementation. Unless, ofcourse, native `/dev/audio' QEMU driver is written. [1] http://docs.sun.com/app/docs/doc/816-0222/6m6nmlssf?q=audioa=view Thanks for the clarification. Guess I'll just go ahead an use the OSS stuff. Regards, Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] armv6 support
I already have ARMv6 and ARMv7 implemented, but am unable to release the code. See: http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00202.html We (CodeSourcery) are negotiating with ARM to have this restriction lifted, but it's slow going. If you want to see ARMv6 support in QEMU please contact ARM directly and encourage them to sort the legal issues out. Would you be able to share the code with someone that has an appropriate license with ARM? No. Section 7 of the GPL says that the code must be freely[1] redistributeable or not distributed at all. Even if this were not the case I would be extremely reluctant to do this. It would effectively mean that you would be able to distribute an armv6 qemu but we would not (because you have braver lawers than we do). Paul [1] freely = to any third party under the terms of the GPL. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/02/27 00:52:01 Modified files: . : configure Log message: Fix make install prefix=/somewhere. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.124r2=1.125 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/02/27 01:03:41 Modified files: . : configure Log message: Honor $cross_prefix when searching for suitable gcc. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.125r2=1.126 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
--- Pierre d'Herbemont [EMAIL PROTECTED] wrote: ... cvs diff -u would be easier to read for me. (or diff -u). You could send this patch to the qemu-devel, that would be cool. Pierre, Please see the diff file attached. ... Ouch! I have noticed the same: qemu can trigger bugs really easily at the kernel level :( Could you explain how you know that cmpxchg8b is the key to our problem? Stepping in gdb I saw that cmpxchg8b attempts to write to a protected page. Besides, when the system crashes, here's what I see in the crash log in the Console app: ... Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x2111faf5 Thread 0 Crashed: 0 qemu-i386 0x0e02254b stq_le_p + 50 (cpu-all.h:344) 1 qemu-i386 0x0e0224d6 helper_cmpxchg8b + 192 (helper.c:1523) 2 0x0e1361b4 code_gen_buffer + 708980 3 qemu-i386 0x0e000db3 cpu_loop + 23 (main.c:498) 4 qemu-i386 0x0e001f75 main + 2814 (main.c:917) 5 qemu-i386 0x0e000a8e _start + 216 6 qemu-i386 0x0e0009b5 start + 41 ... Any suggestions how to fix this? Thanks for your help! Ilya Also qemu signal handlers might be overridden by some mach calls, that could explain the problem you are encountering. We need to work on this. Pierre. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 darwin-user_syscall.c_diff Description: 2740739241-darwin-user_syscall.c_diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
