Jump to content
VegasKarma

Master Chief's P5K PRO ACPI Warfare

908 posts in this topic

Recommended Posts

Done.

Its definitely faster. About 10+ spins less than loading from dsdt.aml file

 

Does this have any effect on your Window or Linux installs, if any?

Share this post


Link to post
Share on other sites
Advertisement
Does this have any effect on your Window or Linux installs, if any?

 

Probably yes. Still need to test XP (is what I use).

OSX runs like a charm

Share this post


Link to post
Share on other sites
Done.

Its definitely faster. About 10+ spins less than loading from dsdt.aml file

Great to have brave people here. I hope to have the same luck in a couple of hours from now. I tried it before but I kept running into some checksum error. Hopefully that's now something of the past.

 

And a reduction of ten revs here would be totally awesome.

 

PRE-DSDT V3.3 UPDATE – THIS MIGHT NOT BE RIGHT!!!!! – but it works here.

It was a nice idea, but unfortunately also a flawed one it seems. The problem is – I think – that the IRQ pin numbers are always the same. That might not be right. What a bummer :rolleyes: LOL I should have taken this cup of coffee sooner. The weird thing is that it works here. Testing...

 

Edit: Good news. I checked the IRQ's with ioreg and they are the same – with and without this change – and thus it appears to work after all!

 

Remember this:

            Device (P0P4)                                      // PCI Express Port 1
           {
               Name (_ADR, 0x001C0000)
               Name (_PRT, Package (0x04)                     // PCI Routing Table AR04 (ACPIspec30a.pdf / 6.2.11 / page 204).
               {
                   [color="#FF0000"]Package (0x04) { 0xFFFF, Zero, Zero, 0x10 },
                   Package (0x04) { 0xFFFF,  One, Zero, 0x11 },
                   Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 },
                   Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 }[/color]
               })
               Name (_PRW, Package (0x02)                     // Power Resources for Wake (ACPIspec30a.pdf / 7.2.10 / page 259).
               {
                   0x09, 
                   0x04
               })
           }

Well. So long. Here's the new one:

            Device (P0P4)                                      // PCI Express Port 1
           {
               Name (_ADR, 0x001C0000)
               Name (_PRT, Package (0x04)                     // PCI Routing Table (ACPIspec30a.pdf / 6.2.11 / page 204).
               {
                   [color="#FF0000"]IRQA, IRQB, IRQC, IRQD[/color]
               })
               Name (_PRW, Package (0x02)                     // Power Resources for Wake (ACPIspec30a.pdf / 7.2.10 / page 259).
               {
                   0x09, 
                   0x04
               })
           }

And all you need to do for this to work is to add the following code snippet:

			// IRQ Definitions (60 bytes - 15 bytes each).
		Name (IRQA, Package (0x04) { 0xFFFF, Zero, Zero, 0x10 })
		Name (IRQB, Package (0x04) { 0xFFFF,  One, Zero, 0x11 })
		Name (IRQC, Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 })
		Name (IRQD, Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 })

