trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[Driftwood]

7 minutes ago, fabiosun said:

ah ok then check all kext you are using and verify you are using latest--things change faster in this time 🙂

 

Ive been using iGPUs EFI (and debug version) nothings changed from anyone else's!

 

Are we saying the kexts used in iGPU's EFI are older/newer versions than what is for Cat or summit? He mentioned both Cat and BS should boot with it... which it did initially until I got down to child 2 and a shutdown bug. Child 2 booted, but the shutdown which went into a reset, then made any other EFI boot impossible causing the errors I showed earlier - and before anyone asks again I did the removal of the problem child FAIL to boot, and complete removal of MMIOwhitelist from the booter - FAILED to boot.

 

I then tried earlier EFIs known to boot Cat BM but = FAIL.

Edited August 27, 2020 by Driftwood

[fabiosun]

I am using mine and I have no checked IGPU EFi

Usually all EFI posted are to be verified for owner system

@iGPUdoes a great job to offer a complete EFi..but he has a system which differ from mine or your..so not all can be "copied" as is

but this is only my 2 cents to this subject

 

[fabiosun]

then I have also seen here his EFI completely changed by user..and this is not good if then EFI is posted again for others..

my role here as a moderator should impose the rule on me to delete all the efi taken and modified by other users than the one posted originally to avoid problems

But I prefer to leave the discussion very free

[Driftwood]

Yes, but iGPUs was good initially until I went thru the process of doing MMIO.whitelist. This was all good until I reached child 2. Shutdown attempt, it restarted. AND something happened to the Cat drive.

 

I also replaced the EFI with an earlier EFI I did days ago but even that will NOT boot anymore. 

 

The prelinked stuff could be from using different EFIs and its got confused! Who knows?!

Edited August 27, 2020 by Driftwood

[fabiosun]

41 minutes ago, Driftwood said:

Yes, but iGPUs was good initially until I went thru the process of doing MMIO.whitelist. This was all good until I reached child 2. Shutdown attempt, it restarted. AND something happened to the Cat drive.

 

I also replaced the EFI with an earlier EFI I did days ago but even that will NOT boot anymore. 

MMIO I see on you excel page is weird 

it seems two of the start part are the same with a name changed

For this I was asking if you have back upped on Bare metal efi that log

no need to start again in BM but only booting in Proxmox, mounting BM efi and copy your boot log

 

about your problem if it is the only change you have done a simply CMOS reset could restore your ideal situation

Maybe you can save firstly on a txt file your actual bios configuration to restore after this

 

[Ploddles]

@Driftwood, although you are locked out of Catalina ATM, have you tried to see if your EFI will boot Catalina Recovery?

 

I have been locked out of the installed os twice after a sudden reboot but the Recovery console booted fine. For me just 'touching' /System/Library/Extensions solved the booting problem.

[iGPU]

2 hours ago, Driftwood said:

Yes, but iGPUs was good initially until I went thru the process of doing MMIO.whitelist. This was all good until I reached child 2. Shutdown attempt, it restarted. AND something happened to the Cat drive.

 

I also replaced the EFI with an earlier EFI I did days ago but even that will NOT boot anymore. 

 

The prelinked stuff could be from using different EFIs and its got confused! Who knows?!

 

I'm sorry to hear about your problems, but it's not related to my uploaded EFI, but a result of whatever you did with MmioWhitelist.

 

The process I went through for MmioWhitelist was documented earlier in this thread, but was simply a more fleshed-out version of what's on Dortania's OC guide. I didn't invent any of those things. It was tedious to go through, but uneventful for me.

 

While it's obvious there was a problem in how you processed MmioWhitelist, as I've mentioned several times, since every mobo's MmioWhitelist is different, few of us can help you. (And this is why I didn't activate mine in the EFI, but only left as a reference.) Once you get your system back up running, I think you should stay away from using MmioWhitelist. Things will work without it. Or, if you definitely want  NVRAM, use NVRAM.plist following Dortania's guilde and OC documentation.

 

