overdue-scratch

Author Topic: ATI and possibly nVIDIA resolution patch (based on prasys' 915resolution port)  (Read 78336 times)

0 Members and 2 Guests are viewing this topic.

lebidou

  • Resident
  • Posts: 133
CEOS, could you please post the whole debug output as BladeRunner did ? So I can check if the modeline is correct, etc.

What bothers me is the fact that you don't see the patched resolution in the video info. That would mean the vbios hasn't been patched at all...
Can you post a vBIOS dump (booting with an other booter)? I saw it doesn't patch the second VESA table, but should do so on 8800 series, I'd like to figure out why.

I attached the RadeonPCI utility by Dong. The kext is 32 bits only. Load RadeonPCI.kext, and in a terminal type "RadeonDump -d" . Send me the resulting file.

Thank you very much.

diebuche

  • VoodooLabs
  • Posts: 30
Hey lebidou,

the patching works for my 3650&4870. EDID is not read correctly, but when i extracted my edid in ubuntu, it wasn't standard conform either.

The problem is: While the Boot Gui is nice and all, I get a KP after ***Device in Slot:1***. It complains about AtiRadeon2000X.kext . Do u know anything that would cause this. My guess would be the "injection" of the modified mode, maybe it doesn't leave the card in the state macosx expects it to be.

ep45-ds3l, 10.6

lebidou

  • Resident
  • Posts: 133
hello diebuche,

I know that if the framebuffer isn't loaded, ATIRadeonX2000.kext would either cause KP or graphic glitches. If you boot in safe mode, or remove ATIRadeonX2000.kext, is ATIFramebuffer loaded ?
If not it can come from a broken graphics enabler, as CEOS reported. But the patch isn't really related to graphics enabler, so...

As I don't use Graphics Enabler because it doesn't cover X1000 series nor ATI Mobility chips, I didn't notice if it was broken. I'll have a look at it though.

Thank you for testing and reporting!

P.S. : GraphicsEnabler seems to do its job here, even if it doesn't enable anything for me, the values are injected in the device tree. So I've no idea why would it make ATIRadeonX2000.kext crash.
[Thinking out loud :] That's weird because we don't do anything to the pci device directly. We're basically copying bytes in the system memory. Macs cards start with non standard modes set, why would it make KP for us?
What version of Chameleon were you using before, diebuche?
« Last Edit: March 09, 2010, 02:34:26 AM by lebidou »

eberts

  • Observer
  • Posts: 15
Okay, I tested the last debug version but it doesn't make a difference  :(
Output:
Chipset is 945G (pci id 0x2770886)
Not an AtomBios card
We have an Nvidia card
First Standard VESA Table at offset 0x8aca
Second Standard VESA Table at offset 0x0
Override Resolution : 1440x900
Override modeline 10736 1440 1527 1679 1919 900 900 903 931
Will patch with modeline  10736 1440 1527 1679 1919 900 900 903 931
Second VESA table wont be patched

Also tried with EDID from ioreg output in com.apple.Boot.plist:
00ffffffffffff0009d1ea765d3700002a10010380281978eac4f6a3574a9c23114f54bdef80714 f8180818c950f81900101010101019a29
a0d0518422305098430098ff1000001ad50980a0205e63101060520898ff1000001a000000fd003 84c1e530e000a202020202020000000fc0042656e51204650
39335657202000b6
Then, 'Override Resolution : 1440x900' disappears...

Just an idea: could it be that the booter gets confused ;) by the onboard graphics chip (GMA950 here) which should be disabled as soon as another pcie card (7300GT here) gets inserted? Maybe it's not completely disabled at that stage... Just a thought...

Thanks for your work, lebidou :)

lebidou

  • Resident
  • Posts: 133
@eberts:
I don't think your GMA950 is in cause. The posted vBios is clearly an nVidia one ("We have an Nvidia card" message). So I guess the GMA950 is disabled already.
I'm gonna ask you two things :
-do you see any 1440x900 mode in video info in boot selection menu ?
-what happen if you try other lower modes like 1280x800 or 1024x640 (assuming one of these is supported by your display)?

@diebuche:
I'm going to make the booter "depatch" the vBios once the mode has been set to see if it comes from a table inconsistency or something like that.
If it comes from CRTC timings, it's going to be hard to solve.

CEOS

  • Member
  • Posts: 49
her you can get my card's vBIOS:
http://www.mvktech.net/component/option,com_remository/Itemid,26/func,fileinfo/id,2386/

somehow this radeondump utility won't work for me.
but my card has the same BIOS rev. like the downloadable (i proof this with GPU-Z)

I will post a picture of the debug output later this day
My Hackintosh: • Intel Core2Quad Q6600 (g0) • PNY 8800gts 512 (g92) • Gigabyte Ga EP45-DS3R (Rev 1; BIOS v. f11e) • 2x2gb OCZ 1066MHz DDR3 • D-Link DWA 547 RangeBooster N

