Jump to content

MacOsX on the Surface Pro 3


LonelyTV
 Share

195 posts in this topic

Recommended Posts

If you're referring to the typecover, it doesn't work at all.

 

If you mean that you have an external USB mouse and keyboard and it still doesn't work, try the kext from here: https://github.com/RehabMan/OS-X-Generic-USB3

 

Edit: sorry, didn't read that you don't have an external mouse. You'll need to get a hub, mouse and external keyboard because the typecover doesn't work yet.

 

There are USB 3 issues galore with the new tablets. The keyboard extensions don't work on either the Dell or the Surface.

Link to comment
Share on other sites

ohh i see ... thanks for explaining.. so in order to get the boot + installer from USB. I will need a usb hub of course.

I should probably try booting from a micro SD then and use a usb mouse.. 

I don't think the SD Card slot works. I don't personally have a Surface Pro 3 but I haven't seen any confirmation of it working. It doesn't work for me on the Dell.

Link to comment
Share on other sites

Alex here is the ioreg after the DSDT OSYS change to include darwin

 

Not sure if the DSDT took effect though.

 

 


Apparently the audio codec is Realtek ALC288 per windows devices manager

Device ID 0x10ec0288

 

But it still does not work with the patched AppleHDA

 

Wonder if voodooHDA will work?

 

Edit: As Suspected audio works with VoodooHDA-v2.8.7

 

I am currently running 10.10.2 on surface pro 3 .

 

Using a USB wifi card for now.

Ravi’s MacBook Pro_afterOSYS.zip

Link to comment
Share on other sites

Alex here is the ioreg after the DSDT OSYS change to include darwin

 

Not sure if the DSDT took effect though.

Hi wen1, thanks for that. DSDT changes did take effect (you can tell because the I2C busses have appeared in the IOReg), I was just wrong about the UART! Surface Pro 3 has no UART unlike the Dell (teaches me to make assumptions) which might mean good news for the Bluetooth adapter on the Surface Pro 3.

 

First I want to see if the BTKL device (Bluetooth RF Kill) is used on the Surface. Can you please boot Windows and go into the device manager and check for a certain "

Intel Bluetooth USB HW RFKilldevice. I am not sure where it will be in the Device Manager but if I have to wager a guess, it will be in the "System devices" section. If not, just check all sections to see if the device is there. If you can't find it, can you provide the device IDs of the Wifi and BT cards please.

 

Can you also provide a copy of your DSDT please?

 

 

By the way, you don't have QE working on the Surface. Are you using FakePCIID?

Link to comment
Share on other sites

If you can't find it, can you provide the device IDs of the Wifi and BT cards please.

 

Hi Alex,

here are my device IDs:

 

Marvell AVASTAR Bluetooth Radio Adapter
Port_#0006.Hub_#0001
USB\VID_1286&PID_204B&REV_3201
 
Marvell AVASTAR Wireless-AC Network Controller
PCI-Slot 2 (PCI-Bus 1, Device 0, Function 0)
PCI\VEN_11AB&DEV_2B38&SUBSYS_045E0001&REV_00
 
Hope, this helps
gkarg
Link to comment
Share on other sites

Alright, there's one more thing I want to see before I can confirm ppage's observations on page 4. Wen1, in the DSDT search for 'BTKL' and change 'Windows 2012' in the '_STA' function to 'Darwin'. Please provide IOReg after.

 

I also forgot as this is important. Can someone provide me with the OEM SSDTs please.

Link to comment
Share on other sites

After comparing everything and looking into any trickery involved, I think ppage is right. His observations could have just been a result of the wifi hardware being powered on which powers on the bluetooth adapter instead of needing to upload the wifi firmware. However, it seems like, according to the IOReg, that the wifi hardware is powered on properly. The DSDT and SSDTs from the Pro 3 don't seem to indicate anything that would cause the bluetooth to be disabled and the Pro 2's DSDT and SSDTs are substantially different.

 

