trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[fabiosun]

Spoiler

Anonymous UUID:       2CE76937-9343-6F88-DEC0-48AD53215D43

Sat Aug 29 08:56:09 2020

*** Panic Report ***
panic(cpu 16 caller 0xffffff801457d694): "Spinlock acquisition timed out: lock=0xffffff8014c99698, lock owner thread=0xffffff81e38119f0, current_thread: 0xffffff81e31eb3e0, lock owner active on CPU 0x27, current owner: 0xffffff81e38132c8, time: 60212764655"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-4570.71.82.5/osfmk/i386/locks_i386.c:465
Backtrace (CPU 16), Frame : Return Address
0xffffffdb92b83c00 : 0xffffff801446ae56 
0xffffffdb92b83c50 : 0xffffff8014594434 
0xffffffdb92b83c90 : 0xffffff8014586604 
0xffffffdb92b83d00 : 0xffffff801441ce60 
0xffffffdb92b83d20 : 0xffffff801446a8cc 
0xffffffdb92b83e50 : 0xffffff801446a68c 
0xffffffdb92b83eb0 : 0xffffff801457d694 
0xffffffdb92b83ef0 : 0xffffff80144633c6 
0xffffffdb92b83f40 : 0xffffff801441ce2c 

BSD process name corresponding to current thread: CINEMA 4D Demo

Mac OS version:
17G14019

Kernel version:
Darwin Kernel Version 17.7.0: Thu Jun 18 21:21:34 PDT 2020; root:xnu-4570.71.82.5~1/RELEASE_X86_64
Kernel UUID: 3D729EED-3C15-378F-AFE5-9BF3B0C87369
Kernel slide:     0x0000000014200000
Kernel text base: 0xffffff8014400000
__HIB  text base: 0xffffff8014300000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)

