trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[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?

[Driftwood]

Ok, a couple problems @iGPU

 

I went thru the MMIO input into Bootloader one by one starting from the back. Everything looked good, and got to this result upto MMIOWhitelist child number 2, where it booted all good, tried shutdown (like the previous) and it was the first time I get the click, but it was quickly followed by a restart!

 

The result was it would no longer boot with 2 enabled or disabled and, with trying the last two, 0 and 1 Childs in any combination of Yes/No.

 

So Enabling (YES) 3792699392 MMIO devirt 0xE2100000 (0x181 pages, 0x8000000000000001) < This one enables SHutdown but it restarts straight away!

 

Following this 'restart' the external USB Catalina boot drive no longer worked - even after disabling rogue child 3.

 

Here's the result of the other Childs  before I got down to child number 2. SO even though I tried 0 and 1 Childs, it was an unfair test as child 2 probably corrupted something resulting in unable to reboot back into the Cat External SSD.

 

Thankfully I still have Proxmox m2 drive untouched!

 

Note that my only other 'No's were 15 & 16 : (rest up until 1, 0 were Yes including 2 which booted but after its shutdown/reboot now fails)

 

 

1099511627776  N 15 time 01:55

1650072748032 N 16 time 01.44

 

 

 

 

Edited August 27, 2020 by Driftwood

[Driftwood]

1 hour ago, iGPU said:

The EFI allows Shutdown (Restart was always working). Are you in Catalina or Big

 

Not for everybody! It only began to work when I got to child 2 of mmiowhitelist. Now I cant get back in to boot on my external SSD Cat install for testing no matter what.

Proxmox m2 all good to get me here, but Ive tried a NVRam Reset together with switching off (NO) on Childs 0, 1, and 2... up to last known good boot on that SSD external  Cat boot/EFI. Just balks now every time. SO some corruption has happened somewhere?

 

Here's the balked boot attempts they all look the same;-

Edited August 27, 2020 by Driftwood

[iGPU]

REMOVING THE SNAPSHOT PARTITION FROM BIG SUR

 

Now, the 'subsequent' post on removing Snapshots... what I'm about to post is based on the posts of fusion71au on the InsanelyMac forum here. I've adapted it for the limitations I've found in how Recovery behaves on the TRX40 builds, especially with regards to Big Sur.

 

There are 2 parts to this section, and so I'll divide into 2 posts. This post will deal with removing Snapshots, the other how to try to prevent a sealed Big Sur install. The 2nd part is here.

 

The key to getting this to work is disabling both csrutil and csrutil authenticated-root as discussed in my EFI post. In fusion71au's post, he recommends disabling these in Recovery. I could not get csrutil to persist being disabled after one re-boot (csrutil authenticated-root remained disabled after re-boot). Accordingly, I turned to using 77080000 for csr-active-config to keep these two disabled after disabling them in Big Sur Recovery (listed as 11.0). These same OC NVRAM settings are used for both booting into Big Sur as well as Recovery. (The boot arguments -no_compat_check and amfi_get_out_of_my_way=1 will be important for the 2nd part dealing with sealing.) To clarify, keep using 77080000 throughout and attempt to disable both csrutil and csrutil authenticated-root in Recovery, and then return to Recovery 11.0.

 

Once you've then re-booted back into Recovery 11.0, there are several steps required to remove the Snapshot partition(s). In order, type the following into Terminal. Note that when in Recovery, you are automatically the Administrator, so adding "sudo" is not needed for Recovery-based terminal commands.

 

1. Run: diskutil list  which will show sometime like the following. What you're after is the main Big Sur disk "BigSur" (not "BigSur - Data") and the <disk identifier> which here is "disk3s5". The Snapshot partition, here shown as "disk3s5s1", may or may not be visible at this stage.

 

2. Next, open a 2nd window in Terminal (so you can easily refer to the listing made in step 1) and type: diskutil mountDisk <disk identifier> (such as diskutil mountDisk disk3s5) You should get a response: "Volume(s) mounted successfully".

 

3. Then type: mount -uw /Volumes/BigSur    (<--- using your disk name without a trailing "/" symbol) You'll get no response unless there's an error.

 

4. Now type: /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs_systemsnapshot -v /Volumes/BigSur -r ""   (<--- again, use your disk name; the final characters are 2 double-quote marks)

    You'll get a response such as "Attempting tagging of snapshot on volume: /Volumes/BigSur

 

5. Next, type: diskutil apfs listSnapshots /Volume/BigSur

    You'll get a response shown below; what we're interested in is the <uuid of snapshot> highlighted in the red box:

 

6. Then type: diskutil apfs deleteSnapshot disk3s5 -uuid 3F27525D-9224-4FBA-9411-EF20292CB299   (repeat this for each snapshot seen on that disk; remember that you can copy and paste inside terminal, making it easy to enter the uuid)

 

7. Optionally, verify that you've removed all of the Snapshots from your Big Sur disk by typing: diskutil apfs listSnapshots /Volume/BigSur 

    You should get a response "No Snapshots for disk" if all were deleted; otherwise, you'll see something like the image in step 5 again.

 

8. Once you've deleted all of the partitions, re-boot into Big Sur desktop and run the following in Terminal (now you need to use "sudo"):

    a. sudo mount -uw /     (this should return no errors)

    b. diskutil info /            (this should return something like "disk3s5" and not return a Snapshot partition like "disk3s5s1")

 

At this point you can change files and folders for which you've previously had no access. For example, I copied a file from the desktop that contained the description for the AMD processor used in the window "About Mac" from a file that I'd altered from a similar folder in Catalina, using the command:

           sudo cp /Users/<username>/Desktop/AppleSystemInfo.strings /System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/Resources/en.lproj/AppleSystemInfo.strings

 

Normally, you'd have no access to this folder as it is read-only. However, since we removed the Snapshot and gained access to read-write, I could make this change to the "About Mac" window as shown below. (And while this isn't profound, it does show you how you can get access to files and folders that are otherwise off-limits in Big Sur.)

 

 

 

 

 

 

