trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[iGPU]

10 hours ago, Jaidy said:

That one has been working without any problems, and swapping the Brio with 920 eradicates the USB issues. This could be an issue with power draw, but its just that this problem does not arise in Manjaro, or with my MacBook Pro (though as the MBP only has two USB ports, it could be that it can provide ample power). So in that sense, it could be an OS issue. There are reports of such problems over the web, and one simple solution is getting a powered hub. Other solutions were more technical of creating a SSDT for USB ports, which after going through a tutorial by RehabMan is a bit too technical for me (plus that is for X299 motherboard, which I am not sure would be the same procedure for Trx40?)..

 

I don't think an SSDT will help. It sounds more like a Logitech, macOS driver problem. I'd try a powered hub as a work-around; this is the one I use.

 

Edited September 30, 2020 by iGPU

[Rox67er]

Updated my Big Sur to latest beta and open core 0.6.2 with latest kext. Still trying to solve my sleep issue. In Catalina system just freezes (display stays on only showing wallpaper) but in Big Sur it sleeps and immediately wakes up again. Initially thought usb related but removed all external usb devices without result. Also disabled network wake and toggled USB power in S5.

 

In "pmset -g log" I found the following, anybody a clue what this D0A1 D0A2 ...  is all about?

2020-09-30 23:47:38 +0200 DarkWake            	DarkWake from Normal Sleep [CDN] : due to D0A1 D0A2 D0A3 D0A4 D0A5 D0A6 D0A7 D0B0 D0B1 D0B2 D0B3 D0B4 D0B5 D0B6 D0B7 D1A0 D1A1 D1A2 D1A3 D1A4 D1A5 D1A6 D1A7 D1B0 D1B1 D/ Using AC (Charge:0%) 8 secs    

 

btw I just deleted my proxmox drive and went full bare metal. 😎👍

[Driftwood]

On 9/29/2020 at 12:11 PM, fojerhar said:

External power never was connected (I also don't have any kind of cable for

 

Thats your problem. You need to get a sata to 4 pin cable from Startech or other suppliers.

 

 

Edited September 30, 2020 by Driftwood

[iGPU]

4 hours ago, Rox67er said:

Updated my Big Sur to latest beta and open core 0.6.2 with latest kext. Still trying to solve my sleep issue. In Catalina system just freezes (display stays on only showing wallpaper) but in Big Sur it sleeps and immediately wakes up again. Initially thought usb related but removed all external usb devices without result. Also disabled network wake and toggled USB power in S5.

 

In "pmset -g log" I found the following, anybody a clue what this D0A1 D0A2 ...  is all about?

2020-09-30 23:47:38 +0200 DarkWake            	DarkWake from Normal Sleep [CDN] : due to D0A1 D0A2 D0A3 D0A4 D0A5 D0A6 D0A7 D0B0 D0B1 D0B2 D0B3 D0B4 D0B5 D0B6 D0B7 D1A0 D1A1 D1A2 D1A3 D1A4 D1A5 D1A6 D1A7 D1B0 D1B1 D/ Using AC (Charge:0%) 8 secs    

 

btw I just deleted my proxmox drive and went full bare metal. 😎👍

 

D0A1...D1B1 are devices seen in the DSDT file:

 

 

I don't see such a listing of devices. When I run the same command, after running Sleep, then awakening again, I see the following (sleep was enabled for about 15 sec, which is what is shown in an excerpt of the results, below).

Spoiler

 

[Rox67er]

2 hours ago, iGPU said:

 

D0A1...D1B1 are devices seen in the DSDT file:

 

 

I don't see such a listing of devices. When I run the same command, after running Sleep, then awakening again, I see the following (sleep was enabled for about 15 sec, which is what is shown in an excerpt of the results, below).

  Reveal hidden contents

 

Thanks @iGPU I was thinking of looking in DSDT last night but needed to get some sleep. If you also have them and they don’t wake-up your system I guess it must be some bios setting still.

[Rox67er]

Some hints in the code: "Power Resources for Wake" well that seems about right... 😂 and "PCI Routing Table" I will check my Bios again... Do you see any difference compared to yours @iGPU ?

 

            Device (D0A0)
            {
                Name (_ADR, 0x00010001)  // _ADR: Address
                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (GPRW (0x08, 0x04))
                }

                Method (_PRT, 0, NotSerialized)  // _PRT: PCI Routing Table
                {
                    If (PICM)
                    {
                        Return (AG04) /* \_SB_.AG04 */
                    }

                    Return (PG04) /* \_SB_.PG04 */
                }

                Device (D0A7)
                {
                    Name (_ADR, 0xFFFF)  // _ADR: Address
                }
            }

            Device (D0A1)
            {
                Name (_ADR, 0x00010002)  // _ADR: Address
                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (GPRW (0x08, 0x04))
                }

                Method (_PRT, 0, NotSerialized)  // _PRT: PCI Routing Table
                {
                    If (PICM)
                    {
                        Return (AG05) /* \_SB_.AG05 */
                    }

                    Return (PG05) /* \_SB_.PG05 */
                }

                Device (D0A8)
                {
                    Name (_ADR, 0xFFFF)  // _ADR: Address
                }
            }

