ktbos

I had the bulk of the write-up on this install completed back in November. However, I got hung up with monitor glitching or stuttering. At first it wasn't so bad but I knew that I couldn't call the job done at that point. And then it got bad enough I needed to fix it. I tried a bunch of things to fix it and eventually ended up just swapping which monitor was plugged into which DP. I didn't believe that would do the trick at first but now here 4 months later with everything still running smoothly, I'm way past time to declare victory. And therefore, I have finally published the full instructions to go along with the bootpack above. See my blog post for the full guide, and for the companion posts that include all the sources and supporting work to get it working. Monterey Hacintosh on Dell 9020 MT – Installation Guide

Success. I have my build complete and working well so far. In addition to the changes I mentioned in the prior post, I found that my USB ports didn't all work exactly right with @Baio77's EFI folder so I created my own USBMap for my 9020 MT. I did disable sleep entirely but I think that whatever the problem was with the kernel panic is now resolved with the new OpenCore version and new EFI folder. As was the case with my Yosemite build using Clover, I found I couldn't have two passive DP to DVI adapters working at the same time and that using one active DP to DVI adapter and one passive DP to DVI adapter works fine. For anyone that wants to give it a go, here's my installer setup folder. I'll write up the full instructions on my blog later but for now, the short version is to follow the same instructions in @morpheousman's original post but use the files in the attached zip. 9020_OC_085.zip Thanks again to morpheousman for pulling together the initial 9020 setup and to Baio77 for getting things working with the latest OpenCore - you two saved me lots of time in doing this build!

@morpheousman, I totally agree about if it isn't broken, don't fix it. And that's why my original 9020 is still running Yosemite! But that's way too old to get current software so that's why I'm working on this build. And the only reason I am aiming for the latest OpenCore is because I want to be able to stick with that install for years - and not need to update OpenCore. But thanks for the reply and thanks for the help in getting me this far with that post! Oh, and as far as the wake from sleep, I don't plan on sleeping this desktop but my sense is that if there is something not quite right with the graphics drivers on wake, it may well bite me somewhere else. So I'm going to test that out once I get the build the way I want. @Baio77, thanks very much for sharing. I was able to download it and get it to work just fine. I compared the config.plist to the prior attempt and there was a lot different - too much to key into one thing in particular and speculate on what did the trick. I did edit the config.plist to add in the SMBios stuff I had built. And when I ran after that, I got an error saying that the version wasn't supported on the platform so I modified the platform from iMac15,1 to iMac17,1 and that took care of that error. Then I cleaned out the kextlog and keepsyms to just keep the "-v" on the log. Also, I set AppleXcpmCfgLock to false since I had followed morpheousman's advice in running the setup_var commands to modify the BIOS. Then I added in the settings for the AudioDxe to get the chime on boot up. I'll share all of this when I get a bit further into the build. Next up is making sure the wake from sleep doesn't cause a kernel panic like it did in the prior build. Thanks again to both of you!

This is a continuation of @morpheousman's post for Big Sur and OpenCore 0.6.6 (post). I have been able to successfully follow those instructions and at least get the base install done to a working desktop. There are some imperfections still (e.g. waking from hibernate kills it) but for the most part, it looks successful. So I wanted to take the next step and upgrade from OC 0.6.6 to the just release OC 0.8.5. After updating the OpenCore.efi file, I had a number of incompatibility issues in the config.plist that needed to be resolved. Once those cleared, I got to the point where I can start the boot but it fails right away at "[EB|#LOG:EXITBS:START]". I've gone through the OpenCore troubleshooting for that error but no progress at all. I have the 0.8.5 EFI folder set up with all 0.8.5 tools, 0.8.5 drivers, and the latest versions of the kexts. If I replace the OpenCore.efi with the one from 0.6.6, it works well. But when I change that file back to 0.8.5, the failure returns. The thing I'm trying to figure out is whether the latest OpenCore just isn't going to work with the 9020 or if it's just a matter of finding the right setting in the config.plist that needs to change/be added to work with 0.8.5. Any guesses?

