Am 13.05.14 21:48, schrieb Bernhard Walle:
However, I took the step to update the x86emu code from X.org. That
seems to work! At least with my test VM that is based on Arch Linux.
I'll try the original Gentoo-based VM tomorrow.
That worked, too. :)
I sent a pull request via https://github.com
Am 2014-05-13 07:52, schrieb Bernhard Walle:
Hi,
* Kevin O'Connor ke...@koconnor.net [2014-05-12 22:07]:
On Mon, May 12, 2014 at 08:53:53PM +0200, Bernhard Walle wrote:
Am 2014-05-12 07:29, schrieb Kevin O'Connor:
It does look like the x86emu issue. You can try applying the
SeaVGABIOS
Am 13.05.14 17:41, schrieb Kevin O'Connor:
So, my advice would be to either avoid x86emu (eg, maybe by trying the
vm86 mode of v86d, or maybe by not using uvesafb), try compiling v86d
with a newer version of x86emu, or stick with the lgpl VGA BIOS.
Unfortunately I cannot use vm86 mode
Am 2014-05-12 07:29, schrieb Kevin O'Connor:
It does look like the x86emu issue. You can try applying the
SeaVGABIOS patch below to confirm it.
The output doesn't appear. But I'm sure that I copied the correct files
because modifications of other strings worked.
Regards,
Bernhard
-Kevin
Hi,
* Kevin O'Connor ke...@koconnor.net [2014-05-12 22:07]:
On Mon, May 12, 2014 at 08:53:53PM +0200, Bernhard Walle wrote:
Am 2014-05-12 07:29, schrieb Kevin O'Connor:
It does look like the x86emu issue. You can try applying the
SeaVGABIOS patch below to confirm it.
The output
Am 10.05.14 17:07, schrieb Kevin O'Connor:
Can you run the original SeaVGABIOS image and provide the output with
the following added to the qemu command line:
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
Since it's quite much debugging info, I uploaded it to
Am 2014-05-11 14:37, schrieb Kevin O'Connor:
On Sun, May 11, 2014 at 01:42:57PM +0200, Bernhard Walle wrote:
Am 10.05.14 17:07, schrieb Kevin O'Connor:
Also, it looks like uvesafb can call x86emu. Older versions of x86emu
are known to not emulate some instructions properly, and it has caused
Hello,
I'm using QEmu 2.0.0 on a Linux host (x86-64) with a quite special
target system that uses uvesafb ('video=uvesafb:1024x768-32'). I get
following errors in the target system:
uvesafb: Getting mode info block for mode 0x2 failed (eax=0x4f01, err=1)
uvesafb: Getting mode info block
Am 26.04.12 11:57, schrieb Andreas Färber:
Fixes the build when combined with the drop of darwin-user.
Enthusiasts can still try building it using --enable-bsd-user.
Signed-off-by: Andreas Färber andreas.faer...@web.de
Cc: Bernhard Walle bernh...@bwalle.de
Thanks. I already stumbled over
Am 26.04.12 11:57, schrieb Andreas Färber:
Fixes the build when combined with the drop of darwin-user.
Enthusiasts can still try building it using --enable-bsd-user.
Signed-off-by: Andreas Färber andreas.faer...@web.de
Cc: Bernhard Walle bernh...@bwalle.de
Tested-by: Bernhard Walle bernh
hacky workarounds, which I will
continue to nack.
Regards,
Andreas
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Bernhard Walle bernh...@bwalle.de
Tested-by: Bernhard Walle bernh...@bwalle.de
[Mac OS 10.7.3, executed qemu-system-arm (target: arm-softmmu), compiled
with gcc-apple-4.2, works
Am 26.04.12 14:50, schrieb Andreas Färber:
Am 26.04.2012 12:30, schrieb Bernhard Walle:
Thanks. I already stumbled over this when trying to test your
uint16 fixes (they work for me, BTW).
In that case please add an appropriate tag (e.g., Tested-by) as reply
there (best with info on what
/bwalle/devel/qemu/fpu/softfloat.h:60: error: conflicting types for
'uint16'
/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:73: error:
previous declaration of 'uint16' was here
-- 8 ---
Signed-off-by: Bernhard
13 matches
Mail list logo
