Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

[Feartech]

Hello,

When updating Big Sur to 11.6 (I'm still on 11.0.1) using the Software Update, do I choose Macintosh HD or my Catalina disk after the restart?

Also, I'm still on opencore 0.6.3. Do I need to update my opencore? My system is running very well and I have not encountered any problems since I first installed it, so I'm a bit worried about updating.

Thanks!

it should boot to the one it needs to complete the upgrade

 

[CaseySJ]

Hello,

When updating Big Sur to 11.6 (I'm still on 11.0.1) using the Software Update, do I choose Macintosh HD or my Catalina disk after the restart?

Also, I'm still on opencore 0.6.3. Do I need to update my opencore? My system is running very well and I have not encountered any problems since I first installed it, so I'm a bit worried about updating.

Thanks!

It’s okay to stay on OpenCore 0.6.3 even when updating to Big Sur 11.6. Each time the system restarts during the update process, it should auto-select the startup disk, which will be Macintosh HD for the first couple of reboots. In most cases it’s not necessary to touch the system during update because everything should be on auto-pilot.

 

[canyondust]

Unfortunately this does not work because:

• The GPRW hack for disabling wake-from-USB (hence wake is only possible with power button) relies upon two parts:
  • SSDT-GPRW -- this SSDT already contains If (_OSI ("Darwin")) { }.
  • ACPI Rename -- we rename Method (GPRW, 2, N) to Method (XPRW, 2, N).
    • It is this ACPI rename (i.e. "ACPI Patch") that is universally applied because OpenCore currently has no means of applying it conditionally.

Right, but forgive my lack of understanding here: we rename the DSDT method so that the rest of the DSDT does NOT call the original GRPW method but instead calls the GRPW method contained in the SSDT (this assumes that the GRPW rename is not a global rename, but ONLY renames the method declaration in the DSDT of course...)

 

[CaseySJ]

Right, but forgive my lack of understanding here: we rename the DSDT method so that the rest of the DSDT does NOT call the original GRPW method but instead calls the GRPW method contained in the SSDT (this assumes that the GRPW rename is not a global rename, but ONLY renames the method declaration in the DSDT of course...)

Correct. ACPI renames are applied to the original DSDT and original SSDTs. OpenCore differentiates between original and injected SSDTs, and applies “patches” only to the original.

 

[canyondust]

Correct. ACPI renames are applied to the original DSDT and original SSDTs. OpenCore differentiates between original and injected SSDTs, and applies “patches” only to the original.

Right, so as long as only the method declaration gets the rename (using OCs renameCount and however it indexes etc) and all references to the method stay as GRPW instead of XRPW, wouldn’t an if/else in the SSDT-GRPW work?

 

[canyondust]

Right, so as long as only the method declaration gets the rename (using OCs renameCount and however it indexes etc) and all references to the method stay as GRPW instead of XRPW, wouldn’t an if/else in the SSDT-GRPW work?

Maybe it's even easier than that? If OSI is NOT Darwin, we can just pass the arguments through GPRW back to XPRW, no?

DefinitionBlock ("", "SSDT", 2, "Slav", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    If (_OSI ("Darwin"))
    {
        Method (GPRW, 2, NotSerialized)
        {
            While (One)
            {
                If ((0x6D == Arg0))
                {
                    Return (Package (0x02)
                    {
                        0x6D,
                        Zero
                    })
                }

                If ((0x0D == Arg0))
                {
                    Return (Package (0x02)
                    {
                        0x0D,
                        Zero
                    })
                }

                Break
            }

            Return (XPRW (Arg0, Arg1))
        }
    }
    Else
    {
        Return (XPRW (Arg0, Arg1))
    }
}

 

[canyondust]

Maybe it's even easier than that? If OSI is NOT Darwin, we can just pass the arguments through GPRW back to XPRW, no?

DefinitionBlock ("", "SSDT", 2, "Slav", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    If (_OSI ("Darwin"))
    {
        Method (GPRW, 2, NotSerialized)
        {
            While (One)
            {
                If ((0x6D == Arg0))
                {
                    Return (Package (0x02)
                    {
                        0x6D,
                        Zero
                    })
                }

                If ((0x0D == Arg0))
                {
                    Return (Package (0x02)
                    {
                        0x0D,
                        Zero
                    })
                }

                Break
            }

            Return (XPRW (Arg0, Arg1))
        }
    }
    Else
    {
        Return (XPRW (Arg0, Arg1))
    }
}

And -maybe- if the rename count and index is limited to JUST renaming the GRPW method itself, this might work? but it's not tested at all. It's me thinking out loud:

DefinitionBlock ("", "SSDT", 2, "Slav", "GPRW", 0x00000000)
{
    External (PRWP, MethodObj)    // 0 Arguments
    External (SS1_, IntObj)
    External (SS2_, IntObj)
    External (SS3_, IntObj)
    External (SS4_, IntObj)

    Method (GPRW, 2, NotSerialized)
    {
        If (_OSI ("Darwin"))
        {
            While (One)
            {
                If ((0x6D == Arg0))
                {
                    Return (Package (0x02)
                    {
                        0x6D,
                        Zero
                    })
                }

                If ((0x0D == Arg0))
                {
                    Return (Package (0x02)
                    {
                        0x0D,
                        Zero
                    })
                }

                Break
            }
        }

        PRWP () [Zero] = Arg0
        Local0 = (SS1 << One)
        Local0 |= (SS2 << 0x02)
        Local0 |= (SS3 << 0x03)
        Local0 |= (SS4 << 0x04)
        If (((One << Arg1) & Local0))
        {
            PRWP () [One] = Arg1
        }
        Else
        {
            Local0 >>= One
            FindSetLeftBit (Local0, PRWP () [One])
        }

        Return (PRWP ())
    }
}

 

[CaseySJ]

Maybe it's even easier than that? If OSI is NOT Darwin, we can just pass the arguments through GPRW back to XPRW, no?

...

Update: Yes you're right.

---

• Method GPRW already exists, but we need to modify it for macOS.
• We could modify the DSDT itself, compile the DSDT, and use our version instead of the original DSDT. We have the ability in OpenCore (and Clover) to drop the entire original DSDT.
• But modifying the DSDT, compiling it, and replacing the original is highly discouraged for various reasons not the least being that some DSDTs will not compile properly.

So how else can we modify a method that already exists?

• Answer: We cannot.
• If we were dealing with a Device instead of a Method, we could try creating a Method (_DSM, 4, Serialized) because _DSM methods are always invoked if they exist.
• So the only other alternative is:
  • Rename GPRW to something else such as XPRW in order to set it aside.
  • Create a new GPRW method.
• And this, as we've seen, affects Windows...
  • But this idea of yours is a good one. In fact, this is typically how we've dealt with similar problems, so it's a bit embarrassing that I overlooked it!

If (_OSI ("Darwin"))
{
    // do Mac stuff
}
Else
{
   Return (XPRW (Arg0, Arg1))
}

 

[CaseySJ]

Surprisingly my water cooler is a Corsair one (but had the same issue before with NZXT). I might simply buy a similar male usb header/usb type A and connect to the back. I'll try that. Still would be good to have GPRW working and not preventing windows 10 from booting

Please try replacing SSDT-GPRW.aml with the attached version, thanks to a good observation by @canyondust. Then see if Windows will boot through OpenCore when GPRW is enabled (both the SSDT and the Patch).

 

[louierh70]

It’s okay to stay on OpenCore 0.6.3 even when updating to Big Sur 11.6. Each time the system restarts during the update process, it should auto-select the startup disk, which will be Macintosh HD for the first couple of reboots. In most cases it’s not necessary to touch the system during update because everything should be on auto-pilot.

Thank you @CaseySJ and @Feartech !