HP Folio 13 Guide! UNIBEAST + parts of MultiBeast

[jackito]

This patch is an attempt to force 0x2a within the code I mentioned above...

sudo perl -pi -i 's|\x66\x83\xf8\x30\x0f\x87\xa7\x00\x00\x00|\x66\xb8\x2a\x00\x90\x90\x90\x90\x90\x90|g' AirPortAtheros40

Breakthrough!!!

Oct  6 00:33:28 localhost kernel[0]: ath_get_caps[4044] rx chainmask mismatch actual 3 sc_chainmak 0
Oct  6 00:33:28 localhost kernel[0]: 2.201315: ath_get_caps[4019] tx chainmask mismatch actual 3 sc_chainmak 0
Oct  6 00:33:28 localhost kernel[0]: 2.206108: Atheros: mac 128.2 phy 13.0 radio 12.0
Oct  6 00:33:28 localhost kernel[0]: 2.206122: Use hw queue 0 for WME_AC_BE traffic
Oct  6 00:33:28 localhost kernel[0]: 2.206131: Use hw queue 1 for WME_AC_BK traffic
Oct  6 00:33:28 localhost kernel[0]: 2.206140: Use hw queue 2 for WME_AC_VI traffic
Oct  6 00:33:28 localhost kernel[0]: 2.206149: Use hw queue 3 for WME_AC_VO traffic
Oct  6 00:33:28 localhost kernel[0]: 2.206158: Use hw queue 8 for CAB traffic
Oct  6 00:33:28 localhost kernel[0]: 2.206165: Use hw queue 9 for beacons
Oct  6 00:33:28 localhost kernel[0]: 2.206289: wlan_vap_create : enter. devhandle=0x6a3526b0, opmode=IEEE80211_M_STA, flags=0x1
Oct  6 00:33:28 localhost kernel[0]: 2.206352: wlan_vap_create : exit. devhandle=0x6a3526b0, opmode=IEEE80211_M_STA, flags=0x1.
Oct  6 00:33:28 localhost kernel[0]: 2.206401: ATH tunables:
Oct  6 00:33:28 localhost kernel[0]: 2.206406:   pullmode[1] txringsize[  256] txsendqsize[1024] reapmin[   32] reapcount[  128]

You want to check the the last boot.
Now wifi is detected and I was able to turn it on from system preferences.
Only problem, it doesn't detect any network (not 2.4 nor 5.0). But man this is really an improvement.

I'm running on AtherosInjector + AirPortAtheros40 patched + Kitchen_Sink DSDT patch. System.log attached.

 

[jackito]

Forget what I said.....

After a second reboot..... it's working!!!!!

I see all the networks (2.4 and 5) and I was able to connect without any problem.
This is awesome man, you should change your nick to "THE MAN".

 

[jackito]

More findings. I just rebooted with a DSDT missing the "Kitchen_Sink" patch, and WiFi still works.

This is awesome.

It seems that all the magic is done by the two patches done directly to the driver.
I'm tempted to remove the injector too, to see if things keep working or not.
Deleting the injector kext from S/L/E, refresh cache and reboot is enough right?

 

[RehabMan]

Forget what I said.....

After a second reboot..... it's working!!!!!

I see all the networks (2.4 and 5) and I was able to connect without any problem.
This is awesome man, you should change your nick to "THE MAN".

OK, cool... You should be able to use only the injector kext or only the DSDT patch (with the DSDT patch, the injector is not in play).

I take it these patches are working with 10.9.4? I was looking at the 10.9.5 binary, but probably the code is similar enough for the patches to apply.

You probably want to test after a sleep/wake cycle, just in case there is additional code that runs when waking from sleep (because the card would have to be re-initialized). Chances are it runs through the same function(s) though.

And finally, you might want to transition to Clover, since the patches can be done on the fly from config.plist.

 

[RehabMan]

More findings. I just rebooted with a DSDT missing the "Kitchen_Sink" patch, and WiFi still works.

Yes, in that case the injector is loading the driver for you...

This is awesome.

It seems that all the magic is done by the two patches done directly to the driver.
I'm tempted to remove the injector too, to see if things keep working or not.
Deleting the injector kext from S/L/E, refresh cache and reboot is enough right?

You need one of "DSDT patches" or "injector" to make the driver load. Once the driver loads, the patches help it work with the odd-ball device-id (the driver is reading the ids directly in PCI-config).

If you remove both the DSDT patch and the injector, the driver will never load (because it is not in the Info.plist).

 

[jackito]