Will this help?

I was holding off to see what others might have said but so you don't hang on too long @Zia-Ur-Rehman for any reply, here are my thoughts. The E5470 is new to me and I'm not really a fan of trackpad gestures. That's why I like that non-Apple-hardware has a a right button, for example. So I'm not going to be able to answer that. But I can tell you that this computer is pretty solidly built and allows for either an M.2 drive or a 2.5" SSD (depending on which it was ordered with originally or depending on what parts you get to change that after the fact). Supposedly some of these were built with touchscreens but they have been rare enough to come on the eBay scene that I'm not sure how real they are. There were 3 display resolution options - 1920x1080, 1600x900, and 1366x768. The lowest resolution is pretty lame for a laptop unless you are going to be docking it most of the time. The top resolution is really nice but on a 14" screen, it's pretty small. And the 1600x900 doesn't come up on eBay often. The backlit keyboard is a nice feature that I'd recommend. On the other hand, the E5570 gives you all the same benefit of the E5470 but in a bigger package. Compared to the E5470, the E5570 gives you enough more display to make 1920x1080 fit well and gives you a keyboard with a numeric keypad section which I'm really enjoying. If you choose the M.2 form factor for a drive on the E5570, you can even get a battery that's something like 50% larger (that fills the space that would otherwise go to a 2.5" SSD). The replacement cost for those extra large batteries might not be worth it to you but the option is there. For either the E5470 or the E5570 (or probably any others in this series), beware of broken USB ports. Dell's design for the port relied on solder for the USB 3 conductors to provide the physical resistance to the guts of the port. So overuse or abuse of the port means broken USB 3 conductors - you end up with the plastic inside able to wiggle in and out which is a clear sign that the conductors are no longer conducting. Hopefully others who are using an E5470 daily (or an E5570) will weigh in here with thoughts on it for you. And can maybe answer your multi-touch trackpad question.

