Sony Vaio VPCF115FM Discussion: DSDT Injection

[Funky frank]

This seems to be very interesting stuff:

ACPI Call - tool to call ACPI commands from terminal - Also there is the following comment:

# turn off discrete graphics card

echo '\_SB.PCI0.PEG1.GFX0.DOFF' > /proc/acpi/call

# turn it back on

echo '\_SB.PCI0.PEG1.GFX0.DON' > /proc/acpi/call

More info about Nvidia GPU poweroff/on

The related DSDT

 

If you look at the VAIO dsdt, there seem to be 2 gfx devices/cards/whatever, PCI0.PEGP and PCI0.PEG3. The variable PNHM controls whether PEG3 (== 0x000106E0 || 0x000106A0) or PEGP is addressed on many splaces in the DSDT. So maybe it a hybrid architecture inside?

[goila]

No AppleLPC is not loaded. In the dsdt the is a LPCB device on PCI0. In IORegistry there is a LPCB with name "8086,3b03" and compatible "pci104d,9067".

 

Edit: Added "8086,3b03" to AppleLPC.kext and now it's loaded. But the cpu is still very hot and the cooler runs all the time. How to enable proper power management now?

 

Edit: Ok, with 1. adding devid to AppleLPC.kext, 2. the option ForeceHPET=Yes, 3. GeneratePStates=yes and 4. GenerateCStates=Yes the cpu is not so hot anymore, but still runs hotter than under win7.

 

Edit: Hm, sleepmode does not work anymore....

 

Windows running at 930 MHz

[OoTLink]

The Vaio F uses the PM55 chipset, there is no hybrid GPU option in there.

[kizwan]

kizwan: Do you know what device is the ethernet device in the dsdt? Did you remove it in your DSDT?

Vendor 11ab Devid 4380, Yukon 88e8057, should be loaded by Yukon2.kext if editing pcimatch...

 

edit: I tried to patch the network device in dsdt like explained here. The strange thing is, in the VaioDST generated in OSX, there is only a P0PF device, in the Vaio DSDT generated in Windows (posted in this thread at beginning and dsdt_VAIO_windows.dsl.ziphere), there is only a P0P9 device. Also strange is Ethernet device is not listed in IOReg at all.

 

So I tried to patch the device like this:

            Device (P0PF)
            {
                Name (_ADR, 0x001E0000)
                Method (_PRW, 0, NotSerialized)
                {
                    Return (GPRW (0x0B, 0x04))
                }
            }

 

The original patch in the thread needs addresses like AR09, GP09 and GP9 that do not exists neither in OSX dsdt nor in Windows dsdt.

 

And why the dsdts are different? Because I have the recent BIOS update? Maybe there is something useful in the Windows DSDT.

You need to adjust the patch according to your DSDT. Patch Device (P0PF) instead of adding new device method.

 

About the different DSDT, I don't know about it. It should be the same. What application you use to extract DSDT in Windows? And what application you use to extract DSDT in OSX? Please use DSDT Editor to extract DSDT in Windows & OSX. Download & use DSDTEditor_Linux_Mac_Win.zip. You can use it in Windows & OSX because it is Java based application. Compare both DSDT.

 

This seems to be very interesting stuff:

ACPI Call - tool to call ACPI commands from terminal - Also there is the following comment:

 

More info about Nvidia GPU poweroff/on

The related DSDT

 

If you look at the VAIO dsdt, there seem to be 2 gfx devices/cards/whatever, PCI0.PEGP and PCI0.PEG3. The variable PNHM controls whether PEG3 (== 0x000106E0 || 0x000106A0) or PEGP is addressed on many splaces in the DSDT. So maybe it a hybrid architecture inside?

That is to enable & disable the Nvidia GPU, not display or internal LCD. You should already know whether your notebook have hybrid graphics or not. Usually DSDT was wrote for a broad range of notebook specification. It doesn't mean it have hybrid GPU (to be precise Nvidia Optimus technology) just because there is an entry in DSDT.

[teppi210]

I have problem graphic card for vaio F12.

 

My graphic card Geforce GT 310 with 512MB

 

THanks

Hmmm. I have been wondering about NVDANV50Hal.kext because the new MacBook Pro Update 1.3 is supposed to have all the updated files needed to natively support the GT 330M. I'm puzzled because I thought that once I installed 1.3 update, my GPU would just work, but was surprised when that did not happen. If you are saying there are no references to the GT 330M in NVDANV50Hal, then why is OS X insisting on loading it when there SHOULD be appropriate drivers available now from the 1.3 update? Where do you think the disconnect is? Isn't my assumption correct that the correct drivers should be able to be found and used now?

 

