Re: [Qemu-ppc] MorphOS 4.x on QEMU

[Mark Cave-Ayland]

On 13/03/14 23:51, BALATON Zoltan wrote:

> On Thu, 13 Mar 2014, Mark Cave-Ayland wrote:
> > On 13/03/14 15:55, BALATON Zoltan wrote:
> > > 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
>
> At last I've managed to run with -vga none by redirecting the monitor
> output and the serial output to different unix domain sockets so I can
> connect to them separately and type into them without mixing up the
> input. This also moves the macio to where MorphOS expect it to be and
> does not hang while trying to talk to cuda at the wrong address.

Excellent!

> > > 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.
>
> I've also found this and experimented with it some but it does not seem
> to change anything so for now I've reverted it the way it was.
>
> > > 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.
>
> Removing the VGA card makes the first alert go away and probably
> removing the serial card makes the second go away too but then I can
> only rely on debug info dumped in ram which may not contain these alerts
> so I'm not 100% sure yet. I have to verify this with enabling only the
> VGA card and see if it puts the alert in ram. So these seem to be
> related to the pci cards but I don't know how and unfortunately removing
> the pci cards does not seem to solve the crash so there's some more.

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.

One thing that does confuse me is how does MorphOS know these mapping 
exist? Since the OS would presumably manage its own MMU hash entries 
then maybe these entries are locked in the MMU TLB?

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.


ATB,

Mark.