If by "speed differences", you mean the boot time, It is definitely related to Trim. Turning off Trim and boom, problem goes away. And from what I can tell, Trim works just fine on most SATA3 drives and it is a small set of Intel drives where the MacOS Trim doesn't work well. If by "speed differences", you mean the regular runtime interaction, I'm only talking about the Intel drive with Trim on versus off. (I'm definitely not comparing the SATA3 to the NVMe drives because of their built in differences.) As I wrote, I'm expecting the slight penalty to turning off Trim to be imperceptible to me compared to when it was on.

The boot problem swapped computers when I swapped drives. That ruled out anything else about the hardware which was a good start. But meant that it could have been the file content on the hard drive or the hard drive itself. Thanks a lot @Jake Lo. That helped me figure it out. I used Clover Configurator to disable the IOACHIBlockStorage kext patch for enabling trim and the problem went away completely. A normal boot. Then I tried using the trimforce enable and the problem returned. trimforce disable and the problem went away again. Pretty clear that the problem is Trim with this SSD. So I researched that and found @Hervé had posted about a similar issue a while ago with an older model of an Intel SSD. I booted into Windows and confirmed that Windows 10 had trim enabled for that drive ("fsutil behavior query DisableDeleteNotify" returned zero meaning the disabling of delete notify is disabled which is better stated as: Trim is on). So it really comes down to some weird issue that MacOS has with this particular drive. I wrote it above but for completeness here, the drive that is causing this problem is an Intel SSDSCKGF256A5 M.2 256 Gb SSD. It is connected via the M.2 connector and shows in the SATA section of System Information. The SSD that works without issue in my other computer, the E5570, is a WD M.2 NVMe and shows in the NVMExpress section of System Information so there's a lot different about it. But from the fact that most people seem to have Trim working on their non-Apple SSDs, it seems that the main problem is this particular drive. The upshot is that if I want a fast boot and I want trim working, I should replace the SSD. Since I don't want to replace the SSD, I need to choose either to have a fast boot or to have Trim working. From what I can tell, not enabling Trim will mean an imperceptible decrease in drive performance especially when running non-taxing applications and could accelerate the demise of the SSD. I can live with that. So I'm going to proceed with the kext patch disabled and after having entered trimforce disable.

I thought about it but decided against it because I thought I'd probably get some other messages about different hardware and because rebuilding the systems on different hard drives would be difficult now that they've been put into use. But I can try just swapping the drives and see what happens. And I'll look into how to disable trim later/tomorrow. Thanks Jake.

Back to the question of the booting up, I'd still like to figure out where the log is stored. I haven't been able to find that. But since I haven't been able to find it, I did a slow-mo of the two points where it gets stuck. That way I could see what the next thing printed is. I'm not sure that really answers the question but it might help. And at least in the first one shows that time is really being used by something. The first place it hangs prints this after 24 seconds: spaceman_trim_free_blocks:3326: scan took 21.194665 s, trims took 20.960902 s The second one after 18 seconds prints this: unexpected session: 100000 uid: -1 requested by 50 AppleKeyStore: operation failed (pid: 50 sel: 7 ret: e00002c2 '-536870206', -1, 100000) I Googled about both of the above. In the case of "spaceman" doing a "trim", I have no idea why my E5470's SSD would be so slow to respond to that. Or why it would be different than the E5570. And in the case of the second, it almost seems like there might be something residual from when trying hibernation but I just confirmed and hibernatemode is zero and the hibernatefile is /dev/null. And this is after a restart, not a sleep so Sleep/Hibernate shouldn't be an issue. Hopefully the above gives you something to go on. Thanks!!

Thanks @Jake Lo for the "update" but unfortunately, there was no change. Still about 24 seconds and about 18 seconds at the same points as before. I deleted the ACPI and kexts folder and config.plist file from the EFI/CLOVER and replaced them with the ones you sent. I know they took effect because I had disabled the mouse in Clover but I could see it was on for this boot. So at least something changed but not the getting stuck part. Regarding the USB Ports, I had fixed that last week. I realized that I hadn't hit the "minus" in Hackintool before doing the Export. I updated that kext in my guide but I didn't think to mention that here in this topic. Sorry about that. Regardless, using your "update" would have replaced the USB Ports kext anyway and that still didn't resolve the boot hangs. I looked through the changes - adding the HPET patch, swapping out some kexts for others - interesting ideas but I wonder about why the E5570 would work fine while the E5470 does not. The storage on the E5470 with the problem is an Intel SSDSCKGF256A5 which isn't the latest greatest. The storage on the E5570 is a WesternDigital WDS500G3X0C which is brand new and super speedy. That seems to make a difference on general speed but I wouldn't think it would cause two holds totaling 42 seconds. Both are M.2 SSDs and I've got the OS installed on APFS on both. Both have the same Fenvi Broadcom cards that replaced the original Intel WiFi/BT cards. Both have 16 Gb of RAM though they are various brands. And the BIOS settings are the same on both computers too.

I still haven't been able to figure out why this particular computer is hanging at these weird places during the boot while the other computer is not. The one that works without any hang-ups is: E5570, i7-6820HQ, 1920x1080. The one that gets hung up as described above is: E5470, i5-6440HQ, 1600x900. Both are HD530 (though the E5570 also has the AMD that has now been disabled with Jake Lo's patch) with the same external connectors. Both have the same exact base build/install/setup (though the E5570 has additional content for the Thunderbolt). Any suggestions on how to debug this? What logs to look at? What things might be worth looking into changing?

The only "release" is for the kext alone. If I did a pull on the whole dev directory, I found the makefile, but the instructions are too light to guide me how to do the Make correctly. That's why I was trying for just the one file. But I see your point now - this one file isn't ready for use until after running through the Make. So that means that overall, I was using the tools correctly but not the project correctly. Therefore I'm still at the point where there isn't enough there for me at this project. If at some point that dev project gets a little bit further along or somebody else wants to spend the time to do that dev work, I'll be happy to get back into it.