Right after Name (_PRT, Package (...{ } in your Device (PCI0) and replace the _PRT packages in the devices: P0P2, P0P4, P0P5, P0P6, P0P7, P0P8 and P0P9 As in simply replace the lines with the corresponding IRQn. And you could make that another one liner like so:

Name (_PRT, Package (0x04) { IRQA, IRQB, IRQC, IRQD })

Anyway. This way we all know what it does / is used for, simply because the names tell us something. And the good news is that it is 26 bytes less per block (7 * 26 = 188) but we have to add 60 bytes for the IRQ definitions. Still good for another code reduction of 122 bytes!! Well. Have fun now.

 

p.s. I didn't had the time to change all _PRT sections (think PCI0 and PCIB here) but I will do these (a few lines more) after the coffee break.

 

And as always: Happy Hacking!

Share this post


Link to post
Share on other sites
Great to have brave people here. I hope to have the same luck in a couple of hours from now. I tried it before but I kept running into some checksum error. Hopefully that's now something of the past.

You can have a look to my files here if you like (theres no much to it):

http://www.mediafire.com/?ji2dyzzynwy

 

But I can confirm the custom dsdt wont let me boot my old windows XP install (safe mode does but no USB), nor a XP live CD I have around, nor Ubuntu 9.04 live CD. For me is fine as I dont need to use those for now, but is good to know.

I tend to belive that the problem is caused by the fake IDs (for USB, SATA, etc) Im injecting. Just a guess

Share this post


Link to post
Share on other sites
You can have a look to my files here if you like (theres no much to it):

http://www.mediafire.com/?ji2dyzzynwy

 

But I can confirm the custom dsdt wont let me boot my old windows XP install (safe mode does but no USB), nor a XP live CD I have around, nor Ubuntu 9.04 live CD. For me is fine as I dont need to use those for now, but is good to know.

I tend to belive that the problem is caused by the fake IDs (for USB, SATA, etc) Im injecting. Just a guess

We can of course check the OS string and change the ID's accordantly... dead easy. Here's how:

Scope (\_SB)
{
       [color="#FF0000"]Method (_INI, 0, NotSerialized)
       {
               Name (TargetID, Original-ID)
               ...

               If (CondRefOf (_OSI, Local0))
               {
                       If (_OSI ("Darwin"))
                       {
                               Store (Darwin-specific-ID, TargetID)  
                               ...
                       }
               }
       }[/color]

       Device (PCI0)
       {
               ...

Here we only change a certain ID when Darwin is used. All other OS'es use the default/original ID. Makes it a bit more difficult to read maybe, but then it works (I just wonder if the SATA code removal isn't causing you major trouble).

Share this post


Link to post
Share on other sites
We can of course check the OS string and change the ID's accordantly... dead easy.

I just wonder if the SATA code removal isn't causing you major trouble

Thanx man, as always! I still need to understand how to implement that code. But I guess first will be wise to know what is actually causing the problem. As you say might very well be the missing SATA code...

I wont be able to do much now, as Im leaving tomorrow on a trip to southamerica for six weeks (yeah!)

I'll try to catch up when Im back!!

Share this post


Link to post
Share on other sites
Thanx man, as always! I still need to understand how to implement that code. But I guess first will be wise to know what is actually causing the problem. As you say might very well be the missing SATA code...

I wont be able to do much now, as Im leaving tomorrow on a trip to southamerica for six weeks (yeah!)

I'll try to catch up when Im back!!

Six weeks? Man that's awesome. Have fun there! Keep an eye on your luggage... all the time ;)

 

To all: Here's my new _PR block for DSDT V3.3:

    Scope (_PR) // Processor scope (namespace).
   {
       Name (PSS, Package (0x04)
       {
           // This needs to match your CPU (use the P-State Calculator for it)
           Package (0x06) { 2498, 88000, 0x10, 0x10, 0x4720, Zero },
           Package (0x06) { 2331, 59643, 0x10, 0x10, 0x071E,  One },
           Package (0x06) { 2165, 51124, 0x10, 0x10, 0x461C, 0x02 },
           Package (0x06) { 1998, 41880, 0x10, 0x10, 0x0616, 0x03 }
       })

       Name (PSD, Package (0x05)
       {
           0x05,
           0x00,
           0x00,
           0xFC,
           0x04
       })

       Name (CST, Package (0x04)
       {
           0x03,  // Number of C-State packages: 3 (C1, C2 and C3).
           Package (0x04)
           {
               ResourceTemplate ()
               {
                   Register (FFixedHW, 
                       0x01,               // Bit Width
                       0x02,               // Bit Offset
                       0x0000000000000000, // Address
                       0x00,               // Access Size
                       )
               },
               One, 
               One, 
               0x03E8
           }, 

           Package (0x04)
           {
               ResourceTemplate ()
               {
                   Register (SystemIO, 
                       0x08,               // Bit Width
                       0x00,               // Bit Offset
                       0x0000000000000814, // Address
                       ,)
               },
               0x02,
               One,
               0x01F4
           }, 

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

       Processor (CPU1, 0x01, 0x00000810, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }

       Processor (CPU2, 0x02, 0x00000810, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }

       Processor (CPU3, 0x03, 0x00000810, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }

       Processor (CPU4, 0x04, 0x00000810, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }
   }

And this results in a stunning reduction of 28 bytes – I'm joking of course.

 

The idea was to get rid of \_PR.CPU1. simply because it made the use of Alias more expensive (in terms of bytes). It should now also be easier to understand. At least I hope it is.

Share this post


Link to post
Share on other sites
And this results in a stunning reduction of 28 bytes – I'm joking of course.

Compile then decompile the resulted .aml you will have some surprise :mellow:

Share this post


Link to post
Share on other sites
Compile then decompile the resulted .aml you will have some surprise :)

Eh. I did. It's exactly the same – with the usual exception of the PSS packages being put on separate lines. So what should I be looking at?

 

Edit: I now also moved Method (PNOT) into the _PR scope:

        Method (PNOT, 0, Serialized)	// Newly added – Power Management Notifier.
       {
           Notify (CPU1, 0x80)		// Notify OSPM - this triggers a re-evaluation of our _PPC object (all states available).
           Sleep (0x64)		// Let it sleep for 100us - giving it some time to response to our previous notification.
           Notify (CPU1, 0x81)		// Notify OSPM once more, this time to trigger a re-evaluation of our _CST object.

           Notify (CPU2, 0x80)
           Sleep (0x64)
           Notify (CPU2, 0x81)

           Notify (CPU3, 0x80)
           Sleep (0x64)
           Notify (CPU3, 0x81)

           Notify (CPU4, 0x80)
           Sleep (0x64)
           Notify (CPU4, 0x81)
       }

Saving an additional 36 bytes – making it 64 in total.

 

Edit: We're getting pretty close to a next release. Currently with a stunning code reduction of 412, 608, 718, 1005 bytes so I call it a day. Let's wrap it up and release DSDT V3.3 – right after I have done some testing myself :whistle:

 

DSDT V3.3 has been released today – see attachments in post #3

 

The size of our previous update was:

dsdt.dsl 95.260 bytes

dsdt.aml 7.957 bytes

 

And todays update:

dsdt.dsl 82.197 bytes

dsdt.aml 6.952 bytes

 

Almost 13% off of dsdt.aml – in just a few hours – which unfortunately doesn't qualify for a significant update, but my hardware let me down ;)

 

Once again; The attached zip file (see post #3) includes two diff files. One against the extracted vanilla DSDT from BIOS V1303 and the other against our previous release.

 

And as always: Happy Hacking!

Share this post


Link to post
Share on other sites
DSDT V3.3 post #535 (page 27)

 

Thank's, I'm gonna try it now.

 

to adapt v3.2 to my board I changed:

Some Firewire value

Name (_GPE, 0x1[color="#0000FF"]E[/color])

Method (_L1[color="#0000FF"]E[/color], 0, NotSerialized)					// Newly added for FireWire support.
		{
			Notify (\_SB.PCI0.PCIB.FRWR, Zero)

 

was 1B

 

added LPCB support for ICH9 chipset with:

 

Method (_DSM, 4, NotSerialized)
{
Return (MCID (Arg2, [s]0x3a188086[/s]))   //Note better use: [color="#FF0000"]0x29168086[/color]
}

 

my P-state for C2D

 

			Package (0x06) { 2672, 56814, 10, 10, 0x82A, Zero },
		Package (0x06) { 2338, 49960, 10, 10, 0x724,  One },
		Package (0x06) { 2004, 43534, 10, 10, 0x61D, 0x02 }

 

 

and my LAN0 and GFX0 code.

 

in 3.3 there is a new LAN0 code that i've overwritten and gives me 2 optimization less form the 3.3 code

 

here it is:

Device (LAN0)					// Newly added LAN (ethernet) Device. 
               {
                   Name (_ADR, Zero)
                   Name (_SUN, 0x0B)
                   OperationRegion (GPIO, SystemIO, 0x0800, 0x06)
                   Field (GPIO, ByteAcc, NoLock, Preserve)
                   {
                       GO01,   8, 
                       GO02,   8, 
                       GO03,   8, 
                       GO04,   8, 
                       GO05,   8, 
                       GP9,    1
                   }

                   Name (_PRW, Package (0x02)
                   {
                       0x09, 
                       0x03
                   })
                   Method (EWOL, 1, NotSerialized)
                   {
                       If (LEqual (Arg0, One))
                       {
                           Or (GP9, One, GP9)
                       }
                       Else
                       {
                           And (GP9, Zero, GP9)
                       }

                       If (LEqual (Arg0, GP9))
                       {
                           Return (Zero)
                       }
                       Else
                       {
                           Return (One)
                       }
                   }
                   Method (_DSM, 4, NotSerialized)
                   {
                       Store (Package (0x06)
                       {
                           "built-in",
                           Buffer (One)
                           {
                               0x01
                           },

                           "device_type",
                           Buffer (0x09)
                           {
                               "Ethernet"
                           },

                           "name",
                           Buffer (0x1D)
                           {
                               "Attansic 1L Ethernet Gigabit"
                           }
                       }, Local0)
                       MCDP (Arg2, RefOf (Local0))
                   Return (Local0)
                   }
               }

 

To eliminate the New added Device (EC) what i need to erase?

so far i've deleted this line without problems:

Device (EC)
{
    all the stuff
}

------------------------------

[color="#FF0000"]// Newly added Method for EC support.
           Method (_L02, 0, NotSerialized)
           {
               Store (0x00, GPEC)
           }[/color]

           Method (_L03, 0, NotSerialized)

the part in red deleted

--------------------------

deleted also this without errors:

// Newly added for EC support.
   OperationRegion (PMIO, SystemIO, 0x0400, 0x80) // Power Management 1 Enable Register (ICH9R-316972.pdf / 13.8.2 / page 506-523)
   Field (PMIO, ByteAcc, NoLock, Preserve)
   {
               Offset (0x02), 
           ,   10, 
       RTEE,   1,              // RTC Event Enable
               Offset (0x20), 
           ,   2, 
       SPST,   1,              // SWGPE_STS
           ,   28, 
       GPF,    1,              // GPIOn_STS (GPIO[15]) 
               Offset (0x42), 
           ,   1, 
       GPEC,   1               // SWGPE_CTRL
   }


-------------------------------- for this part i'm not shure, if i delete it I got 1 error on the blue line-------------------------

// Newly added for EC support.
               OperationRegion (LPC0, PCI_Config, 0xA0, 0x54)	// General PM Configuration 3 Register (ICH9R-316972.pdf / 13.8.1.3 / page 492).
               Field (LPC0, AnyAcc, NoLock, Preserve)
               {
                       ,   10, 
                   XPME,   1,					// Bit 10 - BIOS_PCI_EXP_EN.
                           Offset (0x04),			// General PM Configuration 3 Register (ICH9R-316972.pdf / 13.8.1.3 - / page 492).
[color="#0000FF"]                    AG3E,   1,					// Bit 0 Ð AFTERG3_EN.
[/color]                            Offset (0x50),			// Root Complex Base Address Register (ICH9R-316972.pdf / 13.1.35 / page 451).
                   RCBA,   32					// Root Complex Base Address.
               }

--------------------------------------are only for EC?-------------------------------------

 

Now i'll rebbot with this v3.3 for P5K dsdt:

7196 bytes, 318 named objects, 334 executable opcodes

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

dsdt.aml.zip

 

without GFX and P-State of my configuration:

dsdt.aml_P5K_C__R_NO_GFX_No_P_State.zip

EDIT:It loads but no ich9 sata device... now it's ok, was my fault

Share this post


Link to post
Share on other sites
DSDT V3.3 has been released today – see attachments in post #3

Great (as always) :(

 

Some noob questions:

I noticed that P0P6 has now "AR13" as _PRT, but before it had:

					Package (0x04) { 0xFFFF, Zero, Zero, [color="#FF0000"]0x12[/color] },
				Package (0x04) { 0xFFFF, One, Zero, [color="#FF0000"]0x13[/color] },
				Package (0x04) { 0xFFFF, 0x02, Zero, [color="#FF0000"]0x10[/color] },
				Package (0x04) { 0xFFFF, 0x03, Zero, [color="#FF0000"]0x11[/color] }

Was this to fix something? :)

 

Also, my board had a different _CRS in LDRC:

					Name (CRS, ResourceTemplate ()
				{
					IO (Decode16,
						0x0000,			 // Range Minimum
						0x0000,			 // Range Maximum
						0x00,			   // Alignment
						0x00,			   // Length
						_Y14)
					IO (Decode16,
						0x0000,			 // Range Minimum
						0x0000,			 // Range Maximum
						0x00,			   // Alignment
						0x00,			   // Length
						_Y15)
					Memory32Fixed (ReadOnly,
						0x00000000,		 // Address Base
						0x00000000,		 // Address Length
						_Y12)
					Memory32Fixed (ReadOnly,
						0x00000000,		 // Address Base
						0x00000000,		 // Address Length
						_Y13)
				})
				Method (_CRS, 0, NotSerialized)
				{
						CreateDWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y12._LEN, ML01)
						CreateDWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y12._BAS, MB01)
						CreateDWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y13._LEN, ML02)
						CreateDWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y13._BAS, MB02)
						Store (0xFEC00000, MB01)
						Store (0x1000, ML01)
						Store (0xFEE00000, MB02)
						Store (0x1000, ML02)

					ShiftLeft (One, 0x0A, Local0)
					If (And (IOST, Local0)) {}
					Else
					{
						ShiftLeft (One, 0x0C, Local1)
						If (And (IOST, Local1)) {}
						Else
						{
							CreateWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y14._MIN, P60N)
							CreateWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y14._MAX, P60M)
							CreateByteField (CRS, \_SB.PCI0.LPCB.LDRC._Y14._LEN, P60L)
							CreateWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y15._MIN, P64N)
							CreateWordField (CRS, \_SB.PCI0.LPCB.LDRC._Y15._MAX, P64M)
							CreateByteField (CRS, \_SB.PCI0.LPCB.LDRC._Y15._LEN, P64L)
							Store (0x60, P60N)
							Store (0x60, P60M)
							Store (One, P60L)
							Store (0x64, P64N)
							Store (0x64, P64M)
							Store (One, P64L)
						}
					}

					Return (CRS)
				}