System uptime in nanoseconds: 60213019885
last loaded kext at 15917111081: com.apple.filesystems.exfat    1.4 (addr 0xffffff7f967c5000, size 65536)
loaded kexts:
com.smalltree.driver.SmallTreeIntel82576    1.0.6
as.vit9696.VirtualSMC    1.1.5
as.vit9696.AppleALC    1.5.1
as.vit9696.Lilu    1.4.6
com.apple.filesystems.exfat    1.4
com.apple.filesystems.ntfs    3.13
com.apple.driver.AppleTyMCEDriver    1.0.3d2
com.apple.filesystems.autofs    3.0
com.apple.driver.AppleHDAHardwareConfigDriver    281.52
com.apple.driver.AppleHDA    281.52
com.apple.driver.AppleGraphicsDevicePolicy    3.20.18
com.apple.AGDCPluginDisplayMetrics    3.20.18
com.apple.driver.AppleHV    1
com.apple.iokit.IOUserEthernet    1.0.1
com.apple.driver.AppleUpstreamUserClient    3.6.5
com.apple.driver.AppleMCCSControl    1.5.5
com.apple.iokit.IOBluetoothSerialManager    6.0.7f22
com.apple.driver.pmtelemetry    1
com.apple.Dont_Steal_Mac_OS_X    7.0.0
com.apple.driver.AppleThunderboltIP    3.1.1
com.apple.driver.AppleIntelPCHPMC    2.0.1
com.apple.nvidia.NVDAStartup    10.3.2
com.apple.driver.AppleIntelSlowAdaptiveClocking    4.0.0
com.apple.driver.AppleFIVRDriver    4.1.0
com.apple.driver.AudioAUUC    1.70
com.apple.driver.ACPI_SMC_PlatformPlugin    1.0.0
com.apple.driver.AppleOSXWatchdog    1
com.apple.AppleEthernetAquantiaAqtionFirmware    1.0.34
com.apple.driver.AppleFileSystemDriver    3.0.1
com.apple.filesystems.hfs.kext    407.50.6
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless    1.0.0d1
com.apple.BootCache    40
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib    1.0.0
com.apple.AppleSystemPolicy    1.0
com.apple.driver.PioneerSuperDrive    439.70.3
com.apple.iokit.SCSITaskUserClient    404.30.3
com.apple.driver.AppleAHCIPort    329.50.2
com.apple.filesystems.apfs    748.51.0
com.apple.driver.AppleHPET    1.8
com.apple.driver.AppleACPIButtons    6.1
com.apple.driver.AppleRTC    2.0
com.apple.driver.AppleSMBIOS    2.1
com.apple.driver.AppleAPIC    1.7
com.apple.driver.AppleIntelCPUPowerManagementClient    220.50.1
com.apple.nke.applicationfirewall    186
com.apple.security.TMSafetyNet    8
com.apple.security.quarantine    3
com.apple.driver.AppleIntelCPUPowerManagement    220.50.1
com.apple.kext.triggers    1.0
com.apple.driver.DspFuncLib    281.52
com.apple.kext.OSvKernDSPLib    526
com.apple.driver.AppleGraphicsControl    3.20.18
com.apple.iokit.IOAVBFamily    683.1
com.apple.plugin.IOgPTPPlugin    680.15
com.apple.iokit.IOEthernetAVBController    1.1.0
com.apple.driver.AppleSSE    1.0
com.apple.iokit.IOSurface    211.15
com.apple.driver.AppleSMBusController    1.0.18d1
com.apple.iokit.IOSMBusFamily    1.1
com.apple.iokit.IOSerialFamily    11
com.apple.iokit.IOBluetoothFamily    6.0.7f22
com.apple.iokit.IONDRVSupport    519.21
com.apple.AppleGPUWrangler    3.20.18
com.apple.AppleGraphicsDeviceControl    3.20.18
com.apple.driver.AppleHDAController    281.52
com.apple.iokit.IOHDAFamily    281.52
com.apple.driver.AppleSMBusPCI    1.0.14d1
com.apple.iokit.IOSlowAdaptiveClockingFamily    1.0.0
com.apple.iokit.IOGraphicsFamily    519.23
com.apple.driver.IOPlatformPluginLegacy    1.0.0
com.apple.driver.IOPlatformPluginFamily    6.0.0d8
com.apple.driver.AppleThunderboltEDMSink    4.1.4
com.apple.driver.usb.AppleUSBHub    1.2
com.apple.driver.usb.IOUSBHostHIDDevice    1.2
com.apple.driver.AppleUSBAudio    312.6
com.apple.iokit.IOAudioFamily    206.5
com.apple.vecLib.kext    1.2.0
com.apple.driver.usb.cdc    5.0.0
com.apple.driver.usb.networking    5.0.0
com.apple.driver.usb.AppleUSBHostCompositeDevice    1.2
com.apple.filesystems.hfs.encodings.kext    1
com.apple.driver.AppleUSBMergeNub    900.4.1
com.apple.driver.AppleUSBHostMergeProperties    1.2
com.apple.driver.usb.AppleUSBHostPacketFilter    1.0
com.apple.iokit.IOUSBFamily    900.4.1
com.apple.driver.AppleThunderboltDPOutAdapter    5.5.5
com.apple.driver.AppleThunderboltPCIDownAdapter    2.1.3
com.apple.driver.AppleThunderboltDPInAdapter    5.5.5
com.apple.driver.AppleThunderboltDPAdapterFamily    5.5.5
com.apple.driver.AppleHPM    3.1.3
com.apple.driver.AppleIntelLpssI2CController    3.0.60
com.apple.driver.AppleIntelLpssDmac    3.0.60
com.apple.driver.AppleIntelLpssI2C    3.0.60
com.apple.iokit.IOSCSIMultimediaCommandsDevice    404.30.3
com.apple.iokit.IOBDStorageFamily    1.8
com.apple.iokit.IODVDStorageFamily    1.8
com.apple.iokit.IOCDStorageFamily    1.8
com.apple.iokit.IOAHCISerialATAPI    267.50.1
com.apple.iokit.IOAHCIBlockStorage    301.40.2
com.apple.driver.AppleThunderboltNHI    4.7.3
com.apple.iokit.IOThunderboltFamily    6.7.10
com.apple.iokit.IOAHCIFamily    288
com.apple.driver.AppleEthernetAquantiaAqtion    1.0.55
com.apple.driver.mDNSOffloadUserClient    1.0.1b8
com.apple.driver.AppleXsanScheme    3
com.apple.driver.usb.AppleUSBXHCIPCI    1.2
com.apple.driver.usb.AppleUSBXHCI    1.2
com.apple.iokit.IONVMeFamily    2.1.0
com.apple.driver.AppleEFINVRAM    2.1
com.apple.driver.AppleEFIRuntime    2.1
com.apple.iokit.IOHIDFamily    2.0.0
com.apple.security.sandbox    300.0
com.apple.kext.AppleMatch    1.0.0d1
com.apple.driver.DiskImages    480.60.3
com.apple.driver.AppleFDEKeyStore    28.30
com.apple.driver.AppleEffaceableStorage    1.0
com.apple.driver.AppleKeyStore    2
com.apple.driver.AppleUSBTDM    439.70.3
com.apple.driver.AppleMobileFileIntegrity    1.0.5
com.apple.iokit.IOUSBMassStorageDriver    140.70.2
com.apple.iokit.IOSCSIBlockCommandsDevice    404.30.3
com.apple.iokit.IOSCSIArchitectureModelFamily    404.30.3
com.apple.iokit.IOStorageFamily    2.1
com.apple.driver.AppleCredentialManager    1.0
com.apple.driver.KernelRelayHost    1
com.apple.iokit.IOUSBHostFamily    1.2
com.apple.driver.usb.AppleUSBCommon    1.0
com.apple.driver.AppleBusPowerController    1.0
com.apple.driver.AppleSEPManager    1.0.1
com.apple.driver.IOSlaveProcessor    1
com.apple.iokit.IOReportFamily    31
com.apple.iokit.IOTimeSyncFamily    680.15
com.apple.iokit.IONetworkingFamily    3.4
com.apple.driver.AppleACPIPlatform    6.1
com.apple.driver.AppleSMC    3.1.9
com.apple.iokit.IOPCIFamily    2.9
com.apple.iokit.IOACPIFamily    1.4
com.apple.kec.pthread    1
com.apple.kec.Libm    1
com.apple.kec.corecrypto    1.0