Drives: • HL-DT-STDVD-RAM GH22LS30  • SAMSUNG HD250HJ : Windows 7 Ultimate x64 • SAMSUNG HD161HJ :  Snow Leopard 10.6.3 • SAMSUNG HD103UJ : Backup

Ezhoon

  • Observer
  • Posts: 12
Tried the newest debug version with both edid key and graphic mode key (2560x1600x32)
I got Override resolution: 2560x1600 but, gui isn't 2560x1600 resolution..it's more like
1600x1200 stretched (I am guessing here, of course, it could be 1280x1024 stretched)

I tried both dvi output but made no difference

-8800gts 320MB, Gigabyte 965P-DS3

diebuche

  • VoodooLabs
  • Posts: 30
After booting -x ist just hangs after dmsos has arrived, no kp...
Could u add this to your trunk, it will report the resolution used in the gui etc.

lebidou

  • Resident
  • Posts: 133
@nVidia Testers: I modified the debug version so we have message telling us which mode is actually used by GUI.
Also, I had an idea this morning: Maybe the mode is isn't used because we patched a mode that wasn't meant to used anyway. So, if you get a message about a mode with improper attributes, please, report the mm and attr values for the 'improper mode', AND for the mode it set instead of the one we want.

@diebuche: I made the vBios to be "unpatched" before the kernel launches. I'm not sure it will change anything.
I just had the idea (just now, while typing) that maybe the Framebuffer Physical Address passed to the kernel is wrong.
I'll see if there's correction to be made.

@all: Link in first post.

eberts

  • Observer
  • Posts: 15
This is what I get with the new debug version:
First screen:
VBE Calls returned Mode 118: 1024x768x32 mm:6 attr:39f
Press any key...

Second screen:
efi_inject_get_devprop_string NULL trying stringdata
Override resolution: 1440x900
Override modeline: 10736 1440 1527 1679 1919 900 900 903 931
Will patch with modeline  10736 1440 1527 1679 1919 900 900 903 931
VBE Calls returned Mode 118: 1024x768x32 mm:6 attr:39f
Press any key...

?video has always reported 1024x786 to be the maximum for me.

lebidou

  • Resident
  • Posts: 133
Wait, you have the Mode 118 message First, and Then the override ? No override message before that ?

eberts

  • Observer
  • Posts: 15
Sorry, just double checked it.
I forgot to mention the first output which is black & white:

Chipset is 945G (pci id 0x2770886)
Not an AtomBios card
We have an Nvidia card
First Standard VESA Table at offset 0x8aca
Second Standard VESA Table at offset 0x0
Override Resolution : 1440x900
Override modeline 10736 1440 1527 1679 1919 900 900 903 931
Will patch with modeline  10736 1440 1527 1679 1919 900 900 903 931

Then it turns grey saying:
VBE Calls returned Mode 118: 1024x768x32 mm:6 attr:39f
Press key

Then some the screen blanks for just an instant - afterwards:
efi_inject_get_devprop_string NULL trying stringdata
Override resolution: 1440x900
Override modeline: 10736 1440 1527 1679 1919 900 900 903 931
Will patch with modeline  10736 1440 1527 1679 1919 900 900 903 931
VBE Calls returned Mode 118: 1024x768x32 mm:6 attr:39f
Press any key...
« Last Edit: March 09, 2010, 10:48:06 PM by eberts »

lebidou

  • Resident
  • Posts: 133
It looks like it does apply the patch, but actually doesn't.
I'm reading about nVidia cards (as I don't have one, that's the only thing I can do for now), and apparently there is three different location for the vbios: The legacy address 0xC0000 we are using, PROM, and RAMIN. I guess that despite the correct patching in 0xC0000, when performing and answering to VBE calls, the bios uses either the PROM image or the RAMIN image.
So I have to figure out if at least one these images is writable.

lebidou

  • Resident
  • Posts: 133
There is an other update in first post.
All the changes have made in the debug version are now applied to the regular one.

Nvidia users, if it still doesn't work, it means that the card doesn't care about the vbios image we're patching to set mode. The PROM image is read-only, but RAMIN seems to be writable. I haven't figured out how though. And if I don't the only remaining solution is to port the modesetting part from nouveau, which I won't do.

ATI HD3 & 4, I added output in the debug version to see if the ATIFramebuffer crashing isn't due to the Framebuffer Physical Base Address returned to the kernel. VESA Documentation says it could varies from mode to mode.

Ezhoon

  • Observer
  • Posts: 12
Ok..this time..I don't see anything on the Chameleon boot selection screen.
I just hit return key blindly and, no boot logo is displayed..just a gray background.
I tried with and without the edid key in com.apple.boot.plist and the result was same.

Attaching two pics of first and second screen..