Edited August 28, 2020 by iGPU

[Driftwood]

@iGPUWhat about balked Cat disks?!

[iGPU]

3 hours ago, Driftwood said:

Ok, a couple problems @iGPU

 

I went thru the MMIO input into Bootloader one by one starting from the back. Everything looked good, and got to this result upto MMIOWhitelist child number 2, where it booted all good, tried shutdown (like the previous) and it was the first time I get the click, but it was quickly followed by a restart!

 

The result was it would no longer boot with 2 enabled or disabled and, with trying the last two, 0 and 1 Childs in any combination of Yes/No.

 

So Enabling (YES) 3792699392 MMIO devirt 0xE2100000 (0x181 pages, 0x8000000000000001) < This one enables SHutdown but it restarts straight away!

 

Following this 'restart' the external USB Catalina boot drive no longer worked - even after disabling rogue child 3.

 

Here's the result of the other Childs  before I got down to child number 2. SO even though I tried 0 and 1 Childs, it was an unfair test as child 2 probably corrupted something resulting in unable to reboot back into the Cat External SSD.

 

Thankfully I still have Proxmox m2 drive untouched!

 

Note that my only other 'No's were 15 & 16 : (rest up until 1, 0 were Yes including 2 which booted but after its shutdown/reboot now fails)

 

 

1099511627776  N 15 time 01:55

1650072748032 N 16 time 01.44

 

 

 

 

 

First, I just re-tested the EFI I uploaded, leaving it exactly the same with no entry for MmioWhitelist, and it booted into Catalina without any problem.

 

Second, in your first post here, you mentioned things were working well with the EFI. What exactly did you change from that point where it was working, to the point when it did not? (No matter what, not booting doesn't mean the drive's contents are affected.) And what you've shown does not indicate a problem with BIOS.

 

Where it stops suggests some change in settings, particularly with one of the Quirk settings. Did you change any of those or anything else?

 