EOF
Model: iMacPro1,1, BootROM 1554.40.9.0.0, 32 processors, 3,7 GHz, 256 GB, SMC 
Graphics: Display, PCIe, 33 MB
Memory Module: P0 CHANNEL A/DIMM 0, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL A/DIMM 1, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL B/DIMM 0, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL B/DIMM 1, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL C/DIMM 0, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL C/DIMM 1, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL D/DIMM 0, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Memory Module: P0 CHANNEL D/DIMM 1, 32 GB, DDR4, 3200 MHz, Unknown, 3200 C16 Series
Network Service: Ethernet (en5), Ethernet, en5
Serial ATA Device: ST6000VX0023-2EF110, 6 TB
Serial ATA Device: ST6000VX0023-2EF110, 6 TB
Serial ATA Device: PIONEER BD-RW   BDR-207M
Serial ATA Device: Samsung SSD 840 EVO 250GB, 250,06 GB
Serial ATA Device: ST10000VX0004-1ZE101, 10 TB
Serial ATA Device: ST10000VX0004-1ZE101, 10 TB
USB Device: USB316Bus
USB Device: USB-PS/2 Optical Mouse
USB Device: USB Keyboard
USB Device: USB316Bus
USB Device: USB PnP Audio Device
USB Device: USB316Bus
USB Device: MYSTIC LIGHT
USB Device: USB Audio
USB Device: USB332Bus
USB Device: USB316Bus
USB Device: USB2.0 Hub
USB Device: USB 3.0 Bus
Thunderbolt Bus: iMac Pro, GIGABYTE, 23.0
 

