[GUIDE]: The MacBookPro18 Project

[hdx18]

Hi valv!

 

By the way, it is now possible to purchase new models of pci-e mini-cards, integrating both Wi-Fi and Bluetooth, and using the same cable. To be honest, I don't know if it's compatible with OS X drivers... But it could be an option.

 

If you're interested, is't possible to modify your BIOS for any pci-e mini-card. I found a way to add a SLIP2.1 identification (to make your system recognized as manufactured with Windows 7, i.e. another way to activate this OS) and also to modify the whitelist for any pci-e mini-card device.

 

Since I did it more than 4 months ago, I don't really remember the details, but I managed to save the manipulations on an external HD. Actually, I have airport activated on my Snow Leopard, using a 2.4/5 GHz Wireless 1505 PCI Express WLAN Mini-Card for Dell Vostro 1310/ 1510/ 2510 Laptops (i.e. Broadcom chip), and it's working perfectly! It could be any other mini-card with an OSX-compatible chip... just changing for the right ID in the whitelist. In a matter of fact, I think there are now better cards.

[valv]

@hdx18, Nice share! In fact It could be done this way, and if u can go further on, I know some that would really enjoy this.

Btw, it could be done on the card's level by patching its firmware. This way lazy people can overcome playin' with their Bios, thus avoindin' any dangerous harm.

I meant this part to be the bonus section of the guide but since u pushed it on the grill, u're welcome to make the sausage that goes with. Again thank u for this m8

[manmal]

hi valv,

i am really curious to know such things you are expecting to write soon to the guide in this thread I am thrilled about that !

Also ... i didn't understand where and how to use ssdt and other acpi tables (extracted from everest) using this anv's bootloader... i guess i will find the answers in this thread soon

Great work !

Mal

[valv]

Actually, I have airport activated on my Snow Leopard, using a 2.4/5 GHz Wireless 1505 PCI Express WLAN Mini-Card for Dell Vostro 1310/ 1510/ 2510 Laptops (i.e. Broadcom chip), and it's working perfectly!

I was thinking about another model BCM4321/4311. But if this worked for u, please if as some guidance

Greetz,

[hdx18]

I was thinking about another model BCM4321/4311. But if this worked for u, please if as some guidance

Greetz,

 

It's not so important, because people can choose the chip ID they want. They just have to choose one supported by OS X. They'll put it the way and where I'll tell them in the BIOS (changing vendor & chip IDs of a PCI-E mini-card already in the whitelist with one supported). For example, my Dell card has a BCM4328 chip...

 

I may be wrong, but I see a possible complication with an ID change in the mini-card firmware. In fact, the BIOS compares IDs in the whitelist with the chip ID on the card (not the card itself). Since OS X uses this ID in its drivers, your modified card (i.e. modified chip ID) could be unrecognized by the OS even if passing though an unmodified BIOS whitelist checkpoint. I'm not completely sure about it, but it seems pretty logical. For that reason, I think its better to patch the BIOS with the original ID of a card recognized by Snow Leopard.

 

