Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

CaseySJ said:
Do you mean:
  • Create a PINI() method in the old (standard) Thunderbolt SSDT and add SHOW() into it?
    • If so, yes no problem at all. Can do this in the evening.
  • But if you would like to see the PINI() method I used in the TbtOnPch() function for the hot-plug photographs, that function looks like this:
Code: 
        Method (PINI, 0, NotSerialized)     // _INI: Initialize
        {
            If (OSDW ())
            {
                DBG1 ("RP05 Initialize")
                Acquire (TCFG, 0xFFFF)

                R018 = R_18 // RP Pri Bus
                R019 = R_19 // RP Sec Bus
                R01A = R_1A // RP Sub Bus
                R01C = R_1C // RP IO base/limit from UEFI
                R020 = R_20 // RP base/limit from UEFI
                R024 = R_24 // RP prefetch base/limit from UEFI
                R028 = R_28
                R02C = R_2C
               
                R118 = R_19 // UPSB Pri Bus = RP Sec Bus (UEFI)
                R119 = (R_19 + One) // UPSB Sec Bus = RP Sec Bus + 1
                R11A = R_1A // UPSB Sub Bus = RP Sub Bus (UEFI)
                R11C = R01C // UPSB IO base/limit = RP IO base/limit (UEFI)
                R120 = R020 // UPSB mem base/limit = RP mem base/limit (UEFI)
                R124 = R024 // UPSB pre base/limit = RP pre base/limit (UEFI)
                R128 = R028
                R12C = R02C
               
                R218 = R119 // DSB0 Pri Bus = UPSB Sec Bus
                R219 = (R119 + One) // DSB0 Sec Bus = UPSB Sec Bus + 1
                R21A = (R119 + One) // DSB0 Sub Bus = UPSB Sub Bus
                R21C = R01C // DSB0 IO base/limit = UPSB IO base/limit
                R220 = 0x82008200 // DSB0 mem base/limit = UPSB mem base/limit (from REGISTERS)
//                R220 = R120 // DSB0 mem base/limit = UPSB mem base/limit
                R224 = 0x1fff1 // DSB0 pre base/limit = UPSB pre base/limit
                R228 = Zero
                R22C = Zero
               
                R318 = R119 // DSB1 Pri Bus = UPSB Sec Bus
                R319 = (R119 + 0x02) // DSB1 Sec Bus = UPSB Sec Bus + 2
                R31A = (R119 + 0x02) // DSB1 Sub Bus = no children
                R31C = Zero // DSB1 disable IO
                R320 = Zero // DSB1 disable mem
                R324 = Zero // DSB1 disable prefetch
                R328 = Zero
                R32C = Zero
               
                R418 = R119 // DSB2 Pri Bus = UPSB Sec Bus
                R419 = (((R_1A - R219) >> One) + R219) // DSB2 Sec Bus = UPSB Sec Bus + 3
                R41A = (((R_1A - R219) >> One) + R219) // DSB2 Sub Bus = no children
                R41C = 0x1f1 // DSB2 disable IO
                R420 = 0x6bf06bf0 // DSB2 disable mem
                R424 = 0x1fff1 // DSB2 disable prefetch
                R428 = Zero
                R42C = Zero
               
                RVES = 0x130004 // DSB2 offset 0x564, unknown
               
                R518 = R119 // DSB4 Pri Bus = UPSB Sec Bus
                R519 = 0x3d // DSB4 Sec Bus = UPSB Sec Bus + 4
                R51A = 0x70 // DSB4 Sub Bus = no children
                R51C = 0x1f1 // DSB4 disable IO
                R520 = 0x81f06c00 // DSB4 disable mem
                R524 = 0x49f12001 // DSB4 disable prefetch
                R528 = 0x60
                R52C = 0x60

//                 RH10 = (R220 & 0xFFFC) << 16 // NHI0 BAR0 = DSB0 mem base
                RH10 = ((R220 & 0xFFF00000)) // NHI0 BAR0 = DSB0 mem base (from REGISTERS)
//                 RH14 = Zero // NHI0 BAR1 unused
                RH14 = ((RH10 + 0x00040000)) // NHI0 BAR1 unused (from REGISTERS)

                Sleep (One)
                ICMB (Zero)
                Release (TCFG)
            }
        }
Click to expand...
Have already tested by changing RH10, RH14 and others for system reset data.. all resulting on Thunderbolt Local Node and ThunderboltPort tree disappears.
 
Elias64Fr said:
@CaseySJ

About Osy86's methods, I don't have tested yet ..
To know with kind of device is plugged, MDUV value is used.

CRCM written and read data seem to be curious ..

I have the following for USBC and Tbt device plugged :
Code: 
"UPSB CRMW Read Value 01 = 0000000004000000"
"UPSB CRMW Written Value 02 = 0000000000000000"
"UPSB CRMW Read Value 03 = 0000000004000000"
"UPSB CRMW Written Value 04 = 0000000004000000"