We will probably have to write the kext to upload the wifi firmware. I have looked at the Linux drivers (http://lxr.free-electrons.com/source/drivers/net/wireless/mwifiex/pcie.c) and the process isn't too complicated.

 

I would do it myself but I unfortunately do not have the time nor the incentive since I don't own a Surface Pro 3. The process of building and testing would probably be much more efficient if the kext was written by someone who has the device anyway.

 

I'm very happy to guide someone who is familiar with C++ through the necessary steps to port the firmware upload though.

Link to comment
Share on other sites

Alex,

 

I can develop in java and some other odd languages.

But have never built a kext of any kind. I have created a few simple iOS apps. So familiar with Xcode to some extent.

I can may be take this on if we give me some pointers.

 

I know nothing about device programming too.

Link to comment
Share on other sites

Alex,

 

I can develop in java and some other odd languages.

But have never built a kext of any kind. I have created a few simple iOS apps. So familiar with Xcode to some extent.

I can may be take this on if we give me some pointers.

 

I know nothing about device programming too.

Experience in Java may or may not cut it. Although they're both object oriented, they're not extremely similar. Do you have experience with C? That should be enough since C++ is pretty much an object oriented extension of C (as the name would imply).

 

If you're still up for it, find a PDF copy of "OSX and iOS Kernel Programming" and read through chapters 4,6,9. That will give you an idea on how hardware interacts with the Darwin kernel and will teach you how to begin writing a PCI driver. You'll then need to identify which parts of the linux driver are necessary in order to upload the firmware. From what I can tell, the control flow is like so:

  • Device probed and matched
  • set up memory map
  • register for interrupts
  • firmware upload by the "send data" function
  • wifi device 'rings the doorbell' (their words) i.e generates interrupt to signal that the data has been transferred successfully
  • catch interrupt and proceed to enable firmware? not sure, can't tell what happens when the interrupt is received without a more indepth analysis of the Linux drivers

 

As far as writing drivers goes, this is pretty easy (as compared to, say, ACPI enumerated device drivers). The Darwin kernel exposes a lot of the PCI functionality for you so you just need to identify how the Linux kernel commands correspond to the Darwin kernel commands.

Link to comment
Share on other sites

Hi wen1 & Alex,

Just to be sure, that you have the following information - there is already an existing XCode Project with Wifi (only stub) and Bluetooth (with firmware upload) for the Surface 2 - http://www.insanelymac.com/forum/topic/292645-guide-surfacepro-1-2-osx-android-windows-multiboot/page-75?do=findComment&comment=2016613

 

I used this Project to build a Surface Pro 3 Bluetooth kext - without having much knowlege - i just added the new firmware for our device in the .h File and also changed the Vendor/Hardware ID in the kext. But i was never able to load it.

 

So this linked Project could be taken as a start - i don't have my project anymore - but could create the bluetooth kext with 1 hour of work, if needed.

 

Thanks

Gkarg

Link to comment
Share on other sites

Hi wen1 & Alex,

Just to be sure, that you have the following information - there is already an existing XCode Project with Wifi (only stub) and Bluetooth (with firmware upload) for the Surface 2 - http://www.insanelymac.com/forum/topic/292645-guide-surfacepro-1-2-osx-android-windows-multiboot/page-75?do=findComment&comment=2016613

I used this Project to build a Surface Pro 3 Bluetooth kext - without having much knowlege - i just added the new firmware for our device in the .h File and also changed the Vendor/Hardware ID in the kext. But i was never able to load it.

So this linked Project could be taken as a start - i don't have my project anymore - but could create the bluetooth kext with 1 hour of work, if needed.

Thanks

Gkarg

Yes I've had a look at this but the WiFi stub doesn't do anything really. It's simply a stub that matches against the WiFi device. The Bluetooth firmware uploader will be very useful but first we have to see if uploading the WiFi firmware enables the Bluetooth USB adapter. For some reason, I have a hunch that it won't because it doesn't seem logical to me that Marvell would disable the Bluetooth if the WiFi firmware isn't loaded. Its our only lead though and ppage's observations point towards it being true so we will have to try it.

Link to comment
Share on other sites

Hi Alex,

could we use anything from https://github.com/rubiojr/surface3-kernel for thr WIFI part?

 

Thanks

Gkarg

We can't really use anything from Linux without porting it. However, there is something interesting that is linked to from there.

 

If I understand this page: http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=7f02df82736a85606cd9f33cb709545d9fc5326e, the bluetooth firmware is included in a combo firmware image containing both the WLAN and BT firmwares and can be 'downloaded through WLAN only'. That would explain why ppage was only able to get the BT working on Linux after he enabled the wifi drivers (and hence downloading the aforementioned combo image to the wifi card). I'm more convinced now that if we upload the wifi firmware, the bluetooth will start to work.

Link to comment
Share on other sites

Hi Alex,

Thanks - so could we use this http://www.insanelymac.com/forum/topic/205771-appleintele1000ekext-for-108107106105/ as an example to start with? This is another XCode Project for the AppleIntelE1000e.kext - or do you know a better Project to start with ? It would be great, if we would have a similar working kext XCode Source as an start for our driver.

 

Thanks

Gkarg

Link to comment
Share on other sites

Hi Alex,

Thanks - so could we use this http://www.insanelymac.com/forum/topic/205771-appleintele1000ekext-for-108107106105/ as an example to start with? This is another XCode Project for the AppleIntelE1000e.kext - or do you know a better Project to start with ? It would be great, if we would have a similar working kext XCode Source as an start for our driver.

 

Thanks

Gkarg

Not really. Your best option will be start with Jape's WLAN stub and get it to match against the new WLAN device ID found in the Surface Pro 3. You will then need to follow the steps I outlined above. Mapping the device's memory and registering its interrupts is fairly simple. Once you've got those parts down, you can easily just translate the Linux drivers to OSX.

Link to comment
Share on other sites

Here is an updated DSDT withe battery patch.

 

You also need to install ACPIBatteryManager.kext from rehabman for the battery to show status

 

Also, Attached the patch file i created if someone wants to apply it to their own DSDT

 

 

Rehabman,

 

I confirmed it woking. Feel free to add it to your patch repository 

 

Edit: Nevermind, it displays 100% all the time. Still some more work to do.

Edit2: works fine. I did not wait long enough. battery might last a while with the patch.

DSDT.aml.zip

battery_Surface-Pro-v3.txt

Link to comment
Share on other sites

Alright so lets recap. Although I read all tutorials online as best I could, i had hard times installing Yosemite on my surface pro 3 .  But I am up and running now with Yosemite boot from SSD. 

So what I have done thus far;

  1. Have installed Yosemite on a 8gb memory stick using the tutorial existent here;  http://www.insanelymac.com/forum/topic/301884-guide-surface-pro-1st-gen-yosemite-clean-installation including clover + drivers provided  SurfacePro V0.5.1 files Pack up to the Part 3 from tutorial
  2. Replace the clover Plist with the file supplied here;    Surface Pro 3 Clover Config.zip  (first page in this thread) 
  3. Using an USB hub i plunged in an USB mouse + USB keyboard + the original USB stick with Yosemite and clover installation done at chapter 1.
  4. Started the surface pro with USB boot enable and safe boot disabled in Bios 
  5. At the clover boot, i selected the stick drive where the Yosemite installer is, press space key choosing from the menu Boot Mac OS injection with Kext  NOT ( the option without caches and with injected Kext)
  6. After initiation of the hardware , Mac Installer starts , proceed further with Disk Utility, format partition using Mac Extended.
  7. After first restart the tablet will restart in windows. Restart again with boot from USB doing the steps indicated at number 4 and 5.
  8. Mac installer will continue to install the system until the end, chose country, language, login name and password, DONE. 

The trick part is to actually get to boot your surface from either windows or Yosemite without a USB help.

  1. Install latest EFI clover boot onto the newest Mac OS drive where Yosemite has been installed (same as you have installed initially clover on to the USB stick)
  2. Reboot into windows. 
  3. You must enable the EFI partition in windows to be accessible and writeable using File Manager. Use this tutorial http://defaultreasoning.com/2009/05/29/unhide-the-recovery-partition-on-a-basic-disk-with-diskpart/
  4. Then after EFI drive becomes visible and accessible, you must simple replace the entire EFI folder installed at step 1 with the EFI from your installing memory stick. 
  5. Restart again your computer booting one more time from the same memory stick used to install Mac Os Yosemite.
  6. At the clover boot menu go to both "clover boot options" existent then press space for each enabling "add clover boot options for all entries

That is it, the next restart clover will be enabled automatically and you can safe boot from either windows or Yosemite. Remember to always boot using boot with injected Kext)

 

My surface pro 3 has been identified as MacBook Air 

 

sound + wifi + type cover + others not working. Here is where I need help finding the appropriate drivers for all these. Hopefully others will chime in adding Kext that are required or explaining how to enable these... 

post-1477304-0-92615800-1423501534_thumb.jpg

post-1477304-0-85157500-1423501541_thumb.jpg

Link to comment
Share on other sites

 Share

×
×
  • Create New...