Another thing to consider: your new card must "fit" your cabling configuration; my original card was an Intel 5100 with TWO connections. Some Atheros (if not all, I'm not sure about it) have THREE connections... So, if you choose differently from your original wire setup, you'll have to change the cables (and open the computer case to do it ) !!! Obviously, your mini-card must also fit the slot on your computer (pins are not always oriented the same way).

 

I already made some research on wireless chips natively supported in OSX. I upload the IDs compilation I made (from original SL 10.6.3 kexts). Essentially, there are two vendors: Broadcom and Atheros. So, when choosing a card, be sure it has one of those chips.

 

I'll come with the entire solution (BIOS modification) in another post!

PS: You'll need to do it in a Windows OS...

SL10.6.3_Natively_Supported_Chipsets__Wireless_Cards_.rtf

[valv]

I may be wrong, but I see a possible complication with an ID change in the mini-card firmware. In fact, the BIOS compares IDs in the whitelist with chips IDs on the card (not the card itself). Since OS X uses those IDs in its drivers, your modified card could be unrecognized by the OS even if passing though an unmodified BIOS whitelist checkpoint. I'm not completely sure about it, but it seems pretty logical. For that reason, I think its better to patch the BIOS with the original ID of a card recognized by Snow Leopard.

This remains minimal, cuz' one's we overcome the Bios barrier, we can trick the system into thinking it is dealing with another card than the declared id ( we go like telling someone the truth by telling him the lie was a lie ). more seriously it would work just like the usb thing as long as u know how and what ( am sayin' this now because there is times where the device declares its id anyway but we can go further on this and it should work)

my original card was an Intel 5100 with TWO connections.

same thing over here

I already made some research on wireless chips natively supported in OSX. I upload the IDs compilation I made (from original SL 10.6.3 kexts). Essentially, there are two vendors: Broadcom and Atheros. So, when choosing a card, be sure it has one of those chips.

 

I'll come with the entire solution (BIOS modification) in another post!

PS: You'll need to do it in a Windows OS...

that is really great news mate. btw, didn't look to the list by now (typing), do u know of compatible wifi cards that could include bluetooth (and be 100%ly osx)? by 100% I mean no external kext be needed.

till next time then, see ya

Greetz,

[hdx18]

that is really great news mate. btw, didn't look to the list by now (typing), do u know of compatible wifi cards that could include bluetooth (and be 100%ly osx)? by 100% I mean no external kext be needed.

till next time then, see ya

Greetz,

 

To be honest, I can't tell you for sure because I have 2 cards on my HDX18 (BCM2045=Bluetooth; BCM4328=WiFi) and they were already installed when I purchased it. Both of them work perfectly in OSX.

 

Nevertheless, I did some search. A combo pci-e mini-card exists. It's made by Broadcom (BCM943224PCIEBT) and is installed in late-2009 MacBooks. It's a custom (but Broadcom-made) BCM43224 (basically a dual-band BCM4322 plus a BCM2070 for Bluetooth).

 

Picture of the card:

http://images.weiphone.com/attachments/Day...2478633560a.jpg

This is an official Apple replacement part, and may look slightly different from a generic Broadcom version.

 

The description for BCM943224HMB (the same card in a different form factor) can be viewed at

http://www.broadcom.com/products/Wireless-...ns/BCM943224HMB

 

So, if you find a mini-card manufactured with this chip, it should work. But again, you'll be faced with a problem I already mentioned: you'll need to connect 3 wires to it (2 for WiFi and 1 for Bluetooth). You only need one slot, but 3 wires...

[hdx18]

So, let’s talk about modifying your BIOS whitelist for a new wireless device.

 

First of all, you know you do it at your own risks. Be sure of what you do, because messing up with your BIOS can kill your computer. This method is presented for educational purpose only…

 

To do the work, you will need:

 

1) A computer running a Windows OS

 

2) The last BIOS update from HP (F.32A for HDX18)

ftp://ftp.hp.com/pub/softpaq/sp46001-46500/sp46073.exe

 

3) EzH2O - The program to open your BIOS binary

http://www.mediafire.com/?3zdzl0h0n1j

 

4) An HEX Editor permitting you to access directly the computer memory and write to it.

I like WinHex, but you must register it to have the right to write the memory.

You could use any other HEX Editor of your choice.

http://www.x-ways.net/winhex.zip

 

5) A program to unzip the BIOS package for HP and the EzH2O program

Could be Winrar.

http://www.rarsoft.com/download.php

 

6) A natively airport-supported wireless card. Obviouly!

 

