On 13/08/12 15:16, Anthony Liguori wrote:
I understand what your objection is but it's unreasonable IMHO. The
purpose of QOM is to bring consistency across large swaths of code in
QEMU that have historically done things there own way.
This means expressing concepts like inheritence and casting
On 13/02/13 22:58, Alexander Graf wrote:
This reverts commit 10442558ab1797bfbb01285b909e34c5cf038f12.
With the updated OpenBIOS image, -M g3beige fails to boot quik.
Hi Alex,
Can you point me towards a test ISO image for this? There are so many
other PPC fixes in OpenBIOS worth having that
On 13/02/13 23:45, Alexander Graf wrote:
The release is basically done. I don't think we have time for any fix beyond
reverting the commit. And I'd rather have it reverted, since we regress heavily
against 1.3 with the updated OpenBIOS.
[12:43am]aliguori:agraf, i can wait until the very star
On 14/02/13 00:17, Alexander Graf wrote:
With the following patch fixing the issue at hand for me. Though I don't fully
understand why str would be NULL yet:
diff --git a/packages/mac-parts.c b/packages/mac-parts.c
index a286870..443455e 100644
--- a/packages/mac-parts.c
+++ b/packages/mac-pa
Hi all,
I've just updated my QEMU git pull to master in order to do some
testing, and I'm noticing a regression with 32-bit framebuffers on PPC.
If I load QEMU with the following command line to force a 32-bit
framebuffer then the light yellow OpenBIOS background now appears as a
bright gari
On 15/02/13 13:11, Alexander Graf wrote:
Yes, I see the same thing on PPC hosts. So far I assumed it was due to my
ancient pixman version, but maybe it's not related to that after all.
Does it work with SDL?
Yes - it looks as if SDL is fine, and it's just VNC that is broken. A
session with
On 18/02/13 10:31, Gerd Hoffmann wrote:
In case host and guest endianness differ the vga code first creates
a shared surface (using qemu_create_displaysurface_from), then goes
patch the surface format to indicate that the bytes must be swapped.
The switch to pixman broke that hack as the format
On 16/02/13 15:36, Blue Swirl wrote:
Check if xsltproc and Sparc32, Sparc64 and PPC compilers
are available. If found, rebuild OpenBIOS ROMs from submodule.
Signed-off-by: Blue Swirl
If possible, can we also fix the automatic git svn sync with OpenBIOS
SVN for openbios.git on qemu.org? It us
Hi all,
Whilst running through some OpenBIOS tests, I came across the following
segfault in qemu-system-ppc with -M mac99 on git master. It is
consistently reproducible here with my test openSUSE image although
strangely all my other images seem to run fine. The host is running
amd64 Debian W
On 24/02/13 12:14, Andreas Färber wrote:
Have you tried a revision before my macio refactoring? It changed which
IDE code paths are taken.
Hi Andreas,
It's a git pull as of a few hours ago (commit
a345481baa2b2fb3d54f8c9ddb58dfcaf75786df) if that helps?
Many thanks,
Mark.
On 24/02/13 12:44, Andreas Färber wrote:
The commit you reference does nothing with block or IDE but with mips,
so is very unlikely to be the cause.
I was asking if you have narrowed down whether this is a regression or
not. If so then a git-bisect would hopefully give us some more insight.
(
On 24/02/13 19:29, Mark Cave-Ayland wrote:
If you try booting the openSUSE ISO mentioned in my previous email then
the crash occurs at some point during the "Starting udev..." prompt.
With a manual review of that particular commit, I managed to spot that
it was just a typing error
Commit 07a7484e5d713f1eb7c1c37b18a8ab0d56d88875 accidentally introduced a bug
in the initialisation of the second macio DMA device which could cause some
DMA operations to segfault QEMU.
CC: Andreas Färber
Signed-off-by: Mark Cave-Ayland
---
hw/macio.c |2 +-
1 file changed, 1 insertion
Forth) at the base address of each slot, and if
present executes it so that it creates its own device node in the
OpenBIOS device tree.
The FCode ROM is generated as part of the OpenBIOS build and should
generally be updated at the same time.
Signed-off-by: Mark Cave-Ayland
CC: Blue Swirl
CC
On 20/08/13 23:41, Peter Maydell wrote:
On 20 August 2013 23:25, Mark Cave-Ayland wrote:
Upstream OpenBIOS now implements SBus probing in order to determine the
contents of a physical bus slot, which is required to allow OpenBIOS to
identify the framebuffer without help from the fw_cfg
On 21/08/13 16:34, Peter Maydell wrote:
Unfortunately the OpenBIOS repository is still based in SVN :( There is a
git-svn mirror on git.qemu.org, but currently it needs to be manually
updated and so is generally not particularly helpful. For the 1.6 release I
got Anthony to manually update the
On 21/08/13 18:54, Andreas Färber wrote:
Shouldn't this blob come in the same patch as an update to some
git module, so that we keep track of the sources used to build
the blob?
I concur. Independent of how to order the .gitmodules update, this patch
is missing Makefile support to actually cop
On 21/08/13 18:06, Peter Maydell wrote:
Okay so in that case what is the best way to manage to process? If both this
and the follow-up patchset are committed first without the associated FCode
ROM images then qemu-system-sparc will be broken until the main OpenBIOS
images are updated because (qu
On 24/08/13 18:46, Andreas Färber wrote:
Am 21.08.2013 20:52, schrieb Mark Cave-Ayland:
On 21/08/13 18:54, Andreas Färber wrote:
Shouldn't this blob come in the same patch as an update to some
git module, so that we keep track of the sources used to build
the blob?
I concur. Independe
On 22/09/14 08:15, Fam Zheng wrote:
This fixes the bug introduced by commit c6ac36e (vmdk: Optimize cluster
allocation).
$ ~/build/master/qemu-io /stor/vm/arch.vmdk -c 'write 2G 1k'
write failed: Invalid argument
Reported-by: Mark Cave-Ayland
Signed-off-by: Fam Zheng
Unfortunate
On 13/09/14 11:10, Mark Cave-Ayland wrote:
The S24/TCX framebuffer is a mildly accelerated video card with
blitter, stippler and hardware cursor.
* Solaris and NetBSD 6.x use all the hardware acceleration features
* The Xorg driver (used by Linux) can use the hardware cursor only
This patch
3:14 +0100)
tcx: Implement hardware acceleration
----
Mark Cave-Ayland (1):
tcx: Implement hardware acceleration
hw/display/tcx.c | 677 --
hw/spa
nges up to 1862ed02dfe69d8972641b35495669cc5d4d97c2:
Update OpenBIOS images (2014-09-25 13:34:03 +0100)
Update OpenBIOS images
----
Mark Cave-Ayland (1):
Update OpenBIOS images
pc-bios/QEMU,tcx.bin
Hi everyone,
Has FW_CFG_PPC_CPUFREQ been removed from QEMU for some reason? I noticed
that the value always comes back as 0 in OpenBIOS, and it looks as if
the FW_CFG_PPC_CPUFREQ constant (FW_CFG_ARCH_LOCAL + 0x4) has been
removed from hw/ppc.h?
ATB,
Mark.
On 14/04/13 10:38, Artyom Tarasenko wrote:
Do you have an example kernel .config and qemu command line showing how to
use virtio for those? (Or a working sparc64 image you can point me to?)
Yes. Will send it to you as I get to my home machine. Can you make them
available on your site?
Note t
On 22/03/13 05:19, Rob Landley wrote:
If I do this:
qemu-system-sparc -nographic -no-reboot -kernel image -hda hda.sqf
-append 'root=/dev/sda rw init=/sbin/init.sh panic=1
PATH=/usr/distcc:/bin:/sbin console=ttyS0 HOST=sparc CPUS=1
DISTCC_HOSTS=10.0.2.2:31322/1 FTP_SERVER=10.0.2.2 FTP_PORT=3130
On 19/04/13 16:31, Alexander Graf wrote:
Hi everyone,
Has FW_CFG_PPC_CPUFREQ been removed from QEMU for some reason? I noticed that
the value always comes back as 0 in OpenBIOS, and it looks as if the
FW_CFG_PPC_CPUFREQ constant (FW_CFG_ARCH_LOCAL + 0x4) has been removed from
hw/ppc.h?
In
Thanks for the bug report!
This was a slight bug in the interpose logic within the OpenBIOS disk-
label package - we were always interposing a partition package if we
could detect a valid partition magic. In actual fact the interpose
should only happen when no arguments are specified when opening
On 09/06/14 15:19, Stefan Weil wrote:
Hi Stefan,
The array regs is declared with IOMMU_NREGS (3) elements and accessed
using IOMMU_CTRL (0) and IOMMU_BASE (8). In most cases, those values
are right shifted before being used as an index which results in indices
0 and 1. In one case, this right s
On 09/06/14 15:19, Stefan Weil wrote:
The array regs is declared with IOMMU_NREGS (3) elements and accessed
using IOMMU_CTRL (0) and IOMMU_BASE (8). In most cases, those values
are right shifted before being used as an index which results in indices
0 and 1. In one case, this right shift was mis
On 04/06/14 13:44, Alexander Graf wrote:
From: Mark Cave-Ayland
Currently the macio DMA routines assume that all DMA requests are for read/write
block transfers. This is not always the case for ATAPI, for example when
requesting a TOC where the response is generated directly in the IDE buffer
On 20/06/14 20:17, BALATON Zoltan wrote:
On Fri, 20 Jun 2014, Mark Cave-Ayland wrote:
Zoltan, please can you test the attached patch to see if this still
allows MorphOS to boot?
Unfortunately it seems MorphOS cannot boot with this patch. It hangs
while trying to read the TOC from the CD
://github.com/mcayland/qemu.git qemu-openbios
for you to fetch changes up to 871c60a7368dbfcb7b2620b0483eed8305fd7b6b:
Update OpenBIOS images (2014-06-20 23:59:19 +0100)
Mark Cave-Ayland (1):
Update OpenBIOS images
pc-bios
Hi Peter,
This update contains Stefan's fix for an out-of-bounds array access on apb.
Please pull.
ATB,
Mark.
The following changes since commit 427e1750a0b98a72cad424327604f51e993dcc5f:
gt64xxx_pci: Add VMStateDescription (2014-06-20 23:40:16 +0200)
are available in the git repository at
On 23/06/14 20:25, BALATON Zoltan wrote:
It's how OpenBIOS assigns MMIO addresses to pci devices. It does it
by going through them in order and map them starting from the base
address (with some allingment). I guess you could look at
drivers/pci.c I think it's in there somewhere.
I think it'd
On 23/06/14 20:26, BALATON Zoltan wrote:
(add Kevin to CC)
I'm afraid as you're the only person that can boot MorphOS this far
then we need you to diagnose and suggest a suitable alternative by
comparing the before and after output. Since MacOS is already a
supported client then if no solution
On 23/06/14 23:03, BALATON Zoltan wrote:
Change the order of creating devices for New World Mac emulation so
that devices on the motherboard are added first and PCI cards (VGA and
NIC) come later. As a side effect, this also causes OpenBIOS to map
the motherboard devices into the MMIO space to t
, addr, 3);
break;
}
Great work! I can confirm that this does indeed allow NetBSD SPARC64 to
boot in my tests here.
Tested-by: Mark Cave-Ayland
I'd be happy to take this through my qemu-sparc tree if Richard/Blue can
give a Reviewed-by.
ATB,
Mark.
The IOMMU flush register is a write-only register used to remove entries from
the
hardware TLB. Allow guest writes to this register as a no-op, and return a value
of 0 for reads.
This fixes IOMMU DMA operations under NetBSD SPARC64.
Signed-off-by: Mark Cave-Ayland
---
hw/pci-host/apb.c | 12
On 11/08/14 16:12, Stefan Hajnoczi wrote:
On Fri, Aug 08, 2014 at 05:23:36PM +0100, Mark Cave-Ayland wrote:
@@ -322,6 +342,10 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
}
/* Set write-to-clear interrupt bits */
+dev->wmask[CFR] = 0x0;
+dev->w1cma
ff-by: Artyom Tarasenko
Tested-by: Mark Cave-Ayland
---
With this patch applied on top of cmd646 patches it's possible to install
and boot NetBSD 6.1.4 /sparc64.
Changes from v0: corrected the comment messages, it's store, not load.
Reviewed-by: Richard Henderson
Thanks! I've app
13:24:27 +0100)
Artyom Tarasenko (1):
target-sparc64: implement Short Floating-Point Store Instructions
Mark Cave-Ayland (2):
sun4u: switch second PCI-ebus bridge BAR over to PCI IO space
apb: add IOMMU flush register implementation
hw/pci-host/apb.c
Hi Jakub,
Thanks for the test case. I've just done a git bisect using your test
image above and it seems as if the offending commit is this:
commit 2c7ffc414d8591018248b5487757e45f7bb6bd3c
Author: Peter Maydell
Date: Tue Apr 15 19:18:40 2014 +0100
target-arm: Fix VFP enables for AArch32
Hi Waldemar,
An update on this bug: it seems there is a problem with QEMU's block AIO
code which seems to be easily triggerable with virtio. I think it's be
identified within recent discussions on the mailing list, but I don't
believe a patch has been committed to resolve the issue.
Note that as
HI Waldemar,
Glad that you now have something that works for you.
I've tried to reproduce your virtio hang this morning with multiple 100%
CPU and "find / -name 'foo'" processes running but I can't seem to get
virtio to hang on my system here.
Since this is the second report I've had of this pro
This patchset contains a couple of extra apb PCI fixes for bugs found whilst
trying to boot *BSDs on SPARC64.
With these patches qemu-system-sparc64 can now boot OpenBSD in -nographic
mode.
Signed-off-by: Mark Cave-Ayland
Mark Cave-Ayland (2):
apb: add implementation of UltraSPARC IIi PCI
FreeBSD SPARC64 checks the value of this register on boot in order to calculate
the DVMA base address.
Signed-off-by: Mark Cave-Ayland
---
hw/pci-host/apb.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/pci-host/apb.c b/hw/pci-host/apb.c
index 60bd81e..3b7fb13 100644
Both OpenBSD and FreeBSD SPARC64 attempt to read the interrupt map from the
hardware and will fail if the correct ino isn't present.
Signed-off-by: Mark Cave-Ayland
---
hw/pci-host/apb.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/pci-host/ap
4-08-26 13:52:15 +0100)
----
Mark Cave-Ayland (1):
Update OpenBIOS images
pc-bios/openbios-ppc | Bin 734012 -> 746588 bytes
pc-bios/openbios-sparc32 | Bin 381512 -> 381512 bytes
pc-bios/openbios-sparc64 | Bin 1616768
Due to the OpenBIOS ROM being larger than OBP, it is currently unable to
allocate enough memory for the larger 1152x900 framebuffer (and sadly
it's not a simple fix to shrink down the memory requirements).
Fortunately if you are using the real Sun ROM ss5.bin then you can just
use a real Sun cgthr
Hi all,
When creating a qemu-system-sparc64 machine with a virtio interface,
both QEMU 2.1.0 and current git master emit the above warning:
$ ./qemu-system-sparc64 -drive file=/tmp/file.txt,if=virtio,index=0
-nographic
qemu-system-sparc64: -drive file=/tmp/file.txt,if=virtio,index=0: unable
Currently the graphics resolution for TCX is fixed at 1024x768, however
other framebuffers are capable of supporting additional resolutions.
Signed-off-by: Mark Cave-Ayland
CC: Anthony Liguori
CC: Blue Swirl
---
hw/sparc/sun4m.c |4
1 file changed, 4 insertions(+)
diff --git a/hw
Hi Jan/Paolo,
I've just updated my local QEMU repository to git master for OpenBIOS
testing and it seems that the ioport changes break SPARC64. git bisect
points to this commit:
commit b40acf99bef69fa8ab0f9092ff162fde945eec12
Author: Jan Kiszka
Date: Mon Jun 24 10:45:09 2013 +0200
io
On 27/07/13 09:55, Paolo Bonzini wrote:
Il 27/07/2013 00:21, Mark Cave-Ayland ha scritto:
I suspect that there may be multiple breakages here (as HEAD blows up
differently with a trap failure), but this is definitely the start of
the chain.
Yes, the fixes so far are the following:
commit
any other target. 32-bit Sparc and PPC all use memory-mapped fw_cfg.
Reported-by: Mark Cave-Ayland
Signed-off-by: Paolo Bonzini
---
hw/nvram/fw_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 0a35015..d0820e5 100644
--- a/hw
ysbus-fdc both inherit from an
abstract type base-sysbus-fdc.
This allows to consolidate realizefns by using instance_init functions.
Clean up variable names and variable order while at it.
Reported-by: Mark Cave-Ayland
Cc: Hu Tao
Signed-off-by: Andreas Färber
Hi Andreas,
I can confirm that
to 9a949b94f60ee48ca0fbb5dc263c7ee77b75149f:
Update OpenBIOS images (2013-07-30 23:11:07 +0100)
Mark Cave-Ayland (1):
Update OpenBIOS images
pc-bios/README |4 ++--
pc-bios/openbios-ppc | Bin 733972
On 01/08/13 23:08, Anthony Liguori wrote:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 1.6 release. This release is meant
for testing purposes and should not be used in a production environment.
http://wiki.qemu.org/downloa
On 07/05/14 20:56, Paolo Bonzini wrote:
Il 05/03/2014 11:05, Paolo Bonzini ha scritto:
Il 19/02/2014 10:05, Mark Cave-Ayland ha scritto:
+#define CG3_REG_SIZE0x20
+
+#define CG3_REG_FBC_CTRL0x10
+#define CG3_REG_FBC_STATUS 0x11
+#define CG3_REG_FBC_CURSTART0x12
On 10/05/14 13:30, BALATON Zoltan wrote:
That patch would be 80fc95d8bdaf3392106b131a97ca701fd374489a in QEMU
master. I've tried reverting it and Darwin still boots (without -M
mac99) up to the point where it asks to install as before but I don't
know how good a test is this as I'm not sure it d
On 12/05/14 20:32, BALATON Zoltan wrote:
On Mon, 12 May 2014, Mark Cave-Ayland wrote:
On 10/05/14 13:30, BALATON Zoltan wrote:
That patch would be 80fc95d8bdaf3392106b131a97ca701fd374489a in QEMU
master. I've tried reverting it and Darwin still boots (without -M
mac99) up to the point
On 14/05/14 00:02, BALATON Zoltan wrote:
command 0x43 is read the TOC which according to atapi_cmd_table should
call cmd_read_toc_pma_atip(). You can see that in your MorphOS case
you are getting a line with a "atapi_cmd_error" prefix which indicates
that something is calling ide_atapi_cmd_error
On 14/05/14 12:10, BALATON Zoltan wrote:
I've tried doing this and it seems that the cmd_read_toc_pma_atip
function returns all right (via the case 0 path) with a 20 byte result
array and calls ide_atapi_cmd_reply which takes the DMA path as
s->atapi_dma is set to 1 and the error comes from some
On 15/05/14 06:41, sonia verma wrote:
Hi
I'm getting below error when trying to boot the KVM with ethernet
bridging,kvm support and universel TUN enabled by the following command..
/usr/bin/qemu-system-ppc64 -m 512 -nographic -hda
/var/volatile/debian_lenny_
powerpc_standard.qcow2
FWIW I thi
On 15/05/14 00:21, BALATON Zoltan wrote:
Which part is it that's still confusing you? Putting breakpoints on
pmac_ide_transfer() and pmac_ide_atapi_transfer_cb() will show you the
iterations on each DMA request (be sure to compare against a "known
good" example to understand how it should work f
On 15/05/14 11:01, sonia verma wrote:
Hi Mark
I tried booting KVM using qemy-system-ppc with your suggesstion but
ended up stucking at below logs..
/usr/bin/qemu-system-ppc -m 512 -nographic -hda
kvm/debian_lenny_powerpc_standard.qcow2
qemu-system-ppc: pci_add_option_rom: failed to find romfil
On 15/05/14 11:50, sonia verma wrote:
Hi Mark
The gcc version I'm using is 4.8.1 .
It is not working with the standard Qemu.
Unfortunately if it doesn't work with standard QEMU then it sounds as if
there is something wrong with either your OpenBIOS binary or build
environment.
The debian_
On 15/05/14 18:28, BALATON Zoltan wrote:
If you place a breakpoint on pmac_ide_transfer() then its invocation
of pmac_ide_atapi_transfer_cb() should be the first iteration which
sets up the DMA request, and the second invocation should be the
(failing) callback from the dma_bdrv_*() functions. B
On 15/05/14 21:28, BALATON Zoltan wrote:
On Thu, 15 May 2014, BALATON Zoltan wrote:
On Thu, 15 May 2014, BALATON Zoltan wrote:
confusing.) Do you think that replacing io->len in your patch with
s->io_buffer_size would be the correct thing to do?
That looks reasonable, as the MIN() will help
specified in the
command) and copy the results directly into RAM as indicated by the DBDMA
descriptor. This fixes CDROM access under MorphOS.
Signed-off-by: Mark Cave-Ayland
---
hw/ide/macio.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/hw/ide/macio.c b/hw/ide/macio.c
Hi all,
I've been working on debugging a window-related OpenBIOS issue and
noticed that the cwp register logic in QEMU appears to be backwards
according to the SPARCv9 specification. From sections 6.3.6.1 and 6.3.6.2:
"The SAVE instruction allocates a new register window and saves the
caller
On 18/05/14 17:06, Olivier Danet wrote:
The problem may be related to the fact that the 32bits SPARCv8 and 64bits
SPARCv9 work in opposite directions !
SparcV9 standard, page 360/399 :
The SPARC-V9 CWP register is incremented during a SAVE instruction and
decremented during
a RESTORE instruct
On 08/05/14 15:34, Andreas Färber wrote:
Hi,
Am 19.02.2014 22:39, schrieb Mark Cave-Ayland:
On 19/02/14 13:35, Leandro Dorileo wrote:
Hi Leandro,
+static void cg3_realizefn(DeviceState *dev, Error **errp)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+CG3State *s = CG3(dev
anges.
Signed-off-by: Mark Cave-Ayland
Mark Cave-Ayland (4):
cg3: move initialisation from realizefn to initfn
cg3: add extra check to prevent CG3 register array overflow
tcx: move initialisation from SysBusDevice class to TCX class
realizefn
tcx: move initialisation from realizefn to i
Initialisation cleanup as suggested by Andreas.
Signed-off-by: Mark Cave-Ayland
CC: Andreas Färber
---
hw/display/cg3.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index f5a8299..cd9297d 100644
--- a/hw
Initialisation cleanup as suggested by Andreas.
Signed-off-by: Mark Cave-Ayland
CC: Andreas Färber
---
hw/display/tcx.c | 46 --
hw/sparc/sun4m.c | 10 +-
2 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/hw/display/tcx.c b
This is an intermediate step to bring TCX in line with CG3.
Signed-off-by: Mark Cave-Ayland
CC: Andreas Färber
---
hw/display/tcx.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 2551b67..8fc4e38
- 1, but it seems worth clarifying this for
future review and/or static analysis.
Signed-off-by: Mark Cave-Ayland
CC: Paolo Bonzini
---
hw/display/cg3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index cd9297d..65ef7a7 100644
On 16/02/14 23:15, Olivier Danet wrote:
The S24/TCX framebuffer is a mildly accelerated video card, with
blitter, stippler and hardware cursor.
* Solaris and NetBSD 6.x use all the hardware acceleration features.
* The Xorg driver (used by Linux) can use the hardware cursor only.
This patch imp
On 25/05/14 14:20, Olivier Danet wrote:
Here is the original patch, I have changed email settings since then, it should
work better.
Alas, I have not merged latest QEMU changes (your CG3/TCX patches), so it will
probably not compile as-is...
Thanks for this - don't worry about my latest patc
On 25/10/14 20:16, P. Wilhelm wrote:
> In late May of 2011, Brian Vandenberg queried this group about failures
> he was having trying to install Solaris 8 SPARC 02/04 on a Qemu VM. The
> interaction seemed to have ended with Blue Swirl indicating that Brian
> should run with “-d in_ascm,int” and t
On 27/08/14 07:15, Mark Cave-Ayland wrote:
Hi all,
When creating a qemu-system-sparc64 machine with a virtio interface,
both QEMU 2.1.0 and current git master emit the above warning:
$ ./qemu-system-sparc64 -drive file=/tmp/file.txt,if=virtio,index=0
-nographic
qemu-system-sparc64: -drive
Hi all,
I've had a couple of reports of virtio hangs with qemu-system-sparc64
from QEMU 2.1 and I've recently been given access to one of the systems
in question for testing since I've been unable to reproduce it locally
myself.
After some initial investigations, it seems that the following
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1278977
Title:
qemu-system-sparc64 crash when initializing disk
Status in QEMU:
Fix Released
On 02/09/14 14:17, Richard Henderson wrote:
On 09/02/2014 04:52 AM, Peter Maydell wrote:
Peter Maydell (3):
target-sparc: Remove unused gen_op_subi_cc and gen_op_addi_cc
target-sparc: address_mask(), asi_address_mask() are TARGET_SPARC64
only
target-sparc: is_translating_asi() is
On 28/08/14 12:33, Artyom Tarasenko wrote:
On Mon, Aug 25, 2014 at 7:58 PM, Mark Cave-Ayland
wrote:
FreeBSD SPARC64 checks the value of this register on boot in order to calculate
the DVMA base address.
Signed-off-by: Mark Cave-Ayland
---
hw/pci-host/apb.c | 11 +++
1 file
06:07:12
+0100)
apb: implement PCI bus error interrupt map registers
----
Mark Cave-Ayland (1):
apb: implement PCI bus error interrupt map registers
hw/pci-ho
Hi all,
I've been trying to convert a raw disk partition from my laptop for use
on VMWare player and I'm seeing the following error from qemu-img git
master during conversion:
# qemu-img convert -f raw -O vmdk /dev/mapper/vm-raw out.vmdk
qemu-img: error while writing sector 4247552: Invalid a
and 24 bit
modes. It is based on the NetBSD driver sources and from tests with
Solaris.
Signed-off-by: Olivier Danet
Signed-off-by: Mark Cave-Ayland
---
hw/display/tcx.c | 677 --
hw/sparc/sun4m.c | 56 +++--
2 files changed, 596 insertions
On 13/07/14 17:17, Alexander Graf wrote:
While trying to get Mac OS X booting with our -M mac99 emulation I stumbled
over a few issues that prevented it from doing so.
With these patches applied I still can't properly boot Mac OS X with -M mac99,
but I get a lot further than before. The biggest
On 13/07/14 21:36, Alexander Graf wrote:
Mac OS X calibrates a number of frequencies on bootup based on reading
tb values on bootup and comparing them to via cuda timer values.
The only variable we can really steer well (thanks to KVM) is the cuda
frequency. So let's use that one to fake Mac OS
On 14/07/14 15:00, Alexander Graf wrote:
On 14.07.14 15:58, Mark Cave-Ayland wrote:
On 13/07/14 17:17, Alexander Graf wrote:
While trying to get Mac OS X booting with our -M mac99 emulation I
stumbled
over a few issues that prevented it from doing so.
With these patches applied I still
On 14/07/14 19:19, Dennis Luehring wrote:
i've followed the avices on Artyom Tarasenko's blog to install debian
wheezy sparc on qemu
but qemu won't boot the graphical installation
with -nographic the debian default installation seems to work
is this a known bug?
these are my installation step
On 17/07/14 07:43, Dennis Luehring wrote:
Am 16.07.2014 00:21, schrieb Mark Cave-Ayland:
At the moment my work is focused on getting the basic system emulation
up and running, so I haven't spent much time looking at the graphics
side at all.
I have noticed that the kernel falls back t
On 18/07/14 07:06, Dennis Luehring wrote:
Am 18.07.2014 00:22, schrieb Mark Cave-Ayland:
On 17/07/14 07:43, Dennis Luehring wrote:
> Am 16.07.2014 00:21, schrieb Mark Cave-Ayland:
>> At the moment my work is focused on getting the basic system emulation
>> up and running, so
On 01/08/14 23:33, Peter Maydell wrote:
On 1 August 2014 17:41, Michael Roth wrote:
On behalf of the QEMU Team, I'd like to announce the availability of
the QEMU 2.1.0 release. This release contains 2200+ commits from 180
authors.
Thank you to everyone involved!
Yep, thanks to everybody w
devices. This allows NetBSD SPARC64 to correctly detect and access devices
on the ebus.
Signed-off-by: Mark Cave-Ayland
---
hw/sparc64/sun4u.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index 33c311b..b9f3bee 100644
--- a/hw
of the interrupt status bits is cleared by writing to PCI configuration
space.
Signed-off-by: Mark Cave-Ayland
Mark Cave-Ayland (5):
cmd646: add constants for CNTRL register access
cmd646: synchronise DMA interrupt status with UDMA interrupt status
cmd646: switch cmd646_update_irq() to
Make sure that both registers are synchronised when being accessed through
PCI configuration space.
Signed-off-by: Mark Cave-Ayland
---
hw/ide/cmd646.c | 24
1 file changed, 24 insertions(+)
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index b8dc4ab..74d0deb 100644
Signed-off-by: Mark Cave-Ayland
---
hw/ide/cmd646.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index a8e35fe..d8395ef 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -33,6 +33,9 @@
#include
/* CMD646 specific
1 - 100 of 5669 matches
Mail list logo
