Ryzen 7000 Testing

[CaseySJ]

A friendly reminder to post build problems in the Installation or Post-Installation forums.

Ryzen 7000 Testing

** OpenCore Configurator Users ** Please wait a couple of days for version 2.64.1.0 before editing OpenCore 0.8.7 config.plist. Current version supports "development" version of 0.8.7 but not the "release" version. If you use the current version anyway, it will be necessary to make one change...

forum.amd-osx.com

 

[setzer69a]

can i have a copy of your efi to work with ? i have a different board...but im guessing id need to tweak very little and it would be a good starting point...i think

 

[CaseySJ]

can i have a copy of your efi to work with ? i have a different board...but im guessing id need to tweak very little and it would be a good starting point...i think

I'll provide a copy to you in private message with the expectation that if you're adapting it to your board, the burden is on you to do the due diligence!

 

[CaseySJ]

** Detailed HDA Verb Capture in Linux **​

After a bit of experimentation in Linux, it was possible to capture the entire audio codec initialization sequence. This means every verb sent to every node is captured, but it excludes interaction with lower-level configuration registers that govern stream format, stream start and stop, interrupts, DMA buffers, CORB and RIRB interaction, etc. [CORB = Command Output Ring Buffer and RIRB = Response Input Ring Buffer]

The following simple commands (a) enable trace logging on high-definition audio (HDA) and (b) initiate a full re-initialization of the codec so that the entire sequence is captured.

# switch to privileged mode (type password when requested)
sudo -s

# enable trace logging on HDA subsystem
echo 1 > /sys/kernel/debug/tracing/events/hda/enable

# reinitialize audio codec, which in this case is device hwC2D0, but will be different on other systems
echo 1 > /sys/class/sound/hwC2D0/reconfig

# now grab entire trace log -- just copy it to local file (change 'casey' to your user name)
cp /sys/kernel/debug/tracing/trace /home/casey/Documents/tracelog.txt

# disable trace log
echo 0 > /sys/kernel/debug/tracing/events/hda/enable

# change ownership and group from root to ourselves; replace 'casey' with your user name
cd /home/casey/Documents
chown casey:casey tracelog.txt

# return to normal user mode
exit

The resulting file is posted here. I'll study it over the next day or so to see if there's anything important to be learned. Here's a sample of what it looks like:

# tracer: nop
#
# entries-in-buffer/entries-written: 402/402   #P:16
#
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
            bash-3226    [011] .....   313.300072: hda_send_cmd: [0000:58:00.4:0] val=0x00170500
            bash-3226    [011] .....   313.300142: hda_get_response: [0000:58:00.4:0] val=0x00000000
            bash-3226    [011] .....   313.300146: hda_send_cmd: [0000:58:00.4:0] val=0x00270500
            bash-3226    [011] .....   313.300201: hda_get_response: [0000:58:00.4:0] val=0x00000000
            bash-3226    [011] .....   313.300202: hda_send_cmd: [0000:58:00.4:0] val=0x00370500
            bash-3226    [011] .....   313.300276: hda_get_response: [0000:58:00.4:0] val=0x00000000
            bash-3226    [011] .....   313.300280: hda_send_cmd: [0000:58:00.4:0] val=0x00470500
            bash-3226    [011] .....   313.300325: hda_get_response: [0000:58:00.4:0] val=0x00000000
            bash-3226    [011] .....   313.300326: hda_send_cmd: [0000:58:00.4:0] val=0x00570500
            bash-3226    [011] .....   313.300385: hda_get_response: [0000:58:00.4:0] val=0x00000000
            bash-3226    [011] .....   313.300386: hda_send_cmd: [0000:58:00.4:0] val=0x00670500
            bash-3226    [011] .....   313.300426: hda_get_response: [0000:58:00.4:0] val=0x00000000
            bash-3226    [011] .....   313.300428: hda_send_cmd: [0000:58:00.4:0] val=0x00870500
            bash-3226    [011] .....   313.300466: hda_get_response: [0000:58:00.4:0] val=0x00000000
...

 

[setzer69a]

sorry im not even there.....currently stuck just before installer. It stopped while booting

 

[Bansaku]

I posted some thoughts here:

https://forum.amd-osx.com/threads/need-help-with-ryzen-7700x-gigabyte-x670e.3656/page-20#post-26149

My thoughts are I just scored a used Aorus 6800 XT (the one with the LCD screen), and couldn't be happier! Not willing to be a guinea pig, nor drop $1400 CAD on a non-guarantee, however I am willing to snatch up a 2nd hand card on GPU launch day!

 

[CaseySJ]

** Other Lessons from Linux: PCI Quirks **​

