Leaderboard

@fabiosun - yes I had disabled SMT. This answers our question from 2 months ago - does BS has 64 limit - yes it does, since boot fails very early otherwise. Issue with me was either Whatevergreen and -wegbeta or MMIO or both. Probably WEG but I am not sure 100% which. For sure now the installer is going. I already rebooted past 1st phase beyond my initial freeze. And my fans now ramp up - before the system sounded suspiciously quiet and was corrupting the BIOS splash boot where OC would print text on top of BIOS image. Will post more tomorrow including altered config.plist for those that may encounter similar issue. I removed. 1. WEG kext, -wegbeta and pikera args 2. Intel I211 kext (just in case, will re-add - what does this kext really gain for my card?) 3. Enabled only the last 2 MMIO addresses in my list - left all other disabled, cautious about my own and @Driftwood's earlier mishaps. Turns out my install succeeded with an older EFI which I had used on Catalina baremetal The stricken items are therefore not right. I will re-try the USB booter. My system now clicks on shutdown and shuts, and 1 sec later comes back alive. So still work to do but now it seems very close. Thanks @iGPU! And @fabiosun for the encouragement. This stuff is too time consuming and I almost gave up.

Yes, I routinely copy EFI folders all over the place. I use the EFI Agent app. I never mention as I thought all Hackintoshers use it! (attached below). All of this can be done without any sealing issues. Even if on a old macOS you can still see all EFI partitions. Click on triangle to mount EFI partition (and I disallow notifications). The arrow is pointing to the triangle I'd just clicked which, after entering my pw, mounted the EFI partition at the end of the arrow. This EFI partition is for the MacHD, which contains BS and is on the Sabrent Rocket NVMe drive. Once the EFI partition has mounted, copy and paste to your delight. I add it to auto start on boot, by using the gear pop-up: You can move column (I wish a moved column would 'stick' between boots). To move, hold mouse arrow on column top for triangles and slide adjacent to Device names as shown below. This helps in locating which drive has which EFI you might want. As mentioned in a previous post, I keep a 'safety' EFI that I know will boot on one of the drives. EFI Agent.zip

Yes, it does after disabling the AX200 with an SSDT as per @iGPU's post half a page above this. The 2 big issues I have: 1. Not able to boot in after a shutdown or a restart (peculiar as I have not seen anyone else report this) 2. Shutdown itself still doesn't work but is close as we need to identify what causes the system to spring back to life after the click off. @tsongz - the Dortania guide is discussed earlier in this topic. The MMIO address section of it is not accurate as it does not apply to many motherboards/configurations. I would rather follow @iGPU's posts and try to start from his EFI's.

Some further observations on Big Sur: NVRAM works! Kudos, @iGPU Shutdown clicks and turns off and immediately re-boots back up. Still unresolved even after USB remap (which I think needs more work as my port types are not 100% correct) Whenever I reboot or shutdown (which turns into a reboot after the power off click), I cannot boot back in. Most of the time if not always. Stop is early on in the same manner as if my MMIO's are incorrect. But then when I power cycle the PC, I can boot back in without a problem. This is very weird and is the most serious issue so far.

Happy to report that I managed to install BS onto an NVMe thanks to @iGPU's EFI. No issues with it at all at the moment. The only remaining problem I have is the lack of any SATA drives once Catalina or BS load up. I can see them at the Opencore Picker and within Windows and Mint, so it is restricted to macOS. As I have pretty much no idea when it comes to SSDTs, I'm guessing the problem, and solution, will be in there somewhere. Attached is my IOREG if anyone can point me in the right direction. Thanks. Ploddles IOREG.ioreg.zip

As I mentioned, I'm not using any Slide value. Look at post above, maybe you have a similar USB issue. On a related issue, I think all desktop Hackintoshers should disable Energy Saver as shown below. This can reduce oddball crashes and reboots in many systems (Intel or AMD).

Your slide values are different than what I'd found (posted some days ago) for my MSI mobo. But, I've temporarily stopped using a slide value, but I do keep MmioWhitelist active. I've tested my list and I must a different sequence as No vs Yes than you find with your mobo, or I cannot boot. Unfortunately, we cannot share this info due to our different set-ups. Yes, I'm actively working on TB USB. I've spent hours on it, but I've not given up. I'm working on It now.

