trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[iGPU]

At the bottom of the MMIO debug section, it said:

 

18:289 00:002 OCABC: Only 128/256 slide values are usable!

18:291 00:002 OCABC: Valid slides - 128-255

 

So maybe a slide value needs to be entered? I'll give that a try too.

 

EDIT:

SLIDE IS NOT NEEDED.

 

***

 

I'll try combining that with a SSDT-NVRAM. I'll upload so that you all can try too. In the Docs section, there is an SSDT-NVRAM that is used to attach PMCR to LPCB (so that it is activated before PCI devices). But in our TRX40s, LPCB does not exist. It was, as described, an arbitrary attachment site. I decided to use MCHC, since it has a similar structure in IORE (based on my studying earlier today an Intel Z390 Designare). MCHC is created in the SSDT-EC-USBX-v2 that I uploaded earlieir, and accordingly, SSDT-NVRAM must come after as follows:

 

 

The binding looks like this in IORE:

 

 

 

 

 

Edited September 7, 2020 by iGPU

[iGPU]

Until we get system shutdown working, using the ResetSystem.efi works:

 

 

It creates an Auxillary shutdown button:

 

So when macOS is shutdown, the computer starts up again, I press the space bar to reveal "Shutdown" and this turns the computer off. (BTW, those buttons are not stock but were present in the EFI I uploaded earlier in this thread.)

[fabiosun]

Uhm... my system shutdown normally

only in reboot I can see (maybe) a kp but I am not sure because it has no consequences at all

Whitelisting is useful togheter the research of a proper slide value for owned system

it is possible to calculate your exact memmap and the use a slide value

not tested for now because in my bare metal main problem is sip 

[iGPU]

Yeehaw!  I got NVRAM working (again, I do not know if the values below are CPU or mobo dependent; but worth a try).

 

Test in Terminal:

a) enter: sudo nvram myvar=test

b) verify: nvram -p | grep -I myvar

c) reboot

d) run nvram -p | grep -I myvar   (if you only run "nvram -p" you'll see all stored values)

e) clear test: sudo nvram -d myvar

 

 

Use the following settings in OpenCore:

1. Slide =not needed

2. The MmioWhitelist value (its derivative in complicated; better described in future post here).

3. DevirtualiseMmio enabled

4. SSDT-NVRAM

 

EDIT:  we now know that proper Shutdown requires a proper MmioWhitelist for you mobo, see above link for MmioWhitelist.

 

 

 

Edited September 18, 2020 by iGPU
Improved methodology; see link in text.

[fabiosun]

Mmmmh interesting..but slide value maybe differs from different pc configuration 

how do you have calculated this value for your pc?

have you have done memmap calculation procedure?

[iGPU]

On 8/15/2020 at 11:36 PM, fabiosun said:

Mmmmh interesting..but slide value maybe differs from different pc configuration 

how do you have calculated this value for your pc?

have you have done memmap calculation procedure?

 

I based on what I reported above. The value range came from OC's debug report associated with MmioWhitelist. I simply tried the first one, 128 and it worked.

 

EDIT: a Slide is not needed.

Edited September 18, 2020 by iGPU

[meina222]