The Linux source code for ALSA (Advanced Linux Sound Architecture) reveals a handful of (a) PCI patches and a handful of (b) HDA Verb patches being applied to AMD platforms. In the previous post we collected all of the HDA Verbs. In this post we examine the PCI patches and implement two of them in AppleALC.

File hda_intel.c defines a set of PCI patches for the 3 most common HDA controllers on AMD platforms:

• Device 0x1457
• Device 0x1487
• Device 0x15e3

The set is named AZX_DCAPS_PRESET_AMD_SB.

The same file reveals the contents of the set AZX_DCAPS_PRESET_AMD_SB, which includes:

• AZX_DCAPS_NO_TCSEL
• AZX_DCAPS_AMD_WORKAROUND
• AZX_DCAPS_SNOOP_TYPE(ATI)
• AZX_DCAPS_PM_RUNTIME
• AZX_DCAPS_RETRY_PROBE

Two of the quirks are implemented in the bus initialization procedure azx_init_pci shown below:

• AZX_DCAPS_NO_TCSEL
• AZX_DCAPS_SNOOP_TYPE(ATI)

We can implement the same two quirks in AppleALC and enable the quirks with boot argument alctcsel=1 as follows:

Unfortunately, compiling the changes and running the new kext does not fix our microphone and line-in problem. But the problem does not exist in Linux, so the solution must also lie in Linux!

So what about the other 3 quirks?

• AZX_DCAPS_AMD_WORKAROUND
  • This instructs the Linux sound driver to implement a FIFO position fix. The reference in hda_intel.c:
    

    static int azx_get_delay_from_fifo(struct azx *chip, struct azx_dev *azx_dev,
                       unsigned int pos)
    {
        struct snd_pcm_substream *substream = azx_dev->core.substream;
    
        /* just read back the calculated value in the above */
        return substream->runtime->delay;
    }

  • This function is called through the get_delay function pointer in hda_controller.c:
    

    unsigned int azx_get_position(struct azx *chip,
                      struct azx_dev *azx_dev)
    {
        struct snd_pcm_substream *substream = azx_dev->core.substream;
        unsigned int pos;
        int stream = substream->stream;
        int delay = 0;
    
        if (chip->get_position[stream])
            pos = chip->get_position[stream](chip, azx_dev);
        else /* use the position buffer as default */
            pos = azx_get_pos_posbuf(chip, azx_dev);
    
        if (pos >= azx_dev->core.bufsize)
            pos = 0;
    
        if (substream->runtime) {
            struct azx_pcm *apcm = snd_pcm_substream_chip(substream);
            struct hda_pcm_stream *hinfo = to_hda_pcm_stream(substream);
    
            if (chip->get_delay[stream])
                delay += chip->get_delay[stream](chip, azx_dev, pos);
            if (hinfo->ops.get_delay)
                delay += hinfo->ops.get_delay(hinfo, apcm->codec,
                                  substream);
            substream->runtime->delay = delay;
        }
    
        trace_azx_get_position(chip, azx_dev, pos, delay);
        return pos;
    }

  • This quirk might be relevant.
• AZX_DCAPS_PM_RUNTIME
  • Seems to indicate that the chip supports power management
  • If so, no need to worry about it because IOPCIFamily and AppleHDAController manages it
• AZX_DCAPS_RETRY_PROBE
  • This is used during codec probe to query all the nodes and capabilities. Because AppleALC is able to query the codec properly, this quirk does not seem to be needed. It is used in the Linux function azx_probe_continue in the file hda_intel.c:
    

    probe_retry:
        if (bus->codec_mask && !(probe_only[dev] & 1)) {
            err = azx_codec_configure(chip);
            if (err) {
                if ((chip->driver_caps & AZX_DCAPS_RETRY_PROBE) &&
                    ++hda->probe_retry < 60) {
                    schedule_delayed_work(&hda->probe_work,
                                  msecs_to_jiffies(1000));
                    return 0; /* keep things up */
                }
                dev_err(chip->card->dev, "Cannot probe codecs, giving up\n");
                goto out_free;
            }
        }

---

Supplemental Info on AZX_DCAPS_AMD_WORKAROUND:

Source: https://docs.kernel.org/sound/hd-audio/notes.html#hd-audio-controller

 

[CaseySJ]

** AppleALC Full Verb Log **​

In the earlier post entitled Detailed HDA Verb Capture in Linux we looked at the full verb sequence for initializing the HDA codec in Linux. Linux manages to initialize the codec in a mere 200 or so verbs. In this post we examine the equivalent log from AppleALC running in Monterey 12.6.2 on Gigabyte B550 Vision D with Realtek ALC-1220.