I followed your "logic" and changed it to:

					Name (_CRS, ResourceTemplate ()
				{
					IO (Decode16,				   // Verify these with your DSDT!
						0x0060,					 // Range Minimum
						0x0060,					 // Range Maximum
						0x01,					   // Alignment 
// [color="#FF0000"]Not sure, I noticed that you changed all the other alignments to 1, so I modified these ones too.[/color]
						0x01,					  // Length
						)
					IO (Decode16,
						0x0064,					 // Range Minimum
						0x0064,					 // Range Maximum
						0x01,					   // Alignment
						0x01,					  // Length
						)
					Memory32Fixed (ReadOnly,
						0xFEC00000,			// Address Base
						0x01000,			// Address Length
						)
					Memory32Fixed (ReadOnly,
						0xFEE00000,			// Address Base
						0x01000,			// Address Length
						)
				})
			}

Is that correct?

Thank you very much :(

Share this post


Link to post
Share on other sites
DSDT V3.3 has been released today – see attachments in post #3

 

Almost 13% off of dsdt.aml – in just a few hours – which unfortunately doesn't qualify for a significant update, but my hardware let me down :)

 

Once again; The attached zip file (see post #3) includes two diff files. One against the extracted vanilla DSDT from BIOS V1303 and the other against our previous release.

 

And as always: Happy Hacking!

MC, did you include your firewire hotplug patch? I've been pulling my hair out trying to make headway on that.

Share this post


Link to post
Share on other sites
MC, did you include your firewire hotplug patch? I've been pulling my hair out trying to make headway on that.

 

I can't see it, I'm also waiting for it.

Share this post


Link to post
Share on other sites
to adapt v3.2 to my board I changed: Some Firewire value

And hot-plug works right after fresh boot?

 

added LPCB support for ICH9 chipset with...

You may not need that. And 3a18 is for ICH10 not ICH9 which can be found as 2916 in AppleLPC.kext

			<array>
			<string>pci8086,2811</string>
			<string>pci8086,2815</string>
			<string>pci8086,27b9</string>
			<string>pci8086,27bd</string>
			<string>pci8086,2670</string>
			<string>pci8086,8119</string>
			[color="#FF0000"]<string>pci8086,2916</string>[/color]
			<string>pci8086,3a18</string>
			<string>pci10de,aac</string>
			<string>pci10de,aae</string>
			<string>pci10de,aaf</string>
		</array>

.

 

and my LAN0 and GFX0 code.

in 3.3 there is a new LAN0 code that i've overwritten and gives me 2 optimization less form the 3.3 code

There's only one being Name (_ADR, Zero) but thanks for the reminder. And I didn't add any Wake On LAN code because I don't need it, and it has yet to be proven to work.

 

To eliminate the New added Device (EC) what i need to erase? so far i've deleted this line without problems...

There is evidence that Apple's EC chip is similar to our Winbond Super I/O – with added extra's – and thus I won't remove it yet.

 

Now i'll rebbot with this v3.3 for P5K dsdt:

7196 bytes, 318 named objects, 334 executable opcodes

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

Nice, but here's mine:

 

ASL Input: dsdt.dsl - 1450 lines, 56163 bytes, 416 keywords

AML Output: ./dsdt.aml - 5504 bytes, 273 named objects, 143 executable opcodes

 

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

 

Great (as always) ;)

Thanks!

 

Some noob questions:

I noticed that P0P6 has now "AR13" as _PRT ... Was this to fix something? ;)