I booted OK w slide=128 and your NVRAM ssd and new EC. I have not entered whitelist (without it nvram doesn't work still). I wonder if this whitelist is motherboard dependent.

[fabiosun]

Just now, meina222 said:

I booted OK w slide=128 and your NVRAM ssd and new EC. I have not entered whitelist (without it nvram doesn't work still). I wonder if this whitelist is motherboard dependent.

I have said above

memmap is the way

and it could be different also in an exact same rig

[meina222]

@iGPU  - what is the last stable OC version for which to get debug?

[fabiosun]

When you have time try to boot in recovery and from terminal try

csrutil status

and see the output

also try to change sip status and see

this could be a big problem if you have to install some kext for not supported device by OS X 

[meina222]

Is this why my USBPorts kext I worked so hard yesterday on to learn and figure how to trim my ports, now seems to be not applied anymore? I think after 20 reboots trying different boot args I messed something up.

[meina222]

@iGPU - does shutdown work for you now?

[iGPU]

35 minutes ago, meina222 said:

@iGPU  - what is the last stable OC version for which to get debug?

 

Any from v059 will do (I think v060-final is about the best). Most data is written while booting and so even if it doesn't fully boot, you'll get this data.

 

***

 

Well, shutdown almost works. Before activating NVRAM, computer would effectively do a re-start. Now, the switches click off but then immediately it powers back on and boots (panic reboot). At this point, the panic reboot could be triggered by USB devices connected to the computer. I'll need to test some more tomorrow.

Edited August 16, 2020 by iGPU

[meina222]

Ok. I give up for the time being. I think I'm glazing over all this custom slide, custom SSDT stuff without really understanding what the differences are from board to board. I think I pretty much have the same problem as you, but it's unclear if these whitelist magic addresses will be applicable without me trying to find them myself. Is there a link where this method of finding out which values are enabled and which not, is explained? Do you mind posting a bit more on that tomorrow? Much appreciated.

 

good night, everyone.

 

p.s. I think I was able to answer my own question:

 

https://dortania.github.io/OpenCore-Install-Guide/extras/kaslr-fix.html#finding-the-slide-value

 

Will go over with a clear head and also try Big Sur.

Edited August 16, 2020 by meina222

[fabiosun]

try to read from here

these were all the steps I did (with the help of vit9696 and downloadfritz (criptic help to be honest : ) to have their statement about vanilla AMD Patches on march:

https://www.insanelymac.com/forum/topic/338516-opencore-discussion/?do=findComment&comment=2710959

you can find some useful step to debug MMIO stuff

useful for our actual problem/goal? I do not know 🙂

 

[fabiosun]

16 hours ago, iGPU said:

Has anyone been able to boot bare metal into Big Sur?

with my previous installation done yes

now I have deleted that disk and try to reinstall I can't see macOS installer icon in boot menu (after first installation part went fine)

 

[iGPU]

On 8/16/2020 at 12:34 AM, meina222 said:

Ok. I give up for the time being. I think I'm glazing over all this custom slide, custom SSDT stuff without really understanding what the differences are from board to board. I think I pretty much have the same problem as you, but it's unclear if these whitelist magic addresses will be applicable without me trying to find them myself. Is there a link where this method of finding out which values are enabled and which not, is explained? Do you mind posting a bit more on that tomorrow? Much appreciated.

 

I'll lay out the steps I went through to derive the MmioWhitelist. But first I want to say that aside from the slide value of 128, I'd tried various OC combinations to obtain native NVRAM including using the new SSDT-NVRAM. None worked. Only when combining the Quirks reported above and MmioWhitelist and using the SSDT-TRX40-NVRAM did native NVRAM work on bare metal.

 

Steps for deriving MmioWhitelist (make certain that you have an alternative bootable EFI, as you'll see below):

 

 

A. MmioWhitelist Determination

 

EDIT: Updated from future link at step 4. Initial steps for creating the debug file are still accurate.

 

1. Run OC debug version (≥ v059; even if you can't fully boot into macOS, you'll have sufficient data written out on the next boot with a non-debug, working version).

   

 a. debug OC settings (spoiler):

Spoiler

 

 

b. after running OC-debug, you'll see following on the EFI boot partition; choose one to open (spoiler):

Spoiler

 

 

2. Edit debug text. Once the above text file is open and search for MMIO (spoiler; press press <Cmd><f>, enter "MMIO", then repeatedly press <Cmd><g> until you see list below).

      a. note the MMIO value range and the permissible Slide value range:

Spoiler

 

  b. the 0xYYYYYYYYYY values are copied one-by-one into a calculator (I use the calculator in Hackintool):

Spoiler

 

3.After converting each of the MMIO hex values into decimals, enter those values (and any optional comments) into Booter/MmioWhilelist (spoiler). Initially, leave all entries disabled (no):

Spoiler

 

 

4. Back-to-the-future: we now know a simpler way to create an MmioWhitelist for your mobo. See this  to create that list. A proper MmioWhitelist is needed for proper Shutdown functionality as well as native NVRAM.

 

 

 

B. Slide Calculation (left as an FYI reference, but not seemingly needed, so don't waste your time with it)

 

    1. memmap calculations

       a. to run memmap, you need to have  OpenShell enabled in OpenCore:

Spoiler

 

      b. boot into OC menu system and select "Open Shell" (or however you named it above).

         you'll then see "shell> ", type "fs0:" then type "ls" and see if you see the EFI folder. Is so, then type: "meemap > meemap.txt"

             fs0:\> meemap > meemap.txt

             fs0:\> exit

 

     c. after typing exit above, you'll return to the main OC menu and boot normally into macOS

 

     d. open the EFI partition (if you have more than one, it may not be on the boot EFI, so look around at other drives)

 

     e. locate the file mammal.txt and copy to desktop. once this file is open, you'll see something like this (here, only top portion of the large file):

Spoiler

 

     f. OC guides say to start at bottom of list (Start column only). if you do, you'll calculate a slide value something like 2047; some such nonsense.

             instead start near top and find the largest value that is ≤ 255. The optimum is highlighted by red box above. the value immediately below

             calculates to a slide of 1018, which is also nonsense. The one in the red box will calculate to 127 as shown next, so this is the largest value

             that is ≤ 255.

 

    g. calculations are done in 2 basic steps using the macOS calculator ( type <cmd> <3> to select the Programmer mode):

            i. the value from above red box is 000000001000B000 which is 0x1000B000 in hex. we'll do all math in hex.

                   next, subtract and divide this value as follows (copy and paste from here; the trailing zeros are important):

                   ( 0x1000B000 - 0x100000 ) / 0x200000 = 0xFF0B000 / 0x200000 = 0x7F       ( 0x7F = 127 in decimal )

 

Spoiler

         

        ii. the 2nd step is verifying above result to see if the decimal value of 1 needs to be added. verification means

                 taking the above answer, 0x7F and reversing the calculation to see if we get the original hex value. If we do,

                 then 0x7F is our final answer (and slide is the decimal value of this, or 127). If it calculates to a different value,

                 then we must add the decimal value of 1 to 127, which means the true slide value is 128.

 

                 Reversing the equation:

                  ( 0x7F x 0x200000 ) + 0x100000 = 0xFE00000 + 0x100000 = 0xFF

 

                  since 0xFF ≠ 0x7F, the actual slide value is 127 + 1 = 128

 

  2. Using the Slide calculation result

       the result of step 1-g-ii above is your slide value to be entered into the boot arg section as shown in the spoiler below.

       the ProvideMaxSlide value's default is 0, which means that OC will accept a boot arg slide value ranging from 0 to 254.

       any value other than 0 will be the maximum value of a slide boot argument; best to leave as default 0.

 

       (And oddly enough, this is the same value I'd chosen from above MmioWhiltelist section of 128.)

 

Spoiler

 

 

Edited September 7, 2020 by iGPU
improved MmioWhitelist creation; link added

[meina222]

Tried to install Big Sur public beta today on the bare metal. It boots, starts the installer and 2 min into it it panics. If I try to select MacOS installer on subsequent boots I see another panic after a short while. I could see with one of my efis a halt with memory panic stackshot succeeded, but lost that setting since and I just get reboots now after briefly seeing the log (but not for long enough to be able to read it). Same EFI installs Catalina fine.

[meina222]

@iGPU, thank you for the detailed guide. May I ask - did you try to emulate NVRAM? I see this is an option from the past for X299 boards. Aside from not being able to see the nvram output from console and having to use logout hooks, I would think this is a safer and more robust option. My real concern with the white list and slide is that this is very opaque and poorly understood by me, and might be too sensitive to future hardware reconfigurations or bios updates.

 

After the failure of Big Sur beta installer, I am thinking that I should probably stick with Proxmox for a more "production like" environment and play with Catalina bare metal to just have something to learn configuring a bare metal hack on.

 

Edit:

I tried to add emulated NVRAM following the OC guide. That didn't go well. My hack now hangs on shutdown or restart so I have to manully power cycle the PC to reboot. I also see duplicated boot entries in my BIOS. I did see the nvram.plist created in the EFI. The opposite of what I expected - intsead of it being safer it now seems it's messing up BIOS

 

Edit2: 

Clearing NVRAM fixed BIOS boot options. I guess the BIOS is using the NVRAM to store those settings. But why is emulated NVRAM not working? It is persisted, but shutdown or restart attempt now hang Catalina - it starts to shutdown and freezes with the desktop background cleared of everything. USB/GPU/power issue?

 

Edit3:

Going thru the OC guide section 'Fixing Shutdown/Restart'. Something is off and this time I don't think it's NVRAM (emulated).

Edited August 16, 2020 by meina222

[iGPU]

On 8/16/2020 at 10:59 AM, meina222 said:

@iGPU, thank you for the detailed guide. May I ask - did you try to emulate NVRAM? I see this is an option from the past for X299 boards. Aside from not being able to see the nvram output from console and having to use logout hooks, I would think this is a safer and more robust option. My real concern with the white list and slide is that this is very opaque and poorly understood by me, and might be too sensitive to future hardware reconfigurations or bios updates.

 

After the failure of Big Sur beta installer, I am thinking that I should probably stick with Proxmox for a more "production like" environment and play with Catalina bare metal to just have something to learn configuring a bare metal hack on.

 

I've just finished extensive re-editing of my previous post. A notable error was fixed (Booter/Quirks/ProvideMaxSlide should remain at "0") and the slide value placed in boot arg section.

 

EDIT: slide not needed.

 

Edited September 18, 2020 by iGPU
Obsolete. Slide not needed.

[iGPU]

2 hours ago, meina222 said:

@iGPU, thank you for the detailed guide.

 

Edit:

I tried to add emulated NVRAM following the OC guide. That didn't go well. My hack now hangs on shutdown or restart so I have to manully power cycle the PC to reboot. I also see duplicated boot entries in my BIOS. I did see the nvram.plist created in the EFI. The opposite of what I expected - intsead of it being safer it now seems it's messing up BIOS

 

Those very duplicate boot entries is why OpenCore has this (red box) to eliminate those duplicate entries. It sounds like you should enable this Quirk.

 

[meina222]

Thank you! Will enable the quirk.  Seems already enabled, so not sure what to do.

 

So emulated NVRAM works but shutdown fails miserably. I think this is due to my USB/onboard devices, but now I don't even get restart. So I am trying to see if the FixShutdown-USB-SSDT from OC guide will make a difference. I did a clean install after the BS failure so I haven't reapplied your USB SSDTs yet. What do you think the FixShutdown-USB-SSDT should look like for our boards?

 

https://github.com/khronokernel/Opencore-Vanilla-Desktop-Guide/blob/master/extra-files/FixShutdown-USB-SSDT.dsl

 

I will definitely try to fix native NVRAM. Emulated seems easier goal for less experienced user like me (this is my 1st Hackintosh project and TRX40 seems far from beginner platform). My concern now is that even if I fix native, I'd still see these reboot freezes - I saw them when I enabled ProtectUefiServices last night.

Edited August 16, 2020 by meina222

[iGPU]

13 minutes ago, meina222 said:

Thank you! Will enable the quirk. So emulated NVRAM works but shutdown fails miserably. I think this is due to my USB/onboard devices, but now I don't even get restart. So I am trying to see if the FixShutdown-USB-SSDT from OC guide will make a difference. I did a clean install after the BS failure so I haven't reapplied your USB SSDTs yet. What do you think the FixShutdown-USB-SSDT should look like for our boards?

 

https://github.com/khronokernel/Opencore-Vanilla-Desktop-Guide/blob/master/extra-files/FixShutdown-USB-SSDT.dsl

 

I will definitely try to fix native NVRAM. Emulated seems easier goal for less experienced user like me (this is my 1st Hackintosh project and TRX40 seems far from beginner platform). My concern now is that even if I fix native, I'd still see these reboot freezes - I saw them when I enabled ProtectUefiServices last night.

 

Yes, this is the next SSDT I was going to work on. It must be paired with a patch. The problem was attaching it to a USB device. Through yesterday, I was still sorting out USB devices with custom SSDT files. I'll work on it shortly.

 

All ports are now accounted for and re-named. (I can provide custom SSDTs if anyone wants. I just need more recent IORE file to study).

 

 

***

 

As far as USB go, I seem to recall one of your posts indicating that you'd created a USB-Ports kext to limit USB ports. In my exposure to AMD platforms, I've not yet seen a USB device that has more than 10 USB connections. The 15 USB macOS limit is per device not per machine. So I've seen no need to create any USB limits for AMD to date. (Intel is different, they have sometime 20 USB connections on one device.)

 

 

Edited August 16, 2020 by iGPU

[meina222]

Yes! I did realize that I don't need the 15 limit. But I really wanted to work with a smaller set so I can more easily narrow down problematic devices - as in try to get shutdown/reboot work if less devices attached. But now that I realize this powering down issue maybe not due to the leaf device but the controller itself, I am less concerned. Let me reapply your renames and my own SSDTs (I wanted to disable my ZFS nvme's and I managed to do that yay) and will re-share ioreg.

[iGPU]

As for SSDT-Shutdown, I've already confirmed that the patch (below) has indeed a _PTS function inside our DSDT file (bottom). So the call should work.

 

Next step is finding attachment site for the SSDT call. The original site is "_SB.PCI0.XHC_.PMEE" which doesn't exist on our mobo. I have created an XHC, but I think wrong site for attachment. I originally tried the USB site at D0B8 and the computer would not boot.

 

Again, the patch is enabled along with the SSDT-Shutdown file; neither by itself will work.

 

 

 

 

 

Edited September 7, 2020 by iGPU
Obsolete.