qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: BALATON Zoltan <balaton@eik.bme.hu>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardware
Date: Fri, 11 Apr 2014 13:39:43 +0200	[thread overview]
Message-ID: <5347D47F.7000307@suse.de> (raw)
In-Reply-To: <alpine.LMD.2.02.1403201111290.1165@jedlik.phy.bme.hu>


On 20.03.14 11:16, BALATON Zoltan wrote:
> On Sat, 15 Mar 2014, BALATON Zoltan wrote:
>> Try to better match the memory map of a PowerMac3,1 model by moving
>> the pci-cfg mappings to where they are on a real machine. Also add the
>> VGA card after the macio to let the latter be mapped from 0x80000000 to
>> match hardware. (On real hardware the graphics card is on a different
>> bus but we don't seem to model that yet.)
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>>
>> This patch is intended to bring memory layout closer to what's seen in
>> these dumps:
>>
>> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt
>> http://raveland.org/ports/eeprom.txt
>> http://mail-index.netbsd.org/port-macppc/2007/10/24/0000.html
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134
>>
>> It makes MorphOS a little happier and not print alerts when creating
>> its memory map but not happy enough to not crash later.
>
> I'm not so sure about this patch either by now. I've come across some 
> logs that show that these MorphOS alerts can happen on real hardware 
> too and are probably not related to the crash but it needs more 
> debugging and experimenting. If anyone has any ideas how to converge 
> QEMU's model to what's seen in the dumps above please let me know.

Yeah, I'd rather hold back on this until we fix a real bug.

The problem with the mac99 target in QEMU is that it doesn't match any 
real machine out there. It's essentially a hack good enough to get a 
good amount of Linux and Mac OS X working, but I'm sure if you don't 
look at the device tree for device creation you'll blow up :).

The "real" fix would be to create a new machine model that models 
*exactly* a real system from scratch.


Alex

      reply	other threads:[~2014-04-11 11:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-15  0:17 [Qemu-devel] [PATCH] mac99: Bring memory layout closer to real hardware BALATON Zoltan
2014-03-20 10:16 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2014-04-11 11:39   ` Alexander Graf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5347D47F.7000307@suse.de \
    --to=agraf@suse.de \
    --cc=afaerber@suse.de \
    --cc=balaton@eik.bme.hu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).