iGPU

40 minutes ago, Jaidy said:

@iGPU thank you so much for your work. I have a question (I am a total noob here, so might be silly). The EFI you posted deactivated the restart and shut down functionality. Do we need to include a MIMO to get that (I am not even sure what a MIMO is 😄 )

I'm not sure what you mean. The EFI allows Shutdown (Restart was always working). Are you in Catalina or Big Sur?

1 hour ago, fabiosun said:

@Pavo SSDT is loaded and variable stay there also after a reboot

same behaviour of emulated NVRAM

For now not useful for my problem (Nvidia web driver not loaded properly)

 

@iGPUwaiting for your idea to try...

I wonder way during my test..without doing nothing of special I have it loading well

then after a problem with default secure boot parameter I have had to clear my cmos and from there no joy

 

fabio’s iMac Pro Pavo SSDT.zip 959.7 kB · 3 downloads

attached my IOREG with Pavo's SSDT

 

I've noticed that I sometimes must do a "Reset NVRAM" when changing from Big Sur to Mojave.

(I've not yet had to re-flash BIOS on this MSI mobo.)

Yous SSDT looks okay. Did you use the minimal SSDTs from above EFI; it should have injected to SBRG and MCHC. The SSDT-NVRAM might not work until you get MmioWhitelist working.

Is there an issue I'm missing?

BIG SUR INSTALLATION EFI

I'm posting here an EFI that not only boots the TRX40 bare metal into Catalina or Big Sur, but also allows a Big Sur Install from either a USB Installer, or, having the installer app within the Applications folder. I tested both methods of Big Sur install with destination drives that are internal and external USB. 

[ Debug Version added at bottom ]

There are a few important details that I'll point out below. In a subsequent post, I'll show how removing Snapshots can allow proper read/write of the disk (and this may allow you fabiosun to get your kexts loaded, but I cannot check, so I don't know for certain). That post was divided into 2 parts here and here. 

Besides booting Catalina and Big Sur, this EFI also seems to have a consistent, properly functioning Shutdown in Big Sur (but not so regularly in Catalina). Shutdown also works from Big Sur Recovery. However, while Shutdown works from the Apple menu, it does not seem to work when using the log-in screen Shutdown button, but gives the usual panic re-boot.

I would recommend not changing anything in this EFI (except perhaps for very select items like Ethernet discussed towards the bottom). This EFI uses OC v061 commit from 25 Aug. This commit allow proper booting of Big Sur Recovery without resorting to ScanPolicy 0 or the need to Enable/Yes JumpstartHotPlug (ScanPolicy discussed more below). There are no re-name SSDTs nor any fancy stuff: this is basic, functional EFI.

First off, there are 3 config.plist files as shown below. The active one is simply a duplicate of config-basic-genPI-BSinstall.plist as a backup. The other config file, config-basic-genPI, is the same but without boot args (-v, -no_compat_check, and amfi_get_out_of_my_way=1), Those boot arguments will be discussed in the subsequent post, but they're really only useful during a Big Sur install and are otherwise not necessary. Notice that the Slide boot argument is removed. It seems not necessary and avoids conflict with other mobo builds.

Config files:

Boot Arguments:

The other thing to point out is the csr-active-config value of 77080000. This value was gleaned from user "fusion71au" on the InsanelyMac forum and disables both csrutil and csrutil authenticated-root. Disabling these two allows for working with Snapshot files (that will be discussed in the subsequent). This 77080000 value can be used for both Catalina and Big Sur. Some may need to remove npci=0x2000; it is required for me as I leave "Above 4G decoding" disabled in BIOS.

Moving onto ScanPolicy shown below. With this latest v061 commit, a proper ScanPolicy (rather than 0) can be used that limits filling the boot menu with useless EFI folders. This scan policy allows for the following drives to appear in the OC boot menu: APFS, HFS, SATA, SASEX, NVME, USB and PCI devices (the latter includes virtual disks, so this is a good ScanPolicy for a Proxmox VM config file). The Auxillary items (like Reset NVRAM) are accessed by pressing the spacebar on the keyboard while viewing the OC boot menu. (Another item that can be activated while viewing the OC boot menu is turning on verbose mode by pressing <Cmd><v>; p 33 of included Docs.)

An important new OC setting is changing SecureBootModel to Disabled. The Default value, recommended by the OC Docs, will prevent many things from working, such as the Aquantia kext patch. Don't change this unless you have a good reason.

The next issue to discuss is MmioWhitelist. There are references on the Dortania OC Guide for AMD (which has been discussed earlier on this thread) that are incorrect for the TRX40 build. I've tested these values and they don't work; but I've included for illustrative purposes. The MmioWhilelist array that is active (shown below) is actually empty. The other inactive one contains the MmioWhiltelist for my mobo (MSI Creator, which I posted earlier in this thread). I  do not know, nor can I test, whether this will work for any other mobo. I would encourage deriving your own for your mobo.

Finally, as far as ACPI, kexts and drivers, only a minimum are included. As mentioned earlier, the only other section you might adjust is if you need a different Ethernet driver from what is included in this EFI:  SmallTree82576 and Aquantia AQC107. The AQC107 is activated by a kext patch which is Enabled/Yes (and was discussed by Pavo on the InsanelyMac forum). These two cover a majority of our builds and allow at least one Ethernet port to work. BT/Wifi kexts are included and presently Enabled/Yes; these will work with swapped cards as well as PCIe AICs. WEG is Enabled/Yes but partially disabled thru the -wegbeta boot argument. If WEG is left fully Enabled, Big Sur will not boot in bare metal. Lilu, VirtualSMC and AppleALC are Enabled/Yes as is AppleMCEReporterDisabler.

Since this EFI is more inclusive and robust, I will delete the EFI folder presented on page 1 of  this thread and replace it with a link to this post.

As usual, you need to supply SN and SystemUUID values in the PlatformInfo/Generic section before using.

EFI-v061-8e2755f-BareMetal-USB-installer-Public.zip

Debug version (this is same as above, but does not contain the Install boot-args). The config file is different, adjusted to give more reports, so do not swap between release and debug versions.

EFI-v061-8e2755f-BareMetal-USB-installer-Public-Debug.zip

1 hour ago, rressl said:

@Ploddles

 

Thanks for uploading your configuration.

 

Unfortunately it doesn't work for me and when I boot from the USB stick I only get the selection "CleanNvram.efi" and "ResetSystem.efi".

 

What could be the problem? (CSM and Above 4G decoding is disabled)

See my comment to Ploddles. The things you're seeing on boot are some of the things I had to delete from his config file.

Better to start with the EFI from GitHub or the EFI I uploaded here several days ago.

On 8/22/2020 at 11:17 AM, Ploddles said:

 

Attached is the config file I used with 0.6.1 Debug version built on 12 August. Pretty much my current config with bits disabled. Various bits still need to be added/removed etc, I'm slowly going through it to clean it up for my MB.

 

Thanks for having a look.

OK, I had to re-work a lot of stuff. It became too complicated to just give you back just a config.plist file, so I entered everything in to an EFI that is for your Xtreme mobo. This is derived from v061, just after v060 was made a release version, so it is really v060. It has the things that should also work for BS as well as Catalina. It is the not a debug version. This is the exact version I used to boot in Catalina bare metal for the first time.

You added a lot things to the config files that shouldn't be there. I removed them as most are not necessary for any AMD or Intel mobo I've ever used. The order of SSDTs, kexts and drivers are important and you'd moved things around into orders that were not anything I'd uploaded or recommend. I've put them back into a better order. Your BT kext entries, I've left disabled; I don't have those files and anyhow I would recommend getting the system reliably booting before working on them.

I also revised some new SSDT's for you as you were using some for other builds that wouldn't work. The only one that may not work is the Ethernet one, as it has a nested substitution. It should work, but since it's in a separate file, it won't interfere with other SSDT files, should it not. After booting, run IORE and save it. I can look at it later if there's a problem. (If you use a large SSDT, which does many things, and one part is broken, the whole SSDT won't work: it's better to have many SSDTs each doing a few things.)

If at a later date, you want to modify stuff, make a copy of the config file that's working and leave the original alone so you have something to go back to that works. Better yet, kept a copy of what's working on a USB stick to be able to boot from that. I keep an EFI backup folder that contains every version I've worked on for each mobo. (The Spoiler below shows an excerpt from the TRX40 build of saved EFI folders.)

5 minutes ago, fabiosun said:

i have to disagree about WEG use ( I do not use it because web driver helps to activate well all my GPU output ports)

in many case it could be useful to map in a proper way GPU output port, sometimes without it you have a no working display port , and mapping it in other way could be difficult

 

WEG problems appear with Radeon VII and NAVI AMD GPUs (I've only used AMD GPUs, so no nothing about NVIDA issues). On Intel, if using WEG and one of those AMD GPUs, the computer would freeze within 10 min after booting with the mouse becoming jerky just before the freeze. The only way around it was to disable WEG. When this was done, on some GPUs, one of the HDMI or Display ports would become inactive (I can't remember which now).

And when trying to boot bare metal into BS on TRX40, it was impossible with WEG enabled. I later found out, through trial and error,  that if "-wegbeta" were added to boot arg, then WEG could be left enabled and successfully boot into BS.

1 hour ago, Ploddles said:

I'm not having much luck with this.

 

It halts on a critical error and the saved file does not have the MMIO info in it. I've tried with 0.5.9, 0.6.0 and 0.6.1 debug versions. Tried with and without the SSDTs and with and without the kexts.

 

Any suggestions as to what I am doing wrong?

 

Thanks.

 

 

 

opencore-2020-08-22-153125.txt.zip 3.75 kB · 0 downloads

The schema errors appear when your using a mis-configured config.plist file for the particular version of OC. (In other words, you've probably kept the same config.plist file yet swapped out different OpenCore.efi files that now have different entries.)

Another common OC mistake is to update parts of the OC folder and forget to also update the BOOT folder. All parts of OC's EFI folder need to be of same commit (well, not ACPI or Kexts folders).

I don't include HiiDatabase.efi in GitHub site, so declaring this is config.plist and not having in Driver's folder will give a critical halt. Most of the driver's are not necessary, and I've excluded them from the Driver's folder on purpose.

So upload your config.plist file (without SN info; you can replace that portion later; I gave instructions in Section 6 on GitHub site) and I'll try to fix it, but I'll adjust for the latest commit on get GitHub site that I just updated a few minutes ago. If you again swap out OC parts, the config.plist file will break again.

***

Are you booting into BS or Catalina?

VIrtualSMC seems more an issue for BS than Catalina. WEG is not necessary for either.  I don't think any of the SSDT are important for a boot. The renames are important for Hackintool USB, but booting is okay without, but I like to include "2-SSDT-PLUG" and "3-SSDT-TRX40-EC-USBX-MCHC-SBRG" as a minimum.

OC v061 latest commit, 22 Aug. (Oddly, it still says 12 Aug date, but each couple of days there are changes.)

4 minutes ago, Driftwood said:

 

Graphics performance is down to about 60 odd percent Im told too 😞

 

Not completely true.

I'm finding virtually the same, with ever-so-slightly greater values in bare metal. The only tests where the graphic values are less is Geekbench. Since LuxMark values are the same in VM or bare metal (and LuxMark is one of the few tests that can use 2 GPUs), I think the test is problematic, not bare metal. (I've summarized on GitHub, section 9). And Geekbench GPU-Metal test is basically the same in bare metal or VM; the problem is with OpenCL.

2 hours ago, valmeida said:

I have a few  SATA drives are not loading . It leads me to believe that a specific SATA controller is not loading . I have attached my EFI folder and list of PCIE devices I pulled from Hanckingtool .  Should I add special devices to the Device Properties  in my config.plist or can a ssd be or DSST be crated and added. One more thing does the 15 port usb limit apply with AMD ? In my previous  builds I would have to map out each port using the Hackingtool and then export a USBPorts.kext. Also not shutting down. 

EFI.zip 18.89 MB · 0 downloads pcidevices.plist.zip 2.07 kB · 0 downloads

I'm not sure that you want a Microsoft boot folder inside the OC EFI folder.

What specific SATA are missing? Are they formatted for OS X or other OSs as this will affect what shows up. (If you want other OSs, you'll need different drivers.)

Load a IORE file for your build.

You don't want to use DSDT in OC on this build. As for USBs, I've never seen more than 10 ports per device. The 15 port limit is per device, not per machine.

****

9 hours ago, fabiosun said:

I have a problem with Cinebench 15

running cpu benchmark produces often an instant reboot

I've not seen any reboots with any tests on bare metal or VM.

Some tests crash, like the Corona test, but on forced exit, the macOS was fine.

4 hours ago, Driftwood said:

I'm going to test DaVinci Resolve, Logic Pro, Camtasia and Adobe CC with a bare metal config this weekend. These apps work fine under Proxmox, under Mac 7,1 config, so I'm a little bemused by all the Perl scripts required!

DaVinci will probably not work on bare metal with AMD unless you do the mods I wrote about earlier In this thread. I've used those mods successfully on AMD X570, but not yet tested on the TRX40 platform.

Logic Pro X is no problem, and no problem with Final Cut Pro. I've tested both. Reaper is also functional.

Adobe doesn't play nicely with AMD, but I cannot comment as I refuse to pay Adobe a penny for rental fees. I stopped using after Mojave (I keep Mojave on Intel machines to use older Photoshop, which is 32-bit).

11 hours ago, meina222 said:

@iGPU - went over the full write up on your GitHub finally - great job 👍.

 

I noticed you wrote that BIOS could get corrupted. After all my travails the past 2 days I had reached the same conclusion so I re-flashed earlier today. Now I am wondering if I should re-test with emulated NVRAM to prevent NVRAM writes by OC and MacOS? Are OC NVRAM writes avoidable?

 

Another question - I had tried before my stability issues to dump the memmap file for the slide in the EFI via the console (on fs0: as per your instructions) but later on when OC would boot into MacOS that file would be gone from the EFI folder. I could only see it if I am in the openspell itself but then I did not know how to open an editor there. Anything I missed before I retry?

 

 

Edit: I am also finally catching up on the Proxmox old threads, as for me Proxmox runs rock solid. Wanted to find out what else can I improve i.e. extra USB 3.1 expansion, USB controller speeds etc. I noticed you had a Designare too and abandoned due to instability! Funny, but I am so tired of the quirks of this board that I am close to pulling the same trick, but I am eyeing the Asus Zenith II as there is a discounted open-box one in a store nearby. Trying to sort out with Gigabyte and their BIOS team, will give it 1-2 more weeks. Proxmox is rock solid as well as Ubuntu - the only reason I keep this board (and the free add-ons of course).

Thanks. (I re-wrote some of section 7 and 10 this morning, adding the NVRAM reset stuff --- very important as I found out again while attempting to do a fresh BS install under bare metal.)

As for the "fs0:" that may not actually be your boot EFI partition. Look at other EFI partitions on your setup. You'll probably find the memmap file located on another EFI partition.

I can't comment on the emulated NVRAM as I've not tried it on this build. I briefly used it on a Z390 Designare build and I wasn't convinced it was much better than doing nothing. The only time I think emulated NVRAM is to permit the system to boot. On some of the Z390 builds (like the ASRock Z390 ITX build I wrote on my thread here a while ago, emulation was critical for proper booting). I think OpenCore gets around this (somehow) whether you've got emulated NVRAM working or not.

Native NVRAM is theoretically the superior approach. I think it gets fouled up when we get crashes or when we attempt to boot between OS X  versions. I alluded to this above when I mentioned having to reset NVRAM while attempting to install BS bare metal yesterday. I finally got half way through the 2nd stage of install when it froze. I could not get it pass that point. And after trying to continue the install, I could not boot back into Catalina until I did an NVRAM reset. There were no BIOS problems, just corrupted NVRAM, but again, this was fixable with a reset. I don't know how any of this would have faired if I'd been using emulated NVRAM.

As for Proxmox, I've had my share of corruption of the entire macOS requiring me to re-install things. I've not written much about it, but when I've been silent here for several days it was due to those issues. (And yes, I gave up on GB TRX40 Designare; the MSI seems better, although I don't like its BIOS interface, preferring GB or ASUS.)

52 minutes ago, Ploddles said:

@iGPU please find attached requested IOReg file for the Gigabyte Xtreme motherboard. We also need a different network kext as we have dual intel 10GB chipset. The (modified)  kext is attached.

 

@Jaidy, sound for me is working. I have not tested the onboard headphone jacks etc as I use a Dell AC511 USB Soundbar (it matches my Dell monitors and is designed to clip onto one of them. You could try changing from alcid=1 to alcid=11 or alcid=16 in the boot-args of your config.plist file. My previous Gigabyte boards (Z370 Gaming Ultra, Z390 Designare and Z390 Master all worked with either 11 or 16.

 

As for your keyboard, have you tried going to System Preferences - Keyboard and clicking "Change Keyboard Type..." It should then get you to press a key or two to verify it. I don't use a trackpad so can suggest anything for that.

Gigabyte-Xtreme.zip 1.25 MB · 0 downloads SmallTreeIntel8259x.kext.zip 96.17 kB · 0 downloads

Ok, I've updated the EFI to add the kext and take into account your IORE. You need to do something different from the Designare mobo besides the kext file (which is off by default). In the ACPI section, you mostly want to use the MSI and not the SSDT for the Designare as that will cancel your BT. Instead use the sections shown below. The two new entries for the GB Xtreme are #24 and 25 (and correct to Xtreme rather than Extreme as in image below). I don't think you want to enable the SSDT-GFX's.

41 minutes ago, meina222 said:

 

@iGPU - it was with npci=0x2000 that I actually got the initial error.

 

I actually had missed the energy saver part, and now that you get my attention to it, I was playing with that part of the BIOS (ErP and wake on LAN) around the time my issues started happening, but I later reverted those changes and that didn't fix it.

 

At this point I am more worried about some hardware or NVRAM corruption on my end than actually getting the bare metal itself. However, I still think it is more likely to turn out that it is a subtle bug in the EFI. I will go over your guide and rebuild the EFI from scratch using the tools recommended (I do use OC configurator latest and I see you recommend doing more XML-native edit tools so I will do that too).

 

Thank you for the writeup.

Ah, I didn't know you were using OC Configurator. I don't use it (I only use to generate SMBIOS data). I had too many weird things happen in past and spent hours trouble shooting more than one corrupted config.plist file (you can find the problems, but you need to study the file in text mode which is laborious). 

The developers of OpenCore do NOT recommend using OC Configurator. Truly, the one I prefer is PlistEdit Pro. (Even Xcode can foul up the config file by substituting 'real' values for 'integer' values, leading to boot errors.)

I've uploaded more changes this morning to the EFI folder on GitHub with the latest OC commit. It boots just fine. After using it, do a re-set of your NVRAM. Also, remember you'll need to adjust the ACPI section as I've extensively renamed SSDT files to allow us all to use them, no matter the mobo manufacturer, in what I think is a more coherent fashion.

2 minutes ago, fabiosun said:

installed Catalina

but it is not that I need

so reverting to a clean copy of HS

 

as side note

I can't do a direct install of a new OS in bare metal

I have to use Proxmox

have you tried?

 

No, I've not tried. I have performed an update for Catalina and that went well. I'll attempt an install later on a spare drive.

1 hour ago, fabiosun said:

ok i figured out my problem

same refi same bios settings

Catalina is working perfect also with my patched Nvidia web driver

 

So I have to try a different way (maybe) in High Sierra

 

 

 

I'm happy to hear that you solved your problem. What exactly did you do to fix it?

fabiosun,

On bare metal, the CPU scores are the same as under Proxmox with Geekbench or Cinebench 20.

With Luxmark, the scores for Radeon VII are the same under bare metal and Promox (and only Luxmark uses both GPUs).

only with Cinebench 15 do I see a decrease of 50%. So maybe a problem with Cinebench 15?

2 hours ago, meina222 said:

@iGPU - tried the EFI you just checked in GitHub. Stuck on [ PCI configuration begin ].

 

 

Edit: Managed to boot after tweaking the boot args (no npci needed for me for some reason) and stripped various kexts

This weekend when working up a config.plist file to boot into Big Sur, I would see this if WEG is active. It is okay to leave WEG active, but add -wegbeta to boot arg.

I've stressed adding npc-0x2000 several times on this thread whether or not "Above 4G decoding" is enabled or not.

The kexts I've loaded with the EFI on GitHub should cause no problems.

Overall stability and random reboots will occur if Energy Saver is not disabled. I posted this earlier in this thread and on the GitHub site, Section 7.

GitHub post referral deleted

On 8/18/2020 at 8:01 AM, Ploddles said:

Yeah, finally got bare metal Catalina installed. 😀

 

Turns out that it didn’t like having 2 graphics cards in the machine during install - with just the one it flew along nicely. After the install I put the other one back in just to check but it didn’t miss a heart beat. The 2nd card was an Nvidia 1050, which I know can’t be used in Catalina but was installed for Proxmox when I was trying to get that to work and passing through the RX580.

 

i have the usual restart issue that everyone else seems to have,  but have now seen the other SSTDs that @iGPU has shared and also a new config file that works with Catalina and Big Sur. I will have a play with those later in the week. I did try an install of BS (with my Catalina config file) but that just hangs after the first reboot.

 

If anybody wants my IOReg file to look at to compare between different motherboards just let me know, I have the Gigabyte Xtreme.

 

There are a lot of files floating about in this thread and it can be hard to keep an eye on what is what and remember to update as things are discovered and files are modified. Would it be a good idea to have somewhere, maybe a sticky post or section in the downloads section, where new/updated files can be upload/downloaded to save everybody jumping  around looking for things and trying to remember what each one if for, eg common SSDTs for all boards and then those specific to MSI, Gigabyte etc etc? Just an idea but could be a pain to administer depending on how it is done.

 

Anyway, thanks for your help guys, glad to be finally up and running. Now to try the Adobe fixes later this evening.

I have not had issues with running 2 simultaneous GPUs (mine are the same in slots 1 & 3), but the only install I've done is from within Proxmox. I have updated Catalina in bare metal and it went better than an update from within Proxmox.

As for the SSDTs, I'll add a branch to my GitHub and keep updates there. I can make links back to this thread to avoid writing/repeating on GitHub. Give me a few days to get organized.

And as to your IORE, I'd like to see it. So far, much is the same since the TRX40 chip dictates what's in IORE than what the mobo manufacturer's do.

On 8/19/2020 at 5:39 AM, meina222 said:

I was aware of some of these - the question was why is emulated NVRAM not the same as native (presumably because emulated can only be written on logout/shutdown and be read on login but not in between?). Either way I didn't even get a chance to test native due to the instability. I was messing with trying to set slides, but the weird thing is that this should have not affected the rescue USB - something in the internal/persisted state of MacOS on disk made it unstable. Clearing NVRAM didn't help either.

 

5. SSDTs: removing un-used USB (specifically D0B8 and D1B8; attaching FixShutdown to all USB sites; checking RHUB devices

6. USBPorts to limit/inject properties

7. Removing unnecessary devices from USB ports

 

I was actually in the midst of trying these too! Removing XHC1 and XHC2 and making sure both XHC and XHCI were affected by the fixshutdown aml. Didn't get a chance to test due to sudden instability.

 

Unfortunately I haven't figured a way to be efficient while working on these due to relative inexperience.

Attached are 2 SSDT for cancelling what I've renamed to XHC1 and XHC2. They don't help, but I'm posting if you want to learn how to cancel devices. If you were to use, you want to remove the re-naming sections for XHC1 and XHC2 from the other SSDT file.

As for stability, I've left the computer running all day and night and it seems fine. I'll recheck today and if okay, provide a list of settings, but what I'd updated in the uploaded config.plist file that will boot into Catalina or BS has what seems to be stable settings; but I'll re-visit the settings later.

As for BIOS, I've left: ErP Ready, disabled; Above 4G decoding, disabled; and both IOMMU and SVM, enabled.

EDIT:

Above is obsolete: a proper MmioWhitelist is necessary for Shutdown (and being aware of attached USB devices which can force a re-boot). 

On 8/16/2020 at 8:38 PM, meina222 said:

I am confused by NVRAM and all the quirks. Why is it so important to have native NVRAM? Is there anything critical related to power management / sleep / shutdown which emulated NVRAM can't meet? I honestly would prefer emulated if the only thing it does is persist info between boots.

Here are some reasons native NVRAM is useful.

MacOS reads and writes data in NVRAM during many different phases of operation. Some of them are:

    When booting the computer, NVRAM identifies the Startup Disk.
    When rebooting or shutting down, information is written or updated in NVRAM.
    When there's a system crash, a background process stores kernel panic information into NVRAM.
    When you're running the macOS installer (which is not MacOS), it reads and writes information to NVRAM to select the right intermediate startup disks.
    FaceTime and Messages store various "keys" in NVRAM.
    Information about paired Bluetooth devices is also stored in NVRAM. This allows Apple Magic Mouse and Magic Keyboard to connect via Bluetooth before macOS is booted.
    And other little details are stored in NVRAM.

NVRAM is used by:

    Apple boot loader (boot.efi) -- this is not macOS, it's an EFI boot loader.
    macOS installer -- this is not part of main macOS
    macOS updater -- this is not part of main macOS
   

When we use emulate NVRAM, it stores NVRAM data in a file called nvram.plist in the EFI partition of the boot disk. But it requires OC to read/write that file. However:

    Apple boot loader cannot read/write that file
    macOS installer cannot read/write that file
    macOS update cannot read/write that file

So we don't get all the functionality of NVRAM with emulation. But with native NVRAM, all components of the system can access NVRAM.

23 hours ago, meina222 said:

@iGPU - I did the white list exercise last night. Haven't calculated my slide yet as it was getting late. It required only 4-5 reboots as I noticed the same pattern - bottom 2 addresses can left ON, then the next 2 fail so I have to leave them OFF, then once I hit the 5th to be ON, I enabled everything above it (as I think it only make sense to hit one continuous area where you gave to de-virtualize), and it booted with only the 2 ON, 2 OFF, everything else ON configuration.

 

I now have the same result as you - when I shutdown, I hear a click and the board tries to power cycle but then comes immediately back up. This is good news as this means all platforms share the same quirk. My addresses were of course different. Tonight I will try slides and test NVRAM.

I've spent more time working on the shutdown problem than it took me to get native NVRAM working...

I have tested various things I've found on-line that may contribute to the problem:

1. BIOS:  ErP Ready (enabled/disabled), Above 4G decoding, IOMMU and SVM (turning latter two off for bare metal).

2. macOS: removing Library/Preferences/PowerMangement*.*

3. Verifying that PowerManagement is working.

4. Testing various kexts (VirtualSMC, WEG, AppleALC); removing all un-necessary kexts

5. SSDTs: removing un-used USB (specifically D0B8 and D1B8; attaching FixShutdown to all USB sites; checking RHUB devices

6. USBPorts to limit/inject properties

7. Removing unnecessary devices from USB ports

8. Read about how some people have had this issue with AMD after moving from Clover to OC, so I tried to set up a Clover EFI (not yet successful)

9. Testing various settings within OC, such as Darkwake boot arg; DummyPowerManagement and other Quirks

None of these have worked. I'm wondering if #8 is the issue and it's an OpenCore matter. Or perhaps OC is correlated and not causative; that is, maybe we need another patch.

Any ideas on a kernel patch for shutdown?

5 hours ago, meina222 said:

@fabiosun - I think I am also close to giving up but not yet. I am still baffled by the restarts on shutdown and lack of sleep but I guess this is not uncommon for early hacks - all in all the fact that this is the only issue (and perhaps the seemingly worse power management) is not bad at all.

 

The issues I have with bare metal so far:

1. Shutdown problem

2. TB - no USB functionality

3. Questionable graphics (rumor; I've not fully checked out)

4. No SIP control with Big Sur (but same issue on VM, so not a bare metal problem)

I've got about 4 or 5 things to check out tonight/tomorrow for the shutdown issue. I think it's solvable. I'll certainly post here once I have more info.

As for sleep, fixing shutdown can help with that too. The way I deal with all Macs (hacks or not) is to completely turn off energy saver. I don't allow sleep, just let the monitor go to a screen saver. If I'm really worried about energy and I'm not using the machine, I simply turn it off. (How much more green by turning off can you get?) So for me, sleep  has always been a non-issue.

I'd like to see an automated approach to the data analysis; it should be easy to do for the slide calculation (in fact, I was wondering why during OC debug that it wasn't done already.)

On 8/16/2020 at 8:38 PM, meina222 said:

My smbios is iMacPro. The failed install earlier in the day was MacPro7,1 but the latter works great in a BigSur VM. My VMs are on a zfs pool though and I only had 1 NVME spare so can't try BS the way you did as no NVME has it. I will carbon copy clone it and retry later in the week.

 

I am confused by NVRAM and all the quirks. Why is it so important to have native NVRAM? Is there anything critical related to power management / sleep / shutdown which emulated NVRAM can't meet? I honestly would prefer emulated if the only thing it does is persist info between boots. And I would prefer not to mess with SIP. I have no special hardware beyond the patched CPU I'd like to run unlike @fabiosun .

 

The OC manual only briefly mentions csr-active-config without explaining what it is.

 

Gotta say I have some gaps in knowledge that make this TRX40 quite challenging. I imagine same is true for X299 but at least many more samples exist out there. 

On attempting to refine the config file, I found that WEG does prevent a boot into bare metal BS (but is okay for Catalina). If left enabled, then one must enter the boot-arg "-wegbeta".

Similarly, AMDRyzenCPUPowerManagement kext prevents a bare metal BS boot (but is okay for Catalina). Lilu, VirtualSMC, AppleALC, the ethernet kexts, the AirportBrcm kexts and NVMeFix are all okay, using latest versions.

booter-fileset-basesystem and booter-fileset-kernel are not required as shown below.

Most importantly, this config.plist file boots into both Catalina and Big Sur bare metal (one config to rule them all...).

Booter and Kernel Quirks:

NVRAM:

UEFI: