Jump to content

Sony Vaio VPCF115FM Discussion: DSDT Injection


kizwan
 Share

787 posts in this topic

Recommended Posts

So I booted up my hackintosh with "GraphicsEnabler=yes nv_disable=1". In this way, the geforce driver were loaded but disabled. The GUI came normally as it would without using GraphicsEnabler. But this time the properties of the graphics card and display were properly listed in the System Profiler, although "Display connector" was totally blank. But I noticed that in PCI Devices it showed two devices regarding the NVIDIA card (a "display_b" with vendor/device ids 0x10de,0x0a29 and another entry called "NVDA, Parent", with ids 0x10de, 0x0be2 which may be the HDMI port, although it has different device ID in Windows). The last one has "ejection relations" to the first one in the Device Manager of Windows 7. When not using the GraphicsEnabler boot option, none of these devices appear in System Profiler.

 

Oh very good to know that there is a boot option "nv_disable", I always renamed the nvdahal50.kext to boot work with internal screen :( Does this work also with my dsdt that injects the proper nvidia ids without graphicsenabler?

 

I think if the nvidia driver is disabled, the standard vesa bios of the gfx card will be used, so it's a different mechanism. If there are still some parts of the nv driver inside ioreg, maybe some kexts of nvidia are still loaded? Can you look at kextstat if there is anything nvidia related when using nv_disable? By what kext is display_b hooked up? If you click on it, in the upper part of the window normally "com.apple.iographicsfamily" will appear.

 

But we need nvidia driver to be completely activated.

Link to comment
Share on other sites

Little tutorial about bin patching and disassemble kexts

 

I made some exemplary bin-patching of the nvdaresman.kext of SL 10.6.7 where I disabled the functions "_osLegacyFlatPanelPowerOff" and "_dacPowerOffAllMobilePanels".

 

First we need the offsets of the mach-architectures:

lipo -detailed_info NVDAResman.kext/Contents/MacOS/NVDAResman

 

Result:

fat_magic 0xcafebabe

nfat_arch 2

architecture i386

cputype CPU_TYPE_I386

cpusubtype CPU_SUBTYPE_I386_ALL

offset 4096

size 3586280

align 2^12 (4096)

architecture x86_64

cputype CPU_TYPE_X86_64

cpusubtype CPU_SUBTYPE_X86_64_ALL

offset 3592192

size 3088816

align 2^12 (4096)

So the offset of x86_64 architecture is from dec 3592192 to hex: 0x36d000.

 

Now we need to disassemble the x86_64 part of the kext:

otool -arch x86_64 -vt NVDAResman.kext/Contents/MacOS/NVDAResman

The result will be a very large disassemble code. Maybe it's easier to dump it into a text file by adding " > file.txt" at the end of the line. I search now within the dumped result for the two methods.

 

But there is a much easier way to find the methods by using grep, so you do not need to completely disassemble the kext:

otool -arch x86_64 -vt NVDAResman.kext/Contents/MacOS/NVDAResman  | c++filt | grep -A 2 PowerOff

"-A 2" means that grep will display the found line + 2 lines afterwards.

 

_dacPowerOffAllMobilePanels:

000000000009569d pushq %rbp

000000000009569e movq %rsp,%rbp

...

 

_osLegacyFlatPanelPowerOff:

0000000000067637 pushq %rbp

0000000000067638 movq %rsp,%rbp

...

Now I calculate with OSX's calculator the real binary offsets:

_dacPowerOffAllMobilePanels: 0x36d000 + 9569d = 0x40269d

_osLegacyFlatPanelPowerOff: 0x36d000 + 67637 = 0x3d4637

 

In 0xED I overwrite two bytes at 0x3d4637 and 0x40269d:

C9 C3

C9: opcode for "leave"

C3: opcode for "ret"

I don't really know if the "leave" is really required, but it seems to be exist before every return of a function.

You can ensure that the patches are rightly done by disassemble the kext again.

 

So here is the patched nvdaresman.kext of OSX 10.6.7. Try it out :(

Patched nvdaresman.kext 10.6.7

 

 

EDIT: All functions dump:

otool -arch x86_64 -vt NVDAResman.kext/Contents/MacOS/NVDAResman | c++filt | grep -A 1 _ > functions.txt
Link to comment
Share on other sites

So here is the patched nvdaresman.kext of OSX 10.6.7. Try it out :wacko:

Patched nvdaresman.kext 10.6.7

 

I've tried your patched kext but it didn't work. I've got a "link error" message during the verbose boot and the nv50hal kext didn't load sucessfully. But maybe that's because I haven't updated to 10.6.7 yet.

Nevertheless, I don't believe that disabling PanelOff functions will work. I think the driver doesn't power on the internal panel anyway as it cannot find one.

 

When I get spare time I'll update and test it again.

 

Oh very good to know that there is a boot option "nv_disable", I always renamed the nvdahal50.kext to boot work with internal screen :D Does this work also with my dsdt that injects the proper nvidia ids without graphicsenabler?

 

I think if the nvidia driver is disabled, the standard vesa bios of the gfx card will be used, so it's a different mechanism. If there are still some parts of the nv driver inside ioreg, maybe some kexts of nvidia are still loaded? Can you look at kextstat if there is anything nvidia related when using nv_disable? By what kext is display_b hooked up? If you click on it, in the upper part of the window normally "com.apple.iographicsfamily" will appear.

 

But we need nvidia driver to be completely activated.

 

Wow, so my little contribution wasn't totally useless :)

 

All the NVDIA kexts are loaded when using nv_disable option. That's why I actually get correct data about the graphics card (e.g. memory size) in the System Profiler (I don't use DSDT or any other modification apart GraphicsEnabler=yes). If I don't use GraphicsEnabler and nv_disable at the same time of course I get the standard vesa and the graphics card info in System Profiler becomes wrong.

 

Which window is that regarding the kext for display_b?

Link to comment
Share on other sites

So here is the patched nvdaresman.kext of OSX 10.6.7. Try it out :D

Patched nvdaresman.kext 10.6.7

 

tried with osX 10.6.7 (but with 10.6.6's kernel) and osX boots up.. but nothing happen on main lcd. No differences in ioreg too :wacko:

 

btw, i found a friend with the old mac book pro with geforce 330m, so i asked for a ioreg dump and.. you can download from this post :P Hope this can help!

 

little edit: you must use IORegistryExplorer for open it in a good way!

Calypso.ioreg.zip

Link to comment
Share on other sites

btw, i found a friend with the old mac book pro with geforce 330m, so i asked for a ioreg dump and.. you can download from this post :rolleyes: Hope this can help!

 

little edit: you must use IORegistryExplorer for open it in a good way!

That's interesting. display_A and display_B, its subclasses "NVDA" are matched my com.apple.NVDAResman. On Sony with attached HDMI it's iographicsfamily which matches the hdmi.

 

So I conclude the nvidia driver can work with nvdresman or with iographicsfamily. So there are 2 ways to fix it:

 

1. Adding the capability of detecting the internal display to iographicsfamily (maybe it only supports standards)

 

2. Patching nvdaresman. Here we should compare it somehow with the win7 corresponding dll.

 

(3. Enabling the internal display before driver kicks in by using the SNY5001 device)

 

The display-A and subclass display0 is actually matched by iographicsfamily in this ioreg of the macbookpro. So I guess, patching iographicsfamily would be the most realistic way. What do you think?

 

 

EDIT: Alexander, can you get the DSDT from your friend's macbookpro too?

 

EDIT2: Are there any Vaios with ATI inside that also have the internal display problem?

Link to comment
Share on other sites

That's interesting. display_A and display_B, its subclasses "NVDA" are matched my com.apple.NVDAResman. On Sony with attached HDMI it's iographicsfamily which matches the hdmi.

 

 

EDIT: Alexander, can you get the DSDT from your friend's macbookpro too?

 

just for give a little info: i'm using external monitor via VGA port and i have com.apple.NVDAResman too in both Display_A and B, under the voice "CFBundleIdentifier"

 

i don't have a DSDT dump but i can ask, i'll post here ASAP

 

edit: here the DSDT

dsdt_macbook_pro_6.2.dsl.zip

Link to comment
Share on other sites

That makes sense, on the newer style hybrid graphics systems, the framebuffer is always on the IGP and the LCD is connected there, in optimus-style setups the dedicated GPU chip writes to the IGP's framebuffer.

 

http://arstechnica.com/gadgets/news/2010/0...aller-ion-2.ars

 

That shouldn't really be a problem though - it means that the MBP guys are driving their LCDs off the intel framebuffer. We don't even have that, BUT the nvidia driver detects our GPU just fine anyway.

 

In theory, the regular NVDA framebuffer should work just fine, but it never has for any Nvidia VAIO (or ATI vaio, for that matter - although the hackintosh-made ATI framebuffer supports vaios), so we're still at step 1.

 

At least we all know this now :( We've got to screw around with the nvda framebuffer! You're not going to learn a ton more from studying the MBP files.

 

Unfortunately I can't really help you guys atm, I am still using boot think and can't find a way (just yet) to replace that with chameleon. At the time I tried it, boot think was the -only- thing I could make work on my vaio's funky partition table. It ended up making 2 folders on my windows partition in just the right place, that I could probably jack :(

Link to comment
Share on other sites

The new MacBookPro Update 1.4 consists of new NVDA-kexts (don't know versions of update 1.3, maybe the same):

 

NVDANV50Hal.kext / NVDAResman.kext

update: 1.6.34.13 (256.02.05f01)

10.6.7: 1.6.26.31 (256.00.35f05)

 

Unfortunately still no 260.xxx version. We need to focus on gfxfamily.

 

 

That makes sense, on the newer style hybrid graphics systems, the framebuffer is always on the IGP and the LCD is connected there, in optimus-style setups the dedicated GPU chip writes to the IGP's framebuffer.

Well, I believe lcd devices inside the dsdt just absolutely do not matter for OSX. But if there was a lcd device triggered in the dsdt somehow, I hoped we could call there some kind of SNY5001 devices's wakeup method...

Link to comment
Share on other sites

we must remember that experts said the original problem is about SNC, so i think it's right to still investigate a bit over that :D

i found an old topic here by Krazubu (wow!) about this and a guy posted a beta driver for osx 10.5.5 that try to "switch" display outputs calling a method from dsdt called "SODV". In linucs it works, in osX driver works but that method do nothing. Post with that driver: http://www.insanelymac.com/forum/index.php...t&p=1115004

We must still remember that other laptops with geforce 330m have working internal screen, so the real difference is only the SNC. Ootlink opened a thread about this but it died after 3 reply, sadly :D

i'm tring to investigate more on this SNC and understand what exacly it does, maybe the solution is a simple dsdt patch on the snc device!

Link to comment
Share on other sites

In Linux, they only use the SNC driver you speak of to control backlight brightness. It's not used for anything else that I recall.

 

If you dig up some info on the stuff the Linux guys use, they're usually using either the nvidia driver and adding the EDID info to a profile, or using the driver that comes with Ubuntu (I forgot the name right now) - which was probably made to support Sony laptops to begin with.

Link to comment
Share on other sites

we must remember that experts said the original problem is about SNC, so i think it's right to still investigate a bit over that :P

i found an old topic here by Krazubu (wow!) about this and a guy posted a beta driver for osx 10.5.5 that try to "switch" display outputs calling a method from dsdt called "SODV". In linucs it works, in osX driver works but that method do nothing. Post with that driver: http://www.insanelymac.com/forum/index.php...t&p=1115004

We must still remember that other laptops with geforce 330m have working internal screen, so the real difference is only the SNC. Ootlink opened a thread about this but it died after 3 reply, sadly :)

i'm tring to investigate more on this SNC and understand what exacly it does, maybe the solution is a simple dsdt patch on the snc device!

 

This is the VAIO F11 SODV function:

					Method (SODV, 1, NotSerialized)
				{
					DBGC (0xF6, Zero, BCEN)
					If (LNotEqual (DSEN, Zero))
					{
						Return (Ones)
					}
					Store (Arg0, AODV)
					If (LNot (And (AODV, CADD)))
					{
						Store (One, AODV)
					}
					If (LNotEqual (CADD, PADD))
					{
						Store (CADD, PADD)
						Notify (PCI0, Zero)
						And (PNHM, 0x000FFFF0, Local0)
						If (Or (LEqual (Local0, 0x000106E0), LEqual (Local0, 0x000106A0)))
						{
							Notify (PEG3, Zero)
						}
						Else
						{
							Notify (PEGP, Zero)
						}
						Sleep (0x02EE)
					}
					DBGC (0xF6, 0x80, BCEN)
					Return (Zero)
				}

 

If the Notify PEG3 with 0 or 0x80(?) and sleep moved to a place in the dsdt that is called, for example inside peg3... There would not be the need of a driver... Or did I miss something? The SODV method needs to be called after driver activation?

 

EDIT: Btw. FakeSMC'S ACPIMonitor plugin now seems to support writing to smc, so I guess we could use smc_util to call the SODV method with some value... What do you think?

Link to comment
Share on other sites

In my DSDT instead there's this ...

 

 

Method (SODV, 1, NotSerialized)

{

If (LNotEqual (DSEN, Zero))

{

Return (Ones)

}

 

Store (Arg0, AODV)

If (LNot (And (AODV, CADD)))

{

Store (One, AODV)

}

 

If (LNotEqual (CADD, PADD))

{

Store (CADD, PADD)

Notify (PCI0, Zero)

Notify (PEGP, Zero)

Sleep (0x02EE)

}

 

Notify (GFX0, 0x80)

Notify (^^^PEGP.NGFX, 0x80)

Return (Zero)

}

 

 

there is also this ....

 

 

 

Method (HKDS, 1, Serialized)

{

If (LEqual (Zero, DSEN))

{

Store (Arg0, SMIF)

Store (Zero, TRP0)

If (LEqual (SMIF, Zero))

{

If (LNotEqual (CADL, PADL))

{

Store (CADL, PADL)

If (LEqual (OSYS, 0x07D1))

{

Notify (\_SB.PCI0, Zero)

}

Else

{

Notify (\_SB.PCI0.GFX0, Zero)

}

 

Sleep (0x02EE)

}

 

Notify (\_SB.PCI0.GFX0, 0x80)

}

}

Link to comment
Share on other sites

Yes, I agree with you ... the device snc just about saving energy on a bluetooth, wireless, sleep, hibernate, etc ...

 

I think the problem is in the EDID .... my tests are as follows:

 

- tried to inject edid in dsdt with the result that resx switch me back another edid false.

 

- just by adding edid folder I get an override edid correct switchresx

but I still always use the leopard his false edid ...

should be responsible for the kext which gives the false edid and try them an injection ....

 

What do you think?

Link to comment
Share on other sites

Yes, I agree with you ... the device snc just about saving energy on a bluetooth, wireless, sleep, hibernate, etc ...

 

I think the problem is in the EDID ....

SODV seems to be responsible for switching vga/lvds. It makes sense to me that the default output seems to be vga (works with nv drivers) and needs to be switched to lvds. So the next test I would suggest is to configure a method for the acpiplugin of fakesmc to call the sodv method with different parameters and see what happens.

Link to comment
Share on other sites

SODV seems to be responsible for switching vga/lvds. It makes sense to me that the default output seems to be vga (works with nv drivers) and needs to be switched to lvds. So the next test I would suggest is to configure a method for the acpiplugin of fakesmc to call the sodv method with different parameters and see what happens.

 

I think snc is essentially managed by the bios....in fact, during the black screen lcd is turned on, only when connecting the vga lcd is turned off. So it is not the snc that switches the output, but osx is waiting for a signal from vga output.

Probably the error is in the nvidia driver or kext responsible for managing the video outputs.

Link to comment
Share on other sites

Hm salvo, what exact vaio model do you have? On my machine the screen is completly black and powered off. Also stated as "not connected". VAIO F11 i7 gt330m

 

The model is in the signature... is a sony vaio VGN-FE21B 7400 go 256 MB

 

If you want to see my videos I am attaching the link:

 

http://www.youtube.com/watch?v=xSKfFJ4nB0U

 

http://www.youtube.com/watch?v=HzVqhmo6QHo

 

As you can see the LCD screen is not all black and off ...

 

In system profiler I get the external display as primary monitor and no attached monitor .... as if he recognized the external display as primary ....

Link to comment
Share on other sites

I am trying here to make some acpi methods for fakesmc that we can call for tests. Especially in method SNCE I am trying to build a extract of the SNC method:

				Method (SNCE, 2, NotSerialized)
			{
				DBGC (0xF6, Zero, BCEN)
				Store (Arg0, AODV)
				Store (Arg1, Local1)
				If (LNot (And (AODV, CADD)))
				{
					Store (One, AODV)
				}
				If (LNotEqual (CADD, PADD))
				{
					Store (CADD, PADD)
					Notify (PCI0, Zero)
					Notify (PEG3, Zero)
					Sleep (0x02EE)
				}
				Notify (GFX0, Local1)
				Notify (^^PEG3.NGFX, Local1)
				DBGC (0xF6, 0x80, BCEN)
				Return (Zero)
			}

This method currently expects 2 parameters, the first one like in the SODV method and the second one for setting a parameter for the Notify byte. In the F11 dsdt it's 0x00, in salvo's dsdt it's 0x80.

 

I think there are still some unneeded lines of code in it. Maybe this would be the essence:

				Method (SNCF, 1, NotSerialized)
			{
				DBGC (0xF6, Zero, BCEN)
				Store (Arg0, Local0)
				Notify (PCI0, Zero)
				Notify (PEG3, Zero)
				Sleep (0x02EE)
				Notify (GFX0, Local0)
				Notify (^^PEG3.NGFX, Local0)
				DBGC (0xF6, 0x80, BCEN)
				Return (Zero)
			}

What do you think?

Link to comment
Share on other sites

I am trying here to make some acpi methods for fakesmc that we can call for tests. Especially in method SNCE I am trying to build a extract of the SNC method:

				Method (SNCE, 2, NotSerialized)
			 {
				 DBGC (0xF6, Zero, BCEN)
				 Store (Arg0, AODV)
				 Store (Arg1, Local1)
				 If (LNot (And (AODV, CADD)))
				 {
					 Store (One, AODV)
				 }
				 If (LNotEqual (CADD, PADD))
				 {
					 Store (CADD, PADD)
					 Notify (PCI0, Zero)
					 Notify (PEG3, Zero)
					 Sleep (0x02EE)
				 }
				 Notify (GFX0, Local1)
				 Notify (^^PEG3.NGFX, Local1)
				 DBGC (0xF6, 0x80, BCEN)
				 Return (Zero)
			 }

This method currently expects 2 parameters, the first one like in the SODV method and the second one for setting a parameter for the Notify byte. In the F11 dsdt it's 0x00, in salvo's dsdt it's 0x80.

 

I think there are still some unneeded lines of code in it. Maybe this would be the essence:

				Method (SNCF, 1, NotSerialized)
			 {
				 DBGC (0xF6, Zero, BCEN)
				 Store (Arg0, Local0)
				 Notify (PCI0, Zero)
				 Notify (PEG3, Zero)
				 Sleep (0x02EE)
				 Notify (GFX0, Local0)
				 Notify (^^PEG3.NGFX, Local0)
				 DBGC (0xF6, 0x80, BCEN)
				 Return (Zero)
			 }

What do you think?

 

I can do some tests with fakesmc?

I have version 10.5.2 of Leopard.

Link to comment
Share on other sites

Here are the right download links for FakeSMC 3.

 

Ok, I wrote 0x00 and 0x80 to SODV, without any result.

 

 

How to read/write ACPI from OSX

 

If you want to try, download FakeSMC 3.1, smc_util2 and ACPIMonitor above, place it into Extra/Extensions. Now edit Info.plist of ACPIMonitor and add:

			   <key>keysToAdd</key>
			<dict>
				<key>SMC0</key>
				<string>SMC0</string>
				<key>SMCA</key>
				<string>SMCA</string>
				<key>SNCA</key>
				<string>SNCA</string>
				<key>SNCB</key>
				<string>SNCB</string>
				<key>SNCC</key>
				<string>SNCC</string>
				<key>SNCD</key>
				<string>SNCD</string>
				<key>SNCE</key>
				<string>SNCE</string>
				<key>SNCF</key>
				<string>SNCF</string>
				<key>SNCG</key>
				<string>SNCG</string>
				<key>SNCH</key>
				<string>SNCH</string>
			</dict>

In your dsdt add to the device "PDRC" (can be named different, then search for "PNP0C02") add "__CID monitor" and some test methods, for example the following:

			Device (PDRC)
		{
			Name (_HID, EisaId ("PNP0C02"))
			Name (_CID, "monitor")
...
		  Method (SMC0, 0, NotSerialized)
			{
				Store (\_TZ.TZ00._TMP (), Local0)
				Return (Local0)
			}
			Method (SMCA, 0, NotSerialized)
			{
				Store (\_TZ.TZ01._TMP (), Local0)
				Return (Local0)
			}
			Method (SNCA, 0, NotSerialized)
			{
				^^LPCB.SNC._INI ()
			}
			Method (SNCB, 1, NotSerialized)
			{
				Store (Arg0, Local0)
				Store (^^LPCB.SNC.SODV (Local0), Local1)
				Return (Local1)
			}
			Method (SNCC, 0, NotSerialized)
			{
				Store (^^LPCB.SNC.SODV (Zero), Local0)
				Return (Local0)
			}
			Method (SNCD, 0, NotSerialized)
			{
				Store (^^LPCB.SNC.SODV (0x80), Local0)
				Return (Local0)
			}
			Method (SNCE, 2, NotSerialized)
			{
				DBGC (0xF6, Zero, BCEN)
				Store (Arg0, AODV)
				Store (Arg1, Local1)
				If (LNot (And (AODV, CADD)))
				{
					Store (One, AODV)
				}
				If (LNotEqual (CADD, PADD))
				{
					Store (CADD, PADD)
					Notify (PCI0, Zero)
					Notify (PEG3, Zero)
					Sleep (0x02EE)
				}
				Notify (GFX0, Local1)
				Notify (^^PEG3.NGFX, Local1)
				DBGC (0xF6, 0x80, BCEN)
				Return (Zero)
			}
			Method (SNCF, 1, NotSerialized)
			{
				DBGC (0xF6, Zero, BCEN)
				Store (Arg0, Local0)
				Notify (PCI0, Zero)
				Notify (PEG3, Zero)
				Sleep (0x02EE)
				Notify (GFX0, Local0)
				Notify (^^PEG3.NGFX, Local0)
				DBGC (0xF6, 0x80, BCEN)
				Return (Zero)
			}
			Method (SNCG, 0, NotSerialized)
			{
				DBGC (0xF6, Zero, BCEN)
				Notify (PCI0, Zero)
				Notify (PEG3, Zero)
				Sleep (0x02EE)
				Notify (GFX0, 0x80)
				Notify (^^PEG3.NGFX, 0x80)
				DBGC (0xF6, 0x80, BCEN)
				Return (Zero)
			}
			Method (SNCH, 0, NotSerialized)
			{
				DBGC (0xF6, Zero, BCEN)
				Notify (PCI0, Zero)
				Notify (PEG3, Zero)
				Notify (GFX0, 0x80)
				Notify (^^PEG3.NGFX, 0x80)
				Sleep (0x02EE)
				DBGC (0xF6, 0x80, BCEN)
				Return (Zero)
			}
...
	   }

Methods SMC0/SMCA just return values, so try it after reboot with:

sudo -s
SMC_util2 -kSMC0 -r

The other methods are my test write methods (you can see it in the method header if it expects a parameter). For example:

SMC_util2 -kSNCF -w80

For a help page about what is smc_util2 capable of, write:

SMC_util2 -h

Link to comment
Share on other sites

 Share

×
×
  • Create New...