Jump to content

[GUIDE]: The MacBookPro18 Project

valv

By valv,
in OSx86 10.6 (Snow Leopard)

 Share
499 posts in this topic

Recommended Posts

hdx18
hdx18
Posted
Posted

Hi jdys_1991!

 

I compared your DSDT file with mine. You seem to have extracted it from an older BIOS version (assuming you have an HDX16/HDX18 computer). The latest version of the BIOS is F.32A (ftp://ftp.hp.com/pub/softpaq/sp46001-46500/sp46073.exe). You should update it before fixing the DSDT table. Afterward, extract the updated DSDT table and make the changes as indicated. You should be ok!

 

NB: This update is optional, but since you're doing some modifications to the DSDT file, why not making it with a fresh and updated BIOS... :)

 

Greetz!

Link to comment
Share on other sites
manmal
manmal
Posted
Posted

hi,

talking about hdx18 bios updates ... interesting discussion: do you see many changes from F31A to F32A ? Can anyone please let me have a detailed list of what changed (in dsdt/ssdt/acpi tables) since F31A to F32A ? To my knowledge, nothing changed ... i compared bit to bit the dsl files decompiled from aml files extracted from ubuntu. But i may be wrong...

 

Thanks in advance.

Mal

Link to comment
Share on other sites
rachaf
rachaf
Posted
Posted
Hi,

 

About your sleep/wake problem : have you fixed your dsdt using valv's USB trick in the firsts post of this thread ? If yes, have you checked where's the problem using this command : pmset -g log

 

Mal

 

Hi Mal

 

The cause of my problem was related with "RTC fix" (0x08 to 0x02), i thought that this fix wasn't important for me.

thank you for the command, before the fixe this command give me this message "Sleep: Platform Failure - AC 100"

 

like always; sorry for my english :P

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted
I have no idea what I need to do to fix it. I've uploaded my .dsl file. Could you please have a look, valv? MAKE SURE YOU RENAME dsdt.ZIP to dsdt.DSL!! I don't have any program installed to zip it, so please CHANGE THE EXTENSION. It didn't allow me to upload, otherwise.

Thank you! :thumbsup_anim:

ok. would mind providing me also with the unedited dsdt ?

Link to comment
Share on other sites
hdx18
hdx18
Posted
Posted
hi,

talking about hdx18 bios updates ... interesting discussion: do you see many changes from F31A to F32A ? Can anyone please let me have a detailed list of what changed (in dsdt/ssdt/acpi tables) since F31A to F32A ? To my knowledge, nothing changed ... i compared bit to bit the dsl files decompiled from aml files extracted from ubuntu. But i may be wrong...

 

Thanks in advance.

Mal

 

To be honest, you may be right. I assumed jdys_1991 is using a DSDT file extracted from an HDX18/16. All I can tell with certainty is that his DSDT table has some different codes (other than the fixes and hacks from Valv) than those I have in my DSDT (extracted from the latest BIOS from an HDX18 using an Ubuntu OS). Maybe jdys_1991 has a different HP computer, which could also explain the discrepancies...

 

The only fix/enhancement indicated by HP for the newest BIOS is an update to Computrace Option ROM (version 889). I don't know if the DSDT (and other tables) between F31A and F32A versions are different. Sorry! ;)

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted
I don't know if the DSDT (and other tables) between F31A and F32A versions are different. Sorry! ;)

No difference, in my humble thought.

Edit: That dsdt doesn't seem to be from an hdx18 (I could be wrong). But if am wrong, then it was harshly messed. hacks were not literally applied. Please provide me with ur old untouched and freshly extracted one. I'll see what could be done.

But don't use it by now.

Link to comment
Share on other sites
jdys_1991
jdys_1991
Posted
Posted
Hi jdys_1991!

 

I compared your DSDT file with mine. You seem to have extracted it from an older BIOS version (assuming you have an HDX16/HDX18 computer). The latest version of the BIOS is F.32A (ftp://ftp.hp.com/pub/softpaq/sp46001-46500/sp46073.exe). You should update it before fixing the DSDT table. Afterward, extract the updated DSDT table and make the changes as indicated. You should be ok!

 

NB: This update is optional, but since you're doing some modifications to the DSDT file, why not making it with a fresh and updated BIOS... :P

 

Greetz!

Oh right, I didn't know. Yeah, I have a HDX18 laptop.. I will update my BIOS now and try again! :)

Thank you! :)

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted

u still need to provide the old dsdt even with a bios update (I miss the point on that update, since nothing on dsdt would change after that)

Link to comment
Share on other sites
hdx18
hdx18
Posted
Posted
u still need to provide the old dsdt even with a bios update (I miss the point on that update, since nothing on dsdt would change after that)

 

Since jdys_1991's HDX18 computer seems to have an older BIOS (probably older than F31A because of the discrepancies noted when comparing with the DSDT table of the latest BIOS), shouldn't he update it? I understand that the DSDT table from F31A is identical with the one from F32A... but it seems different with older BIOSes. Only jdys_1991 could clarify that by verifying his computer BIOS version.

 

I also understand that jdys_1991 could stay with the BIOS he has on his computer and correct its DSDT table consequently. But again, since this table seems a bit different, some different errors/warnings could arise. These could obviously be corrected anyway... But isn't it easier to work on a common ground (i.e. same DSDT)?

 

Maybe I'm wrong...

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted

You are totally right, some errors could arise later (not necessarily DSDT related). This is not a problem by itself, 'cuz we could adapt things and correct 'em accordingly, since rachaf and other people does not even have the same DSDT and those hacks do work for them (if attentively following). The big mess would be that, over time, u'll find out that HP engineers, made some hilarious errors on some models. That is I totally agree with u on the point that we should start with closest conditions possible. This way we can easily understand the reasons for a non working hack, or to be sure if some errors arise on one's notebook (same model & same conditions) that they aren't related to ACPI, but more to Software and versions. There's also the point that even with same model, most of us don't have same devices, as of wifi, bluetooth, Processors...

btw, regarding the wifi whitelist's hack, how we could setup the new (patched) version of the bios if we already use the latest one ? could we downgrade (the bios) before making changes ? I've read something about that, but I can't remember exactly. Some clue ?

 

Greetz,

Link to comment
Share on other sites
jdys_1991
jdys_1991
Posted
Posted
u still need to provide the old dsdt even with a bios update (I miss the point on that update, since nothing on dsdt would change after that)

Oh damn sorry, I already updated the bios now. But I will try and see if I can still find an unedited copy of the dsdt file.

 

 

Since jdys_1991's HDX18 computer seems to have an older BIOS (probably older than F31A because of the discrepancies noted when comparing with the DSDT table of the latest BIOS), shouldn't he update it? I understand that the DSDT table from F31A is identical with the one from F32A... but it seems different with older BIOSes. Only jdys_1991 could clarify that by verifying his computer BIOS version.

 

I also understand that jdys_1991 could stay with the BIOS he has on his computer and correct its DSDT table consequently. But again, since this table seems a bit different, some different errors/warnings could arise. These could obviously be corrected anyway... But isn't it easier to work on a common ground (i.e. same DSDT)?

 

Maybe I'm wrong...

The version of the BIOS was F11 and it updated to F32. At least, this is what the program told me last night, which did the flashing of the InsydeH2O bios. Was that really old? Just wondering..

 

 

 

EDIT

I stupid didn't make a backup copy of the .dsl file. So I don't have an unmodified F11 BIOS .dsl file. Sorry. :/

I only have an unmodified F11 BIOS .aml file, if that helps. I didn't touch that file when I did the changes, so if that's any useful, I can upload it.

Link to comment
Share on other sites
hdx18
hdx18
Posted
Posted
btw, regarding the wifi whitelist's hack, how we could setup the new (patched) version of the bios if we already use the latest one ? could we downgrade (the bios) before making changes ? I've read something about that, but I can't remember exactly. Some clue ?

 

This is really no problem. When I did it, I already was using the latest BIOS. Just flash the patched one over. The updating program doesn't mind about flashing over the same BIOS version. If for some reason, it doesn't work for you, I could send you the updating program I used... But I don't see how it could not work! ;)

 

By the way, some people already talked about a BIOS hack which consist in deleting the whitelist module from the BIOS. Not a good idea... It seems that this module does more. Doing so, you lose the possibility to activate/deactivate the bluetooth & wifi options with the led button. Trust me, I also tried it before...

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted
Is there no way to make the built in Intel Wifi working? Is there really no way? :/

There is always a way. but not yet

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted
hope that mercurysquad finish his project on that, and give us finnaly the driver for this wifi;

link:http://www.facebook.com/pages/mercurysquad/130654692121

Yep, I meant this one.

Btw, new hacks for ThermalZone and the win-2006 hacks added to first page.

 

Greetz,

Link to comment
Share on other sites
rachaf
rachaf
Posted
Posted

Hi Valv;

In my DSDT (hp dv5) i don't have this code "If (LEqual (\_SB.PCI0.LPC.EC0.QUAD, One))" in ThermalZone section can i proceed to remove those lines: "If (LLess (OSYS, 0x07D6))" and "If (LGreaterEqual (OSYS, 0x07D6))". 

        ThermalZone (TZ01)
       {
           Method (_HOT, 0, Serialized)
           {
               If (LGreaterEqual (OSYS, 0x07D6))
               {
                   If (LEqual (TJMX, 0x64))
                   {
                       Return (0x0EC6)
                   }

                   If (LEqual (TJMX, 0x55))
                   {
                       Return (0x0E30)
                   }

                   If (LEqual (TJMX, 0x69))
                   {
                       Return (0x0EF8)
                   }

                   If (LEqual (TJMX, 0x5A))
                   {
                       Return (0x0E62)
                   }
               }
               Return (Zero)
           }

           Method (_CRT, 0, Serialized)
           {
               If (LLess (OSYS, 0x07D6))
               {
                   If (LEqual (TJMX, 0x64))
                   {
                       Return (0x0EC6)
                   }

                   If (LEqual (TJMX, 0x55))
                   {
                       Return (0x0E30)
                   }

                   If (LEqual (TJMX, 0x69))
                   {
                       Return (0x0EF8)
                   }

                   If (LEqual (TJMX, 0x5A))
                   {
                       Return (0x0E62)
                   }
               }
               Return (Zero)
           }

I can compile without any error if i remove them

 

THanks, and sorry for my English.

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted

@rachaf,

sorry for making u wait. I've got to clear some points regarding src of "AnVAL" with moderator.

regarding your dsdt code: yes do it that way. It doesn't harm.

 

Greetz,

Link to comment
Share on other sites
valv
valv
Posted
  • Author
Posted
hi valv,

what are such fixes for?

Mal

hi Mal,

those are meant to make the DSDTable declare to the bios that u are using an win-OS. Thus, unblocking all the capabilities of our machines. Each OS has an identifier code. I explain: If u are on vista, your machine's capabilities will not be limited by these lines (that we'r about to remove from DSDT). But when u use some other OS (e.g. Linux), u'r under the constraint to have a hotter cpu for example. Some manufacturers was saying that these limitations where necessary because of the incapability of such OS's to follow/understand the ACPI Specifications. That was a long time ago. Since then, Linux for example made pretty improvements to support ACPI specs. Personally, am convinced that it is another speculation in the favor of Microsoft.

Btw, all hacks am posting, are fully tested by myself since months. So there's really nothing to worry about, if u correctly follow the guide. Plus, am here to review with u any difference between our results. and ready/glad to help u.

 

Greetz,

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...