The EFI I uploaded was to help for BS Installation and debugging. I view it as a tool, not necessarily a daily driver: this is why I uploaded a basic, stripped down version without fancy SSDTs. I mentioned in the upload post, that Shutdown only seemed to be working in BS, not Catalina. All kexts and drivers were latest commits (drivers and other OC efi files must match for current commit; any substitution of a different commit dated efi file could crash a system: this is esp important for BOOTx64.efi, OpenCore.efi, and OpenRuntime.efi).

 

A few Hackintosh caveats:

1. Hackintoshes are fun to experiment with; they can be changed unlike a real Mac; but they're not real Macs.

2. And since these are Hackintoshes, they're guaranteed not to be as stable as a real Mac. If you want reliable and stable, buy a real Mac from Apple.

3. If your system is working and you have a relatively stable machine and it's needed for your work, don't update anything (this includes BIOS, boot-loader, kexts/SSDTs, drivers, and esp a beta OS).

4. Always have a back of your main drive. (I use CCC to keep a clone of everything I work on. If something fouls up, I clone the backup to the main drive.)

5. Have back up EFI's ready for alternative access booting.

6. If things seem unstable, re-flash BIOS. BIOS can become corrupted with crashes and hard reboots. This is not uncommon on Hackintoshes (even on the Intel side). It only takes a few minutes (and if you have a saved configuration, only seconds to re-load all settings as long as the BIOS is the same version.)

7. AMD is the most unstable Hackintosh platform and the TRX40 platform the least supported of all.

 

[fabiosun]

I agree with all above message

 

Usually I do not put entire EFI because I know that for a better learning curve user have to solve some minimal stuff

 

 I appreciate all @igpu efforts in this thread

And I hope..with his job we can improve all our knowledge..and thunderbolt device 🙂 🙂

 

 

[Driftwood]

1 hour ago, Ploddles said:

EFI will boot Catalina Recovery

It wont!

 

Getting prelinked to realy old versons of whatevergreen and lilu which is very staange. Seems like my cache kext on the OS is out of sync!

[fabiosun]

 

Acquantia in HighSierra (no driver or patch needed)

 

 

Thunderbolt without SSDT

I have to change the one I have had by IGPU and test

 

 

 

all my sata devices 

 

 

My two NVME drive

 

 

and finally my GPU and my two monitors connected on it

 

 

 

[meina222]

I thought I had operator error with my MMIO experience - @Driftwood, this is what happened to me - my MMIO pattern was exactly the same (even most numbers matched) - ALL ON, 2 OFF, 2 ON from top to bottom - booted OK (only the 2 OFF prevented boot when either was ON) and then AFTER running, and rebooting once or twice, I got into instabilities.

 

I wonder if you disable that problematic number 2 MMIO, whether things would be different. It is extremely time consuming though to be finding out working MMIO patterns by being locked out by a subsequently unstable configuration (secondary boots) vs just the 1st time boot fail test. The search becomes severalfold more time consuming.

Edited August 27, 2020 by meina222

[fabiosun]

