search

zearp / OptiHack

Dell OptiPlex 7020/9020 Hackintosh Stuff
https://zearp.github.io/OptiHack/
155 stars 53 forks source link

9020 - E/XHCI UFI vars kill USB? #25

Closed alexford closed 3 years ago

alexford commented 3 years ago

First off thank you for collecting this info. I'm running into something that I suspect is a simple issue.

I have a 9020 SFF. I've gotten to this point in your guide: https://github.com/zearp/OptiHack#enable-ehci-hand-off. However, if I set the USB-related vars there, the system doesn't see any USB devices on reboot (I get a warning that no keyboard is connected, even). So I reset with the jumper on the motherboard, and tried again trying to narrow it down. The setting that consistently seems to break USB is setup_var 0x144 0x1, the one that "sets XHCI in normal enabled mode".

I tried just skipping those USB-related config settings, but I just run into this issue: https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/kernel-issues.html#waiting-for-root-device-or-prohibited-sign-error when trying to boot the macOS installer, which makes sense as I haven't properly configured USB per your guide.

I'm wondering if I should update the BIOS on the machine? I'm not sure if BIOS version moves these vars around, and maybe the (older) version I have just doesn't line up. Which BIOS version are you running?

Or, should I go through with extracting the BIOS per https://github.com/JimLee1996/Hackintosh_OptiPlex_9020 and check the addresses myself? If the BIOS version doesn't matter, though, why would my addresses be different?

Couple notes:

zearp commented 3 years ago

It sounds like XHCI handoff isn't working as intended. So then you end up with no visible usb controllers. Whats supposed to happen is we disable anything EHC related and move everything to the XHC controller.

(Only really old legacy OS won't support XHC controllers. I personally have no issues in Windows and Linux and other BSD based systems with just XHI enabled. In fact disabling EHC doesn't seem to fully disable it as without the ACPI patch disabling those ports (again) I get weird EHC related wake-ups sometimes.)

If you followed the steps everything should be fine, maybe you forgot one step? Usually these addresses don't change between BIOS versions, but it can't hurt to check them if you're not on the latest version. They could change although it's not very common to do so. You can also update to the latest version.

I can't check them myself cuz I don't have a 9020 to grab it from. The BIOS needs to be extracted from the chip cuz we can't extract the raw BIOS from the Dell updater .exe anymore. But I do know the latest 7020 is the same as latest 9020 sans RAID controller. They're identical otherwise. Only the 9020m has a completely different BIOS with different addresses.

The USBPorts.kext included assumes the changes are made, you could get around this by removing it and not touching the usb addresses and then add USBInjectAll.kext. You'll get 3 controllers in Hackintool and can do your mappings. But this caused me a lot of headaches with sleep and usb behaving weirdly (drives disappearing etc). The Dortania guide also recommends disabling EHC when you can and enable handoff to XHC.

If I were you I would update to the latest BIOS and try again. Double check everything and if you end up at the same spot again you can extract your BIOS in Windows and check the addresses. I would be very surprised if they're actually different since no other 9020 users reported this issue. Let me know how it goes!

alexford commented 3 years ago

Updating the bios to the latest (A25) allowed those vars to be set without breaking USB. Continuing with the rest of the install now!

When I get a chance I'll open a PR with a note to update the BIOS and anything else I find.

zearp commented 3 years ago

Wow, thats good to know they actually changed in between versions. Do you remember on which version you were? I've added a note about updating to the latest BIOS.

There are some things you can do with the BIOS itself like updating vPro stuff, VBIOS, microcodes and adding NVMe support.

Since you own a 9020 there are some cool mods you can do like replacing the RAID module for one that supports RAID0 and TRIM. macOS doesn't support those on the OS disk anymore with the module you can install macOS on a RAID0 array without any trickery.

But modding the BIOS can be risky if something goes wrong and you have no programmer to recover from a BIOS failure.

Good luck on the install, I'm sure it'll go smoothly. Specially with Catalina. I haven't tested the EFI with the latest Big Sur beta's but it worked fine before. Should still work fine on newer builds. Will check again once the final drops.

alexford commented 3 years ago

I think I was on A10, but I didn't actually make a note to check.