Your new card must "fit" your cabling configuration; my original card was an Intel 5100 with TWO connections. Some Atheros (if not all, I'm not sure about it) have THREE connections... So, if you choose differently from your original wire setup, you'll have to change the cables (and open the computer case to do it ) !!! Obviously, your mini-card must also fit the slot on your computer (pins are not always oriented the same way).

 

I already made some research on wireless chips natively supported in OSX. I upload the IDs compilation I made (from original SL 10.6.3 kexts). Essentially, there are two vendors: Broadcom and Atheros. So, when choosing a card, be sure it has one of those chips.

 

You will also need the Vendor/Chip & Subsys IDs of your new airport-supported wireless card. Since you purchased this card for that particular reason, you should already have an idea of those IDs. But to be sure, let’s confirm this info. Since you can’t install the mini-card without having it blocked by the BIOS barrier during the boot process, you’ll have to install it once Windows is running. Just before starting your computer, remove your original wireless card, but make sure the slot stays accessible. Once Windows is running, install the new card with CAUTION… Normally, it’s not a good idea to install a piece of hardware while a computer is powered on, but if you really want to be sure of your IDs, I don’t see otherwise. Next on Windows 7, go to “Control Panel”, “System and security”, “System”, “Device manager” . The way to get to the device manager can be a bit different depending of you version of Windows. Once there, you’ll search for the network adapter (chances are that a driver was installed for the new device; if not, just search for a new network adapter). Right-click on it and choose “Properties”. Select “Details” and search for the identification numbers for that device.

 

You should see something like this:

 

PCIVEN_14E4&DEV_4328&SUBSYS_000A1028&REV_03

PCIVEN_14E4&DEV_4328&SUBSYS_000A1028

PCIVEN_14E4&DEV_4328&CC_028000

PCIVEN_14E4&DEV_4328&CC_0280

(This is an example for a Dell Wireless 1505 Draft 802.11n WLAN Mini-Card)

 

The important numbers are: VEN for Vendor (In this example: 14E4), DEV for Chip (In this example: 4328), SUBSYS (In this example: 000A1028). You’ll have to manipulate them a bit for using them afterward. You will end up with two series of letters/numbers:

 

Vendor/Chip ID: Merging VEN and DEV together. Note the inversion of symbols of each series. In my example, VEN is now E414 and DEV is 2843. Put together, you have a Vendor/chip ID of E4142843.

 

Subsys ID: You must also make inversions. The two last symbols being now the first, and doing so, from the end to the beginning, two symbols at a time. In my example, 000A1028 gives you a Subsys ID of 28100A00

 

Now, the modifications!

 

1) Unzip the BIOS update with Winrar, but don’t run it. To make so, right-click on the filename and choose “Extract to sp46073”. In the new folder, you’ll find 7 files. The BIOS binary is named “3610F32.fd”

 

2) Unrar the EzH2O program in a folder of your choice.

 

3) Install WinHex (or the Hex Editor of your choice). You must have the capacity to read from and write directly to the memory.

 

4) Then, start EzH2O.exe

Once started, choose “File”, then “Load File…” Open the BIOS binary (3610F32.rd) you just unzipped previously. A pop-up window with some infos about your BIOS will appear. Press OK. Let the program run in the background and do nothing else with it for now.

 

5) Open WinHex. Choose “Tools”, “Open RAM…”, go to “Ezh2o” and open its primary memory.

 

6) Now, the idea is to replace two sets of numbers (Vendor/Chip and Subsys IDs) of a wireless PCI-E device included in the whitelist with those of your new hardware. I choose not to modify the IDs of my WiFi 5100 (VEN_8086, DEV_4237, SUBSYS_12118086); this way, I can swap again with the original hardware if necessary. So, in WinHex, search the RAM for this hexadecimal chain: 86803242 and replace it with your new Vendor/Chip ID (in my example, E4142843). Do the same for the Subsys ID: search and change 86800112 for your new ID (in my example, 28100A00). You shouldn’t find more than one Vendor/Chip ID (86803242) and one Subsys ID (86800112) to change.

Once done, save your changes in WinHex by hitting the disk. This will directly write to the EzH2O program’s working RAM memory.

CAUTION not to do any other changes to the RAM memory before saving it!!!

 

7) Then, go back to EzH2O and “Save as” with a filename different from the original BIOS binary.

 

8) Use the flash utility inside sp46073 folder to flash the new image to the BIOS.

 

9) Voilà! You have now a working airport mini-card in your system!!!

 

 

 

Edit: I removed the modification for the Subsys ID. Even if I already read about it, I think it has no sense. In fact, the result was modifying a Vendor/chip ID of another card in the whitelist with a Subsys ID. This has no real impact on the whitelist, other than making the BIOS think that this Subsys ID is new card to allow (wich is not!)...

 

Edit 2: Finally, I verified to be sure and I change my mind again. Sorry! So, you must modify also the Subsys ID. I was correct the first time. The HEX chain 86800112 is really an original Subsys ID linked to the original Vendor/Chip ID 86803242. It means that you must change both of them for the new Vendor/Chip & Subsys IDs of your airport compatible mini-card. I re-edited the method above to reflect the correct manipulations...

 

 

 

Now valv, I'm ready for the rest of your DSDT & SSDT files modifications!

 

SL10.6.3_Natively_Supported_Chipsets__Wireless_Cards_.rtf