Spoiler

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] (subsys 1022:1480)
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] (subsys 1022:1481)
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) (subsys 1462:7c60)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) (subsys 1462:7c60)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 0 [1022:1490]
02:00.0 Non-Volatile memory controller [0108]: Phison Electronics Corporation E12 NVMe Controller [1987:5012] (rev 01) (subsys 1987:5012)
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 1 [1022:1491]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 2 [1022:1492]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 3 [1022:1493]
20:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] (subsys 1022:1480)
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 4 [1022:1494]
01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 [144d:a804] (subsys 144d:a801)
20:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] (subsys 1022:1481)
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 5 [1022:1495]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 6 [1022:1496]
20:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
20:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 7 [1022:1497]
20:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
20:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
20:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
60:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] (subsys 1022:1480)
20:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
60:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] (subsys 1022:1481)
20:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
60:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
04:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] (subsys 1022:1485)
20:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
60:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
20:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
04:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller [1022:148c] (subsys 1462:7c60)
60:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
03:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] (subsys 1022:148a)
60:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
20:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
60:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
60:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
60:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
60:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
60:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
21:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [TITAN Xp] [10de:1b02] (rev a1) (subsys 10de:0010)
21:00.1 Audio device [0403]: NVIDIA Corporation GP102 HDMI Audio Controller [10de:10ef] (rev a1) (subsys 10de:123e)
22:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] (subsys 1022:148a)
23:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] (subsys 1022:1485)
23:00.1 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP [1022:1486] (subsys 1022:1486)
23:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller [1022:148c] (subsys 1462:7c60)
23:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487] (subsys 1462:cb60)
61:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] (subsys 1022:148a)
62:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] (subsys 1022:1485)
40:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] (subsys 1022:1480)
40:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] (subsys 1022:1481)
40:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
40:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
40:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
40:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
40:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
40:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
41:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse Switch Upstream [1022:57ad]
49:00.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
4f:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:07b1] (rev 02) (subsys 1462:b912)
51:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] (subsys 1022:1485)
50:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] (subsys 1022:148a)
4a:00.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
4a:01.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
4a:02.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
4a:04.0 PCI bridge [0604]: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge 4C 2018] [8086:15ea] (rev 06)
42:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3]
42:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3]
42:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3]
42:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a4]
4b:00.0 System peripheral [0880]: Intel Corporation JHL7540 Thunderbolt 3 NHI [Titan Ridge 4C 2018] [8086:15eb] (rev 06) (subsys 2222:1111)
42:09.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a4]
42:0a.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a4]
44:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03) (subsys 1462:7c60)
4d:00.0 USB controller [0c03]: Intel Corporation JHL7540 Thunderbolt 3 USB Controller [Titan Ridge 4C 2018] [8086:15ec] (rev 06) (subsys 2222:1111)
43:00.0 USB controller [0c03]: ASMedia Technology Inc. (null) [1b21:3242] (subsys 1462:7c60)
46:00.0 (null) [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] (subsys 1022:1485)
45:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03) (subsys 1462:7c60)
46:00.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] (subsys 1022:1486)
47:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51) (subsys 1022:7901)
48:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51) (subsys 1022:7901)
46:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] (subsys 1022:148c)

 

PCI Device in Baremetal

[fabiosun]

 

thunderbolt 🙂

 

[iGPU]

PREVENT SEALING DURING BIG SUR INSTALLATION

 

This is part 2 of the 'subsequent' post on preventing a Big Sur drive being 'sealed'. Presently, this step can only be done during Big Sur installation.

 

Up until BS ß4, there was a technique for avoiding the sealing step that involved stopping the installation of Big Sur during the 3rd re-start (literally pressing the power button and shutting off the computer). However, with BS ß5, this technique reportedly does not work (I did not try it to verify).

 

Instead, it is recommended (again by fusion71au on the InsanelyMac forum here) to use the app Hax2 (attached below), which was derived from ASentientBot's post on MacRumors. This app, along with it's associated files are to be placed on the root section of your macOS drive (ex: MacHD/User/myName/Hax2/) used to run the installation. 

 

 

While it reportedly can use an installer placed on a mounted USB thumb drive, I could only get Hax2 to work by placing the BS ß Installer in the applications folder where it normally is located.

 

Prior to using, as mentioned in part 1 of this 'subsequent' post (here), you need to have the following in the OC boot arg section: -no_compat_check and amfi_get_out_of_my_way=1

as well as 77080000 for car-active-config. I also when into Recovery on the drive containing the Hax2 and ran csrutil disable and csrutil authenticated-root disable and then rebooted into the drive containing Hax2.

 

At this point, the drive destined for the Big Sur installation should be erased using Disk Utility.

 