I am going to try changing the ID's and such and let you know the results,

 

again, I TRULY thank you for your help and appreciate all that you are doing for me. I am killing myself working on this thing solid now for the past two weeks. It is you that provide me hope that we may be able to get this to work.

 

THANK YOU VERY MUCH KIZWAN!!!!

 

[Funky frank]

You need to adjust the patch according to your DSDT. Patch Device (P0PF) instead of adding new device method.

 

About the different DSDT, I don't know about it. It should be the same. What application you use to extract DSDT in Windows? And what application you use to extract DSDT in OSX? Please use DSDT Editor to extract DSDT in Windows & OSX. Download & use DSDTEditor_Linux_Mac_Win.zip. You can use it in Windows & OSX because it is Java based application. Compare both DSDT.

Kizwan, sorry for this, I took the Windows DSDT from this post here, and thought it was for the F11 but it's not

 

That is to enable & disable the Nvidia GPU, not display or internal LCD. You should already know whether your notebook have hybrid graphics or not. Usually DSDT was wrote for a broad range of notebook specification. It doesn't mean it have hybrid GPU (to be precise Nvidia Optimus technology) just because there is an entry in DSDT.

Ok I already got this too I was just wondering if this obsolete code could cause an activation problem of the internal lcd since Snow Leopard runs on a lot of mac with dual graphics, so if the DSDT has code for it in it maybe SL thinks to active the second, stronger device... But I understand the nvidia graphics is already activated, it just does not recognize the internal display.

 

Btw. I looked into the SL 10.6.5 update into yukon2.kext, there is still no change or new support for new Marvel network devices.

 

Edit: Here seems to be Linux open source drivers for Marvell Yukon 88e8057: driver page marvell

 

Edit: Jesus Christ, Bluetooth suddenly works and I don't have any clue why... Lol

 

Edit: {censored}, really don't know why doesn't work anymore. I remove AppleLPC, used pre-SMBUS-patched AML and reinstalled NullCPUManagement.kext - Sleepmode still does not work. But i worked!

 

Edit: Webcam not works too

 

Edit: FOr Atheros AR9287 (wifi card) there is this Linux source and info available: linux source atheros ar9287

[OoTLink]

Bluetooth should work all along, it's supported by default, so is DVD burning and USB

[Funky frank]

Bluetooth should work all along, it's supported by default, so is DVD burning and USB

Was not here.

[Funky frank]

				<string>pci168c,2a</string>
			<string>pci106b,0086</string>
			<string>pci168c,1c</string>
			<string>pci168c,23</string>
			<string>pci168c,24</string>

 

The AirPortAtheros21.kext of OSX 10.6.5 has new PCI matches inside. Maybe it will work now with our Atheros "pci168c,2e"? f11 atheros linux AR9285 fix Maybe interesting

 

kizwan, Ootlink: Do you know where to find the wlan device in the f11 dsdt? Maybe patching it in this way, and using 10.6.5 IO80211Family.kext would work... IO80211Family.kext 10.6.5 patched for 2b and 2e

 

Oh I am sorry it seems some F11s have these Atheros devices built-in, but my actually has a Intel 6200AGN card inside, so there seems to be absoluty no support for it. This project looks most promising for me. But it just compiles for OSX 10.5.

[OoTLink]

lol, little backstory for ya really fast:

 

I don't have OS X on my Vaio at the moment; during the summer I blew at least a half dozen weekends trying to get OS X to behave, several re-installs, and then a hell of a lot of single user mode. With the hardest semester yet of classes in progress, I haven't exactly been enthusiastic about settting aside some hard drive space for a project that has yet to show any progress at all since the last time I touched it.

 

Please don't take that as a bad thing, it's a really hard process because there's next to zero documentation and everyone else that has tried this (midtown and extraspeed included), messed around with a Vaio for a few days, got fed up, and dumped it on ebay.

 

I really appreciate your work, especially that of Kizwan who has been trying since the beginning of this project as hard as he can to help us out (without even having a reason to! After all, he doesn't have a Vaio F).

 

 

IMHO the biggest, monumental problem is there's nothing like ioreg for Windows to peer into the situation and figure out why it works in Windows but not in OS X. We hardly know how these laptops are wired, other than that it uses an LVDS signal. Nobody knows how or why the backlight turns on, or why OS X detects the video card but never actually seems to detect the monitor.

 

See that's a problem - Kizwan I remember distinctly that when i had the video card recognized (with the proper NVDA50HAL.kext and NVDAResman.kext), that the ioreg report listed the video card, but no devices at all plugged into it (and that means the LCD wasn't even detected).

 

