Jump to content
VegasKarma

Master Chief's P5K PRO ACPI Warfare

908 posts in this topic

Recommended Posts

@scrax,

 

It is fine to remove unused code, but don't remove things you may need at a later stage. For example; P0Pn ports. You may want to use some kind of PCI card at a later stage, which won't work without the _PRT section and thus leave it in. BTW; you can read more about this _PTR Method here.

 

And while things appear to work for most people now, the next (major) OS upgrade may break things badly for us.

 

Also. What I want is a little fast boot loader. One that incorporates our modified DSDT.aml so that we don't have to load it anymore. I rather load my DSDT now, this instead of some unneeded theme related graphics, but this option is not yet available. An entirely different story of course, I know, but this would prevent people from flashing their BIOS, and still have a quick boot time.

 

Think about this: Why work this hard, to reduce the code size of one file – being our DSDT.aml – while other people keep adding bloat to your boot loader?

I totally agree.

Until now I use only the Apple Logo of chameleon. I'm thinking about integrate dsdt in bios, but for now i'm trying to assign the correct mac addres in bios because if you use more then the orginal chip you need to have the correct mac addres for the ethernet to work, now I can use various bios with this code at start up:

 

sudo ifconfig en0 up

sudo ifconfig en0 lladdr 00:1D:60:EA:CD:57

and reload Attansic .kext

 

the mac address need to be 00:1D:60:xx:xx:xx because is an asus card.

 

i've tried dmi236.exe /o 1"xxxxxxxxxxxx" but it doesn't work.

 

(sorry for the OT)

Share this post


Link to post
Share on other sites
Advertisement
Here's a first addendum to DSDT V3.3. Let's call it DSDT V3.3.1. The main reason for having it is to clear the "21 Optimizations", to get it down to zero.

 

I also took off another 50 bytes. Not by removing features or functionality, but by combining two OperationRegion / Field's under UHCI and EHCI. There are also a couple of other smaller changes, but you'll find out soon enough.

 

@scrax: I'll have to pass, for now. Too busy with other stuff. Sorry.

 

v3.3 up and running fine on VM - others verified. Just done the v3.3.1 addendum and that works fine for me also - thanks

Share this post


Link to post
Share on other sites
v3.3 up and running fine on VM - others verified. Just done the v3.3.1 addendum and that works fine for me also - thanks

Thank you for the confirmation DB1... and keep up the good work for P5K VM users!

 

To all: I would like to clarify something, just that people here don't get the wrong impression:

 

I love the work done by zef et all, the Chameleon developers, but I want something light and easy. Without all offered features, simply because I don't need them. That's why I called it bloat. Still good, essential even for most people. Thus no, I wasn't even (trying) to demonize their hard work. Not at all.

Share this post


Link to post
Share on other sites
To all: I would like to clarify something, just that people here don't get the wrong impression:

 

I love the work done by zef et all, the Chameleon developers, but I want something light and easy. Without all offered features, simply because I don't need them. That's why I called it bloat. Still good, essential even for most people. Thus no, I wasn't even (trying) to demonize their hard work. Not at all.

The source is avail, nothing prevent you to make your own "light and easy" version...

 

P.S. you are wrong about UAR1, mac do have serial port:

| +-o UAR1 <class IOACPIPlatformDevice, registered, matched, active, busy 0, retain 7>

| | +-o Apple16X50ACPI1 <class com_apple_driver_16X50ACPI, !registered, !matched, active, busy 0, retain 5>

| | +-o com_apple_driver_16X50UARTSync <class com_apple_driver_16X50UARTSync, registered, matched, active, busy 0, retain 10>

| | +-o IOSerialBSDClient <class IOSerialBSDClient, registered, matched, active, busy 0, retain 5>

That is from Xserve2,1 ioreg... ;)

Share this post


Link to post
Share on other sites
P.S. you are wrong about UAR1, mac do have serial port:

 

That is from Xserve2,1 ioreg... :)

Right. Let me rephrase that for the next update: "Not all Mac's have a serial port – removed because I don't need it". That should cover it. Thanks.

Share this post


Link to post
Share on other sites
Right. Let me rephrase that for the next update: "Not all Mac's have a serial port – removed because I don't need it". That should cover it. Thanks.

LOL you are so funny sometimes...my reply was not intented to offend you...just to point something that was explained wrong...

