[GUIDE] Dell XPS 15 (9550) Mojave 10.14 / 10.15 Quick Installation

[Krim404]

57 minutes ago, pourhaus said:

OK, that was a quick post where I was hoping someone may have hit a similar problem.

Let me expand. As mentioned, I used U-n-i-B-e-a-s-t and Clover from t-m-86 to install _just_ the USB. That works from F12 boot menu, and is able to boot the High Sierra it installed from the SSD. I used the Clover, EFI and instructions from the GitHub repo to update/configure the High Sierra on the SSD itself (post-boot). Boot direct from the SSD does not work. I get _no_ text from the OS, it goes from BIOS boot menu to black screen for 5-10 seconds, then to Dell blue can't-boot screen.

as i said... you didnt install clover properly and/or forgot to configure the boot priority. both is explained in the tutorial.
also i will not give support for any tool by TM - see the FIRST text in the tutorial for the reason.

32 minutes ago, Rajveer86 said:

Quick question, has anybody upgraded their 10.13.3 install with the new "10.13.3 Supplemental Update" and if so, how did it go?

works. :-)

Edited March 15, 2018 by wmchris

[Rajveer86]

1 hour ago, wmchris said:

works. :-)

Thank you for the quick reply, I've updated it and it works fine too

[gujiangjiang]

On 2018/3/13 at 6:17 AM, goodwin_c said:

This will:

- permanently enable TB controller (USB-C works like a charm  )

- should make VoodooI2C attaching to TPD acpi device

Hello goodwinc

Does it means it dont need macOS-IOElectrify.kext anymore to enable TypeC?

[Krim404]

9 hours ago, gujiangjiang said:

Hello goodwinc

Does it means it dont need macOS-IOElectrify.kext anymore to enable TypeC?

never required any of these and i used usb-c on a regular base. :-/

[gujiangjiang]

never required any of these and i used usb-c on a regular base. :-/

SSDT-TYPEC.aml？
SSDT-TB.aml？
SSDT-XHC.aml？

May you share your acpi/parched to me to see what happened.

Thansk


从我的 iPhone 发送，使用 Tapatalk

[gujiangjiang]

I test again my xps couldn't recognize typec in hotplug and i must plug it before power on.

I use SSDT-TB.aml SSDT-TYPEC.aml SSDT-TBON.aml SSDT-XHC.aml SSDT-USBX.aml.

 

I try to delete some of them but with no use.

 

How can fix TypeC hotplug.

[gujiangjiang]

I test again my xps couldn't recognize typec in hotplug and i must plug it before power on.

I use SSDT-TB.aml SSDT-TYPEC.aml SSDT-TBON.aml SSDT-XHC.aml SSDT-USBX.aml.

 

I try to delete some of them but with no use.

 

How can fix TypeC hotplug.

 

Update:

And i get back to AppleSmartPS2 kext and delete voodooI2C because when i change to VoodooI2C it may reboot when wake up and come out some ERROR message when boot into macOS.

[Rajveer86]