Next, run Hax2 (you'll need to give permission by <Control> clicking on Hax2 and selecting Open. Hax2 will do some processing and then open the BS Installer. However, if you have not properly used the boot arguments noted above, Hax2 will give you an error window as shown in Spoiler below; select Stop, fix the boot issue in your EFI, re-boot the computer and try again.

 

Spoiler

 

 

Once Hax2 is running without an error window, and after the Big Sur Installation window has opened, do not yet run the Installer. Instead, look at the Installer icon in the menu bar and make certain that it's the ß5 and not some other BS Installer you may have inadvertently left on another drive by opening it in the Finder (Spoiler below):

 

Spoiler

 

 

If it's the correction version, run the Installer and select the proper destination drive. I re-ran all of this tonight and repeated the installation:

 

 

At each re-boot do make certain that the booting EFI contains those same boot arguments noted above ( -no_compat_check and amfi_get_out_of_my_way=1 )

 

 

After the Installation is complete and you've finally logged into Big Sur, re-start the computer and log into the Big Sur Recovery 11.0. At this point, you'll want to run the first part of this post to remove the Snapshot partition (see a synopsis in the Spoiler below).

 

Spoiler

Note the several steps from mounting the disk (diskutil list step not shown) to giving the disk read/write permission.

 

The Snapshot partition was then tagged and a list command was attempted. Since I made a typo there was an error response. Once I realized what had happened, and entered the corrected phrasing, the correct response was seen. This response gave the UUID which allowed deletion of the Snapshot partition. A confirmation step was repeated to confirm that no Snapshots were remaining.

 

 

 

 

Once the Snapshot partition was removed, re-boot back onto the desktop.

 

When you're back on the Big Sur desktop, you can now run in Terminal: sudo mount -uw / and then diskutil info / (mentioned in the first post) and you'll see the following, showing that the Big Sur installation is not sealed:

 

 

The main advantage of removing the seal is that the Big Sur drive will now be visible when the computer is booted into an older macOS. The image below was booted into Catalina and shows one Catalina drive and two Big Sur drives. One Big Sur drive has had the seal removed and is visible as "MacHD". The other Big Sur drive is only visible as "Update" since this drive is still sealed.

 

 

 

Hax2.zip

 

 

Edited August 28, 2020 by iGPU

[fabiosun]

@iGPUhave you mounted in your TRX40 a Titan Ridge card?

I am not be able to adapt the old SSDT used in Proxmox with new ACPI address...

 

[Driftwood]

15 hours ago, meina222 said:

I wonder if you disable that problematic number 2 MMIO, whether things would be different. It is extremely time consuming though to be finding out working MMIO patterns by being locked out by a subsequently unstable configuration (secondary boots) vs just the 1st time boot fail test. The search becomes severalfold more time consuming.

Even with them all off now it wont boot any efi. I put back in some old lilu and whatevergreen (which was being used in an old cloned copy of catalina from Proxmox that I was using for the BM test) just to rid itself of the prelinked errors to see and still no difference.

 

Its definitely a corrupted drive now and therefore going to start a fresh install on it purely for testing. Really dont want to commit my m2 Cat install under Proxmox to be used in any testing for BM so we move on...

[iGPU]

6 hours ago, fabiosun said:

@iGPUhave you mounted in your TRX40 a Titan Ridge card?

I am not be able to adapt the old SSDT used in Proxmox with new ACPI address...

 

 

Yes, I tried the Titan Ridge card a couple of weeks ago. Same response: good TB behavior, no USB functionality. I know that this card works well in other builds, so the problem is now the TRX40 is interacting with the TB AIC. I tried many variations of SSDT without success in activating the USB ports.

 

The only thing I can think to do next is look at modifying the DSDT. That's going to take me some time...

 

I can fix your SSDT (for TB function), just show me your IORE file.

 

Edited August 28, 2020 by iGPU

[fabiosun]

Thank you for your offer but now I have lost again my GPU acceleration..Nvidia is very hard to configure in bare metal

Nvram/sip is a big problem

to understand some problem I have I have resetted my nvram via opencore boot menu option..and now some Nvidia  kexts loaded again ..and Nvidia web driver is checked

 

I hope to fix it..but I can't find a clear way to reproduce a working situation

 

 

[iGPU]

FYI

 

As of yesterday, OpenCore has with latest commits made some notable structural changes to the config file. So unless one studies it carefully there'll be errors in the config file if one simply adds in the latest commit without adjusting the config.plist file. These changes are primarily architectural indicating strings ("Arch") being stored in the Kext section in many locations  as well as adding a "Scheme" to the Kext section.

 

#33 below is a Kext patch entry. Each Add, Block and Patch entry within the Kext section now has an "Arch" element. The choices for this string are Any, i386, x86_64. I can imagine an Apple kernel architecture being an option in the future, which is why I'm setting them all to "Any" (the only other choice for our machines would be "x86_64").

 

 

I adjusted the config file, tested last night and it's working. However, the changes presently offer nothing for the TRX40, so no need to update any EFIs.

[fabiosun]

https://github.com/corpnewt/OCConfigCompare

 

to compare config.plist in an easy and super fast way

 

[Driftwood]

OK Im back up after a re-clone of my Proxmox M2 nvme MacOS Catalinaa drive to the corrupted EFI/OS SSD 2tb drive. We begin again...

 

Ive been using most of Fabiosun's EFI suggestions and his config recommendations, but note Im still using MacPro 7,1 like my Proxmox boot. I didnt want to use Mac1,1. All is good and GfX in Davinci, Final Cut, Logic is up to speed of Proxmox. NO real difference. However, the firewire Fireface card is rock solid now it seems.

 

All good. RESTART cause s a quick KP Restart and wont boot back in.

Shutdown gives me a Restart which will boot back in but doesnt click shutdown.

So now need to enter MMIO to see if I can get  Shutdown working.

 

So now I'm using BIOS 'Above 4G' as with it off using Macpro7,1 it wouldn't boot hanging on PCI begin. (I guess I could've usde the nscpi=0x2000 thing but didnt bother).

 

Remember, Im using a config based on my Proxmox settings and adding in/editing in any useful stuff from @fabiosun plist.

 

Just wanna thank @fabiosun for his tireless support. What a guy!

 

Now here's the interesting news. A comparison of MMIO with Above 4G selected: (Above 4G Left, Above 4G Disabled on Right).

 

I've attached my config (fill in your serials/UUIDs) for Asrock Creator users. Ensure Above 4G is on and this is PRE MMIO configurations. Later if Im successful in getting the MMIO stuff working Ill post the final config.

 

 

 

Download:

Asrock TRX40 Creator Macpro7,1_config.plist.zip

 

EFI: Kexts & Stufff I used

 

 

* remove any EFI (like I did above_) you are not using - only use what is declared in config... I have to tidy mine up!

My setup utilises two Radeon VII cards - so check your graphics as it will be different to mine. Especially Whatevergreen.

 

 

 

 

Edited August 28, 2020 by Driftwood

[Driftwood]

On 8/27/2020 at 5:39 PM, Ploddles said:

tried to see if your EFI will boot Catalina Recovery?

Wouldn't get through to Recovery, definitely a corrupted Mac disk hence why I had to begin again with new clone. See above post.

Edited August 28, 2020 by Driftwood

[Driftwood]

On 8/27/2020 at 5:50 PM, iGPU said:

I'm sorry to hear about your problems, but it's not related to my uploaded EFI, but a result of whatever you did with MmioWhitelist.

 

Dont worry @iGPU its not your problem or fault with my corruption - its part of life experimenting :-) . Each board is different. Your work is excellent and some terrific findings. Many thanks for doing what you do.

Edited August 28, 2020 by Driftwood

[iGPU]

6 hours ago, fabiosun said:

Thank you for your offer but now I have lost again my GPU acceleration..Nvidia is very hard to configure in bare metal

Nvram/sip is a big problem

to understand some problem I have I have resetted my nvram via opencore boot menu option..and now some Nvidia  kexts loaded again ..and Nvidia web driver is checked

 

I hope to fix it..but I can't find a clear way to reproduce a working situation

 

 

 

fabiosun,

 

Are you enabling "Above 4G decoding"? While researching TB issues, I came across a recommendation for a user of NVIDA card to enable it, esp with the TB card in place to avoid KP.

 

If you do keep it enabled, the SSDT-TB will possibly need adjustment as it could shift the device location. Let me know.

[fabiosun]

It is enabled

but on my msi enabling it or not produces pretty identical results

problem for me is to find a scientific way to have nvidia driver working

 

for now not possible

 

I have not verified well about device shifting

 

it seems not but not completely sure of this