AppleALC / AppleHDA issue a far greater number of verbs. I've commented a few of the lines such as this:


Having the full verbs from both Linux and macOS enables us to perform a head-to-head comparison.

 

[Galve2000]

An OpenCore log file will be created in the top folder of the EFI partition. It will contain MMIO Whitelist entries.

Attached are 2 logs created when using the debug version of OC 0.87. I hope this is helpful. please let me know.

@CaseySJ:

Can I borrow your EFI as a jumping off point?

To add insult to injured x16 PCI slot, I was not able to purchase a 7900 XTX in time and now they are all sold out. (never mind that these cards are so thick, they may bot fit into the x8 slot on my X670E Creator.

 

[mariettosun]

Attached are 2 logs created when using the debug version of OC 0.87. I hope this is helpful. please let me know.

both logs are to small
I think if you are sure is an Opencore Debug version , maybe you miss target value to set 67

 

[mariettosun]

maybe next betas...will add support

 

[CaseySJ]

maybe next betas...will add support

WOW WOW WOW!!

It looks as if Apple and/or AMD have refactored (redesigned) the NAVI drivers. Now why would they do that if they intend to stop support for all further AMD GPUs?

Can you please post Info.plist from the AMDRadeonX6000 kext?

And why are there so many individual drivers?

• AMDRadeonX6000HWLibs
• AMDRadeonX6100HWLibs
• AMDRadeonX6200HWLibs
• AMDRadeonX6300HWLibs
• AMDRadeonX6700HWLibs
• AMDRadeonX6800HWLibs
• AMDRadeonX6810HWLibs

What, oh what, could it mean? Looks like AMDRadeonX6000Shared.bundle and AMDRadeonX6000GLDriver.bundle have been refactored.

• AMDRadeonX6000HWLibs
  • 6500 series?
• AMDRadeonX6100HWLibs
  • 6600 series?
• AMDRadeonX6200HWLibs
  • What's this?
• AMDRadeonX6300HWLibs
  • What's this?
• AMDRadeonX6700HWLibs
  • 6700 series? Support does not exist today
• AMDRadeonX6800HWLibs
  • 6800 series?
• AMDRadeonX6810HWLibs
  • 6900 / 6950 series?

Could any of them be for 7900 series?



There are plenty of AMD reference 7900 XTs available right now on AMD's US website.

 

[ExtremeXT]

View attachment 9068
maybe next betas...will add support

Can you send all of the X6000 kexts? I'll try checking if there is any mention at all of the new device IDs.

 

[CaseySJ]

I am also intrigued by this, because it doesn't exist in Ventura 13.1:

Ventura 13.2 beta 1:



Here's Ventura 13.1:

Can you also post Info.plist from AirPortBrcmNIC?

 

[Edhawk]

It does existing in Ventura 13.1.

System Information > Software > Extensions - Ventura 13.1

However, it is not loaded on any of my systems that use a native Apple Broadcom WiFi/BT card.

I just realised that only one kext is showing as loaded in my iMac19,1 system.
Only 2 x kexts are showing as Notarised and signed.

Extensions report sorted by Loaded, with those set as Yes set to be at the top of the list.

Bug in Ventura 13.1, we will probably get an update to 13.1.1 shortly.

 

[CaseySJ]

It does existing in Ventura 13.1.

View attachment 9075 System Information > Software > Extensions - Ventura 13.1

However, it is not loaded on any of my systems that use a native Apple Broadcom WiFi/BT card.

Yes it exists inside of IO80211PCIFamilyLegacy, but I'm wondering why it was moved out of there and placed directly into /System/Library/Extensions as its own parent-level driver...

 

[CaseySJ]

Nevermind -- the whole thing was a false alarm.

I thought we were looking at /System/Library/Extensions, but instead the screenshot is from System Information --> Extensions. So actually there's nothing new.

This is from Monterey:

 

[ExtremeXT]

Nevermind -- the whole thing was a false alarm.

I thought we were looking at /System/Library/Extensions, but instead the screenshot is from System Information --> Extensions. So actually there's nothing new.

This is from Monterey:
View attachment 9077

That doesn't mean there's no new code, even if not finished for the new GPUs, we should still check.

 

[CaseySJ]

That doesn't mean there's no new code, even if not finished for the new GPUs, we should still check.

I would expect a new AMDRadeonX7000 driver set, but there’s no harm in checking out the Info.plist files.

 

[mariettosun]

Easyupload.io - Upload Files and Share Them Easily

Uplaod files easily and share them with your friends and colleagues. File upload solution for everyone. Upload big files and get a link to share effortlesly.

easyupload.io

here you go