With the following CRMW code :
Code: 
            Method (CRMW, 5, Serialized)
            {
                Local1 = One
                Local3 = Zero
                While ((Local3 <= 0x04))
                {
                    Local2 = CIOR (Arg0, Arg1, Arg2)
                    DBG1 (Concatenate ("UPSB CRMW - Read Value 01 = ", Local2 [One]))
                    If ((DerefOf (Local2 [Zero]) == Zero))
                    {
                        Local2 = DerefOf (Local2 [One])
                        Local2 &= ~Arg4
                        Local2 |= Arg3
                        Local2 = CIOW (Arg0, Arg1, Arg2, Local2)
                        DBG1 (Concatenate ("UPSB CRMW - Written Value 02 = ", Local2))
                        If ((Local2 == Zero))
                        {
                            Local2 = CIOR (Arg0, Arg1, Arg2)
                            DBG1 (Concatenate ("UPSB CRMW - Read Value 03 = ", Local2 [One]))
                            If ((DerefOf (Local2 [Zero]) == Zero))
                            {
                                Local2 = DerefOf (Local2 [One])
                                DBG1 (Concatenate ("UPSB CRMW - Written Value 04 = ", Local2))
                                Local2 &= Arg4
                                If ((Local2 == Arg3))
                                {
                                    DBG1 ("UPSB CRMW - Success")
                                    Local1 = Zero
                                    Break
                                }
                            }
                        }
                    }

                    Local3++
                    Sleep (0x64)
                }

                Return (Local1)
            }
Click to expand...
Just made these exact changes to the SSDT and will re-run this evening.
 
Elias64Fr said:
Have already tested by changing RH10, RH14 and others for system reset data.. all resulting on Thunderbolt Local Node and ThunderboltPort tree disappears.
Click to expand...
Okay; will return to the previous settings.

I think a key issue is to understand why MUST() method is rarely being called. Whenever it is called, the TNODE/TBUS tree appears, but this only happens after we do a hot plug or hot unplug (both of which cause system to hang) followed by a hard reset.

EDIT:
  • Below are the previous settings:
R018 = RP18
R019 = RP19
R01A = RP1A
R01C = RP1C
R020 = R_20
R024 = R_24
R028 = R_28
R02C = R_2C

R118 = RP19
R119 = (RP19 + One)
R11A = RP1A
R11C = R01C
R120 = R020
R124 = R024
R128 = R028
R12C = R02C

R218 = R119
R219 = (R119 + One)
R21A = (R119 + One)
R21C = R01C
R220 = R020
R224 = R024
R228 = R028
R22C = R02C

R318 = R119
R319 = (R219 + One)
R31A = (R219 + One)
R31C = Zero
R320 = Zero
R324 = Zero
R328 = Zero
R32C = Zero

R418 = R119
R419 = (((RP1A - R219) >> One) + R219)
R41A = (((RP1A - R219) >> One) + R219)
R41C = Zero
R420 = Zero
R424 = Zero
R428 = Zero
R42C = Zero

RVES = Zero

R518 = R119
R519 = (R319 + One)
R51A = (R319 + One)
R51C = Zero
R520 = Zero
R524 = Zero
R528 = Zero
R52C = Zero
RH10 = ((R220 & 0xFFFC) << 0x10)
RH14 = (((R220 & 0xFFFC) + 0x04) << 0x10)
 
Last edited:
CaseySJ said:
Just made these exact changes to the SSDT and will re-run this evening.
Click to expand...
Another information on CRMW, Titan ridge and Alpine Ridge have same CTBT args for CRMW method access :

\_SB.PCI0.RP21.UPSB.CRMW (0x3C, Zero, 0x02, 0x04000000, 0x04000000)

But are differents on UPSB _PS0 :

CRMW (0x013E, Zero, 0x02, 0x0200, 0x0200)
CRMW (0x023E, Zero, 0x02, 0x0200, 0x0200) For Alpine ridge

CRMW (0x0150, Zero, 0x02, 0x04000000, 0x04000000)
CRMW (0x0250, Zero, 0x02, 0x04000000, 0x04000000) For Titan ridge
 
Elias64Fr said:
Another information on CRMW, Titan ridge and Alpine Ridge have same CTBT args for CRMW method access :

\_SB.PCI0.RP21.UPSB.CRMW (0x3C, Zero, 0x02, 0x04000000, 0x04000000)

But are differents on UPSB _PS0 :

CRMW (0x013E, Zero, 0x02, 0x0200, 0x0200)
CRMW (0x023E, Zero, 0x02, 0x0200, 0x0200) For Alpine ridge