Wow, then I'm doing something really dumb. So let's start with I'm doing all this on the E5570 itself with Catalina running. The version of MaciASL I'm running is 1.5.8. It doesn't say the developer info in the about panel and I don't recall when/where I got it. I go to https://github.com/osy86/ThunderboltReset/blob/master/ThunderboltNative/SSDT-TbtOnPCH.asl and then click on "Raw". I copy and paste the content of what is in the web browser to a new file in TextEdit (with format set to plain text) and then save it with the name "SSDT-TbtOnPCH.asl". Then if I double click on the file, it opens the "Console" application. If I try to drag the file on to the running MaciASL app icon in the dock, it refuses to do anything. If I use File Open I can't select the asl file in the Open dialog window. If I simply change the file extension from "asl" to "dsl", then everything works fine. But are they really the same thing? If instead I skip the TextEdit step and just do a New file in MaciASL and paste the contents from the Raw github page into that new window, it looks like it is fine initially. (Ditto if I rename the file to ".dsl" and double-click to open.) But when I click to compile, I get an error on line 17 that says "#error (Preprocessor)". I've been assuming that it should have compiled with no errors if I had the right file type in the right application. But maybe I have done everything right to this point and the file needs tweaking before it can be used. And if that's the case, I have no idea what tweaking to do. There are instructions at https://github.com/osy86/ThunderboltReset/blob/master/PatchingACPI.md that don't make sense to me so I was hoping to just use the base for Alpine Ridge (which is what I thought the file I was putting into MaciASL above was for based on the comments at the top of it). But if this preprocessor error is indicating that there is more work to go before I can compile, then I'm at the end of the line because I'm not going to be able to figure out what to do based on those instructions. Which brings me back to what I wrote above: "I'd need more handholding than I think is worth it".

Unless I missed something, the download is an ASL and MaciASL wouldn't open that file natively.

The uncompiled text file type in MaciASL is a DSL and yes, pasting the github ASL text into a new DSL file what I had tried. That's what gave me all the compiler directive errors. I took it as a problem with my process/tool but maybe the issue is with the file. Either way, I don't know that it is worth pursuing at this point. I've made my peace with the Thunderbolt port being merely decoration on my computer.

