[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] MorphOS 4.x on QEMU
From: |
BALATON Zoltan |
Subject: |
Re: [Qemu-ppc] MorphOS 4.x on QEMU |
Date: |
Fri, 14 Mar 2014 02:15:04 +0100 (CET) |
User-agent: |
Alpine 2.01 (GSO 1266 2009-07-14) |
On Fri, 14 Mar 2014, Mark Cave-Ayland wrote:
Ah on the basis of this I think I understand the alerts now:
Alert: SYS_MMUAddPage: Page 0x80000 EndPage 0x81000 already exists
Alert: SYS_MMUAddPage: Page 0xf2000 EndPage 0xf2001 already exists
Based upon a page size of 0x1000, my guess is that this is trying to tell you
that ranges 0x80000000-0x81000000 and 0xf2000000-0xf2001000 already have
virtual to physical address mappings; the former seems to correspond with the
VGA BAR0 (VGA vram) region which is likely mapped by OpenBIOS while the
latter which is just a single page could be control registers for the
UniNorth PCI host bridge.
The latter seems to be related to the serial card I've added for
debugging. If running with only VGA it dumps the first alert in the memory
debug buffer and running with the serial card gives only the second. The
serial card has this BAR0: I/O at 0x0400 [0x0407] which probably end up on
the isa_mmio from f2000000. But unfortunately removing these cards is not
enough to prevent the crash even if it's enough to prevent the alerts.
Something else is failing here for some reason which I yet need to find
out.
By the way, for the serial card OpenBIOS prints this at start:
Cannot manage '16550 serial controller' PCI device type '<NULL>':
1b36 2 (7 0 2)
I add it with these options:
-chardev file,id=tS0,path=debug-serial.out -device pci-serial,chardev=tS0
but it is detected and used by MorphOS nevertheless.
One thing that does confuse me is how does MorphOS know these mapping exist?
Yes, that's mistery. For sure not by looking at the translations in the
CPU properties because it seems to skip that. Instead it seems to look at
the properties of the pci cards and maybe reconstructs mappings from that.
It reads these properties: #address-cells #size-cells ranges bus-range reg
assigned-addresses and those related to irq mapping too.
Since the OS would presumably manage its own MMU hash entries then maybe
these entries are locked in the MMU TLB?
Do you mean it probably has built in knowledge about mappings already
present on a certain model of Apple hardware? I'm not sure I understand
this sentence correctly.
Perhaps as a starting point you could try moving the VGA card to 0x90000000
similar to the sample device trees you listed in case the MorphOS guys have
hardcoded this region? It seems that the ATI rage card is on a separate
(presumably AGP) bus so you would need to create another PCI bus/PCI address
space to model this in the same way.
I've seen some commented out code in the mac_newworld file. I'll try to
enable it to see if that works but I'm afraid I don't really know what am
I doing there.
Regards,
BALATON Zoltan
Re: [Qemu-ppc] MorphOS 4.x on QEMU, Mark Cave-Ayland, 2014/03/13