qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Mac OS X PPC host support (was: [4932] Preliminary PPC6


From: Andreas Färber
Subject: Re: [Qemu-devel] Mac OS X PPC host support (was: [4932] Preliminary PPC64/Linux host support)
Date: Thu, 31 Jul 2008 23:50:19 +0200


Am 31.07.2008 um 20:57 schrieb malc:

On Wed, 30 Jul 2008, Blue Swirl wrote:

29 is Data Access Exception, raised from unassigned memory access. The code is

0xffd04020:  std  %l0, [ %sp ]

which is a double word store. Address in %sp (%o6, 0xffdd3fa0) is OK.
So I'd check if qemu_st64 generates correct code.

That was spot on, thanks once again. I have notified main tcg proper to
not align register parameters, but failed to do so myself when calling
qemu_stXX helpers.

With that fixed Sparc test image boots in MacOS X, i386 test image does make it to ext2fs warning but then just hangs there waiting for something, and some dma timer warning messages popup in the console after a while,
therefore i'm reluctant on commiting it just now.

That said the code is there:
http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/tcgppc32macosx
(warning, one commit was amended so things will not fast-forward)

My MacOS X stuff is outdated so maybe the i386 problem is not a TCG one, testing from uptodate MacOS X/PPC32 people would be needed. And i think
someone more MacOS X inclined should take over this part.

I still think your Apple linkage area define is incorrect. The ABI document clearly says it's 24 bytes, with some reserved space in there after the three fields. You sure it's safe to strip that space?

Leaving my linkage area in and applying your alignment fixes I was finally able to boot into Sparc Etch.
http://repo.or.cz/w/qemu/afaerber.git?a=shortlog;h=refs/heads/tcg-osx-ppc

Thanks a lot for your help so far!

After some progress on booting, I get a whole screen full of "esp0: Data transfer overrun." - sounds related to your i386 issue. The monitor is awfully slow at that point, i.e. ~1 second per char typed. Last time I saw these, something was wrong in slavio interrupt handling I believe - haven't checked on another platform yet.

Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]