Port-macppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: machfb still broken for first gen iMacs



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Oct 2, 2010, at 8:30 PM, John Klos wrote:

The first two are for reference and show a genfb kernel. This is a first generation iMac with a VGA connection to a regular monitor.

What about the built-in monitor?

There is none. This iMac doesn't support more than one monitor. The motherboard was saved from a junked iMac.

Ah, ok. I remember the typical DB15 monitor connector inside ;)
If I remember correctly the built-in monitor does not support DDC, instead the firmware puts an EDID block in a property attached to the graphics chip's node. It would be interesting if the EDID block provided is from your monitor or the one for the built-in screen. But that doesn't seem to have anything to do with your problem and the machfb version in the netbsd-5 branch doesn't even try to use it.

Does the iMac lock up here or does it continue booting with an unreadable console?

It seems to continue because I see small groups of pixels change for the next minute or so, but I wasn't able to access it via the network. For a little while other small screen changes happened when I hit keys, but a reboot command didn't (reboot).

Hmm, this is getting weirder. Did it not make it into userland or did you just not set things up (yet) ? I'd like to see the whole dmesg output with debug info when this happens.

Since this seems to be drawing engine related I'm afraid it's a lockup though, and since you see the 'initial resolution...' line we made it past engine initialization and mode setup.
Please do this:
- - comment out the mach64_clearscreen() call in mach64_attach() so output doesn't get lost - - sprinkle printf()s to find out where exactly the messup happens, normal console output should work right up to wsdisplay_cnattach()
- - set options_MACHFB_DEBUG in your kernel config for extra loudness
This should give us an idea where the messup happens. As I said before, I have a beige G3 with onboard Rage II and a Sun PGX ( which is another Rage II on a PCI card ) - both work fine. Finally, you could try to if (0) the ri->ri_ops.putchar = ... line in mach64_init_screen() so we fall back to software character drawing. If that helps at least I know where to look.

I'll try those when I'm on that machine again. Thanks!

I wonder if it has anything to do with the fact that your iMac has 6MB video memory ( as does the one in the PR ) while all the mach64s I have here have 4MB at most. Back when I had access to an iMac it did have 6MB as well though. I don't really see how that would make a difference though - the drawing engine registers are at the end of each aperture, there is no overlap unless you have 8MB VRAM.

That reminds me, since you have been dealing with these machines far longer than I did - my beige G3 has a 2MB onboard Rage II. I added a 4MB VRAM module ( I have two of them, same effect with either one ) yet both machfb and MacOS only see 4MB. Any idea why? It seems to be a firmware thing unrelated to the operating system, with the console on a different graphics chip machfb sees only 2MB.
Firmware is 2.0f1.
I may be able to fix this in machfb but first I'd like to know if that's a known problem with some beige G3s, if there's a way around it etc.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBTKfa8cpnzkX8Yg2nAQKTQAgAgcCa6Wtxcnm07lNGlGu6YmQGZh4H7gVl
66cqkK1K6HeCWdEg34On9tw/7PK7VvuEGWyZ62F2jgGDKlNF03fVy7dRHxDT8oCX
FWNQClmP8Scbb4FcQrOXjvUatVc35HKa33XnjfntKuROUOgZVe9pVevzMuL0gPJB
Mc1VtS2b4U3akZlUqFZJLBa9ayS1kagP9skb1Bdtk0Bo/4wS2GFOGOJbbO4mgg+l
VNBLEhpQlbPb78Pia6AAFqWkQ+7URpqHNyL1yL+okjAauI9G6z7Gu4RKWdfUgwlG
W0wsEFUINKTPq7lPB8oaCNtDL5QsrYiP7WhmhhOcG3c4+vJ7JZELSg==
=44Nh
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index | Old Index