hi,
can anyone provide me some help?
how to boot qemu arm image on i386 target?
i have 2 observations.
1. On qemu-0.8.2, uncompressing starts and then stops at booting kernel.
2. On qemu-0.9.1, nothing happens, no messages on the console.
regards,
sathish.
Meet people who discuss and s
I'm just trying to think of ways to improve, so don't hurt me too much.
What about splitting up the CPU and other functions into their own threads?
The CPU emulation is probably the biggest thing that uses the CPU, the
second biggest the display(?).
From reading the past e-mails, the only thi
Thanks for the tutorial on how to use git bisection ;-)
In fact, whatever version control system you use, I think you spend most of
time recompiling and testing stuff...
Anyway, on the core problem I'm pointing out, does someone have any clue on
what should be done ? Should the revision 1.24 of
Hi,
On Mon, 21 Jan 2008, Fabrice Bellard wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 21 Jan 2008, Fabrice Bellard wrote:
> >
> > > CVSROOT: /sources/qemu
> > > Module name: qemu
> > > Changes by: Fabrice Bellard08/01/21 15:07:18
> > >
> > > Modified files:
> > > .
>
> Still, is there a way to make qemu take advantage of multiple cores? They
> are pretty commonplace in new computers (is there any selling computer that
> doesn't have multiple cores?).
It depends on what you want to do. You could always run two or more
copies of qemu and set up a small networ
Johannes Schindelin wrote:
Hi,
On Mon, 21 Jan 2008, Fabrice Bellard wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard 08/01/21 15:07:18
Modified files:
. : softmmu_header.h
Log message:
fixed register constraint
CVSWeb URLs:
h
On Mon, Jan 21, 2008 at 09:57:54AM -0700, C.W. Betts wrote:
> Still, is there a way to make qemu take advantage of multiple cores? They
> are pretty commonplace in new computers (is there any selling computer that
> doesn't have multiple cores?).
If you've got recent x86 CPUs, then they may wel
Still, is there a way to make qemu take advantage of multiple cores? They
are pretty commonplace in new computers (is there any selling computer that
doesn't have multiple cores?).
- Original Message -
From: "Johannes Schindelin" <[EMAIL PROTECTED]>
To: "C.W. Betts" <[EMAIL PROTECTED]>
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] part
Hi,
On Mon, 21 Jan 2008, C.W. Betts wrote:
> I was thinking, maybe qemu could use threads for at least every
> processor it emulates (on emulated smp computers) and, at the most,
> every single device emulated. This would help users who have multiple
> cores, but it might impact performance o
Hi,
On Mon, 21 Jan 2008, C.W. Betts wrote:
> Builds fine on MinGW gcc 3.4.5
Maybe it was a combination of changes? I don't remember.
Just to make sure, I will recompile and test again, but that will have to
wait until after work.
Ciao,
Dscho
P.S.: do other posters also get that SMTP error w
On Monday 21 January 2008, C.W. Betts wrote:
> I was thinking, maybe qemu could use threads for at least every processor
> it emulates (on emulated smp computers) and, at the most, every single
> device emulated. This would help users who have multiple cores, but it
> might impact performance on t
I was thinking, maybe qemu could use threads for at least every processor it
emulates (on emulated smp computers) and, at the most, every single device
emulated. This would help users who have multiple cores, but it might
impact performance on those of us who don't.
Just an idea I'm throwing
My question is connected with the following:
/* specific usb messages, also sent in the 'pid' parameter */
#define USB_MSG_ATTACH 0x100
#define USB_MSG_DETACH 0x101
#define USB_MSG_RESET0x102
This is some lines, in "usb.h" file in qemu sources. Is this some type of
standard, and where I c
Builds fine on MinGW gcc 3.4.5
- Original Message -
From: "Johannes Schindelin" <[EMAIL PROTECTED]>
To: "Fabrice Bellard" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, January 21, 2008 8:23 AM
Subject: Re: [Qemu-devel] qemu softmmu_header.h
Hi,
On Mon, 21 Jan 2008, Fabrice Bellard wrote:
> Well, what about adding a new backend phase to gcc generating what we
> expect for our purpose? Ok, it is rather easy to have a branch in gcc,
> harder to have it accepted in the main-stream gcc... :-) With a good
> argumentation...
IMHO (as a full time gcc developer) it's easier to just impleme
Hi,
On Mon, 21 Jan 2008, Fabrice Bellard wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Fabrice Bellard08/01/21 15:07:18
>
> Modified files:
> . : softmmu_header.h
>
> Log message:
> fixed register constraint
>
> CVSWeb URLs:
> http:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/21 15:07:18
Modified files:
. : softmmu_header.h
Log message:
fixed register constraint
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qem
> On Mon, 21 Jan 2008 11:18:53 + (GMT), Johannes Schindelin <[EMAIL
> PROTECTED]> said:
Johannes> The miniops right now are implemented as plain C commands.
Johannes> If the "good" gcc guys would not have insisted on not having
Johannes> an option to force the "ret" or "jm
Jérôme PRIOR wrote:
> Hi, qemu 0.9.1 is released, but the changelog is complete ?
>
> On irc I read : use -disc ... so I launch my new qemu and I see lot of
> news options !
>
> Is there other corrections done, not writting on che ChangeLog on the
> site, like better usage of qcow2 ?
Only the mo
> > > As it is, Fabrice's code generator will most likely be something
> > > similar to Paul's qops, which means that you have to invent a
> > > "primitive C" in which to write the miniops, and you will have to
> > > write a backend for _each_ and _every_ host CPU you support.
It's not a terribly
Hi,
On Mon, 21 Jan 2008, Andreas Färber wrote:
> Am 21.01.2008 um 12:18 schrieb Johannes Schindelin:
>
> > The miniops right now are implemented as plain C commands. If the
> > "good" gcc guys would not have insisted on not having an option to
> > force the "ret" or "jmp" statement at the end
Am 21.01.2008 um 12:18 schrieb Johannes Schindelin:
The miniops right now are implemented as plain C commands. If the
"good"
gcc guys would not have insisted on not having an option to force the
"ret" or "jmp" statement at the end of the function, we could use
them for
_all_ processors.
Mark Williamson wrote:
> > > I think it would be great to maintain compatibility with the binary-only
> > > versions of the vm tools though.
> >
> > But you're changing the semantics of the x86 instruction set. You
> > potentially break a real operating system. It also eliminates the
> > possibil
Hi...
On Jan 21, 2008 6:18 PM, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
> As it is, Fabrice's code generator will most likely be something similar
> to Paul's qops, which means that you have to invent a "primitive C" in
> which to write the miniops, and you will have to write a backend for
>
Hi,
On Mon, 21 Jan 2008, Mulyadi Santosa wrote:
> If I may jump into the pool...
>
> > I plan to work around the MinGW issue by guarding the offending part
> > by "#ifdef GCC...", even if I have been told that it works only by
> > chance (but it works, whereas any other option I tried does not
On Jan 21, 2008, at 9:19 AM, Mulyadi Santosa wrote:
On 1/21/08, Alexander Graf <[EMAIL PROTECTED]> wrote:
Hi..
Alexander Graf wrote:
Oops, wrong version :-)
Here we go again...
Bummer! Almost applied that...:) Sure it's the right one? :D
Pretty sure, yes ;-). It still doesn't fix x86_64
On 1/21/08, Alexander Graf <[EMAIL PROTECTED]> wrote:
Hi..
> Alexander Graf wrote:
> Oops, wrong version :-)
>
> Here we go again...
Bummer! Almost applied that...:) Sure it's the right one? :D
regards,
Mulyadi
28 matches
Mail list logo
