Hello,
OK back to this thread now that map-in and other missing words are implemented enough to test this (improvements to the pci-map-in patch will be in the implementing map-in thread, this is about running the FCode ROM now to keep it organised).
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 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?
Regards, BALATON Zoltan