InfiniteMac OSx86 - View Single Post

Stephen.Eidson · 09-16-2010, 12:22 PM

Ah. Would you mind sharing the new changes?

So, even after playing around with every BIOS setting, I still wasn't able to boot iBoot. I played around with EmpireEFI, newer versions of myHack, and others, but I couldn't get anything to boot like I had with myhack 1.0 final back in the spring.

My system currently works, but I'm wanting to make the full switch to DSDT hacks for optimization. As a side bonus, once I get the DSDT tweaked I should be able to actually boot off of something other than my hdd.

I've tried for months to work with DSDTSE, but I was always getting the NilObjectException error. Finally, after messing with install locations to no end, I was able to install it to a myHack thumbdrive and actually access extract the table.

In the guide you say you must be booted with iBoot for DSDTSE to work. Is this just a way to get around the NilObjectException error, or is there something else I'm missing?

At this point, I've done the Ubuntu liveCD boot and have gotten past the changing of Scope(_PR). A couple of notes:

1. For anyone not familiar with Ubuntu, it might be useful to note that additional repositories have to be enabled for apt-get to install acpidump and iasl.
2. The part of checking if _PSD coincides with ist.dsl and if the "Package (0x04)" in _CST are in cst.dsl is stopping me because I don't know how precisely similar they have to be. Can you look over what I've done?

I think the _PSD is alright...

ist.aml (_PSD):

Code:

Method (_PSD, 0, NotSerialized)
        {
            Return (Package (0x01)
            {
                Package (0x05)
                {
                    0x05, 
                    0x00, 
                    0x00, 
                    0xFE, 
                    0x08
                }
            })
        }

dsdt.aml _PSD:

Code:

Name (_PSD, Package (0x05) 
        	{
				0x05, 
				Zero, 
				Zero, 
				0xFE, 
				0x08
			})

...but the _CST has me concerned, because there are some blocks in my cst.aml that match perfectly like 0x0...0815 in this code, but others aren't present in the dsdt.aml. For example, the 0x00...00816 in this code:

cst.aml _CST / Package (0x04):

Code:

Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (SystemIO, 
                                    0x08,               // Bit Width
                                    0x00,               // Bit Offset
                                    0x0000000000000815, // Address
                                    ,)
                            }, 

                            0x03, 
                            0x80, 
                            0x015E
                        }, 

                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (SystemIO, 
                                    0x08,               // Bit Width
                                    0x00,               // Bit Offset
                                    0x0000000000000816, // Address
                                    ,)
                            }, 

                            0x03, 
                            0xA0, 
                            0xC8
                        }

dsdt.aml _CST Package (0x04):

Code:

			Package (0x04)
				{
					ResourceTemplate () 
					{
						Register (SystemIO, 
						0x08,	// Bit Width
						0x00,	// Bit Offset 
						0x0000000000000815, // Address 
						,)
					},
					
					0x03, 
					0x80, 
					0x015E
				}

So, sorry for this exhaustive post, but I'm kind of stuck. Is this because I generated the DSDT while booted with extra kexts, or is it just because my 2.5 BIOS is different than the BIOS you used when you wrote up the guide? Any help would be greatly appreciated! Attached are all three edited files, if that helps at all.