To try and get you "re-set", I included 2 extra config.plist files in the EFI folder as an internal backup. First re-name your current config.plist file to save your MmioWhitelist work. This way you can access that list later. Then, duplicate the extra named "config-basic-genPI.plist", then rename this duplicate "config.plist". This new config file should boot as it re-sets things to what I originally uploaded.

 

As for the MmioWhitelist, since few of us have the exactly the same mobo with the same components, no one can work up an MmioWhitelist for anyone else. Each person has to do it on their own, but only if you want native NVRAM. If you don't want to go the MmioWhitelist route, leave the MmioWhitelist array empty and setup an NVRAM plist by reading the OC Docs. 

 

Assuming you ran the MmioWhitelist test correctly, and you wish to try it once more, I would suggest that you set all entries in the list you displayed to 'Yes', except set 15, 16 and 17, setting those to 'No'.

 

*****

 

And here I would remind anyone else that one always should have an alternative method of booting into a drive (even running a VM). With bare metal, at the very least, you want to have a USB thumb drive with a known, good EFI for access to your drives. Personally, I have 2 NVMe drives (1 Catalina, 1 BS), 1 SATA with Catalina and an external USB with BS. Each can have a unique EFI, but one has an older, working EFI so that there is always bootable access. The known, working EFI is how I tested the MmWhitelist. When a boot failed, I simply forced a shutdown and re-booted using the alternative EFI. Furthermore, the external drive can be connected to my laptop to work on a problematic EFI separate from the Hackintosh.

[meina222]

