I made a custom Mac OS ROM that injects the EDID and ATY,Rage128Ps via a script, however that didn’t solve any issues:-(
Zoltan, did you notice that the node on the PCI bus changes after execution of the FCode ROM, it moves from /pci/@f to /pci/@0.
I think this is why PCIPeek returns garbage and maybe why our NDRV is aborting.
On Aug 2, 2019, at 6:54 AM, Jd Lyons lyons_dj@yahoo.com wrote:
I think the only properties that matter are the “ name” property and the “ EDID” property.
I think if we just inject them correctly into the device tree for the card we will have more success……….
On Aug 2, 2019, at 6:08 AM, Jd Lyons lyons_dj@yahoo.com wrote:
Executing the FCode ROM completely screws up all the address and device properties in PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
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
I've found that the card has two ports but we only emulate the VGA one not the DVI. The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init the CRTC part so we get no picture. Therefore I think this is now OK and what happens is FCode tries reading EDID from DVI and when that fails switches to VGA port and sets default mode before reading EDID which it then puts in the device tree. I'm not sure how it selects default mode though, probably not from EDID.
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.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS but we could not find out yet. It also tries getting DFP EDID but it does not matter if it finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops working. I've compared device tree properties after FCode run to those on real hardware and found these differences:
- address is missing the 8000 offset that also appears in the screen mode it switches to but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not what causing the NDRV to exit.
- reg property matches but assigned-addresses has several differences (probably need my patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS: assigned-addresses 42007810 00000000 81000000 00000000 01000000 01007814 00000000 00001000 00000000 00000100 02007818 00000000 82000000 00000000 00004000 reg 00007800 00000000 00000000 00000000 00000000 02007830 00000000 00000000 00000000 00020000 42007810 00000000 00000000 00000000 04000000 02007818 00000000 00000000 00000000 00004000
real machine: assigned-addresses c2008010 00000000 94000000 00000000 04000000 82008030 00000000 90020000 00000000 00020000 82008018 00000000 90000000 00000000 00004000 reg 00008000 00000000 00000000 00000000 00000000 02008030 00000000 00000000 00000000 00020000 42008010 00000000 00000000 00000000 04000000 02008018 00000000 00000000 00000000 00004000
- We don't have AGP_Master and ATYN property. The AGP one is likely not needed but not sure about what ATYN is.
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?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe connected to DVI port or it's unused on the card and useful in laptops. In any case we don't emulate DFP controller only CRT so this is not needed and likely not where NDRV fails as it does run a bit further after this.
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.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO regs and not the wrong address property. The last thing the NDRV appears to do is getting mmio and ROM BARs then trying to set up mmio but after that no register writes or reads reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in making this work experiment with it and find out.
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org