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.