On Wed, Mar 12, 2008 at 07:24:54PM -0700, David Barrett wrote:
> Is it possible to compile/run qemu on a system that does not have SDL?
./configure --disable-sdl --disable-gfx-check
Carlo
On Wed, 2008-03-12 at 23:07 +0100, Aurelien Jarno wrote:
>
> We finally found the problem with rtl8139 emulation. The byteswapping
> depending on the target was not done for all registers. The 8139too
> driver was able to cope with that, but not the 8139cp. In his patch
> Hollis addressed the issu
Is it possible to compile/run qemu on a system that does not have SDL?
I assumed this is what --disable-gfx-check does, but it's still giving
me errors (below). The specific error ("The error log from compiling
the libSDL test is") sounds like it's compiling some sort of test -- is
there any
On Thu, Mar 13, 2008 at 01:18:46AM +, Paul Brook wrote:
> > That's the '&' which is wrong here. The string can be accessed with
> > *((uint32_t *)devid). So you can simply use:
> >
> > ret = le32_to_cpu(*((uint32_t *)devid))
>
> No you can't. Even ignoring the aliasing violation, devid
On Mon, Mar 03, 2008 at 11:45:28AM +0100, Hervé Poussineau wrote:
> Attached files fixes some problems with nvram emulation:
> - whole nvram was erased in some conditions
> - fix out of range accesses
> - improve speed by keeping contents in memory
>
> Sorry to not provide a patch for ds1225y.c, bu
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/13 01:19:15
Modified files:
hw : ds1225y.c
Log message:
Convert from DOS to UNIX format, no code change.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ds1225y.c
> That's the '&' which is wrong here. The string can be accessed with
> *((uint32_t *)devid). So you can simply use:
>
> ret = le32_to_cpu(*((uint32_t *)devid))
No you can't. Even ignoring the aliasing violation, devid might not be
sufficiently aligned.
Paul
On Fri, Feb 22, 2008 at 06:16:25AM +0530, Vijay Kumar wrote:
> The mipsnet device returns wrong values for device ID, since it returns
> the contents of the pointer rather that the contents of the device ID
> string. Also the contents of the string is returned such that the order
> is host en
>From 498f162fc9d9fb897c756273c481101a44a220de Mon Sep 17 00:00:00 2001
From: Dor Laor <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 00:11:41 +0200
Subject: [PATCH] Fix sci irq set when acpi timer about to wrap.
The acpi timer should generate sci irq when enabled and
when bit 23 of the timer counter
On Wed, Mar 12, 2008 at 03:38:55PM +0100, Aurelien Jarno wrote:
> On Wed, Mar 12, 2008 at 08:52:00AM -0500, Hollis Blanchard wrote:
> > On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
> > > On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
> > > > On Sat, 2008-03-08 at 14:5
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/12 21:40:02
Modified files:
tcg: README
Log message:
TCG README fixes (Stuart Brady)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.3&r
Hmm. Looks like the latest vmwarevga commits broke *ix/xorg guests.
I tested the 2008-03-11 cvs snapshot with
sidux-2008-01-200803010113-nyx_pre1-kde-lite-i386.iso (debian sid based
Linux livecd) and FreeSBIE-2.0.1-RELEASE.iso (FreeBSD based livecd),
on sidux xorg said:
(WW) INVALID MEM ALLOC
Hi,
The included patch fixes a few glitches in the TCG README file.
Please apply.
Cheers,
--
Stuart Brady
diff -urN qemu-orig/tcg/README qemu-new/tcg/README
--- qemu-orig/tcg/README2008-02-04 11:21:46.0 +
+++ qemu-new/tcg/README 2008-03-12 19:50:19.0 +
@@ -223,10
Implement sysrq for the pl011. This was tested on
the ARM Versatile AB + kernel.org 2.6.X kernel.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
---
hw/pl011.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/hw/pl011.c
+++ b/hw/pl011.c
@@ -208,7 +208,24 @@ s
On Wed, Mar 12, 2008 at 08:52:00AM -0500, Hollis Blanchard wrote:
> On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
> > On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
> > > On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
> > > > On Fri, Mar 07, 2008 at 11:23:51
Alexander Graf wrote:
On Mar 12, 2008, at 5:57 AM, Anthony Liguori wrote:
Aurelien Jarno wrote:
On Thu, Jan 31, 2008 at 06:31:09PM +0100, Alexander Graf wrote:
Is it really necessary to have *that much* assembly code within
hw/pc.c?
I would rather see multiboot support as a small image ge
On Tue, 2008-03-11 at 23:49 +0100, Aurelien Jarno wrote:
> On Sat, Mar 08, 2008 at 11:08:48AM -0600, Hollis Blanchard wrote:
> > On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
> > > On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
> > > > Below is a patch I'm using to fi
On Mar 12, 2008, at 5:57 AM, Anthony Liguori wrote:
Aurelien Jarno wrote:
On Thu, Jan 31, 2008 at 06:31:09PM +0100, Alexander Graf wrote:
Is it really necessary to have *that much* assembly code within hw/
pc.c?
I would rather see multiboot support as a small image generated from
C and/or
On Mar 12, 2008, at 12:44 AM, Aurelien Jarno wrote:
On Thu, Jan 31, 2008 at 06:31:09PM +0100, Alexander Graf wrote:
On Jan 31, 2008, at 10:58 AM, Kevin Wolf wrote:
Hi,
I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:
19 matches
Mail list logo