[valv]

@hdx18, wow! what else can I say about. u really made a good contribution to the rrest of us. big thank you.

Regarding DSDT, don't worry, it is weekend soon, and I will be adding some hacks for your eyes.

Greetz

[rachaf]

Thank you very much Valv

i have hp dv5 laptop and your hacks work also for me

waiting for your next hacks (fixs)

[valv]

Thank you very much Valv

i have hp dv5 laptop and your hacks work also for me

waiting for your next hacks (fixs)

soon

btw, should we rename the topic to hp notebooks then ? just kidding.

keep tuned.

[rachaf]

soon

btw, should we rename the topic to hp notebooks then ? just kidding.

keep tuned.

 

Why not ? between the only hack that not worked for me is this:

6) For each line 806 & 820,

replace Name (BCL1, Package (0x0D)

with Name (BCL1, Package (0x0B)

 

 

it seems that this ok for me

 

thank you again

 

and sorry for my english;

[manmal]

hi valv,

changing the bootloader to anv's one (manual installation method of boot0, boot1h and boot) , battery meter shows correctly with voodoobattery ! it was my latest ver of chameleon i was using causing such strange behaviour.

Thanks for that

...I am just waiting for you for other dsdt fixes and how-to-use ssdt-x tables ...

Mal

[valv]

hi valv,

changing the bootloader to anv's one (manual installation method of boot0, boot1h and boot) , battery meter shows correctly with voodoobattery ! it was my latest ver of chameleon i was using causing such strange behaviour.

Thanks for that

...I am just waiting for you for other dsdt fixes and how-to-use ssdt-x tables ...

Mal

Hi Mal,

Glad to know it did work for u. yep, It took longer time than expected with the loader. but, don't worry, I'll be posting next free time

 

Greetz,

[jdys_1991]

Is the guide 100% complete yet or is there still bits missing?

And thank you for the great work, Valv!

[valv]

Is the guide 100% complete yet or is there still bits missing?

And thank you for the great work, Valv!

Take a look at the end of post#4, firewire hack added at the time u've been asking.

Btw, more code to come, don't worry. U'll get all hacks . More complicated ones later on. Too much work on the ACPILoader.

 

Greetz,

[hdx18]

Hi Valv!

 

Unfortunately, there's some problem with your last DSDT modification (concerning Firewire).

The compiler found this error:

 

/Users/MacOSX/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl 1313: Method (_L1A, 0, NotSerialized)

{

Notify (\_SB.PCI0.RP05.FRWR, Zero)

Notify (\_SB.PWRB, 0x02)

}

Error 4064 - Object does not exist ^ (\_SB.PCI0.RP05.FRWR)

 

ASL Input: /Users/MacOSX/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl - 11453 lines, 412976 bytes, 5584 keywords

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

[valv]

Oh, sorry, sorry, this is because I've got confused about device names since I radically changed those, and I don't like to tell do the same 'cause it is not as simple as typing some code. we'll see later if I get more pedagogic way to show u how to do it. In the mean time Code corrected on first place. go edit and everything will turn back to normal.

Again, thank u for waking me up.

[hdx18]

Hi Valv!

 

I just realized something.

 

One of the DSDT fixes seems not to work. It's about UHC5 device. I injected a device-id (0x39, 0x3A, 0x00, 0x00) to make the system think it's a compatible hardware... But it's still not recognized as a built-in device. the ID is also different (0x39 0x29 0x00 0x00)... System info gives me those details (in French, but easy to understand ) :

 

Bus USB :

 

Emplacement du contrôleur de l’hôte : Emplacement d’extension

Gestionnaire du contrôleur de l’hôte : AppleUSBUHCI

Identifiant du périphérique PCI : 0x2939

Identifiant de révision du PCI : 0x0003

Identifiant du fournisseur du PCI : 0x8086

Numéro de bus : 0x7d

 

Note that all other USB devices (UHCx & EHCx) are recognized as built-in...

 

And my injection hack:

 

Device (UHC5)

{

Name (_ADR, 0x001A0002)

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"device-id",

Buffer (0x04)

{

0x39, 0x3A, 0x00, 0x00

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

}

 

 

Do you have any idea about that?

[valv]

Salut hdx18, let's have a closer look into your injection. Pay attention to the Address of your device

Device (UHC5)

{

Name (_ADR, 0x001A0002)

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"device-id",

Buffer (0x04)

{

0x39, 0x3A, 0x00, 0x00

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

}

The device-id we're faking should somehow be compatible with the device address.

What we can do here is replace that address with this one 0x001D0003. Thus the id becomes compatible, and OsX goes to sleep w/o failure (hopefully).

I forgot about this messy trick. thank u for making me remember it.

Greetz,

[rachaf]

thanks you again valv for Firwire and Ethernet hacks and for pulling our attention on realtek (RTLD) because i have it straight above "EXP3" device in my DV5 laptop:

can't wait for the next hacks

btw the sound work for me with voodoohda (V2.62) but with no MAX/MIN/MUTE, do you have this problem?

 

thanks and sorry for my english;

[manmal]

Hi rachaf,

 

i modified voodooHDA 2.6.1 to support volume control on hdx18 (thanks to pcrew : http://www.insanelymac.com/forum/index.php...183321&st=0 , i just adapted some code to the newest VoodooHDA source, the basic idea is from him).

I compiled it 32/64 bit for Snow Leopard.

Please give it a try and please give me your feedback if it works or not for you.

Here it works but i tried only the 32 bit version. It is still experimental, volume changes are effective after the first half of the cursor . I am working on it for a "smoother" version of volume control.

 

I attached also an older version of 2.5.6 VoodooHDA with such modifications, but sometimes it gives me kernel panic (it is due to VoodooHDA, not to my modification).

 

Voodoohda 2.6.2 seems still experimental. If/When you will find a link for a stable version to download, including sources please let me know and i will do the modifications there too and will post the compiled kext here.

 

If there is a "cleaner" method using latest patched AppleHDA.kext where sleep works and volume control works out of the box instead of using VoodooHDA please let me (us) know.

 

Mal

VoodooHDA_256_HP_HDX18.kext.zip

VoodooHDA_261_HP_HDX18.kext.zip

[rachaf]

Thank you manmal, and yes i tried your modified voodoohda_2.61 and result is:

-Only the first half of volume control work (like you)

-Mute not working.

 

AppleHDA kext exist (AppleHDA 1.8.4fc3, patched by deviato for IDT 92HD71B7X for Dell Inspiron 1545) but since we have the same ID it works for me too, sorry i don't know for sleep because i have problem with wake up (for now), this is the link:

http://deviato.wordpress.com/2010/03/31/10...-driver-update/

 

i hope that you success to give us the perfect voodoohda for our IDT;

 

and sorry for my english;

[manmal]

Hi,

strange... here mute is working (the led is still "gray", not red when muted but it works!).

I am working on the "smoother" volume control. I will post an update here when it will be ready.

Thanks for the link to AppleHDA by deviato. Unfortunately, after sleep audio does not work any more like any other AppleHDA i tried. Has anyone a solution for it ? AppleHDA works nice but if i put my system to sleep and awake it, audio does not work any more and i need to reboot. That's the main reason why i am using VoodooHDA .

 

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

 

 

 

Thank you manmal, and yes i tried your modified voodoohda_2.61 and result is:

-Only the first half of volume control work (like you)

-Mute not working.

 

AppleHDA kext exist (AppleHDA 1.8.4fc3, patched by deviato for IDT 92HD71B7X for Dell Inspiron 1545) but since we have the same ID it works for me too, sorry i don't know for sleep because i have problem with wake up (for now), this is the link:

http://deviato.wordpress.com/2010/03/31/10...-driver-update/

 

i hope that you success to give us the perfect voodoohda for our IDT;

 

and sorry for my english;

[jdys_1991]

I get this error when I press compile DSDT:

 

 

Intel ACPI Component Architecture

ASL Optimizing Compiler version 20091214 [Dec 16 2009]

Copyright © 2000 - 2009 Intel Corporation

Supports ACPI Specification Revision 4.0

 

/Users/jay/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl 11233: [*** iASL: Read error on source code temp file /Users/jay/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.src ***]

Error 4096 - syntax error, unexpected $end ^

 

ASL Input: /Users/jay/Library/Application Support/EvOSoftware/DSDT/DSDTFiles/dsdt.dsl - 11234 lines, 407302 bytes, 5484 keywords

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

 

 

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!

dsdt.zip