On Feb 11, 2008 11:18 PM, Felipe Contreras <[EMAIL PROTECTED]> wrote:
> Hi,
>
> There's something wrong with the commit
> edbcc0b2eb1d4caee5f293e5c79f81023f3394e2.
Err, by that I meant:
http://repo.or.cz/w/qemu.git?a=commitdiff;h=edbcc0b2eb1d4caee5f293e5c79f81023f3394e2
Sorry, I'm spoiled by git.
On Feb 12, 2008 10:12 PM, Blue Swirl <[EMAIL PROTECTED]> wrote:
> On 2/12/08, Igor Kovalenko <[EMAIL PROTECTED]> wrote:
> > This patch separates decision about storing temporaries in env
> > structure from target long size by introducing a macro
> > QEMU_TEMPORARY_IN_ENV
> > Makes it a bit easier t
On 2/12/08, Igor Kovalenko <[EMAIL PROTECTED]> wrote:
> This patch separates decision about storing temporaries in env
> structure from target long size by introducing a macro
> QEMU_TEMPORARY_IN_ENV
> Makes it a bit easier to work around register allocation problems.
> By default there is no chang
The patch below uses the float32 and float64 types instead of the float
and double types in the PPC code. This doesn't change anything when
using softfloat-native as the types are the same, but that helps
compiling the PPC target with softfloat.
It also defines a new union CPU_FloatU in addition t
The patch below changes the way to enable softfloat on the PPC target. It
is now enabled when softfloat is used. The rationale behind this change
is that ones who want precise emulation prefer precision over emulation
speed.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
---
target-ppc/exec.h
Alexander Graf wrote:
> This is a resend of a mail I sent to the list on 2008/02/06. I felt it
> rather disturbing, yet normal that nobody cared about Mac OS X host
> support, but this concerns all x86 host OSs, so I believe this deserves
> some discussion.
>
> Hi,
>
> I've been trying to get the
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 08/02/12 21:01:26
Modified files:
. : gdbstub.c
linux-user : main.c signal.c syscall.c
linux-user/mips: target_signal.h
linux-user/mips64: target_signal.h
Hi,
I don't know what I'm doing but this seems to fix the weird issue I was having.
http://article.gmane.org/gmane.comp.emulators.qemu/23314
I've found out that this happens on linux 2.6.23, but not 2.6.24.
Cheers.
--
Felipe Contreras
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 62
This patch separates decision about storing temporaries in env
structure from target long size by introducing a macro
QEMU_TEMPORARY_IN_ENV
Makes it a bit easier to work around register allocation problems.
By default there is no change to generated code.
--
Kind regards,
Igor V. Kovalenko
qemu
Hi all,
I have a board based on the IMX21 (ARM926EJ-S) and I know qemu can
emulate that processor. my board has 64MB SDRAM and 64MB NAND Flash. First,
I want to be
able to boot Linux and I will try to emulate the rest of the peripherals
later. I'm trying to figure out
which files to modified and wh
On 2/12/08, Hervé Poussineau <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Attached patch fixes some issues in the floppy disk controller:
> - Enhance reset support (external and software)
> - Use MAX_FD constant when possible
> - Support up to 4 drives if MAX_FD is set to 4
> - Fix DOR register, which shou
The patch below adds isfinite() and isnormal() functions which can
work with float64 type, used when CONFIG_SOFTFLOAT=yes.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
---
target-ppc/op_helper.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/tar
Hi,
Attached patch fixes some issues in the floppy disk controller:
- Enhance reset support (external and software)
- Use MAX_FD constant when possible
- Support up to 4 drives if MAX_FD is set to 4
- Fix DOR register, which should be writable at any time
- Let MSR return 0x20 when non-DMA transf
Hi,
Attached patch fixes some issues in the floppy disk controller:
- Enhance reset support (external and software)
- Use MAX_FD constant when possible
- Support up to 4 drives if MAX_FD is set to 4
- Fix DOR register, which should be writable at any time
- Let MSR return 0x20 when non-DMA transf
When I try to compile qemu on MinGW gcc 3.4.5 using -march=i686 or higher, or
use -msse, the helper.c file on the i386 (but not the x86_64 target, for some
odd reason) spits out
C:/msys/1.0/home/Owner/SoureCode/qemu/target-i386/helper.c: In function
`svm_check_intercept_param':
C:/msys/1.0/home
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> If you mean the one at repo.or.cz and the one at kernel.dk, no. They
> contain exactly the same history.
You're right. I hadn't checked. My own mirror generated with
git-cvsimport is incompatible with both of co
Hi,
On Tue, 12 Feb 2008, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled
> do?"):
> > On Tue, 12 Feb 2008, Ian Jackson wrote:
> > > At the very least we need one drcs branch containing only changes
> > > from the upstream cvs. It has to be increme
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> On Tue, 12 Feb 2008, Ian Jackson wrote:
> > At the very least we need one drcs branch containing only changes from
> > the upstream cvs. It has to be incrementally updated, automatically
> > and frequently, and gene
Hi,
On Tue, 12 Feb 2008, Ian Jackson wrote:
> * In the meantime, or if upstream decide not to, what is the best way
>for non-upstream contributors to collaborate with each other ?
>
> [...]
>
> What should those of us who want to collaborate using a drcs (so that we
> can share our work-in
> If people don't like using environmental variables, I can accept that.
> Let's not pretend though that the reason is that we're protecting the
> end users :-)
It's more protecting me from end users :-)
I should have said part of the reason. I'll admit a large part is personal
preference.
Paul
Hi,
Am 12.02.2008 um 12:15 schrieb Johannes Schindelin:
On Tue, 12 Feb 2008, Paul Brook wrote:
Any news on the possible cvs->svn migration?
To be perfectly honest, IMO there is little point moving an existing
project from CVS to SVN.
I disagree. CVS has several fairly fundamental flaws (
It seems to me that there are two questions here:
* Should the CVS for the upstream repository be replaced with
something else ?
* In the meantime, or if upstream decide not to, what is the best way
for non-upstream contributors to collaborate with each other ?
The answer to the first qu
> : > > Any news on the possible cvs->svn migration?
> : >
> : > To be perfectly honest, IMO there is little point moving an existing
> : > project from CVS to SVN.
> :
> : I disagree. CVS has several fairly fundamental flaws (no global revision
> : IDs, unable to move files, and more subtle prob
Hi,
I did not really want to continue this discussion, but then, I really
cannot let certain statements slip by. *sigh*
On Tue, 12 Feb 2008, Paul Brook wrote:
> > > Any news on the possible cvs->svn migration?
> >
> > To be perfectly honest, IMO there is little point moving an existing
> > pro
This is a resend of a mail I sent to the list on 2008/02/06. I felt it
rather disturbing, yet normal that nobody cared about Mac OS X host
support, but this concerns all x86 host OSs, so I believe this
deserves some discussion.
Hi,
I've been trying to get the new TCG approach running on an
25 matches
Mail list logo