I also noticed when scrolling through IOService that I see several lines with red strike through. When hovering it shows a discovered and terminated timestamp??? (screenshot below)

[Rox67er]

Well about to give up on getting sleep working, @Driftwood is your AsRock sleeping in Catalina / Big Sur? Would you be so kind to share EFI and deviations from BIOS defaults?

 

Thanks all for your support. 👍

[ckrueger99]

Since it seems likely that MacOS 16.0 or 16.1 will support Big Navi, I thought it might be useful to understand how the AMD (and nVidia, for comparison) GPU product stack will likely shake out in the coming months, according to an excellent video from "Moore's Law is Done"

 

(Quadra RTX A5000)

Navi 21         (Prosumer)     32GB GDDR6, 80 CU 256 bit memory bus, $2-3000, Q1

(RTX 3090 $1499)

Navi 21         RX 6900 XT    16GB GDDR6, 80 CU 256 bit memory bus, $699 Nov'20
(Also, possible liquid version.)

(RTX 3080TI 20gb?)

Navi 21            RX 6800 XT    16GB GDDR6, 72 CU 256 bit, $599 Dec'20
Navi 21            RX 6800        8GB GDDR6, 60 CU 256 bit, $450

(RTX 3080 $699)

Navi 22         RX 6700 XT    12GB GDDR6, 40 CU 192 bit mem bus $400 Q1

(3070TI 16gb)

Navi 22        RX 6700        10GB GDDR6, 36 CU 192 bit $300-350

(RTX 3070 $499)

Navi 23        RX 6500 XT    8 GB GDDR6, 32 CU 128 bit $200-250 Q2 or Q3

(RTX 3060TI mid Oct)

[meina222]

Some of these video card timelines are probably overly optimistic. This one https://www.amd.com/en/products/professional-graphics/radeon-pro-vii for example was announced on May 13 2020 and you still can't buy it anywhere. So expect stock issues for another 6 months at least.

[Ploddles]

19 hours ago, Rox67er said:

Initially thought usb related but removed all external usb devices without result. Also disabled network wake and toggled USB power in S5.

 

btw I just deleted my proxmox drive and went full bare metal. 😎👍

 

Have you also tested by removing all internal USB devices as well, i.e. don't connect any of your case usb cables etc to the headers on the MB?

[Rox67er]

16 hours ago, Ploddles said:

 

Have you also tested by removing all internal USB devices as well, i.e. don't connect any of your case usb cables etc to the headers on the MB?

Yes, the only ones I couldn't disconnect are:

- Onboard LED controller (disabled in bios but still visible in MacOS)

- Onboard Bluetooth (Swapped for a Broadcom BCM94360NG) works without any kext

- Onboard USB Audio (works with alcid=11)

[fabiosun]

@Rox67er

on board usb Realtek audio and alcid boot arg are not related...

 

[fojerhar]

On 10/1/2020 at 1:34 AM, Driftwood said:

 

Thats your problem. You need to get a sata to 4 pin cable from Startech or other suppliers.

 

 

Hi

Got the power cables, didn't help

Ordered the same card as yours, same results

If I didn't wrote, all cards, all ports are working fine all slots under windows, so bios wise and phisically they are okay

ioreg shows, that kext is loaded, but.... 

tried different smbioses also, installed a new virgin catalina, high sierra also, to an external drive, removed all the kexts, removed everything to basic default at opencore config

at other forum they wrote that this is an amd problem, but not, because it is working for you

nowdays this is our only option with OC isnt it?

https://dortania.github.io/OpenCore-Install-Guide/AMD/zen.html

tried to force load iofirewire.kext at efi, original and olders also (read somewhere for someone the older mavericks kext solved the problem)

my config is attached, if I made a big donkey mistake there....

thank you 🙂

config.plist.zip

[iGPU]

1 hour ago, fojerhar said:

Hi

Got the power cables, didn't help

Ordered the same card as yours, same results

If I didn't wrote, all cards, all ports are working fine all slots under windows, so bios wise and phisically they are okay

