|
From: | Mark Cave-Ayland |
Subject: | Re: [Qemu-ppc] MorphOS 4.x on QEMU |
Date: | Thu, 13 Mar 2014 23:14:25 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 |
On 13/03/14 15:55, BALATON Zoltan wrote:
Hello, I'm still trying to find out how to boot MorphOS on QEMU. I think at least some of the problems come from MorphOS being confused about the memory layout. Not sure if this is because of incorrect assumptions on its side or bugs in the OpenBIOS supplied device tree but so far I've found out the following. I'll put the questions first hoping that more people read and answer it this way. For detailed explanation see below. Here are the questions: 1. Is there a way to move the VGA mapping after the macio one? I've tried -vga none but I need to type a boot command and without a graphics card the console and QEMU monitor both ended up on stdio and mixed up. I guess OpenBIOS creates mappings in the order of the device number of the cards. How can I change the device number of the VGA? Like putting it in a different slot or otherwise make it mapped after the on-board devices. 2. Another difference between the memory maps seems to be that on hardware the pci controller gets f2000000 and f3000000 and on QEMU it's f2000000 and f2800000. Can this alignement be changed somewhere? I think it is in OpenBIOS somewhere but where?
If you want to start experimenting with changing the machine layout, you need to take a look at the Mac99 initialisation code in hw/ppc/mac_newworld.c. The memory API should make it reasonably straightforward to change the addresses of all the different peripherals, including PCI bus ordering as required.
Note that OpenBIOS can probe the PCI bus and so any changes you make to the ordering/BARs should be picked up automatically without having to make any additional changes.
(cut)
The other errors I get that may be related to the memory map differences are these: Alert: SYS_MMUAddPage: Page 0x80000 EndPage 0x81000 already exists Alert: SYS_MMUAddPage: Page 0xf2000 EndPage 0xf2001 already exists I don't know what these mean but bringing the memory layout closer to hardware may solve it or provide some more clues.
It will create a lot of debugging output, however you can try enabling DEBUG_MMU and friends in target-ppc/mmu_helper.c. This should give you enough information to work out when these two pages are being set in order to help you find the culprit.
ATB, Mark.
[Prev in Thread] | Current Thread | [Next in Thread] |