Anynone who want to do some serial debugging will love the port, especial with this method added on it:

                    Method (_DSM, 4, NotSerialized)
                   {
                       Store (Package (0x04)
                           {
                               "AAPL,connector", 
                               "DB9", 
                               "built-in", 
                               Buffer (0x01)
                               {
                                   0x00
                               }
                           }, Local0)
                       DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                       Return (Local0)
                   }

Add that and you will see some magic... ;)

Also serial can be used for UPS, I have 2 ports on my TrippLite 1400XL(yeah i know new one use USB, but I'm old fashion :P )

And many other stuff...

 

Another tip since I'm on my sharing day :)

Some definitions:

LDRC means LPC_Device_Resource_Consumtion

PDRC means PCI_Device_Resource_Consumption

Changing some AMI or AWARD device names dosen't have the same effect!

I've checked almost all Apple DSDT's and I can tell for sure they are the same for same platform, e.g. same for ICH8, or ICH8-M or ICH-7, ICH-10 etc.

 

Enjoy!

Share this post


Link to post
Share on other sites
Anynone who want to do some serial debugging will love the port, especial with this method added on it:

					Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x04)
						{
							"AAPL,connector", 
							"DB9", 
							"built-in", 
							Buffer (0x01)
							{
								0x00
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}

 

King, what does your UAR1 device look like in your DSDT?

 

Something like this? I'm wondering how slim I can make the DSDT patch.

				Device (UAR1)
			{
				Name (_HID, EisaId ("PNP0501"))
				Name (_UID, One)
				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x04)
						{
							"AAPL,connector", 
							"DB9", 
							"built-in", 
							Buffer (0x01)
							{
								0x00
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}
			}

Share this post


Link to post
Share on other sites

ASUS chose to not add serial port on P6T6 WS Revolution :angel:

But I did tested that _DSM code on my Atom board :angel:

Add it on existing code, not just that...

Share this post


Link to post
Share on other sites
LOL you are so funny sometimes...my reply was not intented to offend you...just to point something that was explained wrong...

But I wasn't offended. Not at all. I was merely correcting a comment in my DSDT. That's all. I mean when people need it, they won't remove it. Otherwise we'll hear about it anyway.

 

Another tip since I'm on my sharing day :)

Some definitions:

LDRC means LPC_Device_Resource_Consumtion

PDRC means PCI_Device_Resource_Consumption

Changing some AMI or AWARD device names dosen't have the same effect!

I've checked almost all Apple DSDT's and I can tell for sure they are the same for same platform, e.g. same for ICH8, or ICH8-M or ICH-7, ICH-10 etc.

 

Enjoy!

Is this about my error, the mix up I mentioned some time ago?

Share this post


Link to post
Share on other sites

I have been playing with my DSDT and got here:

 

ASL Input: dsdt-332.dsl - 1379 lines, 53267 bytes, 214 keywords

AML Output: ./dsdt.aml - 2994 bytes, 163 named objects, 51 executable opcodes

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

 

Pretty awesome since everything is still functional. Well. I had to remove SBUS and EC, otherwise this would not have been possible.

 

Note: I moved my graphics and USB device-id's back into com.apple.Boot.plist because that way it is quicker – the file is loaded anyway. Now I only see 7 revs with the stock CPU speed. The unneeded kext removal action I did earlier, as a test, may be a good thing to do now.

 

Edit: Oops. I lost audio. Let me check that... Got it. Back to 3072 bytes. Looking for another 72+ bytes now ;)

 

Dang!!!

 

ASL Input: dsdt-332.dsl - 1380 lines, 53189 bytes, 164 keywords

AML Output: ./dsdt.aml - 2359 bytes, 127 named objects, 37 executable opcodes

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

 

Didn't make 2K :P

 

Still an awesome low 0.066% (down from 35,633 bytes of the factory dsdt.aml) which is what we started to work with ;)

Share this post


Link to post
Share on other sites
I have been playing with my DSDT and got here:

ASL Input: dsdt-332.dsl - 1380 lines, 53189 bytes, 164 keywords

AML Output: ./dsdt.aml - 2359 bytes, 127 named objects, 37 executable opcodes

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

 

Didn't make 2K :)

 

Still an awesome low 0.066% (down from 35,633 bytes of the factory dsdt.aml) which is what we started to work with -_-