In the process of trying to figure out hibernation (that's another topic), I looked more into why my E5470 gets hung up booting up at a couple of points. Especially now that I can see that the E5570 does not get hung up the same way. (and that might help explain the hibernation difference) It'd be great if I could find the log somewhere on the system but I searched for the stuff I saw on the screen in the dmesg and in doing the log show predicate thing and I couldn't find any of the text there. So far starters, if somebody can point me to where I can find the full log of what rolls by during bootup with -v on, including the phrases I'm going to detail below, that'd be great. But for now, I can at least write about what was on the screen at the time the log got hung up. The first spot is right after it showed "VM Swap Subsystem is ON". It hung there for about 24 seconds. The second spot was after it printed "AirPort_BrcmNIC::getSSIDData(): Get failure: APPLE80211_IOC_SSID: 6". It hung there for another 18 seconds. I don't know if the thing that it is stuck on at those points it what it printed for a message or what it was working on next that it hadn't yet printed. But maybe what I've written above is enough to go on. And the fact that the E5570 doesn't get hung up in either of these places and just races right through to login is very strange considering I'm using the same setups and versions of everything. Oh, and I updated both computers to 10.15.7 this morning which didn't have an impact on the boot up of either computer.

Yes, I had tried it. But to be honest, I couldn't remember how I tried it so I went back and did exhaustive testing this morning. I used the latest HibernationFixup kext from acidanthera. And the Bootpack is pretty much the same as it was before but with some USBPorts tweaks (I had forgot to test USB3 ports when running Hackintool). One of the reasons hibernate needs exhaustive testing is because there are so many things that can impact it. In Clover Configurator, I had initially had the flag set to NeverHibernate. And there are a bunch of other flags that have the word Hibernate in them that needed to be tested and in combination with each other. (Documentation about those flags is not very descriptive so I couldn't really figure out which flags are needed for which circumstances.) There's also the issue of what to set in MacOS. I eventually settled on doing the following to put things back the way they were originally and then switch to Hibernate mode only. sudo pmset -a restoredefaults sudo pmset -a hibernatemode 25 So with those MacOS settings and with only the flags "StrictHibernate" and "HiberationFixup" selected, I got the closest. When I select sleep, the computer display immediately goes dark, spends about 30 seconds writing to disk and then the power goes off entirely. When I turn it back on, I get the BIOS boot, then Clover comes up and shows that the MacOS partition is "(hibernated)" and starts to boot it. But then it bounces back to the BIOS boot page and when Clover comes up again, there's no more "(hibernated)" and it boots up normally as a new start up. So right up until it failing to boot from the image, it looks like it is doing the right thing. I'd like to figure out why it can't boot from that image but I don't really know how. I thought I'd check out hibernation on the E5470 I have and see how that went. I fully expected the same result. But instead on that computer, I can't even get it to save to disk at all. It pretty much ignores the mode "25" and only sleeps to RAM. I did the setups the same way on both computers with the same kexts and USBPorts kext and SSDT files. Besides the differences in the motherboard (including Thunderbolt on the D5570), the SSD on the E5470 is slower and smaller, and maybe most importantly, on the E5470, I have only Mac and Windows with MacOS installed in the first partition while on the E5570, I have MacOS installed on the second partition and I'm also booting Ubuntu. If anything, I would have assumed the E5470 had a better shot of working so it's really surprising that it actually seems like it doesn't even get as far. I really don't know what to make of that. At this point, I'm back to where I was above. I'm fed up with the exercise of trying to get hibernation working when there are so many pieces that could be contributing to the issue. But if somebody has a suggestion for a solution, or even to figure out why it won't boot from the hibernated image, I'm willing to give it another try.

Thanks a lot for that link @Bronxteck. Wow. Umm.. Even if I had the tech chops to do it, I don't want to patch the firmware in my Thunderbolt Controller. So I went with door #2 and looked into using the kext and the native ASL and then modifying it. But I don't even know what to do with an "ASL" file. I use MaciASL and it works fine for DSL and AML but I can't get an "ASL" file in it (ironic considering the name). When I just copy the ASL from github and paste it in a new file in MaciASL, I get errors from the compiler directives - clearly not the right way to do it. Maybe there's a simple program or technique I'm missing which would be great. But it may be that to get through that process, I'd need more handholding than I think is worth it.

Jake, I clicked on the Precision 5510 link in your signature to take a look at what is getting the USB-C working on that computer - let me know if you have something later than what's in that link. Assuming it is the latest, I didn't see anything in the bootpack that's special for Thunderbolt. No special kext for Thunderbolt - it uses USBInjectAll so there's no special USBPorts kext. And the UIAC didn't seem to have anything particularly special for USB-C in it. I did find two SSDT files that were interesting, though. The YTBT had the name that was interesting so I looked into that and tested it. But it's pretty empty and didn't seem to have much effect. So the "TBT" may be entirely unrelated to Thunderbolt. The TYPC file was the most promising since it did include a connection on RP15 which could be similar to the RP05 on my E5570. And there was stuff in there about "Thunderbolt" and devices named "TB##". But that didn't seem to have an impact either, unfortunately. When I used it, The upshot is I couldn't figure out what in your published bootpack in your sig link is what gets your USB-C working. So @Jake Lo, what do you think about your 5510 setup is activating your USB-C port? Is the controller in your 5510 an 8086 15B5? One other thought - this could be a BIOS related issue. I'd be interested in the BIOS version on the 5510 and what the BIOS settings look like for Thunderbolt. I've got the latest BIOS and I think they have made changes to Thunderbolt in it based on security concerns.