CRMW (0x0150, Zero, 0x02, 0x04000000, 0x04000000)
CRMW (0x0250, Zero, 0x02, 0x04000000, 0x04000000) For Titan ridge
Click to expand...
Yes no problem!
Screen Shot 2020-02-07 at 10.26.02 AM.png


Screen Shot 2020-02-07 at 10.22.14 AM.png


UPDATE:

There's one more in UPSB.PCED():

Screen Shot 2020-02-07 at 10.30.55 AM.png
 
CaseySJ said:
Okay; will return to the previous settings.

I think a key issue is to understand why MUST() method is rarely being called. Whenever it is called, the TNODE/TBUS tree appears, but this only happens after we do a hot plug or hot unplug (both of which cause system to hang) followed by a hard reset.

EDIT:
  • Below are the previous settings:
R018 = RP18
R019 = RP19
R01A = RP1A
R01C = RP1C
R020 = R_20
R024 = R_24
R028 = R_28
R02C = R_2C

R118 = RP19
R119 = (RP19 + One)
R11A = RP1A
R11C = R01C
R120 = R020
R124 = R024
R128 = R028
R12C = R02C

R218 = R119
R219 = (R119 + One)
R21A = (R119 + One)
R21C = R01C
R220 = R020
R224 = R024
R228 = R028
R22C = R02C

R318 = R119
R319 = (R219 + One)
R31A = (R219 + One)
R31C = Zero
R320 = Zero
R324 = Zero
R328 = Zero
R32C = Zero

R418 = R119
R419 = (((RP1A - R219) >> One) + R219)
R41A = (((RP1A - R219) >> One) + R219)
R41C = Zero
R420 = Zero
R424 = Zero
R428 = Zero
R42C = Zero

RVES = Zero

R518 = R119
R519 = (R319 + One)
R51A = (R319 + One)
R51C = Zero
R520 = Zero
R524 = Zero
R528 = Zero
R52C = Zero
RH10 = ((R220 & 0xFFFC) << 0x10)
RH14 = (((R220 & 0xFFFC) + 0x04) << 0x10)
Click to expand...
Like said previously,
  • MacOS driver call NHI0 MUST method then UPSB MUST method
NHI macOS driver call this method.. It might be Because TNode appears that's why MUST appears on log.
 
Hello!

Seems like my new Catalina install no longer has h264 and HEVC hardware accel

Screenshot 2020-02-07 at 19.31.08.png

I'm running:
vega64 in slot -1
r9270x in slot-2

Screenshot 2020-02-07 at 19.35.39.png

thinking it might be the fault of:

Screenshot 2020-02-07 at 19.07.59.png


agdpmod=pikera
and
shikigva=32
I removed them [include shake-id=Mac-7BA5B etc etc

Screenshot 2020-02-07 at 19.32.35.png

rebooted
and still videoproc show no accel

do you think its because :

1. I should rename the cards so that Vega is 1st on the list and the R9 second [alphabetical order]
2. use different boot argument in clover, and which one?

big thanks,
J-P
 
iMac 19,1 Catalina
Z390 DESIGNARE |  i9 9900K |  Radeon Other
Elias64Fr said:
...
NHI macOS driver call this method.. It might be Because TNode appears that's why MUST appears on log.
Click to expand...
Sure:
  • TNODE/TBUS appears --> then --> MUST() is called
instead of:
  • MUST() is called --> then --> TNODE/TBUS appears
So far we see the following behavior:
  • Cold Boot --> no devices attached --> No TNODE/TBUS
  • Cold Boot --> TB3 and/or USB-C attached --> No TNODE/TBUS
  • Warm Boot --> no devices attached --> No TNODE/TBUS
  • Warm Boot --> TB3 and/or USB-C attached --> No TNODE/TBUS
But then...
  1. Hot plug or hot unplug a TB3 device --> system hang
  2. Then press physical reset button with TB3 device connected
  3. When system boots up --> TNODE/TBUS appears --> MUST() appears
So Step 1 "triggers" something important...
 
Last edited:
hussar said:
Hello!

Seems like my new Catalina install no longer has h264 and HEVC hardware accel

View attachment 448705

I'm running:
vega64 in slot -1
r9270x in slot-2

View attachment 448708

thinking it might be the fault of:

View attachment 448706


agdpmod=pikera
and
shikigva=32
I removed them [include shake-id=Mac-7BA5B etc etc

View attachment 448707

rebooted
and still videoproc show no accel

do you think its because :

1. I should rename the cards so that Vega is 1st on the list and the R9 second [alphabetical order]
2. use different boot argument in clover, and which one?

big thanks,
J-P
Click to expand...
Yes it seems the AMD R9 is being prioritized because of alphabetical order of names:
  • AMD Radeon R9 270X
  • Radeon RX Vega 64
You may try renaming them to something appropriate such as:
  • AMD Vega 64
  • Radeon R9 270X
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top