That we're going at this with DSDTs is actually a very good idea, I'm curious what bootloader you're using and how though, because when I last used Chameleon the build I had didn't seem to work with DSDTs at all.

 

Anyway, as a last interesting tidbit - Ubuntu's Nouveau driver recognizes the LCD, albeit at a really strange resolution (2048x1440?). I want to know why nouveau recognizes our LCDs! lol.

 

When I've gotten that far, I'll put OS X on my Vaio again and it'll be a matter of time before we have 1920x1080 support.

[OoTLink]

Mmmm Nouveau guys, thanks.

 

In Linux, when the nvidia driver doesn't support Vaios (as it usually doesn't)... in the dude's own words:

"on the linux nvidia driver you have to tell it that a DFP is actually present, in addition to providing an EDID for it, so you might have both problems too"

"it does. the EDID has to be retrieved via ACPI and it doesnt know how to do that yet. but before it even gets to that it has to be told that DFP-0 is connected."

 

What the heck do we call a DFP in OS X and how do we tell it that there's one there even if it doesn't detect it?

[First Last]

DFP in the xorg.conf means a digital flat panel. Every TFT display is treatened as an DFP device.

 

see the definition from the man page:

"The driver usually can autodetect the presence of a digital flat panel. In the case that this fails, this option can be used to force the driver to treat the attached device as a digital flat panel. With this driver, a digital flat panel will work only if it was POSTed by the BIOS, that is, the computer must have booted to the panel. If you have a dual head card you may also need to set the option CrtcNumber described above. Default: autodetected."

Src.: http://www.x.org/archive/X11R7.5/doc/man/man4/nv.4.html

 

What is meant with "booted to the panel"?

[OoTLink]

Thanks to a friendly member at macrumors, i was able to get us the 'device-properties' for an i5/i7 MacBook Pro (with the 330m!)

 

This is great, because we can use it to experiment with EDID injection

 

 

I've attached it, the idea is you can try using your own EDID and try a few values, then dump it into your boot.plist (or however you wish to use it) using something like OSX86Tools (which can import a plist file and convert it into the fat "device properties" hex mess at the bottom of boot.plist

 

I tried this, but my bootloader is pretty goofed up right now and is ignoring my Boot.plist files

 

Also: If you want to use it with a plist editor change the extension to .plist. There's a few EDID strings in this thread and you can always use SoftMCCS to grab yours.

gfxplist.txt

[OoTLink]

I think I'm getting somewhere! Using that gfx.plist (with a modified EDID), my LCD *still* doesn't come on, but I get 3 display interfaces in my ioregdump.

 

LCD, CRT, and HDMI. And they are on PEG3 beyond the NGFX object, bet you didn't see that coming!

 

I'm beginning to think some DSDT mojo might help, but still!

 

Look at attachments, ioregdmp is what I had to begin with, and with string modifications I'm at gdump2.txt now

 

I've also included the boot.plist with my EDID in it (and the gfx.plist which should also have my EDID in it )

 

 

BTW, the plist files end in .plist, I just converted them to .txt .. bceause that's the only way to make them uploadable XD

You'll notice that I changed the PCI on the 4th ACPI entry (where EDID is) to PCI(0x3, 0x0) .. this is how Chameleon recognizes my GT330m

gdump2.txt

ioregdmp.txt

com.apple.CurrentBoot.plist.txt

gfx.plist.txt

[Funky frank]

Maybe a "Notify (PEG3, 0x02)" or "Notify (PEG3.NGFX.LCD, 0x02)" somewhere at the right place could activate the LCD? 0x02 means "activate/unsleep". Please also watch the "GFX0.DD01" to "GFX0.DD08" devices which seem to be virtual display devices or something... DD02 has also brightness functions inside. Don't know if it's important.

 

offtopic:

kizwan: Do you know why only RP01 and RP02 devices appear in my ioreg, but no RP06... ? RP06 seems to be the internal ethernet device...

[kizwan]

offtopic:

kizwan: Do you know why only RP01 and RP02 devices appear in my ioreg, but no RP06... ? RP06 seems to be the internal ethernet device...

Usually it doesn't appear in IOReg if the PCI-Express port (RPXX) is not available (not implemented electrically). You can trace where the ethernet device is connected to which PCI-Express port in Windows Device Manager. Open the properties, go to Details tab & get the Parent value. It should consist of vendor & device ID. Locate it under System devices. When you found the device, open properties, go to Details tab & get the Address value. Search Name (_ADR, 0xAddress) in DSDT. you will found the correct RPXX.

[Funky frank]

kizwan, thanks a lot!

 

So here are some places in our F11-ACPI, taken from Win7:

 