@Driftwood - what you described above pretty much happened to me too a week ago (on an older OC EFI based on @iGPU's original post). I went from bottom to top, 1st 2 were enabled and booted fine, then next 2 I had to disable, then managed to enable all the rest. At this point I could get the click on shutdown and subsequent reboot (no click before, just silent reboot) but then my rescue USB and no other EFI worked after a while - can't remember anymore if it was immediate. I ended up flashing BIOS which was probably unnecessary.

Edited August 27, 2020 by meina222

[fabiosun]

 

I would like to suggest during testing MMIO stuff to leave verbose boot on to see verbose data during reboot (often during reboot there is a fast KP, you can solve with proper quirks and MMIO skipped)

 

[fabiosun]

I still don't know how ... more or less ... but I managed to activate the driver again

.... hurray..

the hard head always rewards if it also joins a good blow of .... ass

(colorful way to say that I was lucky)

 

[Driftwood]

5 hours ago, iGPU said:

First, I just re-tested the EFI I uploaded, leaving it exactly the same with no entry for MmioWhitelist, and it booted into Catalina without any problem.

 

Second, in your first post here, you mentioned things were working well with the EFI. What exactly did you change from that point where it was working, to the point when it did not? (No matter what, not booting doesn't mean the drive's contents are affected.) And what you've shown does not indicate a problem with BIOS.

 

Yes, the untouched EFI is fine but it won't work after a mmiowhitelist failure! Things went wrong during the mmiowhitelist discovery session. I couldn't shutdown previously and when I got to child 3 (working backwards from child 18) I first encountered the successful shutdown 'click' ( it never happened on the previous test boots).

 

However, the shutdown didn't shutdown, it immediately restarted after the click. Subsequently, no further boots with this, a non edited mmiowhitelist EFI or any previous now work. 

 

My only way in to MAc is thru Proxmox and my untouched M2 catalina  work drive. 

 

So everything was hunky dory until enabling child 3. 

 

Hope u understand this now. Can't be any clearer!

 

PS As to EFI backups, yes I have three bootable EFIs on three different usb sticks  - none now work after child 3 was enabled in the mmiowhitelist test. 

 

i'll upload my config.plist so you see how for yourself how far I got. BTW Where u had three failures at around child 14,15,16 to or thereabouts whereas I only had two. Differences between mobos need to be understood and I'm working at fixing this. 

 

@meina222 it shouldn't need to be reflashed! Proxmox is fine. Tried (for the first time in this test) a nvram reset. Did not fix. So I'm assuming that my EFI boot partition is locked out by a CRS secure. Or it's corrupted. I'll rebuild it.  🙂

Edited August 27, 2020 by Driftwood
corrections and spellings

[fabiosun]

Ah..as other infos I would like to share in a very happy way....

Sleep is working 🙂 🙂 🙂 🙂

 

 

 

[Driftwood]

3 hours ago, fabiosun said:

I would like to suggest during testing MMIO stuff to leave verbose boot

I think we all do with iGPUs EFI!

[Driftwood]

Failed EFI boot

 

Recovery method 1: take out everything in mmiowhitelist (blank with no entries)

 

Didn't work produced following graphic

 

 

Edited August 27, 2020 by Driftwood

[meina222]

@Driftwood’s experience is similar to mine even though I didn’t document it so well - basically I went to Proxmox full time after this as I couldn’t find a single working EFI. My only explanation at the time was corrupt nvram or something in the OS data disk. The only difference is that I could occasionally boot but would invariably suffer restarts. Even the reinstall process would fail with random restarts.

Edited August 27, 2020 by meina222

[fabiosun]

@meina222may I have your fully working EFI in proxmox and your mmio plist (bare metal I mean)?

if you want loose some time again with bare metal I will prepare an EFI for your system

I would also suggest an important thing to consider

Proxmox threats ddr4 in its way

so maybe a more conservative memory settings in bare metal could help if system acts weird

[Driftwood]

Anyone know what causes a lilu refusal?

[fabiosun]

Seems old problem with prelinled kernel and big sur

[meina222]

@fabiosun - I will retry the whole process tomorrow or Saturday. Busy work schedule till then. I will share my experience and EFI - will start fresh with a re-install using @iGPU's EFI.

 

I run my memory only at 3200mhz and infinity fabric 1600 even though it is rated 3600. I can hit 3600 at rated XMP, but either due to size (256GB) or motherboard it requires high voltage - 1.45V and I found that CPU throttles more quickly. I doubt it's the memory since I didn't touch the settings when things went wrong. It did cross my mind and I verified the same behavior under default 2667 - same problem.

 

Also I use now a Gigabyte beta BIOS f4j. I have been in a long discussion with them regarding how to make TB work in Slot 4. They keep sending me beta BIOS-es that don't fix anything but these latest ones shifted all my PCI id's in Proxmox by +20, and has a bit of a different structure,  and I suspect MMIO would change too.

Edited August 27, 2020 by meina222

[fabiosun]

I would try to start from your Proxmox EFi also in Baremetal

Adding full set of AMD patches and nulling all ssdt you are using in proxmox

Then Devirtualize MMIO on

this should be the starting point for all people who have a working Proxmox EFI

 

You (AMD GPU user) should have less problem than I have had because AMD driver is in OSX

 

Evaluate also well, how in your system act some quirk (booter quirk) relative to memory remapping...

For me this was the key

MMIO whitelisting is useful for debugging restart and shutdown problem you can have

This, without using any ssdt only enabling blacklisted MMIO

MSI users should not need of npci 0x2000 boot arg, also with 4g disabled in Bios

 

I have the same bios setting I use to boot in Proxmox 

Now I will test more extensively the apps I usually use, but as first impressions they acts in the same way

 

[Driftwood]

This is where I got to for Asrock board owners! MMIO whitelist Child 2 is a problem child!!!!

[fabiosun]

sorry @Driftwoodthese are yours?

 

could you put a fresh open core log if your bare metal rig boots?

[Driftwood]

Just now, fabiosun said:

ould you put a fresh open core log if your bare metal rig boots?

@fabiosun Sorry, remember Im currently locked out! Trying to recover the EFI partition of my USB SSD Catalina drive Im using for this test. Im currently typing from Proxmox Cat m2 drive!

[fabiosun]

if I remember well maybe you posted something here...

 

[Driftwood]

53 minutes ago, fabiosun said:

s old problem with prelinled

Not attempting Big Sur atm. All my testing is on Cat usb SSD external

 

4 minutes ago, fabiosun said:

if I remember well maybe you posted something here...

 

Yes but it was unfinished. Can't post an unfinished OC txt  yet sorry. It's broke. 

Edited August 27, 2020 by Driftwood

[fabiosun]

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