Things seemed to go smoothly (once I realized VGA doesn't work, which is what I had on the bench). I have not USB mapped yet but even iMessage/iCloud are working fine.

zearp commented 3 years ago

Glad to hear its working properly! You don't have to map the usb ports if you use the included kexts. It's all ready to go for SFF models. On the bigger models there are internal headers to be mapped if used. Enjoy the little beast!

alexford commented 3 years ago

Good to hear the USB mapping stuff isn't required. Hadn't fully wrapped my head around that yet!

To hijack this a bit: I am having a little trouble with iGPU. Perhaps I should make another issue? Consider this more of a log of things for anyone trying later...

On 10.15.6, using iMac 15,1—I'm getting some intermittent UI freezes and graphics glitches that get worse over time (a few minutes after boot) until the system stops being usable. When the freeze happens I can see in power gadget that the clock speed of the iGPU goes from 200mhz to the max (around 1ghz) for the duration of the freeze, about 5-10 seconds. The mouse moves but no UI is updated. Usually it's a beachball cursor but sometimes not. When the freezing stops, it returns back to 200mhz. Not sure if that's causation or correlation.

Glitches are not always correlated with clock but freezes are. Eventually I just have to force restart. Websites/Electron apps seem to bring this kind of thing on faster, but that's really the only thing I've done that would require the GPU to do any real work.

Additionally I notice some color banding in gradients/subtle areas like transparent backgrounds. The system reports 24bit color, and it certainly doesn't look like 8 or 16 bit, but not the smooth gradients I'm used to with other Macs on this display. Seems like it could be correlated as well.

I've done a good deal of reading on WhateverGreen and HD4600 settings and haven't changed anything in your config as it all matches up with what I read. However I saw that on 9/7 WhateverGreen changed the rps-control property to off by default due to "a bug in 10.15.6 iGPU drivers". Your OC config in this repo turns it on. I plan to try turning it off and see what happens, since as best I can tell "RPS control" has to do with logic for adjusting the clock frequency of the GPU and that seems at least correlated to my issues.

Some details:

zearp commented 3 years ago

@alexford Is there a way to reproduce this?

I have one 7020 connected to a tv that's used pretty much all day long to play Youtube and downloaded videos (including full BR rips) and browse the web and such. I didn't notice any artefacts or glitches on it and haven't heard any complaints from others using it. I have another here on the desk that's on a big portion of the day also without any glitches. Both run at 1080p.

I think it's best to make a new issue for this if you believe its due to some setting in the config. Let me know if your issues go away when you disable rps. You can also try another SMBIOS. Mind you that the graphics base clock is pretty high on some and lower on others. In my testing the only influence this has is on temperatures. Using an SMBIOS that sets the base clock to 750mhz instead of 200-300mhz will result in more heat and wasted energy and no noticeable differences.

On my real Macs there's some "aggressive" undervolting and underclocking going on as well. Apple runs them slightly below Intel specified clock speeds. Both processor and graphics scale up their clocks as needed under load. Lower base clocks don't mean low performance or glitchy behaviour.

As for colour banding, this is probably due to EDID. You may need to inject one for your screen to work properly. I have one rgb calibrated screen that I use form time to time and didn't notice anything weird on that but it's a been a while and I do know that for some screens it can be a pita to get it to work properly with macOS without injecting a customised EDID. You can also try different colour profiles, sometimes that can help. But usually you'll have to inject your own EDID.

I don't think there's a separate sensor for the GPU since its baked into the CPU.

alexford commented 3 years ago

Disabling rps seems to have reduced the issues dramatically. I also notice that with rps disabled, the GPU clock varies more readily—before it was either 200mhz or the max, basically. Now it's floating between the two as needed. I can't find any more reference to this supposed 10.15.6 bug beyond the WhateverGreen release notes, but it seems like things were wonky (or at least, wonkier) with rps enabled. Anecdotally things seem a little smoother now, too. (Resizing windows, etc.).

I did start to get glitches/freezing again after unplugging the DP cable and moving to another port, in an effort to see if color banding was any better. I had to restart after that because it started glitching out, but since then I haven't seen any issues. I'll open another issue here if it comes back, and will try to include a repeatable reproduction.

I've tried some EDID patching but I'm not really sure what I'm doing and haven't seen any difference. Very confident it's not an issue with your config, but thanks for your advice anyway!

zearp commented 3 years ago

Thanks for the tests, I will try some stuff too and maybe just remove the setting again. I only added it cuz I didn't notice any issues and its supposed to improve performance a bit. But not at the cost of artefacts of course. I did notice I get glitches using some DP -> HDMI cables on my tv but no such thing when using DP -> DP cables and not all DP -> HDMI cables were affected. My new DP -> HDMI cable (ASIN: B07QKYPSQ1) is working without any issues for a couple of months.

I need to check the frequencies used with rps disabled but with it enabled it does cycle trough some clocks when running the Geekbench compute benchmark on it. Could count about 3-5 different steps but Intel Power Gadget is probably not the correct tool to check which steps are available. I wonder if those change with and without rps.

Hot plugging used to cause a panic when I started my journey a while go now, managed to fix that but hot plugging can still a bit dodgy sometimes. You can try mapping the connectors and disable ones that aren't in use. I can't remember the exact command but you can see which frame buffers are active with ioreg. I'll have to look that up later and check. Last time I messed about with that was with a laptop that had some long delays with booting and lots of weird graphical glitches. Ended up being some kind of internal connector that had an active framebuffer but nothing connected to it.

From what I understand about EDID patching is that you need extract it from your screen and then fabricate a patch with it. I haven't got any fancy screens that would benefit from it other than my calibrated one but that one can't display higher bitrate colours so banding will always be an issue on it. So I never really read up on it. Not sure if there are any good guides on it either. Its one of those more exotic things to do but still an important part of getting close to the perfect hackintosh.

I hope to be able to do some A/B testing with rps later. Might just remove the option again. I added it not too long ago thinking it wouldn't cause any issues as I didn't run into any showstoppers when I tested it here. But since it seems to cause issues might be best to get rid of it until it's more polished/bug free.

alexford commented 3 years ago

Well here's something weird — putting the system to sleep and waking it up again fixed the color banding issue. I can live with that, honestly, because this will be on or asleep 24/7.

Ran the Geekbench compute benchmark just now and beyond a little stuttering trying to drag windows around while it's running, it's been stable. 3027 OpenCL score, for reference.

🤞 the rps control thing took care of the issues. I will try to get to trying the benchmark with rps turned back on to see if there are any differences and again I'll open a new issue if freezing continues.

zearp commented 3 years ago

Thats an interesting development. I had a similar issue where after sleeping it woke up with an extra usb hub added which caused countless of weird issues. This was on a NUC though. I only figured out what changed after creating an ioreg dump before and after sleep and compared the two.

The same might help you to pin point what exactly happened. That way we might be able to find a solution that defaults to the after sleep state and doesn't change when ti cycles sleep again.

Your hot plug issue also reminded of my NUCs, for some reason HDMI audio doesn't work until you re-plug the cable. It also changes some h/w stuff but I wasn't able to sort that one out yet, adding FakePCIID fixed it but that's more of a bandage than a proper fix to me. But maybe adding that kext can help you too. Can't hurt to try. It's quite old and doesn't do that much but seems to be able to do some magic regarding iGPU/HDMI etc, who knows it may leave you in after-sleep state.

I'll nuke the rps option, your score is about same as mine and I have it enabled. Don't think it will be noticeable in that compete bench anyways. From what I understood when I checked that option it only improves performance by a bit and it's not worth glitching out on on certain setups. Thank you for taking the time to test and report.

Edit: Aaaand, it's gone.

https://github.com/zearp/OptiHack/commit/bfeb562ae312e42d71ab329f1c99eb130048a66f

Edit 2: Here's the Haswell framebuffer guide I was thinking about earlier, it's not very recent but all the knowledge still holds true today. Port count is the part you'll need for the connector and used ports stuff. You can use Hackintool for it to ease the process a bit and create a patch that should work on any kext version. I prefer not to patch kexts directly or with search/replace as those patches tend to break with macOS updates. We had to do that for proper 4k support. @mgrimace did all the hard work regarding that; https://github.com/zearp/OptiHack/pull/11#issuecomment-667554875

zearp commented 3 years ago

Dortania has just added some more in-depth framebuffer patching their guide. Did only skim it quickly and doesn't appear to have much news but presented in an easier format for sure.

https://dortania.github.io/OpenCore-Post-Install/gpu-patching/intel-patching/