and this is KP after Nvidia web disinstall and without any usb connected  mouse/keyboard and USB cheaper audio are instead connected

 

 

 

Edited August 29, 2020 by fabiosun

[fabiosun]

@Driftwood@l422y

 

[fabiosun]

Summary of my situation

with the same Efi I can boot fine with high Sierra, Mojave’s, catalina

what works

Shutdown

restart

sleep/wake

i can’t install Big Sur with the same EFI

[Ploddles]

11 hours ago, Jaidy said:

It hangs for me at both restart and shutdown. I simply pasted your EFI to my EFI partition. Did I miss something, like did I need to edit some settings?

I am on Catalina..

 

Have you changed the config.plist to include your MMIO Whitelist?

 

The same was happening to mine until I went through the process. Now it Restarts without any issue and NVRAM is working fine. On Shutdown though I still get reboot.

 

I also had to change the Debug bits in the config file, leaving it as enabled etc it would take up to 5 minutes before it would fully boot into Catalina after selecting that from the picker. One other change I made was to the ScanPolicy, changing it back to 0, the reason being leaving it at 19596035 resulted in me not seeing the Windows NVMe - as I dual boot Windows it was the quickest way to get that back into the picker rather than hitting F12 to be able to choose that to boot from.

[Ploddles]

I've just reattached 2 SATA disks, a 3TB spinner that I used as a backup of my files and also as a CCC of the system, and a 256GB SSD that I want to try BigSur on.

 

In Windows they show up fine and the CCC backup on the spinner appears in the OpenCore picker, so OpenCore can see the disks at that stage.

 

When I boot into Catalina, both SATA drives completely disappear. Disk Utility can't see them and in Terminal diskutil list does not show them either. I'm assuming this is either a SSDT problem, or I'm missing a rename somewhere in my config.plist.

 

To check it wasn't something just in Catalina, I started the BigSur installation but couldn't see the SATA drives in there to choose as an installation point.

 

Time to do some checking to see where the problem is 🙂 and then give a BigSur  installation a try.

 

[Driftwood]

9 hours ago, iGPU said:

Sealed volume only important if you wish to access Big Sur drive from older macOS. I don't think if affects any other functionality. But it cannot be done at a later date, only during the installation step. I wouldn't sweat it.

When installing Big Sur using Proxmox sealing is done automatically. I see my BS Update drive on this Cat ssd boot.

 

Just can't boot into it yet with same BM settings as Cat BM. It boots fine under Prox.

Edited August 29, 2020 by Driftwood

[writerinserepeat]

6 hours ago, meina222 said:

@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.

 

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.

Meina, thank you for this information.  I was curious if MacOS had finally, finally raised the 64 core/thread limit with Big Sur.  Ah well.  

[fabiosun]

@writerinserepeat welcome here

in the past I have checked if some difference in kernel was there about cores count  limit, and Big Sur gave me a big illusion because 3F parameter seems to not be there..

Asked @meina222 to check..illusion ended immediately 🙂

 

[writerinserepeat]

8 minutes ago, fabiosun said:

@writerinserepeat welcome here

in the past I have checked if some difference in kernel was there about cores count  limit, and Big Sur gave me a big illusion because 3F parameter seems to not be there..

Asked @meina222 to check..illusion ended immediately 🙂

 

 

Thanks fabiosun.  I still have grand illusions of my 128 core / 256 thread  Epyc workstation running MacOS on all cores as part of a tri-boot setup.  Extreme overkill I know, but it sounds fun, regardless.  I can always use  Proxmox at 64 cores.  Too bad we can't hack the MacOS kernel and enable more multi-core support, AND Nvidia driver support past HS!   

Edited August 29, 2020 by writerinserepeat
typo

[fabiosun]

