Jump to content

meina222

Donator
  • Posts

    449
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by meina222

  1. @iGPU - I left my IOReg running for the last 20 min. No such flickering. The only items that change (which is normal as I browse some stuff) are: RootDomainUserClient AMDRadeonX6000_AMDAccelCommandQueue AMDRadeonX6000_AMDAccelSharedUserClient AMDRadeonX6000_AMDGFX10GLContext IOAudioEngineUserClient IOAudioControlUserClient IOSurfaceRootUserClient IOTimeSyncDomainUserClient I see a lot of those being stricken out, but none from USB ports.
  2. Correct - no slide here too. I pretty much took your official OC debug EFI and tweaked args, MMIO and now added some SSDT's to it for my hardware. The reboot happens at the very beginning before I even get a chance to see any text log - and not always, maybe once every 3-4 boots.
  3. One more thing to report after some testing the shiny new BS install. Every once in a while I fail to boot and instead of getting deep into the log, my PC just reboots. Next time it usually succeeds. So there is still some quirk around maybe slides that causes this instability.
  4. Not much of a hackintosher - this TRX40 is my 1st attempt - so didn't know about it. Thanks! One thing that BS confuses me about - with this "Preboot" volume selected - how do I know which EFI am I using? Once in, what's the best way to tie up what I see with whichever EFI I want to change? Right now I see my USB renames are not being applied properly, so not sure if some other EFI is sneaking on me like before. Ah! Now I see - it's the green one from your app. Thanks, this app is indeed great!
  5. Seems I have a ghost mount of dev/disk1s1 that didn't show up in Finder. Nothing to do with what I typed below. So in Big Sur - is there a way without going through avoiding the sealing of volumes to copy the boot EFI to the disk instead of USB? When I try dd, I get udo dd if=/dev/disk8s1 of=/dev/disk1s1 dd: /dev/disk1s1: Resource busy
  6. Back in business. Fixed the USB MMIO to match the install EFI (the one that sneaked on me via Bootstrap). The world makes sense now. Booting with OC 0.6.1 and WG and -wegbeta and pikera. Pikera is always required for me - the previous info that I could disable it (I never did due to not realizing I booted from another EFI) is misleading and I edited it out. Now should I re-try to reinstall BS with 0.6.1 (@iGPU's latest EFI)? I think not :). Or at least not right away.
  7. @iGPU - yes! Bootstrap was enabled in my target drive EFI containing Catalina. So what happened was this: My USB never worked. But when it froze it created a state where on next boot, my target disk EFI would get auto selected. That happened to be the previous bare metal EFI for Catalina which is non-Debug and contains OC 0.6.0 with bootstrap enabled. The reason I enabled some time ago was because I couldn't figure how to delete duplicate entries in my boot menu before. Anyways, so without knowing I actually succeeded installing BigSur using that EFI. Even after the entire disk volume group was erased, the EFI files survived when the installer (from the USB before the freeze) recreated the partitions. I am very wary of this "success" though as I ended up with a corrupt install before in Catalina. I think the MMIO group is critical to this whole effort - my freezes must have come from it. I will retry the USB as now I removed the bootstrapping EFI.
  8. I feel the answer to my weird experiences has to do with this MMIO black magic. So last night I succeeded with these values.Notice how my slides are exactly the same as @Driftwood's. Something about our board MMIO is common as he also experiences the click shutdown/restart and install corruption issues. 35:415 00:054 OCABC: MMIO devirt start 35:472 00:056 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0 35:529 00:057 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0 35:587 00:057 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0 35:643 00:056 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0 35:700 00:056 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0 35:757 00:057 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0 35:814 00:056 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0 35:871 00:057 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0 35:928 00:056 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0 35:986 00:057 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0 36:043 00:057 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0 36:096 00:053 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0 36:150 00:053 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0 36:205 00:054 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0 36:260 00:055 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0 36:315 00:054 OCABC: MMIO devirt 0x10000000000 (0x10400 pages, 0x8000000000000001) skip 0 36:370 00:054 OCABC: MMIO devirt 0x3CB90000000 (0x10400 pages, 0x8000000000000001) skip 0 36:425 00:055 OCABC: MMIO devirt 0x3CBC0000000 (0x10400 pages, 0x8000000000000001) skip 1 36:483 00:057 OCABC: MMIO devirt 0x69750000000 (0x10400 pages, 0x8000000000000001) skip 1 36:537 00:054 OCABC: MMIO devirt end, saved 555184 KB 36:592 00:055 OCABC: Only 176/256 slide values are usable! 36:647 00:054 OCABC: Valid slides - 80-255
  9. Can someone tell me how is the following possible? 1. Launch Mac OS BS installer 2. Erase the entire volume group of the target drive 3. Complete a clean installation 4. Boot into "Preboot" partition to check on the new bare metal install 5. Find out from Hackintool that my previous EFI with O.C. 0.6.0 and the ACPI files from before are found - how??? Hackintool bug or erase didn't happen. Also, there is clearly something non-deterministic going on with my system as the same USB I did finally manage to do an install with last night, now goes into a black screen after running though some logs. And I get the corrupted text over my BIOS splash. Reason I mention this weird text, is that I could correlate this with my install failures last night, but once I did some tweaks to the config.plist (completely remove WEG kext, I211 kext and pikera and -wegbeta args), the splash was not corrupted and the install went very clean. Could it be that I got lucky with hitting some KASLR region? And I still don't understand - how did the EFI of my target survive the volume deletions? After thinking a bit I think I now know what happened. I must have somehow fallen back on booting from my Catalina bare metal EFI and managed to complete the Big Sur install from there using OC 0.6.0 and a variation of @iGPU's old EFI, thinking that I actually booted from the USB. I can verify that later, but this EFI had WG 1.4.1 and no -wegbeta and is also non-debug, which explains the no OC debug text on BIOS splash. So ok - now I know I can boot into bare metal with 0.6.0 and my old EFI with whatevergreen 1.4.1 (no -wegbeta!), but that wasn't the goal! (I mean it is a goal to install BS, but it's best to achieve it in a way agreeable with others' experiences and version).
  10. @fabiosun - yes I had disabled SMT. This answers our question from 2 months ago - does BS has 64 limit - yes it does, since boot fails very early otherwise. Issue with me was either Whatevergreen and -wegbeta or MMIO or both. Probably WEG but I am not sure 100% which. For sure now the installer is going. I already rebooted past 1st phase beyond my initial freeze. And my fans now ramp up - before the system sounded suspiciously quiet and was corrupting the BIOS splash boot where OC would print text on top of BIOS image. Will post more tomorrow including altered config.plist for those that may encounter similar issue. I removed. 1. WEG kext, -wegbeta and pikera args 2. Intel I211 kext (just in case, will re-add - what does this kext really gain for my card?) 3. Enabled only the last 2 MMIO addresses in my list - left all other disabled, cautious about my own and @Driftwood's earlier mishaps. Turns out my install succeeded with an older EFI which I had used on Catalina baremetal The stricken items are therefore not right. I will re-try the USB booter. My system now clicks on shutdown and shuts, and 1 sec later comes back alive. So still work to do but now it seems very close. Thanks @iGPU! And @fabiosun for the encouragement. This stuff is too time consuming and I almost gave up.
  11. Success! Bare Metal is now installing. I disabled WEG and removed -wegbeta and pikera and also only enabled my last 2 MMIO. Right away the weird corruption where OC would print text in top of my BIOS image at boot disappeared and the installer is now going smooth! Fingers crossed. Will post abridged config plist when done.
  12. Here is my OC txt log saved on the EFI. If you see anything off let me know, but OC boot itself worked. The MacOS installer then fouls up.opencore-2020-08-29-050354.txt.zip
  13. Could be. But Catalina worked 2 weeks ago. However, with all the changes to OC I doubt too many (if any) are testing 3990X. I got this CPU specifically for VM setups so won't be too bummed if I can't get MacOS bare metal but the fact that Catalina succeeded with your original EFI from 10+ days ago, makes me worry something else is going on. Also Proxmox Big Sur works very well. Not the same, I know but ....
  14. Yes -wegbeta is there (I believe your EFI had it, I made sure). I will disable it completely next but I have a feeling it's something else related to my hardware. To be precise - boot is fine, and install starts and goes on for 5 min. Then at 12 min left hard freezes. Mouse doesn't move, I need to power cycle.
  15. Thanks. I have a much bigger problem. Install freezes. I may retry Catalina again with older EFI. The only thing I changed from your original EFI is the 67 to 65 output for saving the mmio whitelist - I used the debug version and added pikera arg.
  16. I must be bare metal cursed. Got so much further than last time but my installation hard freezes halfway. Clean reformat and install. Starting to wonder if it is the video card or BIOS. I am the only using 5700XT so I have to add pikera boot arg. I disabled all memory overclock for this install so it's not that. Next I may try to disable Whatevergreen but I doubt that's it. (edit: almost forgot I have the 3990x too so need to disable SMT, weird thing is that 1st time a couple of weeks back bare metal worked - I wonder what changed and how does one debug this). Proxmox continues to work without a flaw.
  17. @TheDantee - this is an internal Gigabyte BIOS they shared privately with me (built Aug 25). Their US support claims their HQ / Bios developer shared it in an attempt to resolve the PCIE issues where I can't get my Slot 4 to full speed if NVME 4x4x4x4 is in Slot 3. 1st world problem 🙂. Since it's a "beta" BIOS and it actually didn't fix my issue, and it's unclear what other changes or improvements it might have, I actually just downgraded back to official f4c (which hasn't been upgraded since March and is still CastlePeak 1.0.0.3B). I ran f4j for a few days and other than messing with all my PCI id's I didn't see any perceptible or measurable improvement. In order to share it here, I need permission from the moderator @fabiosun, but I advise against using beta BIOSes. Oh and I think I am getting a different board. The GB is a nice one on paper, and if you run it conservative performs great, but I just can't stomach that crippled slot and some other quirks such as fan curve bugs and occasional USB port errors on reboots, and not very stable XMP1 at 3600, where I need to crank voltage above 1.45 to run. I feel I am tinkering too much with it - want to sit back and feel happy about it, and something with their BIOS and poor support bugs me. Maybe they fixed the quirks in rev 1.1 - no idea.
  18. For the record - I changed my GB BIOS from f4c to f4j (not officially available on GB site) - stemming from a lengthy attempt to find a way for my TB to work in Slot 4 while AIC is installed. This changed ALL of my PCI device id's. Every MMIO group other than non-AIC NVME got shifted - VGA from 000:23:00 to 000:43:00 etc, as I found out by being greeted by black Proxmox screen on VM start. So almost surely this scrambled my MMIO's and I'll have to do it from scratch. Not on-topic, but I am so disappointed with GB's BIOS support and inability to provide updates and fixes, that I think I'll buy another board - got an RMA approved already. BigSur beta5 USB is ready. I will try bare metal again tomorrow. @iGPU, I am bit confused on one thing - how important is to not have the sealed volumes - should I bother with that, or should I try to 1st get it running without trying to unseal it?
  19. I have the same. No matter what kexts I use, the injection is as above. Probably I should disable anything related to USB other than EC.
  20. Thank you @tsongz. What does SSDT-ALS do? Also, in Hackintool USB section - does it show any USB ports? Can you set port capability via SSDT or it's not needed?
  21. Question on Proxmox and USB - does any of you use custom SSDT? No matter what I inject Hackintool always shows no or very few ports. Do any SSDT's help with port capabilities when passing through PCI USB controller from Proxmox?
  22. 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.
  23. @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.
  24. @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.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.