Wow when I complied your last 3.3.1 I got:

ASL Input:3.3.1 dsdt.dsl - 1932 lines, 82499 bytes, 647 keywords

AML Output:3.3.1 dsdt.aml - 6902 bytes, 317 named objects, 330 executable opcodes

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

 

Were you really able to squeeze that much more out in 3.3.2, even with removing SBUS and EC?

Share this post


Link to post
Share on other sites
ASUS chose to not add serial port on P6T6 WS Revolution :)

But I did tested that _DSM code on my Atom board :D

Add it on existing code, not just that...

You wouldn't happen to have the DSDT for the Xserve would you? If so could you post it? The amount of code required to get the serial port working from Gigabyte is enormous. Hoping to compare it against Apple's.

Share this post


Link to post
Share on other sites
You wouldn't happen to have the DSDT for the Xserve would you? If so could you post it? The amount of code required to get the serial port working from Gigabyte is enormous. Hoping to compare it against Apple's.

 

i don't think that Xserve dsdt will help you a lot unless it uses the same Super-I/O chip as your board. IT8718F datasheet is probably more useful if you want to try slimming down that code.

Share this post


Link to post
Share on other sites
Note: I moved my USB device-id's back into com.apple.Boot.plist because that way it is quicker

 

please tell me more about this, i was aware that only graphics/ethernet could be in com.apple.Boot.plist

Is something related to this:

 

<key>USBBusFix</key>

<string>Yes</string>

 

@THe KiNG

You are right about the source code, I (like anybody) have the opportunity to make my ChameleonLite but only knowing how to do it.

Maybe...

Can you tell me how to do it?

If not my only solution is to wait somebody else Lite version, and use the actual without GUI in preferences.

Another option is to install dev tool and start making an "hello world" app, but for the time that I know how to program I think that OsX could be PC compatible directly from Apple

Share this post


Link to post
Share on other sites
Wow when I complied your last 3.3.1 I got:

ASL Input:3.3.1 dsdt.dsl - 1932 lines, 82499 bytes, 647 keywords

AML Output:3.3.1 dsdt.aml - 6902 bytes, 317 named objects, 330 executable opcodes

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

 

Were you really able to squeeze that much more out in 3.3.2, even with removing SBUS and EC?

More even:

 

ASL Input: dsdt-332.dsl - 1390 lines, 53338 bytes, 164 keywords

AML Output: ./dsdt.aml - 2097 bytes, 127 named objects, 37 executable opcodes

 

Note: I have taken out – read comment out – everything I don't use/need. Even the unused P0Pn and ditto IRQ assignments, all in an insane attempt to get below the 2000 marker. I also plan to disable and remove all unused UCH[1/6] USB code, which I think will result in far less AML code.

 

Edit: I am currently adding comments, lots of them, about where how much bytes can be gained. I'll attach it here when I'm done with it.

 

please tell me more about this, i was aware that only graphics/ethernet could be in com.apple.Boot.plistIs something related to this:

I will after, the usual morning coffee break (I woke up not too long ago). Oops. I forgot a birthday party. Gotta go have that nice big piece of... whatever they have for me now ;)

Share this post


Link to post
Share on other sites

Okay. So you want to set/change certain properties. Fine. Let's start with a code snippet:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PciRoot(0x0)/Pci(0x1A,0x0)</key> //UHC4
<dict>
	<key>device-id</key>
	<string>0x3a37</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1A,0x1)</key> // UHC5
<dict>
	<key>device-id</key>
	<string>0x3a38</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1A,0x2)</key> // UHC6
<dict>
	<key>device-id</key>
	<string>0x3a39</string>
</dict>
[color="#FF0000"]	<key>PciRoot(0x0)/Pci(0x1a,0x7)</key> // EHCI
<dict>
	<key>device-id</key>
	<string>0x3a3c</string>
</dict>[/color]
<key>PciRoot(0x0)/Pci(0x1D,0x0)</key> // UHC1
<dict>
	<key>device-id</key>
	<string>0x3a34</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1D,0x1)</key> // UHC2
<dict>
	<key>device-id</key>
	<string>0x3a35</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1D,0x2)</key> // UHC3
<dict>
	<key>device-id</key>
	<string>0x3a36</string>
</dict>
[color="#FF0000"]	<key>PciRoot(0x0)/Pci(0x1D,0x7)</key> // UHCI
<dict>
	<key>device-id</key>
	<string>0x3a3a</string>