To free the IRQ and to reduce code size yes.

 

Also, my board had a different _CRS in LDRC

...

 

I followed your "logic" and changed it... Not sure, I noticed that you changed all the other alignments to 1, so I modified these ones too. ... Is that correct?

Yes!

 

MC, did you include your firewire hotplug patch? I've been pulling my hair out trying to make headway on that.

No, but start by commenting out Name (_GPE, 0xNN) in your FRWR device(s) and see what that does. Enter hot-plug after a fresh boot.

 

I wrote a new / custom GPE code block for it, but I lost it – I cannot open any file anymore from my former Snow Leopard installation, without killing it – and I wanted to ensure that we go forward. Be it a little slower now.

Share this post


Link to post
Share on other sites

Anyone got something like this on log?

kernel[0]: FireWire (OHCI) VendorID 1180 ID 832 built-in: 52 bus resets in last 3 minute.

Lot of that...

Share this post


Link to post
Share on other sites
Anyone got something like this on log?

 

Lot of that...

Yes, I get one of these every 3 minutes:

FireWire (OHCI) Lucent ID 5811 built-in: no valid selfIDs for more than 3 minutes after bus reset.

Sadly, I don't have any FireWire device, so I can't check if it works or not.

Share this post


Link to post
Share on other sites
And hot-plug works right after fresh boot?