ioreg shows, that kext is loaded, but.... 

tried different smbioses also, installed a new virgin catalina, high sierra also, to an external drive, removed all the kexts, removed everything to basic default at opencore config

at other forum they wrote that this is an amd problem, but not, because it is working for you

nowdays this is our only option with OC isnt it?

https://dortania.github.io/OpenCore-Install-Guide/AMD/zen.html

tried to force load iofirewire.kext at efi, original and olders also (read somewhere for someone the older mavericks kext solved the problem)

my config is attached, if I made a big donkey mistake there....

thank you 🙂

config.plist.zip 6.49 kB · 0 downloads

 

Firewire is natively loaded with macOS (at least through Big Sur); there are no extra kexts to load and there is no impact by usual SMBIOS that we use (I'd recommend iMacPro1,1 as any SMBIOS with an internal GPU is not a good idea with the TRX40 build). I've used Firewire AIC on each of my builds without issue (Intel X99, Z390, X299 and AMD X570, TRX40 with macOS ranging from Mtn Lion to Big Sur). In other words, Firewire just works with macOS.

 

Further, the OC boot loader has little influence aside from injecting properties via an SSDT or DevProp (well, if you want to boot from a Firewire device, then you must re-calculate the ScanPolicy; but you shouldn't try this until the Firewire port is actually working). Further, an inoperable Firewire device will have nothing to do with AMD or patches. As long as you're booting into macOS, your patches are fine. 

 

I think your problem is related to the type of device you're trying to connect to the Firewire port. And what exactly is/are the Firewire device(s) that you're trying to connect? (Testing with a Firewire hard drive is the most certain method to verify the Firewire connection.)

 

To clarify so that I understand you, when you boot into Windows, you can connect a Firewire device and use it? If the Windows response is 'yes, I can connect a device to the Firewire port and it works', then it should work in macOS, but with some caveats.

 

Again, I would suggest connecting an external Firewire hard drive to test. However, If you don't have a hard drive and you're using an audio device, it will require a software driver, supplied by the manufacturer of the audio device, to interface between macOS and the Firewire audio device. If the software driver is not present or not working, then this device will not work under macOS (despite working under Windows because the proper Windows driver was installed). This is why I'd trouble shoot with an external Firewire hard drive, not a complicated audio device. If you insist on testing with an audio device, and you're certain that the driver was installed and the Firewire device won't connect, then it must be a problem with that macOS and the manufacturer's driver. At that point, you'd need to contact the manufacturer of the audio device. If the driver cannot work with Catalina or later, you might have to revert to Mojave or an earlier macOS for compatibility.

[fojerhar]

3 hours ago, iGPU said:

 

Firewire is natively loaded with macOS (at least through Big Sur); there are no extra kexts to load and there is no impact by usual SMBIOS that we use (I'd recommend iMacPro1,1 as any SMBIOS with an internal GPU is not a good idea with the TRX40 build). I've used Firewire AIC on each of my builds without issue (Intel X99, Z390, X299 and AMD X570, TRX40 with macOS ranging from Mtn Lion to Big Sur). In other words, Firewire just works with macOS.

 

Further, the OC boot loader has little influence aside from injecting properties via an SSDT or DevProp (well, if you want to boot from a Firewire device, then you must re-calculate the ScanPolicy; but you shouldn't try this until the Firewire port is actually working). Further, an inoperable Firewire device will have nothing to do with AMD or patches. As long as you're booting into macOS, your patches are fine. 

 

I think your problem is related to the type of device you're trying to connect to the Firewire port. And what exactly is/are the Firewire device(s) that you're trying to connect? (Testing with a Firewire hard drive is the most certain method to verify the Firewire connection.)

 

To clarify so that I understand you, when you boot into Windows, you can connect a Firewire device and use it? If the Windows response is 'yes, I can connect a device to the Firewire port and it works', then it should work in macOS, but with some caveats.

 

Again, I would suggest connecting an external Firewire hard drive to test. However, If you don't have a hard drive and you're using an audio device, it will require a software driver, supplied by the manufacturer of the audio device, to interface between macOS and the Firewire audio device. If the software driver is not present or not working, then this device will not work under macOS (despite working under Windows because the proper Windows driver was installed). This is why I'd trouble shoot with an external Firewire hard drive, not a complicated audio device. If you insist on testing with an audio device, and you're certain that the driver was installed and the Firewire device won't connect, then it must be a problem with that macOS and the manufacturer's driver. At that point, you'd need to contact the manufacturer of the audio device. If the driver cannot work with Catalina or later, you might have to revert to Mojave or an earlier macOS for compatibility.

Thank you

You was right, I was missing the testing with a hard drive.

I did it now, the drive was popped up for me in windows with macdrive, but not in osx.

 

And yes, in windows everything is fine.

 

I checked the UAD Apollo 16 interface with my laptop with catalina, and works well trough a TB3-Firewire adaptor (i have only thunderbolts in my MBP 14,3), and the latest driver was not needed for catalina compatibility, and with the trx40 I tried the same and the latest also (i can see at boot, that the UAD kext is loaded at the last step in verbose mode)

and my MBP was the testing hard drive, started in target mode and was working trough adapters in windows. (my old external firewire hd power adaptor is dead)

 

I also used firewire in the last 8 years without any problems in the hacks z370 and earlier too, thats why this issue is strange for me, should work easily

[Rox67er]

11 hours ago, fabiosun said:

@Rox67er

on board usb Realtek audio and alcid boot arg are not related...

 

interesting so it should work without kext and alcid=11?

I used iGPU efi initially (I think) which had alcid=1 and got digital noise from front headphone jack. after changing to alcid=11 it worked fine.

Will try without kext later this weekend.

[iGPU]

On 10/2/2020 at 11:33 AM, fojerhar said:

Thank you

You was right, I was missing the testing with a hard drive.

I did it now, the drive was popped up for me in windows with macdrive, but not in osx.

 

And yes, in windows everything is fine.

 

I checked the UAD Apollo 16 interface with my laptop with catalina, and works well trough a TB3-Firewire adaptor (i have only thunderbolts in my MBP 14,3), and the latest driver was not needed for catalina compatibility, and with the trx40 I tried the same and the latest also (i can see at boot, that the UAD kext is loaded at the last step in verbose mode)

and my MBP was the testing hard drive, started in target mode and was working trough adapters in windows. (my old external firewire hd power adaptor is dead)

 

I also used firewire in the last 8 years without any problems in the hacks z370 and earlier too, thats why this issue is strange for me, should work easily

 

I would concentrate on getting the Firewire drive to mount in macOS (before working on the UAD device).

 

Have you tested booting into macOS with the Firewire drive already connected before turning on computer?

 

 

Edited October 3, 2020 by iGPU

[fabiosun]

hi to all

Someone of you are trying to boot our trx40 chip with latest clover boot loader?

Testing from some days here but for now it is not possible to boot fine.

It uses a part of Opencore booting pipeline but It seems it is affected from the problem I have had on January with old OpenCore bootloader

 

 

[iGPU]

 

I initially tried booting TRX40 with Clover (both VM and bare metal) and had no success. OpenCore works so well, I don't see why to use Clover any longer (except for nostalgia).

 

A couple of weeks ago, I spent time converting other builds (X299 and Z390) completely over to latest OpenCore from Clover. I only go forward with OpenCore.

[fabiosun]

In VM is possible to boot with both bootloaders 

In baremetal no

when you have to test stuff to have the chance to do some modify  in bootloader menu is a very good option in my opinion

so I hope a day it could be an option to boot with clover ☘️ 

[Rox67er]

On 10/3/2020 at 12:13 AM, Rox67er said:

interesting so it should work without kext and alcid=11?

I used iGPU efi initially (I think) which had alcid=1 and got digital noise from front headphone jack. after changing to alcid=11 it worked fine.

Will try without kext later this weekend.

@fabiosun confirmed that without AppleALC.kext audio also seems to work fine. Still interesting that setting alcid=1 messes up audio from headphone jack.

[fabiosun]

@Rox67er check also if you have some device properties in your opencore config

our usb audio is a bridged usb audio with 2 chip, maybe some features need of applealc and alcid bootarg (headphone? Mic?) not tested by me so much because in highsierra internal audio does not work

 

[Jaidy]

2 hours ago, fabiosun said:

@Rox67er check also if you have some device properties in your opencore config

our usb audio is a bridged usb audio with 2 chip, maybe some features need of applealc and alcid bootarg (headphone? Mic?) not tested by me so much because in highsierra internal audio does not work

 

Would an external (USB connected) DAC require the AppleALC kext? Or an SSDT, settings in the config.plist?

[Rox67er]

49 minutes ago, Jaidy said:

Would an external (USB connected) DAC require the AppleALC kext? Or an SSDT, settings in the config.plist?

I have an behringer umc 404HD usb audio interface which also seems to work fine without the AppleALC next. 

[fabiosun]

@Jaidyall usb audio should work fine with internal apple usb audio driver

if there is not a specific driver from audio manufacturer