[TEQUILA-FIX] GraphicsEnabler, Black Screen and PCIRoot Fix for Chameleon

[iHack13]

Hey guys. original Post can be found here http://forum.voodooprojects.org/index.php/topic,1111.0.html

 

What you need to do to provide smthn:

 

- tell me if your PciRoot is found when booting up. (Can be seen for half a second after hitting OSX Install to boot up. If you only get one line or so , your PciRoot should be ok)

- Post the few lines under Device (PCI0) like I did in the original Post. In order to do that get this app DSDTSE and click "Extract dsdt" and use the searchbox

- Try to replace the old name with _UID

- tell me if PciRoot works for you now

- tell me if GraphicsEnabler=yes bootflag works for you now (remember to remove any injectors or EFI string)

 

lets see if we can get something working in this thread

______________

The Problem: Chameleon may not recognize the entry for the PciRoot in your DSDT even if it exists, since Chameleon RC4 only sees _UID entries for PciRoot ( proof in Chameleon Source/i386/libsaio/device_inject )

The idea: Getting Chameleon to see your PciRoot ( 0 or 1, doesn't matter), in order to get GraphicsEnabler working.

The Profits (if it works): Your Graphics will be fully recognized, without any Injector or String. Futureproof!

Note: Please don't mix up things. This Guide does NOT have to do anything with getting the values (0/1) right for your particular Motherboard. This guide shows you that even if you do have the right value, Chameleon may not find it, because of adressing issues.

 

First Step: See if Chameleon finds your PciRoot

Reboot if you are in the OS. I cant promise you that this will make your life easier but try to press the Pause key on your keyboard after hitting enter to boot up your OSX Install or try following boot flag

Wait=Yes

I hope it pauses/slows the output for you... if not, you need fast eyes and maybe several bootups to vaguely read the line.

 

Look if it says PciRoot found or not.

1. If it already finds your PCIRoot and only gives you one line in the beginning, then sorry this guide wont help you most likely.
   
2. If it tells you that it couldn't find the PciRoot, then try to boot with PciRoot=1 which is the alternative, since PciRoot=0 is default in RC4. If it finds the PciRoot now, then sorry look at 1).
   
3. If it still doesnt find it then continue.
   

Alternatively you can use the IORegistryEditor mentioned a step below, to see if PciRoot is recognized. Just check if it outputs a value for PciRoot ( _UID), look below for further information. I cant guarantee you whether this method is doubtfree tho...

 

Second Step: Getting PCIRoot information from your DSDT

 

Here you can choose one of the methods to obtain the information required. Use the other method if the once which you've chosen doesn't work for you.

 

// Please do post the Information in this thread.

 

A) Tequila Method, using DSDTSE

Get the DSDTSE Tool from >>> Click to Download DSDTSE <<<

 

Open it up. Click "Extract DSDT". It will take you to a new window. On the right search for "Device (PCI" . It should get you to the location.

IORegistryExplorer-method

 

The IORegistryEditor is also implemented into DSDTSE, just click on Get under Registry info. If you want to get the Tool separately you can download >>> IORegistryEditor here (indirect link) <<<

 

When you fire up the Tool, search PCI , first. Click on the PCI0 which is the entry below default selection and look if there is a PCIRoot value 0 or 1 on the right, e.g. in the form of _UID. Since we want to add the PciRoot information, there shouldn't be one and we are most likely good to go and continue..

 

Third Step: Add/Replace the information in your DSDT

 

In case your PciRoot's name is _ADR or something different, replace it with _UID like I did. If there is no such value, simply add the line. You can take a look at my special case.

 