Not yet tested on 3.3 on 3.2 wasn't working

You may not need that. And 3a18 is for ICH10 not ICH9 which can be found as 2916 in AppleLPC.kext

This is mi lspci (2918 not 2916) so i need to fake it as 3a18 (ICH10), maybe 2916 is better, now i'll try:

00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02)

 

And I didn't add any Wake On LAN code because I don't need it, and it has yet to be proven to work.

Ok so i think I can delete them too.

 

There is evidence that Apple's EC chip is similar to our Winbond Super I/O – with added extra's – and thus I won't remove it yet.

Ok i'll follow your advice

 

No, but start by commenting out Name (_GPE, 0xNN) in your FRWR device(s) and see what that does. Enter hot-plug after a fresh boot.

Another thing to try :)

 

Again Thanks for the info.

 

Anyone got something like this on log?

 

Lot of that...

 

for me the only line about firewire in log is this at 32bit:

 

FireWire (OHCI) VendorID 1106 ID 3044 built-in now active, GUID 0011d800018fcabf; max speed s400.

 

EDIT: I've removed also the P0Px devices not in my lspci or not in use. (P0P5, P0P6, P0P7, GBEC, PRT2 & PRT3 removed, then renamed PRT4 & PRT5 to PRT2 & PRT3 )

 