</dict>[/color]
<key>PciRoot(0x0)/Pci(0x1F,0x7)</key> // SATA
<dict>
	<key>device-id</key>
	<string>0x2681</string>
</dict>
</dict>
</plist>

This code snippet is the human 'readable' variant, in XML format, but you need to convert it to hex format with gfxutil (search for it). Then add the new device properties with EFIStudio (again search for it). And do a reboot. That's all to it.

 

This is a good way of fixing device-id's without the need of a DSDT.aml and/or BIOS modification. Especially for people who want/need Windows/Linux compatibility, thus they won't like to change all kind of device ID's or nothing works anymore.

Share this post


Link to post
Share on other sites

Hi MC, I discovered that the new _PTS method breaks Hibernation (is it S4?). The system just tries to go to normal sleep (S3), the power button light blinks and than it reboots instead of shutting down, the CMOS also resets. I tried with the old _PTS and it works fine.

Just do "sudo pmset -a hibernatemode 1" to get hibernation instead of sleep (use 0 to revert back).

I hope this is easy to fix :wacko:

Share this post


Link to post
Share on other sites
Hi MC, I discovered that the new _PTS method breaks Hibernation (is it S4?). The system just tries to go to normal sleep (S3), the power button light blinks and than it reboots instead of shutting down, the CMOS also resets. I tried with the old _PTS and it works fine.

Just do "sudo pmset -a hibernatemode 1" to get hibernation instead of sleep (use 0 to revert back).

I hope this is easy to fix :wacko:

Eh... this is broken since when exactly? I mean you wrote: "the old _PTS" not the original or (one of) the previous one. Making it hard for me to verify/reproduce it.

 

p.s. Yes S4 is hibernation.

Share this post


Link to post
Share on other sites
Eh... this is broken since when exactly? I mean you wrote: "the old _PTS" not the original or (one of) the previous one. Making it hard for me to verify/reproduce it.

 

p.s. Yes S4 is hibernation.

With the original one, I couldn't get it to work with all the previous ones.

Share this post


Link to post
Share on other sites
With the original one, I couldn't get it to work with all the previous ones.

Interesting. Something to check, at a later stage. Let you know when I found the problem, or PM me if I forget about it.

 

To all: I am about to attach an insanely small – only 2024 bytes – but still fully functional DSDT as an example / a study object only, because I know that people are going to fall over it, jump right in and get back hundreds of times with all sort of complaints, and questions, simply because they don't know what to do with it. Not exactly something I am waiting for, but here we go; compiling...

 

ASL Input: dsdt.dsl - 1460 lines, 55943 bytes, 152 keywords

AML Output: ./dsdt.aml - 2024 bytes, 121 named objects, 31 executable opcodes

 

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

 

Okay. Uploading file from anonymous server... And here it is!

 

p.s. You'll find comments all over the place, as usual – to let you know where how much bytes were taken off of the AML file.

 

And as always: Happy Hacking!

dsdt.dsl.zip

Share this post


Link to post
Share on other sites

I located my audio boot bottleneck. It's caused by AppleHDAPlatformDriver (in AppleHDA.kext Plugins) and specifically its enormous – over 2MB (2.364.890 bytes) – Info.plist.

 

What I did to "fix" it, as a work around, was to copy the data from my Legacy kext into it, resulting in a much smaller file (only 75236 bytes) and now everything it is cool again. Well. Except for the following – soon to be dog food – sound assertions:

 

Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAWidget.cpp" at line 3641 goto handler

Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 989 goto handler

 

And of course... no more: "Waiting for DSMOS..." for me :thumbsup_anim:

Share this post


Link to post
Share on other sites

Ok I'm now shure that with this new dsdt, anche info about the efi ijection i'll not sleep for a few day :P

 

I've managed to put usb in my com.apple.Boot.plist and it's working as expected. Now i'll try to put also my lpc device, so in the future update from your dsdt i've une thing less to correct for my mobo.

Also for the usb fix, are you gonna eliminate from the 3.4 dsdt or it was just a test?

 

As always, thanks for sharing

Share this post


Link to post
Share on other sites

Aha! Just to let (other) people know: The new Chameleon (RC4) is out. Go get it from chameleon.osx86.hu and give it a try!

 

