[Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Hi all, I want to add the ARMv6 instructions support to the QEMU, andnow I am analysing the QEMU architecture. I think maybe someone has done it or doing it now. Can you give me some guide about this work or give your suggestions? Please talk about it. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Ask for debugging linux kernel with Qemu 0.8.1 on Msys
I recently try the patch you recommend but I got the same result. In fact, after make this patch into Qemu source code 0.8.1, I compiled it with these commands: ./configure --prefix=/travail/install/qemu-8.1 make install And I run Qemu to simulate ARM on debugging mode: ./qemu-system-arm -kernel myKernel-with-kgdb -initrd arm_root.img -s And I tried to connect to Qemu by default port 1234: (gdb) target remote localhost:1234 But I got the error: connection refused So I test the current openned port in localhost by the command: netstat -ao And the result I got is below: [code] Connexions actives Proto Adresse locale Adresse distante EtatTCP vinh-phu:epmap vinh-phu:0 LISTENING 1056TCP vinh-phu:microsoft-ds vinh-phu:0 LISTENING 4TCP vinh-phu:1025 vinh-phu:0 LISTENING 1216TCP vinh-phu:1027 vinh-phu:0 LISTENING 4TCP vinh-phu:2869 vinh-phu:0 LISTENING 1416TCP vinh-phu:3016 vinh-phu:0 LISTENING 2036TCP vinh-phu:3019 vinh-phu:0 LISTENING 2012TCP vinh-phu:3026 vinh-phu:0 LISTENING 2012TCP vinh-phu:5000 vinh-phu:0 LISTENING 1416TCP vinh-phu:5101 vinh-phu:0 LISTENING 2012TCP vinh-phu:3001 vinh-phu:0 LISTENING 1800TCP vinh-phu:3002 vinh-phu:0 LISTENING 1216TCP vinh-phu:3003 vinh-phu:0 LISTENING 1216TCP vinh-phu:3015 vinh-phu:0 LISTENING 2036TCP vinh-phu:3015 localhost:3016 ESTABLISHED 2036 TCP vinh-phu:3016 localhost:3015 ESTABLISHED 2036TCP vinh-phu:3019 cs8.msg.dcn.yahoo.com:5050 ESTABLISHED 2012TCP vinh-phu:3026 sip7.voice.re2.yahoo.com:5061 ESTABLISHED 2012TCP vinh-phu:15871 vinh-phu:0 LISTENING 1988UDP vinh-phu:epmap *:* 1056UDP vinh-phu:microsoft-ds *:* 4UDP vinh-phu:isakmp *:* 896UDP vinh-phu:1026 *:* 1216UDP vinh-phu:3004 *:* 1216UDP vinh-phu:3011 *:* 1988UDP vinh-phu:3012 *:* 1384UDP vinh-phu:3025 *:* 1384UDP vinh-phu:3068 *:* 1384UDP vinh-phu:3069 *:* 1384UDP vinh-phu:3071 *:* 1384UDP vinh-phu:3072 *:* 1384UDP vinh-phu:3073 *:* 1384UDP vinh-phu:3074 *:* 1384UDP vinh-phu:ntp *:* 1216UDP vinh-phu:1900 *:* 1416UDP vinh-phu:3005 *:* 1216UDP vinh-phu:3009 *:* 1216UDP vinh-phu:3022 *:* 2012UDP vinh-phu:3441 *:* 2036UDP vinh-phu:3997 *:* 1540UDP vinh-phu:ntp *:* 1216UDP vinh-phu:1900 *:* 1416UDP vinh-phu:3030 *:* 2012UDP vinh-phu:3031 *:* 2012UDP vinh-phu:8257 *:* 1988UDP vinh-phu:57073 *:* 1988 [/code] Do you know any suggestion for this problem? Thanks so much Best regards. Thanh Lonnie Mendez [EMAIL PROTECTED] wrote: On Tue, 2006-06-06 at 05:35 -0700, Tieu Ma Dau wrote: Hi All, I've compiled Linux kernel 2.6.16 with kgdb on Linux. And after that, I've tried to debug this kernel with Qemu 0.8.1 on Msys to simulate ARM Processor. In fact, I've run the command below: qemu-system-arm -kernel myKernel -initrd arm_root.img -s But I can't make the connection from arm-toolchain-gdb to the port 1234 (by default, this port must be openned by Qemu when using the option -s for debugging) Furthermore, I've confirmed if the port 1234 is openned or not with the command: netstat -ao and there is not port 1234 openned. I've also try the option -p 123456 to change the default port for debugging of Qemu but I've got the same result. Do you know where the problem arrive? Have you seen this?http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00457.htmlhttp://lists.gnu.org/archive/html/qemu-devel/___Qemu-devel mailing listQemu-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/qemu-devel __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Ask for debugging linux kernel with Qemu 0.8.1 onMsys
Sent: Wednesday, June 07, 2006 4:56 PM Tieu Ma Dau wrote: I recently try the patch you recommend but I got the same result. In fact, after make this patch into Qemu source code 0.8.1, I compiled it with these commands: ./configure --prefix=/travail/install/qemu-8.1 make install And I run Qemu to simulate ARM on debugging mode: ./qemu-system-arm -kernel myKernel-with-kgdb -initrd arm_root.img -s And I tried to connect to Qemu by default port 1234: (gdb) target remote localhost:1234 But I got the error: connection refused MinGW's gdb doesn't support network debugging. You need to use Cygwin's gdb for remote debugging with network. So I test the current openned port in localhost by the command: netstat -ao And the result I got is below: [code] Connexions actives Proto Adresse locale Adresse distante Etat TCPvinh-phu:epmap vinh-phu:0 LISTENING 1056 TCPvinh-phu:microsoft-ds vinh-phu:0 LISTENING 4 TCPvinh-phu:1025 vinh-phu:0 LISTENING 1216 TCPvinh-phu:1027 vinh-phu:0 LISTENING 4 TCPvinh-phu:2869 vinh-phu:0 LISTENING 1416 TCPvinh-phu:3016 vinh-phu:0 LISTENING 2036 TCPvinh-phu:3019 vinh-phu:0 LISTENING 2012 TCPvinh-phu:3026 vinh-phu:0 LISTENING 2012 TCPvinh-phu:5000 vinh-phu:0 LISTENING 1416 TCPvinh-phu:5101 vinh-phu:0 LISTENING 2012 TCPvinh-phu:3001 vinh-phu:0 LISTENING 1800 TCPvinh-phu:3002 vinh-phu:0 LISTENING 1216 TCPvinh-phu:3003 vinh-phu:0 LISTENING 1216 TCPvinh-phu:3015 vinh-phu:0 LISTENING 2036 TCPvinh-phu:3015 localhost:3016 ESTABLISHED 2036 TCPvinh-phu:3016 localhost:3015 ESTABLISHED 2036 TCPvinh-phu:3019 cs8.msg.dcn.yahoo.com:5050 ESTABLISHED 2012 TCPvinh-phu:3026 sip7.voice.re2.yahoo.com:5061 ESTABLISHED 2012 TCPvinh-phu:15871 vinh-phu:0 LISTENING 1988 UDPvinh-phu:epmap *:*1056 UDPvinh-phu:microsoft-ds *:*4 UDPvinh-phu:isakmp*:*896 UDPvinh-phu:1026 *:*1216 UDPvinh-phu:3004 *:*1216 UDPvinh-phu:3011 *:*1988 UDPvinh-phu:3012 *:*1384 UDPvinh-phu:3025 *:*1384 UDPvinh-phu:3068 *:*1384 UDPvinh-phu:3069 *:*1384 UDPvinh-phu:3071 *:*1384 UDPvinh-phu:3072 *:*1384 UDPvinh-phu:3073 *:*1384 UDPvinh-phu:3074 *:*1384 UDPvinh-phu:ntp *:*1216 UDPvinh-phu:1900 *:*1416 UDPvinh-phu:3005 *:*1216 UDPvinh-phu:3009 *:*1216 UDPvinh-phu:3022 *:*2012 UDPvinh-phu:3441 *:*2036 UDPvinh-phu:3997 *:*1540 UDPvinh-phu:ntp *:*1216 UDPvinh-phu:1900 *:*1416 UDPvinh-phu:3030 *:*2012 UDPvinh-phu:3031 *:*2012 UDPvinh-phu:8257 *:*1988 UDPvinh-phu:57073 *:*1988 [/code] Do you know any suggestion for this problem? Port 1234 doesn't open. The program doesn't work well. If you use the patch , TCP 1234 port will be used. Did you see this message? Waiting gdb connection on port 1234 Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] getting the 5446 in 1152x864 mode
On Wednesday 07 June 2006 02:31, Ben Taylor wrote: I've been able to get 1152x864 out of the Solaris Xorg gdm5446 driver so there must be something else that's causing you problems. I think I've gotten win98se to do it as well. Thanks for the confirmation. So, I re-tried (extensively) to get 1152x864. That resolution is listed by Windows as possible at 70Hz and 75Hz (monitor), so I set the monitor refresh rates to those values in the Windows display settings, but still no success. Even with rebooting after changing the settings. I still also have sometimes an 'invisible wall' problem for the mouse pointer problem that was discussed on this list a few weeks ago. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Ask for debugging linux kernel with Qemu 0.8.1 onMsys
MinGW's gdb doesn't support network debugging. You need to use Cygwin's gdb for remote debugging with network. I installed gcc-4.0 toolchain (so it also include gdb) from http://www.gnuarm.com/ to debug the code generated for ARM Linux. And I did not install Cygwin because when I had installed this gcc-4.0 toolchain, the installer had asked me if I want to install the files .dll used by Cygwin in case of I had not installed Cygwin as well. Finally, it means I did not installed Cygwin but installed gcc-4.0 toolchain and I can run well the command (used for debug ARM Linux code): arm-elf-gdbPort 1234 doesn't open. The program doesn't work well. If you use the patch , TCP 1234 port will be used. Did you see this message?Waiting gdb connection on port 1234 I said that I've applied this patch to source code and recompiled this source code but I got the same problem. For the msg: "Waiting gdb connection on port 1234", I did not see this message in the screen of Msys (because I think that Qemu must use stdio to print the message on the console of Msys but there is not stdio in Msys/Windows) but I don't know if it can be printed on the screen (the new window for Qemu when running Qemu from Msys) of Qemu or not; because this screen scroll very fast and I could not see all the messages on the screen. So do you have any suggestions to see all of which printed on the screen of Qemu? And any solutions to test if the port 1234 is already openned or not? Or any another patches? Thanks so much and best regards. Thanh Kazu [EMAIL PROTECTED] wrote: Sent: Wednesday, June 07, 2006 4:56 PM Tieu Ma Dau wrote:I recently try the patch you recommend but I got the same result. In fact,after make this patch into Qemu source code 0.8.1, I compiled it with thesecommands:./configure --prefix=/travail/install/qemu-8.1make installAnd I run Qemu to simulate ARM on debugging mode:./qemu-system-arm -kernel myKernel-with-kgdb -initrd arm_root.img -sAnd I tried to connect to Qemu by default port 1234: (gdb) target remotelocalhost:1234But I got the error: connection refusedMinGW's gdb doesn't support network debugging. You need to use Cygwin's gdbfor remote debugging with network.So I test the current openned port in localhost by the command: netstat -aoAnd the result I got is below:[code]Connexions actives Proto Adresse locale Adresse distante Etat TCPvinh-phu:epmap vinh-phu:0 LISTENING 1056 TCPvinh-phu:microsoft-ds vinh-phu:0 LISTENING 4 TCPvinh-phu:1025 vinh-phu:0 LISTENING 1216 TCPvinh-phu:1027 vinh-phu:0 LISTENING 4 TCPvinh-phu:2869 vinh-phu:0 LISTENING 1416 TCPvinh-phu:3016 vinh-phu:0 LISTENING 2036 TCPvinh-phu:3019 vinh-phu:0 LISTENING 2012 TCPvinh-phu:3026 vinh-phu:0 LISTENING 2012 TCPvinh-phu:5000 vinh-phu:0 LISTENING 1416 TCPvinh-phu:5101 vinh-phu:0 LISTENING 2012 TCPvinh-phu:3001 vinh-phu:0 LISTENING 1800 TCPvinh-phu:3002 vinh-phu:0 LISTENING 1216 TCPvinh-phu:3003 vinh-phu:0 LISTENING 1216 TCPvinh-phu:3015 vinh-phu:0 LISTENING 2036 TCPvinh-phu:3015 localhost:3016 ESTABLISHED 2036 TCPvinh-phu:3016 localhost:3015 ESTABLISHED 2036 TCPvinh-phu:3019 cs8.msg.dcn.yahoo.com:5050 ESTABLISHED2012 TCPvinh-phu:3026 sip7.voice.re2.yahoo.com:5061 ESTABLISHED2012 TCPvinh-phu:15871 vinh-phu:0 LISTENING 1988 UDPvinh-phu:epmap *:*1056 UDPvinh-phu:microsoft-ds *:* 4 UDPvinh-phu:isakmp*:*896 UDPvinh-phu:1026 *:*1216 UDPvinh-phu:3004 *:*1216 UDPvinh-phu:3011 *:*1988 UDPvinh-phu:3012 *:*1384 UDPvinh-phu:3025 *:*1384 UDPvinh-phu:3068 *:*1384 UDPvinh-phu:3069 *:*1384 UDPvinh-phu:3071 *:*1384 UDPvinh-phu:3072 *:*1384 UDPvinh-phu:3073 *:*1384 UDPvinh-phu:3074 *:*1384 UDPvinh-phu:ntp *:*1216 UDPvinh-phu:1900 *:*
[Qemu-devel] Intel OSX build
Does anyone have a reliable way to build qemu on Intel OSX from CVS? Yes, I've seen Q. It isn't very stable, nor do I have the command line I'm used to and it hasn't been updated since mid April. Joe Batt ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Intel OSX build
Am 07.06.2006 um 14:02 schrieb Joe Batt: Does anyone have a reliable way to build qemu on Intel OSX from CVS? Yes, I've seen Q. It isn't very stable, nor do I have the command line I'm used to and it hasn't been updated since mid April. You'll find all sources and patches of Qemu for Intel OS X and Q at our new server: http://www.kju-app.org/proj/wiki/CompilingQ The sources are up-to-date, we only havent managed to fully move to the new server yet. Greetings, cordney* project Q Joe Batt ___ 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] I want to add the ARMv6 instructions, who can give some advices?
On Wednesday 07 June 2006 08:11, wang lianwei wrote: Hi all, I want to add the ARMv6 instructions support to the QEMU, and now I am analysing the QEMU architecture. I think maybe someone has done it or doing it now. Can you give me some guide about this work or give your suggestions? I have already implemented armv6 and armv7 support in qemu, but am unable to distribute it for legal reasons. See the previous thread on this topic: http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00199.html If you want armv6 support in qemu your best bet is to contact ARM and persuade them to lift this restriction. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [NEWBYE] Adding a hardware module
Hi to everybody, I'm starting to study qemu for degree's thesis. I need to implement a simple hardware module such as serial or parallel port. Can you tell me where I can get documentation about it or source code to start? Now I'm looking at serial.c and parallel.c but I don't know if it's the right place to start. Thanks Ale ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Or, someone who hasn't agreed to the contract could implement armv6 and 7 support. -- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
On Wednesday 07 June 2006 15:38, John R. wrote: Or, someone who hasn't agreed to the contract could implement armv6 and 7 support. That implies implementing it without looking at the architecture documentation, since the only way to get that documentation is to agree to the licence. I do have access to the architecture documentation, so I probably wouldn't be able to touch that code. ie. I'd be unable to continue working on qemu. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Paul Brook wrote: On Wednesday 07 June 2006 08:11, wang lianwei wrote: I want to add the ARMv6 instructions support to the QEMU, and now I am analysing the QEMU architecture. I think maybe someone has done it or doing it now. Can you give me some guide about this work or give your suggestions? I have already implemented armv6 and armv7 support in qemu, but am unable to distribute it for legal reasons. See the previous thread on this topic: http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00199.html If you want armv6 support in qemu your best bet is to contact ARM and persuade them to lift this restriction. There were three suggestions in that thread, and persuading ARM Ltd to lift the restriction was one of them. The other two suggestions were: 1. For someone who is not bound by an ARM documentation license to do it, for example by working out the instruction set from reading Binutils, GCC and Linux code, and from reading books like the ARM System Developer's Guide, by Sloss, Symes, and Wright, Elsevier 2004. The objection was raised that although that would be possible, it would prevent some people (who are bound by an ARM license) from contributing to the new Qemu. I think that would not be a problem if the ARMv6 support were in the form of a contributed patch, which those people could avoid looking at. 2. To add an explanation of why ARMv6 isn't supported to Qemu's FAQ. Anyone in a position to add to the FAQ? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Paul Brook wrote: I do have access to the architecture documentation, so I probably wouldn't be able to touch that code. ie. I'd be unable to continue working on qemu. Is there a time limit on that part of your documentation license? Can you reveal to us what exactly your license prohibits, for example by pasting that part of the license here? Thanks, -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Can you reveal to us what exactly your license prohibits, for example by pasting that part of the license here? Though probably different from the license CodeSourcery had to sign, you can try to download ARMv7-M architecture pdf from ARM site to see the kind of restriction on has to agree on. Laurent ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
On Wednesday 07 June 2006 15:53, Jamie Lokier wrote: Paul Brook wrote: I do have access to the architecture documentation, so I probably wouldn't be able to touch that code. ie. I'd be unable to continue working on qemu. Is there a time limit on that part of your documentation license? No. Can you reveal to us what exactly your license prohibits, for example by pasting that part of the license here? http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html Specifically clause 2(i): No right is granted to [...] use the ARM Architecture Reference Manual for the purposes of developing or having developed microprocessor cores or models thereof which are compatible in whole or part with either or both the instructions or programmer's models described in this ARM Architecture Reference Manual You may argue whether qemu constitutes a microprocessor model. However the ARM licencing/legal department have stated that in their opinion it does, and is covered by this clause. Also note clause 2(iii) that prohibits redistribution of the document. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Paul Brook wrote: Can you reveal to us what exactly your license prohibits, for example by pasting that part of the license here? http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html Specifically clause 2(i): No right is granted to [...] use the ARM Architecture Reference Manual for the purposes of developing or having developed microprocessor cores or models thereof which are compatible in whole or part with either or both the instructions or programmer's models described in this ARM Architecture Reference Manual Qemu is already compatible in part with the the instructions and models described in the manual, isn't it? So by the language of clause 2(i), aren't you _already_ prohibited from working on Qemu's ARM code? I suppose you could argue that you're not using those particular manuals to work on Qemu's ARM code at the moment. Even though you've read and understood those manuals... that somehow, the knowledge you've gained from them (even in part) isn't being used to write the existing Qemu code. That seems dubious to me. Isn't it much the same as arguing that you're not using those particular manuals to develop ARMv6 support, if you can refer to other resources (books etc.) which provide the necessary information? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Switch to OpenBIOS for Sparc32/64?
I'd like to replace Proll with OpenBIOS as the Qemu/Sparc32 boot prom and then develop a Sparc64 port that would finally make the Sparc64 system emulator usable. OpenBIOS/Sparc32 has reached or exceeded the level of functionality that Proll provides: * boot from HDD and CD (several Linux distro installers work, NetBSD and Solaris in progress) * preloaded kernel, initrd and command line support * Forth support, which is needed for Sparc64, maybe also for other OSes than Linux on Sparc32 * graphical console and -nographic support * SMP support One big advantage is that OpenBIOS is actively being developed at the moment. OpenBIOS is very portable, currently x86, ppc, sparc32, and amd64 are supported. The only missing feature is TFTP boot ability, but that is in my opinion not very useful for Qemu, as you can preload the kernel. What do you think, is the switch okay, and if so, when can this happen? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Specifically clause 2(i): No right is granted to [...] use the ARM Architecture Reference Manual for the purposes of developing or having developed microprocessor cores or models thereof which are compatible in whole or part with either or both the instructions or programmer's models described in this ARM Architecture Reference Manual Qemu is already compatible in part with the the instructions and models described in the manual, isn't it? So by the language of clause 2(i), aren't you _already_ prohibited from working on Qemu's ARM code? All the information used to implement the current qemu Arm support is available from other sources not covered by this licence. I'm confident I could prove this if necessary. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for Sparc32/64?
On Wednesday 07 June 2006 16:56, Blue Swirl wrote: I'd like to replace Proll with OpenBIOS as the Qemu/Sparc32 boot prom and then develop a Sparc64 port that would finally make the Sparc64 system emulator usable. ... What do you think, is the switch okay, and if so, when can this happen? Sounds like a good idea to me, and the sooner the better. Even if we find some things that work with proll but not openbios I guess there's a good chance of getting openbios fixed. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Paul Brook wrote: Qemu is already compatible in part with the the instructions and models described in the manual, isn't it? So by the language of clause 2(i), aren't you _already_ prohibited from working on Qemu's ARM code? All the information used to implement the current qemu Arm support is available from other sources not covered by this licence. I'm confident I could prove this if necessary. Of course, I'm sure you're right. In the thread you cited earlier, Wolfgang Schildbach refers to ARM System Developer's Guide, by Sloss, Symes, and Wright, Elsevier 2004 as documentation that may be sufficient for Qemu ARMv6 support, and which is not covered by the license. If ARMv6 support were developed by someone else, using only that book, and maybe looking at other code (GCC, Linux etc.), that would prove that all the information used is from other sources not covered by the license, wouldn't it? The support might be missing a few features, if the other information sources are incomplete, but even incomplete support that can be deduced from those sources would be good enough for most purposes. If that were done, you could prove that the resulting feature in Qemu was written using sources not covered by the license. So would you have any problem contributing to Qemu after ARMv6 support was integrated, if the person who contributes ARMv6 support states that they have never seen the ARM document and refers to the sources they have used instead? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
All the information used to implement the current qemu Arm support is available from other sources not covered by this licence. I'm confident I could prove this if necessary. True for ARMv6, probably not for ARMv7, be it -A, -R or -M. In the thread you cited earlier, Wolfgang Schildbach refers to ARM System Developer's Guide, by Sloss, Symes, and Wright, Elsevier 2004 as documentation that may be sufficient for Qemu ARMv6 support, and which is not covered by the license. Yes. But you would need instruction encoding that are not in the book. You will find them in binutils (opcode directory). If ARMv6 support were developed by someone else, using only that book, and maybe looking at other code (GCC, Linux etc.), that would prove that all the information used is from other sources not covered by the license, wouldn't it? Linux uses a small subset of the System Coprocessor. If you want information about ARMv6 cp15, look in ARM TRM (arm11), I don't think they have any restriction such as ARMv7-M. The support might be missing a few features, if the other information sources are incomplete, but even incomplete support that can be deduced from those sources would be good enough for most purposes. Certainly yes. But that's not a small effort :) But bear in mind a few things: for instance supersection, that are ARMv6 specific, were added to Linux kernel in 2.6.13 which is kind of recent; so if you omit some features, you might have to add them in one day. If that were done, you could prove that the resulting feature in Qemu was written using sources not covered by the license. So would you have any problem contributing to Qemu after ARMv6 support was integrated, if the person who contributes ARMv6 support states that they have never seen the ARM document and refers to the sources they have used instead? I think that it could be very difficult to prove you did not use any official NDA document. I am doing simulator development at ARM and would certainly never approach anything v6 or v7 related until information is publically available with no restriction. Anyway I am not speaking for ARM :) Laurent ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for Sparc32/64?
I propose the same for QEMU/PowerPC. However I was not able to test OpenBIOS over it as I did not find an OpenBIOS/PPC binary and cannot create it. Does anyone can/has ? Regards, Natalia Portillo El 07/06/2006, a las 17:17, Paul Brook escribió: On Wednesday 07 June 2006 16:56, Blue Swirl wrote: I'd like to replace Proll with OpenBIOS as the Qemu/Sparc32 boot prom and then develop a Sparc64 port that would finally make the Sparc64 system emulator usable. ... What do you think, is the switch okay, and if so, when can this happen? Sounds like a good idea to me, and the sooner the better. Even if we find some things that work with proll but not openbios I guess there's a good chance of getting openbios fixed. Paul ___ 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] Switch to OpenBIOS for Sparc32/64?
Natalia Portillo wrote: I propose the same for QEMU/PowerPC. It would be nice to some day be able to use QEMU to run classic Mac OS, now that Apple has discontinued the classic environment in OS X. Would switching to OpenBIOS negatively affect efforts in this direction? - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for Sparc32/64?
Au contraire, It will positively. Currently OHW is unable to load anything, and when it was able, Mac OS complained about the firmware not being able. However the Apple implementation of OF was very simple and incomplete until BW G3, just enough to interpret the CHRP script in /System Folder/Mac OS ROM file, and load the binary data on it (the Mac OS nanokernel that emulates the toolbox, contains the 68 emulator, and links/loads the System and Finder.). OpenBIOS is a far more complete OF implementation than Apple ones used to load Mac OS = 9. Just it need to be able to read HFS partition, handle CUDA, ADB, other devices, and, it will be able to run a Mac OS. If I'm wrong, Gwenole please correct me :p. Regards El 07/06/2006, a las 17:54, Joshua Root escribió: Natalia Portillo wrote: I propose the same for QEMU/PowerPC. It would be nice to some day be able to use QEMU to run classic Mac OS, now that Apple has discontinued the classic environment in OS X. Would switching to OpenBIOS negatively affect efforts in this direction? - Josh ___ 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] I want to add the ARMv6 instructions, who can give some advices?
Paul Brook wrote: So would you have any problem contributing to Qemu after ARMv6 support was integrated, if the person who contributes ARMv6 support states that they have never seen the ARM document and refers to the sources they have used instead? As I mentioned before I have significant local patches implementing unreleased Arm features. The only way to avoid cross contamination between that and a third party qemu implementation two would be for me to stop contributing anything (or at minimum anything ARM related) back to qemu. The idea is for someone else, working completely independently of you, and without ever seeing those patches of yours, to provide the later ARM support. I know it doesn't feel good to think about someone else duplicating the work you have done, but that's not a reason to not do it, if it's the only legal solution to a useful feature. So why anything ARM related and not anything ARMv6 or later related? Isn't it sufficient for you to avoid contributing anything related to the versions/features the restrictive license covers, so that you could continue to contribute ARM related things for the older, publically documented features? That may feel uncomfortable, but it is no different than your present situation. And for other people, it would provide a useful feature. Basing work on the gcc/binutils code doesn't help me either because I wrote most of that code in the first place :-) Since the idea is for someone else do it, that doesn't matter. I'm wondering why, if it were done, it would be a problem for you to contribute in future in the areas which you contribute to now. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Basing work on the gcc/binutils code doesn't help me either because I wrote most of that code in the first place :-) Since the idea is for someone else do it, that doesn't matter. I'm wondering why, if it were done, it would be a problem for you to contribute in future in the areas which you contribute to now. Because a large proportion of my contributions, and most of my interest is in this area. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for PowerPC? (was: Switch to OpenBIOS for Sparc32/64?)
Natalia Portillo wrote: OpenBIOS is a far more complete OF implementation than Apple ones used to load Mac OS = 9. Just it need to be able to read HFS partition, handle CUDA, ADB, other devices, and, it will be able to run a Mac OS. OK, great. One small correction though: Mac OS since at least version 8.1 is perfectly happy without ADB as long as it has USB. I guess if we want to run older versions we still need ADB though. :) - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
On 6/7/06, Paul Brook [EMAIL PROTECTED] wrote: Basing work on the gcc/binutils code doesn't help me either because I wrote most of that code in the first place :-) Since the idea is for someone else do it, that doesn't matter. I'm wondering why, if it were done, it would be a problem for you to contribute in future in the areas which you contribute to now. Because a large proportion of my contributions, and most of my interest is in this area. Paul No one wants to lose your effort on the ARM port. For the most part you are the ARM port. Have you talked to an IP or contract lawyer about the issue? There's your liability and another issue is liability for the project or copyright issues. It is interesting to know how far both go and how they relate. To my mind this just seems pretty murkey. Yes the best solution would be a pass from ARM but everyone knows that isn't going to happen. -- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for PowerPC? (was: Switch to OpenBIOS for Sparc32/64?)
I personally am not happy with partial emulations. So, having ADB, is a must for a G3 beige or previous macintosh emulation. El 07/06/2006, a las 18:39, Joshua Root escribió: Natalia Portillo wrote: OpenBIOS is a far more complete OF implementation than Apple ones used to load Mac OS = 9. Just it need to be able to read HFS partition, handle CUDA, ADB, other devices, and, it will be able to run a Mac OS. OK, great. One small correction though: Mac OS since at least version 8.1 is perfectly happy without ADB as long as it has USB. I guess if we want to run older versions we still need ADB though. :) - Josh ___ 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] Switch to OpenBIOS for Sparc32/64?
Sounds like a good idea to me, and the sooner the better. Even if we find some things that work with proll but not openbios I guess there's a good chance of getting openbios fixed. So I'll send you a patch that changes the name 'proll.elf' to 'openbios-builtin.elf' (or maybe it's better to use something like 'openbios-sparc32', simplifies the code) and a sample OpenBIOS file and that's it? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for Sparc32/64?
On Wednesday 07 June 2006 20:24, Blue Swirl wrote: Sounds like a good idea to me, and the sooner the better. Even if we find some things that work with proll but not openbios I guess there's a good chance of getting openbios fixed. So I'll send you a patch that changes the name 'proll.elf' to 'openbios-builtin.elf' (or maybe it's better to use something like 'openbios-sparc32', simplifies the code) and a sample OpenBIOS file and that's it? Yes. Plus documentation bits. Bonus points if you include a README describing where the bios comes from and basic description of how to reproduce it, even if this is just download the openbios sources and they should just work. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Patch] Kqemu patch for 2.6.17-rc2
Leonardo E. Reiter wrote: Hi, I'm attaching a small update to Thomas's patch which conditionally enables this based on kernel version. As far as I can tell (from very brief research), module_param became available very late in 2.4. Also, the old version (MODULE_PARM) is supported in most 2.6 kernels as well. I picked arbitrarily 2.6.10 as the break-off point - it's really easy to change that to be something else. In any case, Fabrice, can you think about applying this, or something very similar, as it looks like MODULE_PARM has been finally abandoned in the latest kernels. Regards, Leo Reiter Thomas Petazzoni wrote: Hi, On 2.6.17-rc2, the MODULE_PARM() way of declaring module parameters seems to have disappeared (it is anyway deprecated since the beginning of the 2.6 series). As such, kqemu-1.3.0pre7 doesn't compile. --- kqemu-linux.c.orig 2006-06-06 10:06:03.0 -0400 +++ kqemu-linux.c 2006-06-06 10:09:41.0 -0400 @@ -49,7 +49,11 @@ /* if 0 is used, then devfs/udev is used to automatically create the device */ int major = 250; +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,10) MODULE_PARM(major,"i"); +#else +module_param(major, int, 0); +#endif /* Lock the page at virtual address 'user_addr' and return its physical address (page index). Return a host OS private user page I have just had to apply this fix to get kqemu to work with the latest FC6 Development kernel 2.6.16-1.2252_FC6. ALl working fine now. Nigel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Good news for Gentoo Linux users
Hi all, I just made an ebuild for Gentoo Linux that directly takes QEMU from CVS You can find it out here at http://www.claunia.com/qemu/ in the QEMU Official OS Support List It is just after the OS list. It does support emerging KQEMU and QEMU system emulators, but not QVM86 nor QEMU user emulators. Any comment, suggest, so on, here, or on the IRC channel Regards, Natalia Portillo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Remove abuse of kernel headers.
The _syscallX() macros in the kernel's private headers are not suitable
for use in userspace. This patch switches from abusing those to using
the syscall() function which glibc provides.
--- qemu-0.8.1/linux-user/syscall.c~2006-05-03 21:32:58.0 +0100
+++ qemu-0.8.1/linux-user/syscall.c 2006-06-07 22:11:48.0 +0100
@@ -79,127 +79,59 @@
#defineVFAT_IOCTL_READDIR_SHORT_IOR('r', 2, struct dirent [2])
-#if defined(__powerpc__)
-#undef __syscall_nr
-#undef __sc_loadargs_0
-#undef __sc_loadargs_1
-#undef __sc_loadargs_2
-#undef __sc_loadargs_3
-#undef __sc_loadargs_4
-#undef __sc_loadargs_5
-#undef __sc_asm_input_0
-#undef __sc_asm_input_1
-#undef __sc_asm_input_2
-#undef __sc_asm_input_3
-#undef __sc_asm_input_4
-#undef __sc_asm_input_5
#undef _syscall0
#undef _syscall1
#undef _syscall2
#undef _syscall3
#undef _syscall4
#undef _syscall5
+#undef _syscall6
-/* need to redefine syscalls as Linux kernel defines are incorrect for
- the clobber list */
-/* On powerpc a system call basically clobbers the same registers like a
- * function call, with the exception of LR (which is needed for the
- * sc; bnslr sequence) and CR (where only CR0.SO is clobbered to signal
- * an error return status).
- */
-
-#define __syscall_nr(nr, type, name, args...) \
- unsigned long __sc_ret, __sc_err; \
- { \
- register unsigned long __sc_0 __asm__ (r0); \
- register unsigned long __sc_3 __asm__ (r3); \
- register unsigned long __sc_4 __asm__ (r4); \
- register unsigned long __sc_5 __asm__ (r5); \
- register unsigned long __sc_6 __asm__ (r6); \
- register unsigned long __sc_7 __asm__ (r7); \
- \
- __sc_loadargs_##nr(name, args); \
- __asm__ __volatile__\
- (sc \n\t\
-mfcr %0 \
- : =r (__sc_0), \
- =r (__sc_3), =r (__sc_4), \
- =r (__sc_5), =r (__sc_6), \
- =r (__sc_7)\
- : __sc_asm_input_##nr \
- : cr0, ctr, memory, \
- r8, r9, r10,r11, r12); \
- __sc_ret = __sc_3; \
- __sc_err = __sc_0; \
- } \
- if (__sc_err 0x1000) \
- { \
- errno = __sc_ret; \
- __sc_ret = -1; \
- } \
- return (type) __sc_ret
-
-#define __sc_loadargs_0(name, dummy...)
\
- __sc_0 = __NR_##name
-#define __sc_loadargs_1(name, arg1)\
- __sc_loadargs_0(name); \
- __sc_3 = (unsigned long) (arg1)
-#define __sc_loadargs_2(name, arg1, arg2) \
- __sc_loadargs_1(name, arg1);\
- __sc_4 = (unsigned long) (arg2)
-#define __sc_loadargs_3(name, arg1, arg2, arg3)
\
- __sc_loadargs_2(name, arg1, arg2); \
- __sc_5 = (unsigned long) (arg3)
-#define __sc_loadargs_4(name, arg1, arg2, arg3, arg4) \
- __sc_loadargs_3(name, arg1, arg2, arg3);\
- __sc_6 = (unsigned long) (arg4)
-#define __sc_loadargs_5(name, arg1, arg2, arg3, arg4, arg5)\
- __sc_loadargs_4(name, arg1, arg2, arg3, arg4); \
- __sc_7 = (unsigned long) (arg5)
-
-#define __sc_asm_input_0 0 (__sc_0)
-#define __sc_asm_input_1 __sc_asm_input_0, 1 (__sc_3)
-#define __sc_asm_input_2 __sc_asm_input_1, 2 (__sc_4)
-#define __sc_asm_input_3 __sc_asm_input_2, 3 (__sc_5)
-#define __sc_asm_input_4 __sc_asm_input_3, 4 (__sc_6)
-#define __sc_asm_input_5 __sc_asm_input_4, 5 (__sc_7)
-
-#define _syscall0(type,name) \
-type name(void)
\
-{ \
