Jump to content

Pavo

Members
 View Profile  See their activity

  • Posts

    67

  • Joined

  • Last visited

 Content Type 

Everything posted by Pavo

  1. Pavo
    The reason you guys are seeing huge increase in speed is because the TSC timing is set to a higher rate than the CPU frequency. It is similar to not using invariant timing, each tick of the timer gets mutiplied against itself. Most of the stuff related to the Datahub is related to timing and frequency settings, by disabling it you basically take what is in your ACPI tables which are only for machine startup, then the kernel suppose to recalculate those, which doesn't happen in macOS because it doesn't support AMD CPUs natively.
  2. Pavo
    B7 is booting fine for me with DisableLinkeditJettison enabled and no boot-args.
  3. Pavo
    AMD hacks are now working with beta 7 using new kernel patches, thanks to Algrey from AMD discord server https://github.com/AMD-OSX/AMD_Vanilla/tree/experimental-opencore
  4. Pavo
    Been working with Algrey on discord.... The first one gets past the sticking point but kernel panics and instant reboots after ACPI tables load and can not get a good video of the panic itself, have tried multiple times. FIND : E8 5C 61 01 00 REPLACE : 0F 1F 44 00 00 The second one does not get found at all.. Algrey is aware.
  5. Pavo
    Ok.... was about to update without issues using UnRAID, cpu is set to host and no issues. Tried to boot back into bare metal after update was complete, nogo. So.. its gotta be a kernel patch that needs to be updated. Going to test each kernel patch while in UnRAID to see if I can identify which patch needs to be updated. Also just too prove that CPU is set as host and booting without issues, here is a pic (not photoshopped like some people think I might do).
  6. Pavo
    In my opinion we shouldn't be putting EFIs or snippets in the thread itself but use a GitHub repo so everyone can collaborate with forks and merges or if there is major differences, have configs to specific systems in the repo. This would eliminate anything in the past to present issue. The config structure is the same for all systems and change on OC updates, which can be maintained on the repo itself.
  7. Pavo
    That was a typo at the time I posted a screenshot of that. That patch only works with BigSur beta 3 and above.
  8. Pavo
    Thought you said on discord yesterday that removing the Fix PAT effected Bare Metal in HS heavily?
  9. Pavo
    I did not because I do not used custom DSDTs, if you can provide the exact modifications you did I can replicate them with a SSDT. I also created a ACPI delete entry to remove the ACPI error that we were getting see below in the pic. This removes the ShakTooth table that is trying to overwrite the WMI1 device that already exist in the DSDT and causes the ACPI error.
  10. Pavo
    Just wanted to give everyone an update on the GPU performance fix, it is 100% the last kernel patch, Fix PAT. Disable it and see if you can still boot and if you can, your GPU performance will be like it should be. Currently trying to get the AMD devs to re-work the patch so all AMD systems can benefit from it using the PAT fix without hindering the GPU performance.
  11. Pavo
    You should not use a custom patched DSDT from a different system, not even if you applied common patches. Every patch that can be done in a DSDT can be converted to a SSDT.
  12. Pavo
    This is correct, I was saying that Min 17.x.x with Max 20.x.x would be applied to High Sierra, Mojave, Catalina and Big Sur. It would not stop with just Catalina. Maybe I misinterpreted what he was saying.
  13. Pavo
    This is correct. This is incorrect Min 17.x.x with a Max of 20.x.x means used if set to enabled (yes) from High Sierra to BigSur. Not Catalina
  14. Pavo
    @fabiosun I would agree with you but the kernel patches they provided are based off what they added back in the day to compile a kernel for AMD specifically when they were using Clover. It is always good to validate what patches are needed or not needed in my opinion. I have had tons of discussions this with algrey and Shaneee before to get a better understanding of exactly what each individual kernel patch is doing. There are quite a few patches that are applied simply to avoid a kernel panic on certain function calls that was being produced back in 10.12 era. They simply apply the same methodology on every update instead of going through each new kernel to get the bare minimum kernel patches needed.
  15. Pavo
    The story is from me, I decided to try and reduce the amount of kernel patches applied for AMD system and simply did a test of disabling one patch at a time and seeing if I could boot and checking my WoW game performance. Once I got to the point of my WoW game performance was like it should have been from the beginning I stopped reducing the patches. The reason they are not recommended is because it is not consistent across all AMD systems on what patches can be removed and provide the GPU gaming performance increase.
  16. Pavo
    Using Sound BlasterX G6 USB DAC, working perfectly fine.
  17. Pavo
    Yeah, update went smooth as a baby's ass.
  18. Pavo
    Yeah I figure this much, but you can do all that in your GFX SSDT and it only requires 3 of the 40+ settings you currently have in the Device properties section of the config. The performance gain is not from the frame buffer settings but from the `ATY,EFIVersion`and `ATY,EFIRom` values, if you look at the ACPI folder I uploaded from mine, my GFX SSDT has those as well. The RX 5700 XT can not use the `PP_WorkLoadPolicyMask` settings of my SSDT though, so do not include that into your SSDT.
  19. Pavo
    A few things I notice you really shouldn't be doing.... You should not be specifying a specific frame buffer (see pic of highlighted below) for the dGPU, RX 5700 XT works perfectly fine when using the default frame buffer. Also do not need all these other properties in the Device Properties section of your config for the GPU. Nor do you need to add a property or `built-in` to any devices using Device properties section of the config. If you want a device to show as `built-in` you simply create a SSDT and give said device a ACPI name and add it to the appropriate scope that the devices falls under and the device will by default be assigned as `built-in`. Have you tried booting without the `npci=0x2000` boot-arg? I do not need this boot-arg and don't think any other TRX40 system needs it either. What exactly is the SSDT-AIC for? I am not tracking anything the about a `class-code` change needed for a pci-bridge on our systems at all. Method (_SB.S0D2.D2B1.D0D1._DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LNot (Arg2)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x04) { "class-code", Buffer (0x04) { 0xFF, 0x08, 0x01, 0x00 }, "built-in", Buffer (One) { 0x00 } }) }
  20. Pavo
    So... your HPET is exactly like mine and @iGPU system. Here is yours.... Device (HPET) { Name (_HID, EisaId ("PNP0103")) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { If (LEqual (HPEN, One)) { If (LGreaterEqual (OSVR, 0x0C)) { Return (0x0F) } Store (Zero, HPEN) Return (One) } Return (One) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Return (BUF0) } } Here is mine.... Device (HPET) { Name (_HID, EisaId ("PNP0103")) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { If (LEqual (HPEN, One)) { If (LGreaterEqual (OSVR, 0x0C)) { Return (0x0F) } Store (Zero, HPEN) Return (One) } Return (One) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Return (BUF0) } } So... I am not sure why you are having HPET issues, please upload your entire EFI Folder.
  21. Pavo
    Below is an example of changing a ACPI method of a device. DefinitionBlock ("", "SSDT", 2, "APPLE ", "HPET", 0x00001000) { External (HPET._STA, UnknownObj) Scope (_SB) { Method (_INI, 0, NotSerialized) { \HPET._STA = 0x0F } } } now... the \HPET._STA depends on the location of HPET in your original DSDT. This is what I used on my MSI MPG X570 Gaming Edge WiFi when I was using a 3950X. It is not needed on my MSI Creator TRX40 system. @meina222 If you upload your DSDT I can modify this to meet your system needs.
  22. Pavo
    Some AMD systems has HPET issues, and this KP is exactly that. The DummyPowerManagement quirk does nothing for AMD, I have proven this time and time again with previous AMD systems like X570 and now TRX40 but some of the AMD discord people don't listen and have given vit9696 suggestions that aren't needed. You can create an SSDT to change the _STA method to turn HPET on, let me look through previous SSDTs I have made and I can post it.
  23. Pavo
    Ok... so after doing a little more testing it would seem the first 0x10400 address enabled cause some side effect issues with USB controllers. Started having random disconnects from varies devices. 19:131 00:019 OCABC: MMIO devirt 0x2040000000 (0x10400 pages, 0x8000000000000001) skip 0 So.. I changed mine to disable that first address from the 0x10400 section. Will report anymore findings.
  24. Pavo
    Ok.... just wanted to make sure you understood what I wanted to be tested.
  25. Pavo
    I didn't mean for you to use my addresses, I meant for you to disable only the last 3 addresses of your MMIO list.
×
×
  • 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.