Internal LAN (Marvell Yukon 88e8057):

 

ven/dev: 11ab/4380

Location in dsdt: RP03.PXSX

Parent device: "chipset PCI Express Root Port 3 - RP03" (8086/3b46), address "0x001c0002"

DSDT-status: Missing mac-like functions and naming

kext to hack: yukon2.kext

 

 

WLAN (Intel Centrino Advanced-N 6200 AGN):

 

ven/dev: 8086/422c

Location in dsdt: RP01.PXSX

Parent device: "chipset PCI Express Root Port 1 - RP01" (8086/3b42), address "0x001c0000"

DSDT: Missing mac-like functions and naming

kext to hack: None available, maybe iwiDarwin could support it (description says it supports PROSet/Wireless 6x00 devices in svn version), if it will have support for OSX 10.6.

 

 

nVidia Geforce GT 330m:

 

ven/dev: 10de/0a29

Location in dsdt: PEG3.NGFX

Parent device: "processor PCI Express Root port 1 - PEG3" (8086/D138), address "0x00030000"

DSDT-status: Hierarchy seems to be special, there exist also pseudo-deive "dd01" to "dd08". There is also a not used node "PEGP.NGFX" that is for Vaios with hybrid graphics processors.

kext to hack: NVDAHal50.kext

 

 

Realtek High Def Audio ALC275:

 

ven/dev: 10ec/0275

address: 0x0000000001

Location in dsdt: PCI0.HDEF

Parent device: "High Definition Audio Controller Intel" (8086/3b56), address "0x001b0000"

DSDT-status: Naming is ok, needs _DSM function and other

kext to hack: AppleHDA.kext with proper pin configuration or VoodooHDA.kext with proper dual device configuration (currently only detects the HDMI/Nvidia Audio device)

 

 

4 x nVidia Highdef Audio:

 

ven/dev: 10de/000a

addresses: 0x00000001,0x00000101,0x00000201,0x00000301

Location in dsdt: none

Parent device: "High Definition Audio Controller nVidia" (10de/0be2), "0x00000001", parent is PEG3 (8086/D138)

DSDT-status: devices and parents do not appear at all

kext to hack: AppleHDA (with proper DSDT entries) or VoodooHDA (unstable)

 

 

Internal LCD:

 

id: *PNP09ff

address: 0x0110

Location in dsdt: PEG3.NGFX.LCD

Parent device: "Gefore GT 330m" (10de/0a29)

DSDT-status: Seems to be quite complete, but is not active at login

kext to hack: ? NVDAHal50

[Funky frank]

I've also included the boot.plist with my EDID in it (and the gfx.plist which should also have my EDID in it )

 

Just to understand this, do I have to put these ACPI entries into chameleon's com.apple.Boot.plist ? Because I did and there is no change in my ioreg...

 

Edit: UNder IOACPIPlane I have PEG3.NGFX.LCD and so on without your ACPI patches. Where do they appear in your IOREG? Under IOService?

[OoTLink]

Frank, I was beginning to worry this morning that what I might've said was in fact caused by the newer NVDA50Hal.kext from the MBP update (which you are probably using), and NOT the gfx-strings lol

 

I Guess that was the case Oh well.

 

I still don't think there's much harm to come from screwing around with gfx-strings, but it looks like YET AGAIN we're back at a sorta square 1 situation ><

 

To me though it seems like OS X is guessing the computer is a 15" high res MacBook Pro. With the bare GPU driver I remote in and get 1680x1050.

 

That said, I was doing gfx-string tweaking and now I can't remote in at all, although OS X is running. I could really use a VGA monitor right now lol.

[Funky frank]

Frank, I was beginning to worry this morning that what I might've said was in fact caused by the newer NVDA50Hal.kext from the MBP update (which you are probably using), and NOT the gfx-strings lol

Can you tell me whether your LCD appears under the IOService tree or just under the IOACPIPane ?

[OoTLink]

Tell me what command to use to dump the IOService tree and I'll dump it..

 

Or do you want that one program? the registry explorer? Yea I can do that.. hehe

[Funky frank]

Tell me what command to use to dump the IOService tree and I'll dump it..

Can you just look into the IOService with IORegExplorer and look at the node PEG3.NGFX if there is LCD.

[OoTLink]

Nothing Grr. @#% it. *ebays his Vaio* or something

[Funky frank]

What about focusing on

 

1. Internal LAN

 

2. Internal sounddevice

 

?

 

I think it is quite presumably that we can make these two work. What do you think?

 

My OSX is already ok for audio editing (usb device) and programming...

[jlvaio]

http://www.insanelymac.com/forum/index.php...p;#entry1591866