HP ProBook 4x30s (4330, 4430, 4530, 4730) patches -- Updated

[BigDonkey]

This is the first thing I've tried, I got the same warnings and remarks as with your DSDT, but I got no delay. It's my own DSDT after all.



Maybe so, but why I don't have such delay with the DSDTs, provided by the installer? They are nothing like my own.
Anyway, is there a way to solve this problem? My idea was to make these DSDTs universal, so they could be included in the ProBook Installer.

As long we run similar pci hardware we should be fine, most of the users are able to use Probook Installers dsdt's.
I think bcc9 got around this problem by editing dsdt for his Dell laptop.
He wrote and shared scripts in this thread
http://www.projectosx.com/forum/index.php?showtopic=2416&view=findpost&p=17548

 

[BigDonkey]

I am attaching a fresh DSDT table un-patched from my F.28 BIOS on an AK07.... I hope this helps. I am in the process of running the patches on it for myself. Applying the battery fix is taking crazy long on my new Ivy Bridge build. Is this necessary and if so should it take over 5 minutes for part 0?

Original battery patch was divided into two parts because DSDT editor during compiling get stuck on last 2 lines if they come in wrong order.
Apply everything excepts these

into_all method label SBTC code_regex \(Zero,\sMAXC\) replaceall_matched begin (Zero, AXC0)\nStore (Zero, AXC1) end;
into_all method label SBTC code_regex \(0x00,\sMAXC\) replaceall_matched begin (0x00, AXC0)\nStore (0x00, AXC1) end;

choose only one of the above matching your dsdt - using one with Zero or 0x00

 

[Elrom]

Oh, you have Ivy Bridge series (ie. gen 3 Intel Core i-series).

Let us know how the DSDT patching goes...

Yes, i have 4340s model with hm76 chipset, but 2nd generation CPU i5 2450m, so i'm confused about what to choose in system definition - mbpro8,1 or mbpro 9,2.
The differences what i found for now:
LPC device id - 1e59 must be changed in dsdt patch
Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E26 - must be changed in dsdt. By the way - why we use the same device id for EHC1 and EHC2 devices - they have different device id's,so that is the question, because i have second Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E2D (different device id) does it mean that i need to change dsdt patch for EHC1 - device id - 1e26, for EHC2 device id - 1e2d?
A have additional Device (XHC) Intel(R) USB 3.0 eXtensible Host Controller - 0100 (Microsoft) [8086-1E31] with device id - 1E31, do i need to use _DSM method for this device too?
Just strange - i have 3 usb 3.0 ports and only 1 usb 2.0 port - i don't understand why i have 2 x Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller and only one - Intel(R) USB 3.0 eXtensible Host Controller. So i guess usb 3.0 controller connected to hub with 3 connectors and one usb 2.0 is connected to USB 2.0 socket and other USB 2.0 is for internal connections and hasn't output inside. Maybe that's why?
My Audio Codec: IDT 92HD87B2/4. High Definition Audio Controller [8086-1E20]. Is it the same as in 4530s? If yes, i can use dsdt patch for audio in my dsdt - right?
Wifi - Qualcomm Atheros AR9485 802.11b/g/n WiFi Adapter [168C-0032] - there is no way how to make it visible and functional.
Ethernet - Realtek RTL8168/8111 PCI-E Gigabit Ethernet Adapter - the same as in 4530s?
What is SMBUS - where it is in windows? is it "Extended IO Bus - ACPI\VEN_PNP&DEV_0A06 - PNP0A06"?

I need some time to test my options to change things more accurate for my hardware, but maybe anyone can tell me now were to pay attention to do not do useless job?

Thanks!!!

 

[philip_petev]

Original battery patch was divided into two parts because DSDT editor during compiling get stuck on last 2 lines if they come in wrong order.
Apply everything excepts these

into_all method label SBTC code_regex \(Zero,\sMAXC\) replaceall_matched begin (Zero, AXC0)\nStore (Zero, AXC1) end;
into_all method label SBTC code_regex \(0x00,\sMAXC\) replaceall_matched begin (0x00, AXC0)\nStore (0x00, AXC1) end;

choose only one of the above matching your dsdt - using one with Zero or 0x00

Woops, and my files here are compiled with both lines inside! Actually, these two lines are doing one and the same job, only the values are different, so the second line will overwrite the changes, made by the first line and the result will be DSDT with applied only the second line, right?

What are these two lines for anyway?

 

[RehabMan]

This is the first thing I've tried, I got the same warnings and remarks as with your DSDT, but I got no delay. It's my own DSDT after all.



Maybe so, but why I don't have such delay with the DSDTs, provided by the installer? They are nothing like my own.
Anyway, is there a way to solve this problem? My idea was to make these DSDTs universal, so they could be included in the ProBook Installer.