@iGPU ended for now my serious tests in bare metal because I can't figure out Nvidia problem, so I did a Catalina fresh instal to avoid classic high Sierra problem with old usb driver

attached my IOREG

when you have time the goal could be usb function activation in TB device 🙂

TY

iMac Pro di fabio_for_TB_IGpu.zip

[Driftwood]

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!

Edited August 30, 2020 by Driftwood
MMIO List updated

[fabiosun]

I would suggest to use the schema I have proposed..entirely 😉

and see

with that one I can restart/shutdown and sleep with a minimal config.plist as we did yesterday

obviously using your data conversion number

 

[meina222]

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).

 

 

 

Edited August 29, 2020 by meina222

[meina222]

I feel the answer to my weird experiences has to do with this MMIO black magic. So last night I succeeded with these values.Notice how my slides are exactly the same as @Driftwood's. Something about our board MMIO is common as he also experiences the click shutdown/restart and install corruption issues.

 

35:415 00:054 OCABC: MMIO devirt start
35:472 00:056 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0
35:529 00:057 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0
35:587 00:057 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0
35:643 00:056 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0
35:700 00:056 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0
35:757 00:057 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0
35:814 00:056 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0
35:871 00:057 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0
35:928 00:056 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0
35:986 00:057 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0
36:043 00:057 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0
36:096 00:053 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0
36:150 00:053 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0
36:205 00:054 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0
36:260 00:055 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0
36:315 00:054 OCABC: MMIO devirt 0x10000000000 (0x10400 pages, 0x8000000000000001) skip 0
36:370 00:054 OCABC: MMIO devirt 0x3CB90000000 (0x10400 pages, 0x8000000000000001) skip 0
36:425 00:055 OCABC: MMIO devirt 0x3CBC0000000 (0x10400 pages, 0x8000000000000001) skip 1
36:483 00:057 OCABC: MMIO devirt 0x69750000000 (0x10400 pages, 0x8000000000000001) skip 1
36:537 00:054 OCABC: MMIO devirt end, saved 555184 KB
36:592 00:055 OCABC: Only 176/256 slide values are usable!
36:647 00:054 OCABC: Valid slides - 80-255

[iGPU]

14 minutes ago, meina222 said:

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:

 

 

 

 

That's a little strange. Normally, you'll only see bootstrap issues if you've set BootProtect to "Bootstrap". I don't use and set to "None". Did you change this value? In the sample plist you uploaded early it was "None" (and everyhing else looked okay).

 

 

If you enable by entering "Bootstrap" instead of "None", this will place an OpenCore entry in the boot menu of your BIOS, setting it as the first entry to boot. Since I want to use different EFI's that all contain OpenCore, but different versions in case the one I'm testing is corrupt, I wouldn't know which EFI was then booting. Therefore, I keep BootProtect as "None" and select the EFI partition from which I wish to boot. (See ~ p 38 of OC Docs/Configuration/Misc/Security/BootProtect for description.)

 

If you've still got it as "None", then I'd check your BIOS. Boot into BIOS and look at your bootable partitions. If you see an OpenCore entry, it is a holdover from whenever you'd left BootProtect as "Bootstrap". Delete or Hide this entry (or re-flash BIOS) to remove from the boot sequence.

 

***

 

As for WEG, this is what I found early on: BS does not like current WEG. I left in kext folder and partially disabled to allow people to be able to boot into both BS and Catalina.

 

I normally don't even use WEG as it does not often play nicely with Radeon VII and Navi AMD GPUs and does not seem to be very necessary for our builds which have no iGPU on the CPU. The only thing I've noticed when WEG is completely turned off (the boot arg "-wegoff" completely disables if you wish to leave in kext folder vs disabling inside config file Kernel/Add/WEG), is that you'll see pink/purple lines at top of screen. This has been a GPU artifact since mid-Mojave and WEG added some code to suppress these artifacts. Without WEG, the artifacts simply show through; they're no big deal.

 

[iGPU]