Sorry to ask something that seems so obvious, however I'm looking to change my SMBIOS to MacbookPro13,3 and have read in this (and other) guides that I will need to change the fake ethernet to en0. The confusion arises from darkhandz's guide (https://github.com/darkhandz/XPS15-9550-High-Sierra#网卡顺序修正) where he doesn't have the fake ethernet installed and instead has the wifi as en0. Is this because this guide defaults to using an iMac setup whereas his defaults to MacbookPro13,3?

[th3_v0ice]

Hello guys, 

This is a little bit out of topic but i had to ask. My dell decided not to give any signs of life at all. Pressing the power button does nothing and status LED is not lightning up also. It seems like its completelly dead. 

I tried removing ssd, ram modules and turning it on, but even then it doesnt give error codes (amber and white lights) on front LED. 

The only time it responds is if I hold CTRL + ESC and insert the power adapter. But according to the manuals something should be displayed on the screen but its not. 

The laptop is missing the battery and this happened when i pulled the cable out because it was stuck on the dell logo for a while and it didnt respond to the power button.

Any kind of help is appreciated. Thanks!

[goodwin_c]

50 minutes ago, th3_v0ice said:

Hello guys, 

This is a little bit out of topic but i had to ask. My dell decided not to give any signs of life at all. Pressing the power button does nothing and status LED is not lightning up also. It seems like its completelly dead. 

I tried removing ssd, ram modules and turning it on, but even then it doesnt give error codes (amber and white lights) on front LED. 

The only time it responds is if I hold CTRL + ESC and insert the power adapter. But according to the manuals something should be displayed on the screen but its not. 

The laptop is missing the battery and this happened when i pulled the cable out because it was stuck on the dell logo for a while and it didnt respond to the power button.

Any kind of help is appreciated. Thanks!

Actually, CTRL+ESC is starting Dell Bios Recovery 2. And it is tricky - it is starting only when it can find recovery file. If file is not found - it will just start and shutdown in few seconds, and even without showing anything on screen.

To start Bios Recovery properly, do next steps:

 - Download bios update file from Dell site (it will be .exe file)

- Rename this file to BIOS_IMG.rcv (yes, from exe to rcv. file name should have perfect match)

- Take some not-too-big USB flash drive, format it in FAT32 fs

- Copy BIOS_IMG.rcv to the root of flash drive

- Insert flash drive to left USB port on laptop (shouldn't be difference in which port, but from my personal experience left one is better )

- Start laptop with CTRL+ESC. If flash drive has activity led - it should blink at least few times. If machine is not physically damaged - it will run bios recovery with options to reset BIOS settings and re-flash BIOS image

[pourhaus]

On 3/15/2018 at 1:06 PM, pourhaus said:

OK, that was a quick post where I was hoping someone may have hit a similar problem.

Let me expand. As mentioned, I used U-n-i-B-e-a-s-t and Clover from t-m-86 to install _just_ the USB. That works from F12 boot menu, and is able to boot the High Sierra it installed from the SSD. I used the Clover, EFI and instructions from the GitHub repo to update/configure the High Sierra on the SSD itself (post-boot). Boot direct from the SSD does not work. I get _no_ text from the OS, it goes from BIOS boot menu to black screen for 5-10 seconds, then to Dell blue can't-boot screen.

I have now re-installed, following the entire guide here as closely as I can, using Pandora's Box and not U-n-i-B-e-a-s-t. I have also upgraded my firmware to 1.5.1 as I found a YouTube video where that was being used and worked.

I am still not able to boot directly from SSD (which is partitioned using APFS by the way), but can boot from the USB.

Any suggestions?

[Krim404]

18 hours ago, pourhaus said:

I have now re-installed, following the entire guide here as closely as I can, using Pandora's Box and not U-n-i-B-e-a-s-t. I have also upgraded my firmware to 1.5.1 as I found a YouTube video where that was being used and worked.

I am still not able to boot directly from SSD (which is partitioned using APFS by the way), but can boot from the USB.

Any suggestions?

For the last time: read the TUTORIAL! https://github.com/wmchris/DellXPS15-9550-OSX/blob/10.13/Tutorial_10.13_Step7.md#clover-doesnt-boot-or-model-name-error

 

Edited March 19, 2018 by wmchris

[pourhaus]

OK, so I added an entry to the BIOS for CLOVERX64.efi.

It still does not boot from SSD.

BTW, a suggestion - how about you add a note to the guide in Step 3, near where it says "Your system should be bootable by itself", that if it can not, refer to "clover doesnt boot OR Model Name Error" in "Step 7: Fixes / Enhancements / Alternative Solutions / Bugs".

[hackedWifi]

OK, so I added an entry to the BIOS for CLOVERX64.efi.
It still does not boot from SSD.
BTW, a suggestion - how about you add a note to the guide in Step 3, near where it says "Your system should be bootable by itself", that if it can not, refer to "clover doesnt boot OR Model Name Error" in "Step 7: Fixes / Enhancements / Alternative Solutions / Bugs".

You are obviously not reading. Why don't you create an USB with create install using Rehaab man tutorial. Pandorabox never work for me. [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] is only for desktop set ups.

Sent from my Pixel XL using Tapatalk

[Krim404]

5 hours ago, pourhaus said:

OK, so I added an entry to the BIOS for CLOVERX64.efi.

It still does not boot from SSD.

BTW, a suggestion - how about you add a note to the guide in Step 3, near where it says "Your system should be bootable by itself", that if it can not, refer to "clover doesnt boot OR Model Name Error" in "Step 7: Fixes / Enhancements / Alternative Solutions / Bugs".

because i wrote in the tutorial - at the very beginning:
 

Quote

please read the whole document before reporting an issue to prevent multiple questions. Also check Step7 and do a google search.

i dont include jump statements in a 3 page document for people who mistake a tutorial for a bash script.

also i want to hint to:

Quote

But it is NOT suited for people with no or only few knowledge in Hackintosh Systems. If you only know how to copy commands in your shell and you dont know what they're doing, then stop the tutorial and revert to windows or buy a real mac. Even if you get it running: this system is not failsafe and will be broken multiple times in its usage time, where you have to fix it without a step by step tutorial.

your issue is not even a specific issue for this computer. You cant get Clover to boot. This is pre- driver and pre- configuration. It's like: "i cant get my nuclear reactor to work. need help with how to open the front door". We know it's not a clover issue, because the preconfigured stick works. So if you cant configure the EFI to boot from your internal SSD, how will you fix the real issues?

 

Edited March 20, 2018 by wmchris

[Krim404]

On 17.3.2018 at 9:36 PM, Rajveer86 said:

Sorry to ask something that seems so obvious, however I'm looking to change my SMBIOS to MacbookPro13,3 and have read in this (and other) guides that I will need to change the fake ethernet to en0. The confusion arises from darkhandz's guide (https://github.com/darkhandz/XPS15-9550-High-Sierra#网卡顺序修正) where he doesn't have the fake ethernet installed and instead has the wifi as en0. Is this because this guide defaults to using an iMac setup whereas his defaults to MacbookPro13,3?

Some Mac-Services identify itself by the Mac(-Address) The wifi driver has been reported as unstable in the past, which resulted in en0 been absent - so no mac address.

obviously it will boot without fake ethernet, but you can run into issues with the AppStore.

So it's just more failsafe to use fake ethernet.

Edited March 20, 2018 by wmchris

[Lockzi]

On 3/20/2018 at 9:05 AM, wmchris said:

It's like: "i cant get my nuclear reactor to work. need help with how to open the front door".

1

Best thing I've read all day hahahaha

[alex.daoud]

On 11/03/2018 at 9:59 PM, hvolkoff said:

So, my post was deleted due to the forum's recent changes...

Anyway, here is what you need to enable VoodooI2C on our machine (Better touchpad and touchscreen)

More info about VoodooI2C here (thanks @alexandred for the great work)

Add these two entries to Clover's config.plist at `ACPI > DSDT > Patches`:

<dict>
	<key>Comment</key>
	<string>change GPI0 device _STA to XSTA</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X1NUQQCgCZNTQlJHAA==</data>
	<key>Replace</key>
	<data>WFNUQQCgCZNTQlJHAA==</data>
</dict>
<dict>
	<key>Comment</key>
	<string>change I2C devices _CRS to XCRS</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X0NSUwCgDg==</data>
	<key>Replace</key>
	<data>WENSUwCgDg==</data>
</dict>

Copy the SSDT-I2CX.aml file inside the attached zip to `CLOVER > ACPI > patched`

Download the latest VoodooI2C.kext release (link) and copy both VoodooI2C.kext and VoodooI2CHID.kext files to Clover's kexts folder . The other files are not needed. (more info about them here)

Reboot and that's it.

Personally I think the performance of our's laptop touchpad is better using VoodooI2C.kext than with VoodooPS2Controller.kext. And the added gestures to the Touchscreen are a nice bonus.

P.S: Don't delete VoodooPS2Controller.kext, as it is still necessary for the keyboard to function and it is compatible with VoodooI2C.

P.S.S: Inside the attached zip I included a beta version of VoodooI2C.kext (10.13 only, based on this changes) that enable native gestures and settings for our touchpad (Just like Apple's Magic Trackpad). However this version is in current development and those willing to test should expect bugs. 

I2C.zip

I did not give you permission to upload a compiled version of the native branch. Kindly remove it. I said multiple times that it was not for public use and the source code is online strictly for development purposes.

 

I will take down the source code for the native branch if people continue to abuse this.

[vasvas10]

48 minutes ago, alex.daoud said:

I did not give you permission to upload a compiled version of the native branch. Kindly remove it. I said multiple times that it was not for public use and the source code is online strictly for development purposes.

 

I will take down the source code for the native branch if people continue to abuse this.

Done, already removed it from the attachment. Sorry if it caused any troubles, wasn't my intention. However, I do have to point out that you actually gave permission to your software distribution when you released it under GNU GPL3, as per section 6.d. Maybe you want to revise the license?

[vasvas10]

On 15/03/2018 at 7:53 AM, Lockzi said:

Same for me. Even though removing the I2C kexts it does not work. It may be due to the SSDT-XOSI or voodooPS2daemon?

I have only tried the SSDT-XOSI as @goodwin_c suggested, not using the previous one with enabling later windows as @hvolkoff stated.

I have tried both I2C 2.0.1 and the "10.13 beta" as included in zip file of original post by @hvolkoff .

The ControllerInterrupt first two hex are "10" looking at IOReg.

I've noticed that in some cases the mouse works just fine during the login screen, but shortly after logging in it stops moving, hard to do mouse clicks, essentially unusable except for scrolling. The touchscreen, however, works perfectly.

Hun? That is weird. I don't think neither SSDT-XOSI nor voodooPS2daemon should cause any incompatibilities with I2C. Could you plz provide you system IOReg and logs?

Edited March 21, 2018 by hvolkoff

[Krim404]

46 minutes ago, hvolkoff said:

Done, already removed it from the attachment. Sorry if it caused any troubles, wasn't my intention. However, I do have to point out that you actually gave permission to your software distribution when you released it under GNU GPL3, as per section 6.d. Maybe you want to revise the license?

i was in contact with the original author @alex.daoud before, and it was quite the opposite of a friendly chitchat. i think his problem is, that he doesnt like to fiddle with any bug reports (quote: "i know all existing bugs") and this binary triggers the usage by people without much knowledge.

but this is the opposite of an open development, which is very sad.

i fixed some of the (what the original autor told me as "very hard to fix") bugs like the physical click errors, but i was unable to fix the random crashes. The native and the master branch kexts should be considered as highly unstable and i suggest everyone to stick to VoodooPS2 for now.

Before someone asks: I didnt push my changes back to the repo, because of the hostile enviroment...  still, if someone is interested in the changes, contact me.

Edited March 21, 2018 by wmchris

[68x]

1 hour ago, wmchris said:

i was in contact with the original author @alex.daoud before, and it was quite the opposite of a friendly chitchat. i think his problem is, that he doesnt like to fiddle with any bug reports (quote: "i know all existing bugs") and this binary triggers the usage by people without much knowledge.

but this is the opposite of an open development, which is very sad.

i fixed some of the (what the original autor told me as "very hard to fix") bugs like the physical click errors, but i was unable to fix the random crashes. The native and the master branch kexts should be considered as highly unstable and i suggest everyone to stick to VoodooPS2 for now.

Before someone asks: I didnt push my changes back to the repo, because of the hostile enviroment...  still, if someone is interested in the changes, contact me.

Just my opinion:

To be fair, @alex.daoud faces the same redundant questions being asked on Gitter (mostly from newbies) and most of the questions are quite easy to understand from reading the documentation. It gets quite frustrating after a while. However, I also understand where you are coming from.

I am pretty sure @alex.daoud is all for open-source community driven development. So why don't we all get along and get those pull-requests going shall we?

Back to the native branch:

A lot of the work on the native branch was *a lot* of guess work. I can provide more details on the multitouch protocol and the simulator. Feel free to PM here on InsanelyMac if you want to clarify on why certain parts of the code (i.e. magic constants) are set up that way.

[Rajveer86]

On 3/20/2018 at 8:30 AM, wmchris said:

Some Mac-Services identify itself by the Mac(-Address) The wifi driver has been reported as unstable in the past, which resulted in en0 been absent - so no mac address.

obviously it will boot without fake ethernet, but you can run into issues with the AppStore.

So it's just more failsafe to use fake ethernet.

Thank you for the help, I've gone ahead with making the fake ethernet en0 and everything seems to be working fine with my Apple ID

[Krim404]

1 hour ago, 68x said:

To be fair, @alex.daoud faces the same redundant questions being asked on Gitter (mostly from newbies) and most of the questions are quite easy to understand from reading the documentation. It gets quite frustrating after a while. However, I also understand where you are coming from.

ofc, thats why most people dont offer chat support and use either bug reports or add a readme with common bugs or a big warning, but if you dont add anything, people can be missleaded. for ex. the current readme file for the NATIVE branch contains:

Quote

Current Status

The following Intel I2C controllers are fully supported:

1. INT33C2 and INT33C3 - Haswell era
2. INT3432 and INT3433 - Broadwell era
3. pci8086,9d60, pci8086,9d61, pci8086,a160 and pci8086,a161 - Skylake/Kabylake era

The following device classes are fully supported:

1. I2C-HID devices
2. ELAN devices

how should anyone know that these are highly unstable pre-alpha debug code with major system compromising and os crashing flaws without reading +100 pages of chatlogs?
so i cant understand why @alex.daoud got so upset from the release of the compiled files by @hvolkoff. 

however this is highly off-topic, but VoodooI2C itself is not.

VoodooI2C has high potential, but it's not ready yet. Whenever i see a (semi-)stable release, i'll consider adding it to this tutorial. till then i can just repeat: VoodooPS2 has its flaws, too, but its much more stable and feature rich right now

 

--- Report of March, 21st 2018 ---

Pro of VoodooI2C:

• Much smoother scrolling
• faster reaction time

Con of VoodooI2C:

• no palm detection/rejection
• very VERY sensitive to touch, accidental clicks every time
• random crashes on bootup (with automatic reboot)
• random crashes after sleep (with automatic reboot)
• unable to customize
• is only compatible with the touchpad, NOT the touchscreen of the Dell XPS 15

 

Report of Native, last commit from early March: https://github.com/alexandred/VoodooI2C/commit/3be7546fd95693330dc84aa3feb7da11d7c3621c

Pro of VoodooI2C Native:

• Native Multitouch
• Configurable like an original Apple Magic Trackpad 2
• Everything from the Pro of the non native version

Con of VoodooI2C Native:

• Physical Clicks are buggy - nearly impossible to use
• Random Freezes
• Random Kernel Panics
• Random Crashes on Shutdown / unable to shutdown
• Most touch gestures dont work as they should - if at all
• hypersensitive
• Non working drag and drop
• Everything from the Con of the non native version
• and many more

 

 

Edited March 21, 2018 by wmchris

[alex.daoud]

9 hours ago, hvolkoff said:

Done, already removed it from the attachment. Sorry if it caused any troubles, wasn't my intention. However, I do have to point out that you actually gave permission to your software distribution when you released it under GNU GPL3, as per section 6.d. Maybe you want to revise the license?

Thank you. The license acts as a deterrent for companies like touch-base from appropriating code from VoodooI2C. Legally speaking, however, Apple's EULA nullifies any open source license that is applied to kernel level software developed for OS X. The license is merely the illusion of rights applied.

That being said I have always and will always be 100% committed to the open-source development of VoodooI2C. However, it is typically well-recognised that OSS that does not start as a form of collaboration between many people (i.e that was only really started and worked on for a large amount of time by one or two people) will develop a group of people that is known as the "benevolent dictator for life"(https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). Linux is a famous example of this whereby Linus Torvalds effectively has the final say as to what is merged into the master branch of the Linux kernel. Currently myself and @coolstar exercise our rights to this kind of control over the project due to the vast amount of man-hours we have put into it. We have recently (within the last year and a half or so) seen new people eagerly contributing and helping out and, gradually, they will also be able to exercise the same rights over the project.

 

One day I will officially leave this project fully to the community (and cease development myself) but that day cannot come until people realise that this whole idea of making some small changes, bundling them up in a new buggy kext and spreading these kexts around the internet severely undermines the hackintosh community as a whole. This is why the hackintosh community is so unpolished as compared to the iOS jailbreak community. There is very little attention to quality control and what is appropriate to be released as a "beta". This is also why we get so many of the same boring old questions over and over again - its because the internet is full of old junk kexts which people continue to download then complain about when they don't work. You can see this easily with VoodooI2C. We had someone called macforceone create a fork with a certain fix for Elan1200 back in the days of v1.0.0. It was a buggy fix and has long since been superseded - yet I still get questions about why this kext isn't working for people and whether its better to use than v2. The existence of these things undermines the very goal of this project: to provide super fluid (someday native) input on I2C devices. I spent 3 long months working very hard full-time to rewrite VoodooI2C from the ground up officially finishing it in September 2017. I held off on releasing until January 2018 after months of extensive private and then public beta testing. As a result, something that was written in 3 months is almost up to scratch to (and even often outperforms) VoodooPS2 which has been around (and not been rewritten since) in various iterations for close to 13 years. I remember using the predecessor to VoodooPS2 back in 2005 when I first started hackintoshing and the performance has not drastically improved since then.

 

It is for this reason that I do not approve of anything that isn't on the Release page being posted anywhere. It really is for the good of the development of VoodooI2C.