Here is a quick Changelog highlight:

 

Fixed booting the default partition when using timeout. Added Intel Core i5 detection.

Applied rivig’s patch against all stage 1 loaders. Now linear address mapping uses 12 bit offsets. Added DigitalDJ’s SMBIOS CPU detection patch. Applied IntVar’s system-id patch. Applied hnak’s read_lba register saving patch. Added radekg’s HFS filesystem fix to handle 2GB+ file sizes. Backported ATI device injection EFI64 tables and hibernation fix from netkas’ PC_EFI. Thanks and credits goes for them!

Share this post


Link to post
Share on other sites
Ok I'm now shure that with this new dsdt, anche info about the efi ijection i'll not sleep for a few day :gun:

Sleep is more important. This can wait. Don't forget to sleep in time!

 

I've managed to put usb in my com.apple.Boot.plist and it's working as expected. Now i'll try to put also my lpc device, so in the future update from your dsdt i've une thing less to correct for my mobo.

You got it. Great!

 

Also for the usb fix, are you gonna eliminate from the 3.4 dsdt or it was just a test?

Like I said: I am not trying to get the smallest possible DSDT ever, but the next update will however include a number of patches from the "insane DSDT". Of course, but not all of it.

 

BTW: My first goal was to satisfy my own curiosity about ACPI coding. And because of this I was able to lower the barrier for other people. For non-developers, people like yourself. Or at least that's what I hear from people PM'ing me.

 

I'm also trying to change the way (some) people think about (code) sharing. Which I think is the biggest asset of my work. Sharing. I mean without sharing we would have been... nowhere. Right?

 

And I don't know everything. Of course not. Sometimes I have to search and think hard to get something done. And this next to other work (hello Mozilla). Not being afraid to make mistakes is a plus. Probably because mistakes are just that. Mistakes. No wrong doing whatsoever. I mean; Aren't we all learning something new here?

 

Sorry. Had to get something off my chest. Done!

Share this post


Link to post
Share on other sites
Okay. So you want to set/change certain properties. Fine. Let's start with a code snippet:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PciRoot(0x0)/Pci(0x1A,0x0)</key> //UHC4
<dict>
	<key>device-id</key>
	<string>0x3a37</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1A,0x1)</key> // UHC5
<dict>
	<key>device-id</key>
	<string>0x3a38</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1A,0x2)</key> // UHC6
<dict>
	<key>device-id</key>
	<string>0x3a39</string>
</dict>
[color="#FF0000"]	<key>PciRoot(0x0)/Pci(0x1a,0x7)</key> // EHCI
<dict>
	<key>device-id</key>
	<string>0x3a3c</string>
</dict>[/color]
<key>PciRoot(0x0)/Pci(0x1D,0x0)</key> // UHC1
<dict>
	<key>device-id</key>
	<string>0x3a34</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1D,0x1)</key> // UHC2
<dict>
	<key>device-id</key>
	<string>0x3a35</string>
</dict>
<key>PciRoot(0x0)/Pci(0x1D,0x2)</key> // UHC3
<dict>
	<key>device-id</key>
	<string>0x3a36</string>
</dict>
[color="#FF0000"]	<key>PciRoot(0x0)/Pci(0x1D,0x7)</key> // UHCI
<dict>
	<key>device-id</key>
	<string>0x3a3a</string>
</dict>[/color]
<key>PciRoot(0x0)/Pci(0x1F,0x7)</key> // SATA
<dict>
	<key>device-id</key>
	<string>0x2681</string>
</dict>
</dict>
</plist>

This code snippet is the human 'readable' variant, in XML format, but you need to convert it to hex format with gfxutil (search for it). Then add the new device properties with EFIStudio (again search for it). And do a reboot. That's all to it.

 

This is a good way of fixing device-id's without the need of a DSDT.aml and/or BIOS modification. Especially for people who want/need Windows/Linux compatibility, thus they won't like to change all kind of device ID's or nothing works anymore.

 

This is an interesting approach. Just so people know. If you're looking for the PCI address of ANY of your devices not just your GFX card. All you have to do is use the command

./gfxutil -f pci8086,3a34

it should spit out something like:

DevicePath = PciRoot(0x1)/Pci(0x1d,0x0)

 

Just change he device ID of the one you want the address for. And if you don't know how to get your device IDs... use lcspi.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×