On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's device tree creation and set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with MacOS (and maybe the NDRV does not fully init yet).
You'll also need these two QEMU patches at the moment before they are merged in QEMU:
http://patchwork.ozlabs.org/patch/1127919/ http://patchwork.ozlabs.org/patch/1136568/
The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM), the other one tries to add registers the NDRV seems to access but not sure if those are correct.
The FCode ROM switches mode but does that before reading EDID and with parameters that I can't handle from the emulation so the question is why it
Here's another QEMU patch that hopefully fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead which no longer works after FCode ROM has set up the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver into FCode as well so it works more like it should on real hardware. This looks like a welcome clean up but I'm not volunteering to do that because I don't know enough about how this should work just so I'm bringing up the topic here for comments.
selects this mode and if this is correct. What mode does it set on real hardware? Before setting the mode it tries to access another set of registers similar to what is used to get the EDID. These are called AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which is an ATI specific feature connector but I'm not sure. Does it try to access some info over that? Does the card have multiple connectors and it expects the primary display somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop after that without trying the switch mode. Does anyone have any info on this or knows about some source of info?
This is still the same. I wonder if MacOS uses the firmware routines to draw before the NDRV is inited and picture is now broken because OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive the card? Then next question is why NDRV stops but I can't answer that because it gives no error and just stops accessing card regs after attempting to read something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV to find out.
Regards, BALATON Zoltan