10 minutes ago, meina222 said:

I feel the answer to my weird experiences has to do with this MMIO black magic. So last night I succeeded with these values.Notice how my slides are exactly the same as @Driftwood's. Something about our board MMIO is common as he also experiences the click shutdown/restart and install corruption issues.

 

35:415 00:054 OCABC: MMIO devirt start
35:472 00:056 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0
35:529 00:057 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0
35:587 00:057 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0
35:643 00:056 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0
35:700 00:056 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0
35:757 00:057 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0
35:814 00:056 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0
35:871 00:057 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0
35:928 00:056 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0
35:986 00:057 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0
36:043 00:057 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0
36:096 00:053 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0
36:150 00:053 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0
36:205 00:054 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0
36:260 00:055 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0
36:315 00:054 OCABC: MMIO devirt 0x10000000000 (0x10400 pages, 0x8000000000000001) skip 0
36:370 00:054 OCABC: MMIO devirt 0x3CB90000000 (0x10400 pages, 0x8000000000000001) skip 0
36:425 00:055 OCABC: MMIO devirt 0x3CBC0000000 (0x10400 pages, 0x8000000000000001) skip 1
36:483 00:057 OCABC: MMIO devirt 0x69750000000 (0x10400 pages, 0x8000000000000001) skip 1
36:537 00:054 OCABC: MMIO devirt end, saved 555184 KB
36:592 00:055 OCABC: Only 176/256 slide values are usable!
36:647 00:054 OCABC: Valid slides - 80-255

 

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.

3 hours ago, fabiosun said:

@iGPU ended for now my serious tests in bare metal because I can't figure out Nvidia problem, so I did a Catalina fresh instal to avoid classic high Sierra problem with old usb driver

attached my IOREG

when you have time the goal could be usb function activation in TB device 🙂

TY

iMac Pro di fabio_for_TB_IGpu.zip 1004.44 kB · 0 downloads

 

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.

[fabiosun]

this afternoon I have dedicated some time to apply my MMIO schema to @Driftwoodrig

using a minimal efi and config

Those MMIO schema it is working also for his PC

now his system reboot/shutdown fine..

I do not know if your system sleep and wake well

but in my case this is so

 

I advice to try 😉

obviously if in your rig all above stuff is failing 🙂

[meina222]

@iGPU - yes! Bootstrap was enabled in my target drive EFI containing Catalina.

 

So what happened was this:

 

My USB never worked. But when it froze it created a state where on next boot, my target disk EFI would get auto selected. That happened to be the previous bare metal EFI for Catalina which is non-Debug and contains OC 0.6.0 with bootstrap enabled. The reason I enabled some time ago was because I couldn't figure how to delete duplicate entries in my boot menu before. Anyways, so without knowing I actually succeeded installing BigSur using that EFI. Even after the entire disk volume group was erased, the EFI files survived when the installer (from the USB before the freeze) recreated the partitions.

 

I am very wary of this "success" though as I ended up with a corrupt install before in Catalina. I think the MMIO group is critical to this whole effort - my freezes must have come from it. I will retry the USB as now I removed the bootstrapping EFI.

Edited August 29, 2020 by meina222

[meina222]

Back in business. Fixed the USB MMIO to match the install EFI (the one that sneaked on me via Bootstrap). The world makes sense now. Booting with OC 0.6.1 and WG and -wegbeta and pikera. Pikera is always required for me - the previous info  that I could disable it (I never did due to not realizing I booted from another EFI) is misleading and I edited it out.

 