ASL Input: dsdt.dsl - 1450 lines, 56163 bytes, 416 keywords

AML Output: ./dsdt.aml - 5504 bytes, 273 named objects, 143 executable opcodes

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

 

I'm impressed but I don't understand. If your is so reduced, why the 3.3v on this post is so long? The best i can do is this:

ASL Input: dsdt.dsl - 1984 lines, 84304 bytes, 640 keywords

AML Output: ./dsdt.aml - 7220 bytes, 311 named objects, 329 executable opcodes

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

 

... for now :)

Share this post


Link to post
Share on other sites
Eh. I did. It's exactly the same �" with the usual exception of the PSS packages being put on separate lines. So what should I be looking at?

 

Edit: I now also moved Method (PNOT) into the _PR scope:

        Method (PNOT, 0, Serialized)	// Newly added �" Power Management Notifier.
       {
           Notify (CPU1, 0x80)		// Notify OSPM - this triggers a re-evaluation of our _PPC object (all states available).
           Sleep (0x64)		// Let it sleep for 100us - giving it some time to response to our previous notification.
           Notify (CPU1, 0x81)		// Notify OSPM once more, this time to trigger a re-evaluation of our _CST object.

           Notify (CPU2, 0x80)
           Sleep (0x64)
           Notify (CPU2, 0x81)

           Notify (CPU3, 0x80)
           Sleep (0x64)
           Notify (CPU3, 0x81)

           Notify (CPU4, 0x80)
           Sleep (0x64)
           Notify (CPU4, 0x81)
       }