MMIO Above 4G Asrock Creator, SMBIOS: MacPro7,1 Weird results I gotta say when compared to iMacpro1,1 Above 4G disabled. Had no corruption unlike the last time which makes me think I may have shutdown to early on summit and caused a problem.... who knows?! This time with Above 4G Problem Child no. 2 on/off the test went thru ok but as a fail (NO) - interestingly on iMacpro1,1 it was this child 2 which enabled the click sound shutdown - but wouldn't reboot / from some weird. corruption afterwards. UPDATED: I now have shutdown and restart plus Sleep Power Management, here's the updated MMIO list. Follow the schema, but check YOUR addresses. Anyways, here's the results... Now got to do slide value calls. to compare here was my iMacpro1,1 profile with Above 4G Disabled Testing (yep it takes time) and involves some soft/cold reboots. Like iGPU says, make sure you have a secondary thumb drive EFI copy to boot back in with all MMIOwhitelist to NO (off) I note I was getting a few hangs on AppleACPIPlatformExpert where it couldnt determines UUID. When testing check for Skips = 1 (thats good) * Thank you @fabiosun UPDATE: After a long chat with @fabiosun I decided to use his schema replacing Yes/No in the address childs with his selections. Subsequently, on Menu>Shutdown SHUTDOWN worked! click sounded and computer switched off correctly. Later I noticed I had a few addresses incorrectly pasted, and I was getting Skip = 0 when they should be 1 when checking MMIO in boot logs. After fixing I will upload the latest & replace the Config.plist for Asrock TRX40 Creator users. Thanks once again to @fabiosun UPDATE 2: Sleep Works!

@Driftwood@l422y

Success! Bare Metal is now installing. I disabled WEG and removed -wegbeta and pikera and also only enabled my last 2 MMIO. Right away the weird corruption where OC would print text in top of my BIOS image at boot disappeared and the installer is now going smooth! Fingers crossed. Will post abridged config plist when done.

Totally slipped my mind that there was no drivers ever written for RTX under Mac OS. Oh well, might see how I get on with my RX 560.

@iGPU - I left my IOReg running for the last 20 min. No such flickering. The only items that change (which is normal as I browse some stuff) are: RootDomainUserClient AMDRadeonX6000_AMDAccelCommandQueue AMDRadeonX6000_AMDAccelSharedUserClient AMDRadeonX6000_AMDGFX10GLContext IOAudioEngineUserClient IOAudioControlUserClient IOSurfaceRootUserClient IOTimeSyncDomainUserClient I see a lot of those being stricken out, but none from USB ports.

Can someone tell me how is the following possible? 1. Launch Mac OS BS installer 2. Erase the entire volume group of the target drive 3. Complete a clean installation 4. Boot into "Preboot" partition to check on the new bare metal install 5. Find out from Hackintool that my previous EFI with O.C. 0.6.0 and the ACPI files from before are found - how??? Hackintool bug or erase didn't happen. Also, there is clearly something non-deterministic going on with my system as the same USB I did finally manage to do an install with last night, now goes into a black screen after running though some logs. And I get the corrupted text over my BIOS splash. Reason I mention this weird text, is that I could correlate this with my install failures last night, but once I did some tweaks to the config.plist (completely remove WEG kext, I211 kext and pikera and -wegbeta args), the splash was not corrupted and the install went very clean. Could it be that I got lucky with hitting some KASLR region? And I still don't understand - how did the EFI of my target survive the volume deletions? After thinking a bit I think I now know what happened. I must have somehow fallen back on booting from my Catalina bare metal EFI and managed to complete the Big Sur install from there using OC 0.6.0 and a variation of @iGPU's old EFI, thinking that I actually booted from the USB. I can verify that later, but this EFI had WG 1.4.1 and no -wegbeta and is also non-debug, which explains the no OC debug text on BIOS splash. So ok - now I know I can boot into bare metal with 0.6.0 and my old EFI with whatevergreen 1.4.1 (no -wegbeta!), but that wasn't the goal! (I mean it is a goal to install BS, but it's best to achieve it in a way agreeable with others' experiences and version).

intendi questa? ovvero l'ultima EFI prima della tua con oc060 ?

Secondo me, visto poi anche il discorso e cosa ha deciso il diretto autore, per rispetto sarebbe meglio che tale driver rimanga separato. Dal tempo, per esempio, non si sa se può "violare" qualcosa sul bootloader stesso come per esempio "cose" che riguardano la sicurezza. Inoltre può essere usato anche su clover. il driver è questo in allegato. Brumbaer_CFGLock.efi.zip

I must be bare metal cursed. Got so much further than last time but my installation hard freezes halfway. Clean reformat and install. Starting to wonder if it is the video card or BIOS. I am the only using 5700XT so I have to add pikera boot arg. I disabled all memory overclock for this install so it's not that. Next I may try to disable Whatevergreen but I doubt that's it. (edit: almost forgot I have the 3990x too so need to disable SMT, weird thing is that 1st time a couple of weeks back bare metal worked - I wonder what changed and how does one debug this). Proxmox continues to work without a flaw.