Now should I re-try to reinstall BS with 0.6.1 (@iGPU's latest EFI)? I think not :). Or at least not right away.

[meina222]

Seems I have a ghost mount of dev/disk1s1 that didn't show up in Finder. Nothing to do with what I typed below.

 

So in Big Sur - is there a way without going through avoiding the sealing of volumes to copy the boot EFI to the disk instead of USB?

 

When I try dd, I get

 

udo dd if=/dev/disk8s1 of=/dev/disk1s1

dd: /dev/disk1s1: Resource busy

 

Edited August 29, 2020 by meina222

[Jaidy]

8 hours ago, Ploddles said:

 

Have you changed the config.plist to include your MMIO Whitelist?

 

The same was happening to mine until I went through the process. Now it Restarts without any issue and NVRAM is working fine. On Shutdown though I still get reboot.

 

I also had to change the Debug bits in the config file, leaving it as enabled etc it would take up to 5 minutes before it would fully boot into Catalina after selecting that from the picker. One other change I made was to the ScanPolicy, changing it back to 0, the reason being leaving it at 19596035 resulted in me not seeing the Windows NVMe - as I dual boot Windows it was the quickest way to get that back into the picker rather than hitting F12 to be able to choose that to boot from.

I actually made none of those changes, simply copied the EFI folder into my EFI partition. Though reading from your post. Thanks for pointing it out. For now it seems I have a fully operational hack with shutdown not working. Hopefully that would be resolved soon too 🙂

Edited August 29, 2020 by Jaidy

[iGPU]

14 minutes ago, meina222 said:

So in Big Sur - is there a way without going through avoiding the sealing of volumes to copy the boot EFI to the disk instead of USB?

 

When I try dd, I get

 

udo dd if=/dev/disk8s1 of=/dev/disk1s1

dd: /dev/disk1s1: Resource busy

 

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

 

 

Edited August 29, 2020 by iGPU

[meina222]

Not much of a hackintosher - this TRX40 is my 1st attempt - so didn't know about it. Thanks!

 

One thing that BS confuses me about - with this "Preboot" volume selected - how do I know which EFI am I using? Once in, what's the best way to tie up what I see with whichever EFI I want to change? Right now I see my USB renames are not being applied properly, so not sure if some other EFI is sneaking on me like before.

 

Ah! Now I see - it's the green one from your app. Thanks, this app is indeed great!

Edited August 29, 2020 by meina222

[iGPU]

While working on the TB USB problem, I'd left IORE open for some time on my desktop. I noticed that. one USB device in particular had a lot of activity: something was repeatedly attaching and de-attaching to XHCI/HS02 (the spoiler below shows how it goes on and on; if left to itself, the cycle would repeat dozens of times).

 

Now why I think this important is that I found an error when shutting down in both Catalina and Big Sur that said "Restart waiting on HS02". At the time, I didn't know which HS02 it was referring and put the idea in the back of my mind. But now seeing this failed attachment attempt and knowing that USB problems can affect sleep and shutdown I thought it worthwhile to pursue. I do not yet know if will will affect Shutdown.

 

To see if you have such a problem, open IORE and left run for a few minutes then study the USB ports, primarily those under S0D2/BYD8 that is common to all of our TRX40 mobos. I can help you generate an SSDT should you have a similar problem: below is posted a generic SSDT  (here) with instructions on how to modify it.

 

 

Spoiler

 

 

On inspecting further down IORE, I saw that it was a problem of AppleUSBInterface trying to interact with ASMedia (ASMedia has a bit of bad reputation on the Intel side). See spoiler below showing AppleUSBXHCI (this list too went on hundreds of times, so what's shown is just a few cycles).

 

Spoiler

 

 

The fix was to re-define the USB ports within the XHC-XHCI SSDT, similar to how I showed earlier to delete the BT/Wifi port (as I recall it was XHC/Prt5). After re-booting with this new SSDT, the following was seen with no more failed attachment attempts by AppleUSBInterface. Spoiler shows AppleUSBXHCI is free of AppleUSBInterface.

 

 

 

Spoiler

 

 

 

Edited August 29, 2020 by iGPU

[meina222]

One more thing to report after some testing the shiny new BS install. Every once in a while I fail to boot and instead of getting deep into the log, my PC just reboots. Next time it usually succeeds. So there is still some quirk around maybe slides that causes this instability.