For anyone looking for a Catalina bootpack as the title of this topic states, I've written a guide in the Guide section for the E5570 or E5470 and have a bootpack posted there that I'll try to update as I find reasons to update it. For now, here's my revision 2 bootpack compiled from this post and many others here at OSXLatitude. LatE5470 Bootpack-2.zip

Unsurprisingly, I didn't get hibernatemode=3 to work. In other words, I can't get it to sleep to disk, only to RAM. That's great for when you want it to wake up quickly but not so great for when it runs out of battery after going to sleep. It means I need to know before I leave the laptop whether I'm going to be back before the battery runs out so I prepare for a run out of power situation. Or I could always shutdown the computer. Or just leave it plugged in. All are options but none are as cool as MacOS provides for real Apple hardware where it sleeps to disk when it needs to. I know the hibernate topic has been discussed at length in many other locations but in case I'm missing something, if anyone has suggestions on how to sleep to disk for this E5570, let me know! Thanks.

@Hervé, thanks for replying with that info - if you don't have Thunderbolt in your 7490, then it's not worth pursuing the comparisons. I found this article from Dell describing which Latitudes had Thunderbolt as optional and both your 7490 and my E5570 are in that list. And therefore whoever configured my E5570 initially paid for the Thunderbolt and whoever configured Hervé's 7490 initially did not. And the funny thing is that paying more for the additional Thunderbolt controller actually makes the port less usable in a Hackintosh. Also, it's worth noting that my BIOS setup screen doesn't look like the one linked in the article. And most importantly, I don't seem to have the ability to bypass the Thunderbolt controller to make the port work like a USB-C/DP. It's wired differently. Which is why I can't just make my E5570 work like Hervé's 7490. At least as far as I can tell. I've also been reading more about the issue of hotplugging Thunderbolt on a Hackintosh and that appears to be the main challenge without many solutions. Some have gotten it working for their specific hardware but in all cases I've found so far, they are desktop computers with add-in cards. And even there, I haven't found anyone declaring success with an Alpine Ridge (8085 15B5) based card. Some of the SSDT patches I tried did get additional USB ports to show in Hackintool but they didn't actually sense anything being connected to the TB port - even when I could see it in MacOS. Other SSDT patches I tried did allow for boot-up Thunderbolt use but no hotplugging and they didn't show in Hackintool at all. And of course others did neither. So it seems the best I'll get with my E5570 is for the Thunderbolt device to be connected at boot-up and stay connected. Far from ideal and makes it generally unusable for most things. But for the rare time when I'll need something Thunderbolt-like connected, at least it will be possible with restrictions. Attached here is the AML file I'm using to get me boot-up and stay connected Thunderbolt access. If anyone has any ideas for how to fix it now, reply and let me know! (Or at some point in the future, if this thread is closed, PM me then!) SSDT-TBOLT3-KGP.aml.zip

Good to know that you have a computer where the USB-C is working, @Hervé. So if we can, let's do some comparing. Is your port USB-C or Thunderbolt as far as BIOS is concerned? And how does it operate in MacOS? Does hotplugging work for you? Do you recall what method you used to get the USB-C port(s) working on your 7490? AML, kext, etc.? When you run Hackintool, do you need to do anything special to get the USB-C to show in it? I had tried yesterday clicking on the different controllers at the top and it doesn't seem to impact anything in the list of ports below but if you find a way to do something like that in Hackintool, definitely let me know. (I'm running version 3.4.4)

@Jake Lo, one more piece of info: Both without the scavenged AML and with the scavenged AML, Hackintool showed two USB controllers, Hackintool always showed the normal "XHC" (8086 A12F), and Hackintool showed the second controller 8086 15B5 device. The only difference was whether it was named TTUB or XHC5. But all of the 26 ports listed below were all type "XHC" regardless - none were connected to "TTUB" or "XHC5". And therefore, Hackintool never showed the Thunderbolt device in the list. But then maybe considering the Thunderbolt port to be a USB port is the wrong way of thinking about it. In which case the USB tab in Hackintool would be entirely irrelevant.