OK, cool... You should be able to use only the injector kext or only the DSDT patch (with the DSDT patch, the injector is not in play).

I take it these patches are working with 10.9.4? I was looking at the 10.9.5 binary, but probably the code is similar enough for the patches to apply.

You probably want to test after a sleep/wake cycle, just in case there is additional code that runs when waking from sleep (because the card would have to be re-initialized). Chances are it runs through the same function(s) though.

And finally, you might want to transition to Clover, since the patches can be done on the fly from config.plist.

Indeed they are working with 10.9.4.

I don't have a clue about what Clover is, but I will check it out tomorrow.

Again, thanks a lot for your time, help and voodoo that made this project work.

Oh and one more question: would it be possible to make Fn+F12 turn wifi on and off? Will that need another DSDT patch, or should I check with the PS2 Debug + ACPI Debug kexts first to see if keyboard is generating any codes or not, like with the brightness keys?

 

[RehabMan]

Indeed they are working with 10.9.4.

I don't have a clue about what Clover is, but I will check it out tomorrow.

Again, thanks a lot for your time, help and voodoo that made this project work.

You're welcome... enjoy...

Oh and one more question: would it be possible to make Fn+F12 turn wifi on and off? Will that need another DSDT patch, or should I check with the PS2 Debug + ACPI Debug kexts first to see if keyboard is generating any codes or not, like with the brightness keys?

It may work already... you should test it. Otherwise it may require DSDT debugging/patching. Or may not be possible without significant work. Many of those special keys defer from DSDT to a special OEM (Windows) driver. But sometimes they are handled internally (ProBook handles it in the EC, for example).

 

[jackito]

You're welcome... enjoy...



It may work already... you should test it. Otherwise it may require DSDT debugging/patching. Or may not be possible without significant work. Many of those special keys defer from DSDT to a special OEM (Windows) driver. But sometimes they are handled internally (ProBook handles it in the EC, for example).

Just checked it. Didn't work. So when I find a slot during the week I will do some debugging and come back. In any case is a very very minor thing.

 

[jackito]

Just checked it. Didn't work. So when I find a slot during the week I will do some debugging and come back. In any case is a very very minor thing.

So I found a slot to test the keyboard combination (Fn+F12) to turn wifi on and off.
It seems to go through ACPI too (like the brightness keys).

Oct  8 21:50:16 TestOSX-MacBook-Pro kernel[0]: ACPIDebug: "EC _Q40 enter"
Oct  8 21:50:17 TestOSX-MacBook-Pro kernel[0]: ACPIDebug: "EC _Q40 exit"

Do you think you can figure out a DSDT patch to enable/disable wifi?

Thanks!

 

[RehabMan]

So I found a slot to test the keyboard combination (Fn+F12) to turn wifi on and off.
It seems to go through ACPI too (like the brightness keys).

Oct  8 21:50:16 TestOSX-MacBook-Pro kernel[0]: ACPIDebug: "EC _Q40 enter"
Oct  8 21:50:17 TestOSX-MacBook-Pro kernel[0]: ACPIDebug: "EC _Q40 exit"

Do you think you can figure out a DSDT patch to enable/disable wifi?

Thanks!

If you look at the code for _Q40, you see:

            Method (_Q40, 0, NotSerialized)
            {
                Store (0x40, P80H)
                Store (Zero, Local0)
                If (LEqual (OSYS, 0x07DC))
                {
                    Notify (WLBU, 0x80)
                }
                Else
                {
                    ^^^^WLBU.UPWL ()
                    Sleep (0xC8)
                    Store (0x05, ^^^^WMID.WEI1)
                    Store (Zero, ^^^^WMID.WED1)
                    Notify (WMID, 0x80)
                }
            }

So for the case of Windows 2012 (aka. Windows 8) (OSYS=0x7DC), it simply notifies the WLBU device. In the other cases it does some stuff notifies WMID. In the former, you can see that the WLBU device is an HP specific device, which probably has a specific driver to interface and capture that notification (to turn WiFi off in this case). In the case of pre-Windows 2012, it is interfacing to WMI (Windows Management Instrumentation) -- again to communicate to a Windows specific driver.

Since your DSDT doesn't handle "Darwin" as "Windows 2012" (no patch in _SB.PCI0._INI for it), you are falling into the latter case.

Either way, it does not appear that the DSDT toggles the power level to the device by itself -- it relies on notifications into Windows drivers to do the actual work.

If you could figure out a way to turn the WiFi device on/off (in a safe manner) from DSDT you could write your own code to do it directly in _Q40.