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
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
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 mos
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.
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
Paul Brook 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
> >
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 <=
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 pr
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
> > 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 area
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
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 B&W G3, just enough to interpret the CHRP script in /System
Fol
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
___
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
> > 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 Schi
> 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 impl
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 curre
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?
> > 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 p
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 distr
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
> M
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 lic
> 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.
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,
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
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 ha
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
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 righ
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?
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 Int
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@nongn
> 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
> 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
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 Qe
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 -ker
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?
Please talk about it.
___
36 matches
Mail list logo