Before:

		Device (PCI0)
	{
		Name (_HID, EisaId ("PNP0A08"))
		Name (_CID, EisaId ("PNP0A03"))
		Name (_ADR, Zero)
		Name (_BBN, Zero)
		OperationRegion (HBUS, PCI_Config, 0x40, 0xC0)
		Field (HBUS, DWordAcc, NoLock, Preserve)

 

After:

		Device (PCI0)
	{
		Name (_HID, EisaId ("PNP0A08"))
		Name (_CID, EisaId ("PNP0A03"))
		Name (_UID, Zero)
		Name (_BBN, Zero)
		OperationRegion (HBUS, PCI_Config, 0x40, 0xC0)
		Field (HBUS, DWordAcc, NoLock, Preserve)

 

In my case it doesn't matter if the value is Zero or 0x00.

 

On DSDTSE click Compile DSDT and either place the dsdt.aml in your /Extra folder respectively custom folder or use the Install DSDT button.

If you're not using this tool, then compile your dsdt.aml with the DSDT Patcher in Terminal. But simply stick to the tool if you are a novice.

 

Fourth Step: Reboot and Check your work

 

Before rebooting, check for any Graphics injection ( Injector kexts NVKush or NVEnabler , or EFI Strings etc ). All has to be clear, so your machine boots up in VESA without any QE and Full Res.

Check if Chameleon finds PciRoot at startup, like you did in Step one. Also boot with the flag

GraphicsEnabler=Yes

to see if Chameleon handles Gfx fine now. If it does then edit it into your Boot.plist in /Extra so you don't have to retype it every time you're booting up

 

Under construction

[Razorbackeve]

I did get the "Pci root not found" on boot, then i did a little check to my Device (PCI0) on DSDT, this is what i had:

 

Device (PCI0)
	  {
		  Method (_S3D, 0, NotSerialized)
		  {
			  Return (0x02)
		  }

		  Method (_S4D, 0, NotSerialized)
		  {
			  Return (0x02)
		  }

		  Name (_HID, EisaId ("PNP0A08"))
		  Name (_CID, EisaId ("PNP0A03"))
		  Name (SUPP, Zero)
		  Name (CTRL, Zero)
		  Method (_OSC, 4, NotSerialized)
		  {
			  If (LEqual (Arg0, Buffer (0x10)
					  {
						  /* 0000 */	0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40, 
						  /* 0008 */	0x96, 0x57, 0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66
					  }))

 

Then i reordered a little the code and added the "Name (_UID, Zero)" :

 

  Device (PCI0)
	  {
		  Name (_HID, EisaId ("PNP0A08"))
		  Name (_CID, EisaId ("PNP0A03"))
		  Name (_UID, Zero)						/* Added */
		  Name (SUPP, Zero)
		  Name (CTRL, Zero)
		  Method (_S3D, 0, NotSerialized)
		  {
			  Return (0x02)
		  }

		  Method (_S4D, 0, NotSerialized)
		  {
			  Return (0x02)
		  }

		  Method (_OSC, 4, NotSerialized)
		  {
			  If (LEqual (Arg0, Buffer (0x10)
					  {
						  /* 0000 */	0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40, 
						  /* 0008 */	0x96, 0x57, 0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66
					  }))

 

Now i don´t have the "Pci root not found" anymore.

 

 

[iHack13]

olaaaa amigo

 

I am almost done, check the guide

[MacManX]

Thanks for this post, my GraphicsEnabler is working now!

[sbg]

Thanks for this post, my GraphicsEnabler is working now!

Changed Name (_UID, One):

Name (_HID, EisaId ("PNP0A03"))
		Name (_ADR, Zero)
		Name (_UID, Zero)
		Name (_BBN, Zero)
		Name (_STA, 0x0F)
		Method (_CRS, 0, NotSerialized)

GraphicsEnabler is now working! Thanks!

[KariNeko]

Hi, what happens to all the other parts where _ADR is used?

[jerryfanyang]

Thanks! Got mine working! Acer Revo R1600.

 

I basically moved the UID line up right below the ADR line.

Complied and Installed. Changed pciroot to 0 instead of 1.

Works perfectly now!

 

Thanks!

 

Jerry

[dino7777]

Hello,

 

my mobo is a GigaByte P965-DS4 rev 3.1

 

it took me some time to get my HD4670 working with QE/CI, as I have to boot up with -pci1, i.e. put this kernel extension in boot plist.

 

My standard DSDT has _UID value 0x01

The newly generated DSDT gives me this value too

IORegistry Explorer gives my _ADR 0x0 and _UID 1 for PCI0@0, and the gfx is under the node pci-bridge@1

 

Currently I am using Chamleon RC3 and PCEFI 10.6 (/boot)

Automatic detection does not work, i.e. have to boot up with -pci1 in boot plist or at Chameleon console.

 

Reading posts about the HD4670 I assume that most Gigabyte mobos have pci root set at 1.

 

So if GraphicsEnabler does not work, just try

 

-pci1

[Beerkex'd]

Hi, what happens to all the other parts where _ADR is used?

Nothing. But if you want, you can leave _ADR as it is - just add _UID below _ADR.

 

I don't understand why, since I have this:

...I'm still getting this:

I'm using the AsereBLN 1.19 Chameleon 2.0 RC4 derivative and it works fine - I just don't get why it's still complaining about PCIRoot during bootup then.

 

/EDIT

 

Haha, frawress victoly!:

Thanks to Master Chief and Phoenix Wright for all your DSDT work.

[KariNeko]

Hi Beerkex'd, can I ask how you managed to fix it? I'm having the same symptoms as you, _UID is set, the bootloader is the same as the one you are using and the boot process complains the same thing.

Thanks in advance

[Beerkex'd]

I took a good look at all the other instances of _UID in my DSDT, and found that it always is on the second line.

 

Then I decided to place _UID on the second line (right below _ADR) and then it worked.

[KariNeko]

Thanks for the tip.

[Hacktrix2006]

When i add this to my DSDT i get a compile issue of 1319 Error Name already exists in scope (_UID). There is a UID in scope_pci area but unsure how to fix it.

[Gringo Vermelho]

That means your PCI0 already has _UID declared.

 

Move the existing one up below _ADR as already discussed here.

[krishan23]

I followed you instruction... now my boot got screwed up../.. man I am trying to enable GraphicsEnabler = yes for more than 3days.. I am getting failture....

 

I have post the capture... man i am going to give up... that's my fate that I should work in 1024x768 screen...

 

 

http://www.flickr.co...N03/6947190447/

 

it saying "Waiting for root devices" and no further movement.. f*ked up man

[Gringo Vermelho]

"Still waiting for root device" is not in any way related to what we are discussing in this topic.

 

It means that OS X for whatever reason cannot see the drive controller that your hard drive is connected to. Use the search or google to find solutions, your solution depends on what brand & model drive controller the drive is connected to and which patches you are using for it.

[oSxFr33k]

I have the Asus G51Jx I7-720M Laptop.

 

I see the PCIroot-UID-device 0x0

 

Then the usual Chameleon messages just before the kernel starts. Right after the kernel starts I get up to the point, [PCI Configuration Begin] but with no more verbose messages from this point on. It does boot to the desktop and I have full graphics acceleration. No problems with my GTX360M.

 

I do remember modifying my DSDT for the UID mod a long time ago.

 

I am looking for a fix to see the rest of the verbose messages before the desktop and to be able to boot into single user mode.

 

Is your thread mostly a fix for the graphics portion solely or a fix in order to see the rest of the verbose messages in console as well as single user mode?

 

That is what I need to fix.

[Gringo Vermelho]

This topic is two years old, the issue you're having didn't exist two years ago. The topic is about making sure that Chameleon auto detects the PCI Root correctly so that GraphicsEnabler=y and EthernetBuiltIn=y will work.

 

The issue you're having can in most instances be fixed by adding the kernel flag npci=0x2000 (for some people it's 0x3000).

This started happening with 10.6.8 - go find the release topic for the 10.6.8 update in the "new releases and updates" sub forum for more information.

[LatinMcG]

npci=0x2000 is the pci class for onboard vid. n is for no .. so it blocks onboard. vga

[Gringo Vermelho]

Hey that's interesting, where did you read that?

 

I remember reading a post by bcc9 (I think) where he talked about what the npci flag does but I don't remember him mentioning on board video.

 

It sort of makes sense, except I don't have any on board video to block and I use 0x2000.

There must be something else there then? Or is it just to prevent OS X from "looking there" at all?

0x3000 doesn't work for me.

 

Besides trying 0x3000 I haven't messed with it since I put it there after updating to 10.6.8. It works, so..

 

oSxFr33k: If this is true then since you're on a laptop you'll probably not want to use 0x2000, 0x3000 should work for you then. Not sure, I need more information. Try both and let us know what happens.

[LatinMcG]

i didnt read it .. was some things i noticed looking at pci device classes in lspci.

i guess it blocks those mem range addresses.

 

i think 0x3000 is hybrid optimus and so.

[Gringo Vermelho]

After I added a USB 2.0 PCI-E card I could remove npci=0x2000 - this was back when I was running Lion on my P5Q-E motherboard.

 

I am 100% positive that this is because the USB card has a PCI Bridge on it.