It doesn't sound like there is a way to make them truly universal. And it sounds like if you (or I) didn't have a delay to begin with, it was just pure luck.

 

[RehabMan]

Original battery patch was divided into two parts because DSDT editor during compiling get stuck on last 2 lines if they come in wrong order.
Apply everything excepts these

into_all method label SBTC code_regex \(Zero,\sMAXC\) replaceall_matched begin (Zero, AXC0)\nStore (Zero, AXC1) end;
into_all method label SBTC code_regex \(0x00,\sMAXC\) replaceall_matched begin (0x00, AXC0)\nStore (0x00, AXC1) end;

choose only one of the above matching your dsdt - using one with Zero or 0x00

If you are using a raw DSDT it will be most likely 0x00. After you compile and then" un-compile" (disassemble in Intel's terminology), you will notice the 0x00 gets replaced by Zero unless you use compiler flag -oi (disable integer optimization).

There should be no problem running both. The first will convert any Store (Zero, MAXC) it sees (if any) into two lines Store (Zero, AXC0) and Store (Zero, AXC1). And the second should convert any Store (0x00, MAXC) it sees into two lines Store (0x00, AXC0) and Store (0x00, AXC1). The compiler will optimize the latter to using Zero instead of 0x00. I think in a clean DSDT, it will always be 0x00, because evidently the older compiler used to create HP BIOS did not include this 'integer optimization' feature.

It is possible that DSDT Editor has a bug somewhere, but I haven't run into it yet.

 

[philip_petev]

It doesn't sound like there is a way to make them truly universal. And it sounds like if you (or I) didn't have a delay to begin with, it was just pure luck.

Maybe it's pure luck but think about it - why there is no one, who has complained about such delay with the DSDTs, included in the installer? Are they something special or it's just differences between F.20 and the newest version. I'm aware that they will never be truly universal, but I think this delay can be fixed (the only think I don't know is how, the DSDT is out of my range of knowledge).

 

[RehabMan]

Woops, and my files here are compiled with both lines inside! Actually, these two lines are doing one and the same job, only the values are different, so the second line will overwrite the changes, made by the first line and the result will be DSDT with applied only the second line, right?

What are these two lines for anyway?

I don't see any "overwriting" going on there. Basically the lines are in there to make sure that any clearing of MAXC is done correctly once the MAXC register is converted to two fields of 8-bits instead of one field 16-bits.

MAXC - originally 16-bits
AXC0 - least significant 8-bits of MAXC (bits 0-7)
AXC1 - most significant 8-bits of MAXC (bits 8-15)

The intent of these patches is to convert code like:
Store (Zero, MAXC)
-or-
Store (0x00, MAXC)

to
Store (Zero, AXC0)
Store (Zero, AXC1)

Whether the resulting code uses Zero (constant for zero), 0x00 (hex for zero), or 0 (decimal for zero), or 00 (octal for zero), doesn't really matter. After going through the compiler without, they are all going to be converted to the contant Zero.

The patch is trying to convert both Zero and 0x00, but really in a clean DSDT it is only going to see 0x00.

 

[RehabMan]

Maybe it's pure luck but think about it - why there is no one, who has complained about such delay with the DSDTs, included in the installer? Are they something special or it's just differences between F.20 and the newest version. I'm aware that they will never be truly universal, but I think this delay can be fixed (the only think I don't know is how, the DSDT is out of my range of knowledge).

It could be that the OperatingRegion addresses that are used in the ProBook installer are "more compatible" (ie. less likely to cause a delay) than the ones from my machine???

It is also possible that many have experienced the delay, but haven't noticed... Come to think of it there have been people asking about why a 45 sec boot time...

I don't know, but after discovering the differences in these items when I went through this process to patch my own DSDT, I'm probably done with using DSDT from the installer and will always choose to patch custom. I really did this just so I could understand the process and update the patches to what we currently have in our DSDT, but it seems I learned a little extra...

 

[BigDonkey]

Woops, and my files here are compiled with both lines inside! Actually, these two lines are doing one and the same job, only the values are different, so the second line will overwrite the changes, made by the first line and the result will be DSDT with applied only the second line, right?

What are these two lines for anyway?

It will not override. If your match is the second line, it will error out on first and stop. That's why some people can't get past this part when applying patches.
Perhaps we should "purify" dsdt first and agree on "Zero" or "0x00" ?
I'm sure RehabMan can tells us what is the correct approach.

The lines were added to fix battery compilation errors we had in the past. After MAXC register was divided into AXC0 and AXC1 additional entry with for AXC1=0x00 or so was needed for some sections. (B1B2(AXC0,AXC1) couldn't be used.