Saving an additional 36 bytes �" making it 64 in total.

 

Edit: We're getting pretty close to a next release. Currently with a stunning code reduction of 412, 608, 718, 1005 bytes so I call it a day. Let's wrap it up and release DSDT V3.3 �" right after I have done some testing myself ;)

 

DSDT V3.3 has been released today �" see attachments in post #3

 

The size of our previous update was:

dsdt.dsl 95.260 bytes

dsdt.aml 7.957 bytes

 

And todays update:

dsdt.dsl 82.197 bytes

dsdt.aml 6.952 bytes

 

Almost 13% off of dsdt.aml �" in just a few hours �" which unfortunately doesn't qualify for a significant update, but my hardware let me down :(

 

Once again; The attached zip file (see post #3) includes two diff files. One against the extracted vanilla DSDT from BIOS V1303 and the other against our previous release.

 

And as always: Happy Hacking!

Share this post


Link to post
Share on other sites
Anyone got something like this on log?

 

Lot of that...

Now that is weird. Never seen any of these. Or I can't remember it. Anyway. Did you do something 'special'? You get that when you remove: Name (_GPE, 0xNN) ?

 

@Macway44: What is the question?

Share this post


Link to post
Share on other sites
Not yet tested on 3.3 on 3.2 wasn't working

I bet it isn't working with DSDT V3.3 either.

 

This is mi lspci (2918 not 2916) so i need to fake it as 3a18 (ICH10), maybe 2916 is better, now i'll try

Tip: Look at the fat bold red 9 in my reply. That's the ICH9 here. Likewise for ICH10 hence the 3A18.

 

EDIT: I've removed also the P0Px devices not in my lspci or not in use. (P0P5, P0P6, P0P7, GBEC, PRT2 & PRT3 removed, then renamed PRT4 & PRT5 to PRT2 & PRT3 )

How can I put this nicely. Not good!

 

I'm impressed but I don't understand. If your is so reduced, why the 3.3v on this post is so long? The best i can do is this:

ASL Input: dsdt.dsl - 1984 lines, 84304 bytes, 640 keywords

AML Output: ./dsdt.aml - 7220 bytes, 311 named objects, 329 executable opcodes

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

... for now :(

My aim is not to get the smallest possible DSDT, otherwise I would have ripped out a lot more, but to get one that still works. One that can be used to flash my BIOS with so to speak. And this because it saved BlackOSX 10 revs during boot time. That's what I want. A shorter boot time. I'm way past a smaller DSDT.

 

Darn. I cannot remember where I read about this BIOS thing. I remember DB1 PM'ing me this link but I cannot remember where BlackOSX wrote about his success. Anyone?

 

Edit: Ok. Found a reference of me trying to flash my BIOS. That was on or before 20 September 2009. Great goodness time flies.

Share this post


Link to post
Share on other sites

Confirmed HotPlug not working on v3.3 like in v3.2

Error with _GPE removed (32 and 64 bit):

FireWire runtime power conservation disabled. (2)

 

In 64bit mode:

FireWire runtime power conservation disabled. (2)

ERROR: FireWire unable to determine security-mode; defaulting to full-secure.

 

In 32 bit no errors

 

NOTE: looks like hotplug works only if HDs are connected before wake from sleep

 

Tip: Look at the fat bold red 9 in my reply. That's the ICH9 here. Likewise for ICH10 hence the 3A18

Yes now I understand better how id are assigned by intel, but if I don't inject 2918 or 3a18 it doesn't load AppleLPC (and is correct because the id from lspci don't match the appleLPC.kext's one).

From your tip now I use 2916 to fake my 2918 instead of 3a18 (that was also loading AppleLPC).

 

 

How can I put this nicely. Not good!

:(

not good:

1. P0P deletion (not listed in lspci and in Ioreg) maybe a problem if i'll put something pci?,

2. GBCE deletion (not listed in lspci and shown with nothing connected in Ioreg),

3. PRT changes (On my board there are only 4 SATA ICH9 ports + 1 Jmicron ),

 

or all them? (Note now i've putted the firs two back like in v3.3.1)

 

The link from DB1 is also posted at post #525,

The BlackCH (if is the same person that you mean) is at post #524

 

EDIT:

After some check and research seems that my board (P5KC) is different from the P5K Pro in:

ICH9 instead of ICH9R

4 ICHx SATA ports instead of 6

JMicron® JMB363 PATA and SATA controller instead of Marvell 88SE6102 PATA controller (and is not working either with v3.3 or any dsdt tryed before, also jmicron .kext don't work, maybe is the P5KR bios loaded in place of the original one to have AHCI capabilities)

One PCI port in place of one PCIe port

Two unused DDR3 slot (not working with P5KR bios)

For the other device it looks like they are identical (ALC883, VIA VT6308P, Winbond).

 

So the PCI configuration, the ICH9R SATA related stuff (because I think that here are the main difference from ICH9), the PATA section of the dsdt are the parts that i have to check and verify to use your tips (and dsdt ;) ).

Share this post


Link to post
Share on other sites

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.

diff_v33_v331.txt.zip

Share this post


Link to post
Share on other sites
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" and 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.

 

No problem, I like your style, we can go on in another moment if-and-when you can.

 

For now, I'm trying this code below for the firewire.

At the first boot it was working with FW mounted without sleep, but now after some reboot and a pair of device connected seems it isn't perfect, but only a bit better than before.

Now looks like that if there are more than one HD connected the other can't connect (before that editing maybe was the same, not tested specifically for this before).

If I disconnect the first device then the second device mount. Sometimes plugging in a second device disconnect the first with the error you get when you remove a device without unmount it before.

I've found this code on the iMac11 posted by THe KiNG in the OSXRestart thread, and in the dsdt of a iMac that i don't know exactly the number (the last series before the new iMac with the bigger monitor in store now).

Device (FWBR)								  // Newly added Device for FireWire support.
			{
				Name (_ADR, Zero)
				Device (FRWR)
				{
					Name (_ADR, Zero)
					Name (_GPE, 0x1B)						 // here i have 1E (P5KC with P5KR bios)
					Method (_DSM, 4, NotSerialized)
					{
						Store (Package (0x02)
							{
								"fwports", 
								Buffer (0x04)
								{
									0x01, 0x00, 0x00, 0x00	// 0x01 firewire 400, 0x02 fw800
								}
							}, Local0)
						MCDP (Arg2, RefOf (Local0))
						Return (Local0)
					}
				}
			}

The second device when not mounting gives this error:

SystemUIServer[99]: ICANotifications framework timed out waiting for a FireWire device with GUID '9067680985281999' to become ready!

 

 

Hope this help somebody else. Now i'll check the difference in the v3.3.1 and i think i'll leave the p0p and other stuff there. Maybe one day i'll learn why it's not good remove them, for now i'll keep trusting your advice.

 

Again, Thanks for all MC.

Share this post


Link to post
Share on other sites

@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?

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.

×