meina222
-
Posts
449 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Events
Downloads
Everything posted by meina222
-
@iGPU - I continue to have reboot issues even from the 'safe' EFI I used initially. I am completely baffled. My only explanation is that the board NVRAM is corrupt. Does the clear CMOS button clear NVRAM too or do I need to short the pins on the board? "Safe EFI" - will reach the point where OC would hand off to MacOS, I would get a black screen but instead of the login screen or apple logo I just get a reboot at this point. "Last EFI" - I can login into MacOS or start recovery but not even 2 minutes I get a reboot. Next I will try your GitHub EFI.
-
@Rocket88 - no-one has succeeded installing Big Sur directly yet on bare metal. @iGPU managed to boot into Big Sur bare metal from a preinstalled Proxmox instance using the bare metal EFI. Don't try to upgrade direct, you will likely corrupt your OS image.
-
For everyone else recently posting - bear in mind that the bare metal is still not 100% stable. My installation suffered falling into an inexplicable state where the initial EFI (which I used as a rescue reference) and on-disk EFI became severely unstable - random reboots or even failure to load. Something in the OS main disk state changed. Haven't had time to debug - I think I will do a clean reinstall, but I would not trust the bare metal for a production environment (even though so far I am the only one with this issue). On the other hand Proxmox is 100% solid. Also, I am yet to see any performance benefit other than a 3% edge in Geekbench multicore, but 5% lower single core for that matter (I don't trust at Geekbench as the best app to measure with). I just ran a Cinebench out of my Proxmox - matched bare metal with a score 21468. Anecdotally, Proxmox is also more stable with apps. If you do a TRX40 hack, I would definitely keep Proxmox as a production base and bare metal as experimental until the community (and @iGPU as an active member) figure how to make it a bit less cumbersome and maybe stable.
- 3,970 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
CSM and 4G decoding need to be off for me. Virtualization can be ON according to @iGPU XMP 1 profile is not necessarily a good thing. On the 3990X XMP1 performs worse on Cinebench compared to manual 3200mhz with and IF 1600mhz by about 4% on my rig. but Geekbench multi-core is higher in XMP1. I think CB is a better real world benchmark - the extra IF can produce a lot of heat in Threadrippers even with water cooling.
-
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.
-
Tonight the bare metal hack started experiencing extreme instability where even my rescue USB would immediately reboot after a black screen when the GPU driver is supposed to load while my NVME would boot, stay fine for 2-3 min and then suddenly reboot without me doing much. What could be the cause? Corrupt NVRAM or mis-calculated slide? Why would the rescue USB fail so bad?
-
@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.
- 3,970 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
@fabiosun - I got my flash rom device today from Amazon. Which romfile do you use for Titan Ridge and how can I get it? Thanks.
-
@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. I will definitely go through @iGPU's exercise. I feel like I want to script this so you can avoid all the manual steps - just auto parse the OC debug output from 1 run and generate X pre-calculated configs that you can then just drop and re-try. I'll see what I can do - it'd be fun exercise. To me the biggest draw of Proxmox is the isolation layer it provides and the ease of back ups / replication / reinstalls - no worries if I brick my VM with an update, and much less likelihood of a break. That paired with superior power management in the newest Linux kernel, makes it quite compelling. Due to the AMD reset bug I am now forced to emulate a bare metal workstation - host shutdown on macOS shutdown via hook, but when the reset bug is finally solved with new hardware this will be close to perfect setup minus the TB and less physical ports. Btw Linux kernel / Proxmox 5.8.1 is out. This is labeled as 'stable' by the Linux community - suitable for production use. Fabian has a release already in 2 flavors (reset and no reset, but this does not affect our OS).
- 3,970 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
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.
- 3,970 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
BigSur didn't work for me - tried to adapt your config plist and got a message that my platform is not supported by MacOS. Anything special about your boot args that would trigger this? I should clarify - I tried to install it again. The idea of bypassing the installer via the VM is an great one! Thanks - your latest SSDTs split my controllers. I now need to set correct capabilities.
-
For me an EFI that installed Catalina booted but failed during Big Sur installation. Let me try your config. I wouldn't think the whitelist/nvram would be critical for that so I will remove for now. My USB mappings don't seem to work in Catalina. I've attached my IOReg, but so frustrated I think I will just backup my EFI and try BigSur again clean. p.s. to be precise the file that defines XHC and XCHI works and disables my AX200 after I delete port5. The other XHCx rename file - I don't think it works so I disabled it. p.s. 2 - studying your efi shows you use more renames. Let me try with just basics on the install. Will worry about those later.
-
I applied the files. Attached is my IO reg. Do you see anything regarding your FixShutdown SSDT? Also don't we need to do this for every controller? XHC, XHCI etc. ? Also my USB reporting doesn't look quite right - Hackintool sees 2 XHC0 controllers TRX40Designare.zip
-
I need to install snagit or something. Sorry for the bad resolution. Mine are there but look a bit more involved
-
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.
-
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.
-
@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).
-
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.
-
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.
-
@iGPU - does shutdown work for you now?
-
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.
-
@iGPU - what is the last stable OC version for which to get debug?
-
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.
-
MmioWhitelist Properties 1. Address Type: plist integer Failsafe: 0 Description: Exceptional MMIO address, which memory descriptor should be left virtualised (unchanged) by DevirtualiseMmio. This means that the firmware will be able to directly communicate with this memory region during operating system functioning, because the region this value is in will be assigned a virtual address. The addresses written here must be part of the memory map, have EfiMemoryMappedIO type and EFI_MEMORY_RUNTIME attribute (highest bit) set. To find the list of the candidates the debug log can be used. It does not say, that supplying these addresses means you can now disable DevirtualiseMmio - on the contrary, that you only provide an exception list to it.
-
From OC manual DevirtualiseMmio Type: plist boolean Failsafe: false Description: Remove runtime attribute from select MMIO regions. This option reduces stolen memory footprint from the memory map by removing runtime bit for known memory regions. This quirk may result in the increase of KASLR slides available, but is not necessarily compatible with the target board without additional measures. In general this frees from 64 to 256 megabytes of memory (present in the debug log), and on some platforms it is the only way to boot macOS, which otherwise fails with allocation error at bootloader stage. This option is generally useful on all firmwares except some very old ones, like Sandy Bridge. On select firmwares it may require a list of exceptional addresses that still need to get their virtual addresses for proper NVRAM and hibernation functioning. Use MmioWhitelist section to do this. Based on this, it maybe pointless to try to disable it, as it seems it is recommended to be enabled for most modern firmwares.
