MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0

[ariethekid]

So I got an RTX 2080ti for my Mac Pro 5,1 (2010) a few days ago. I had 144.0.0.0.0 initially before installing windows on a separate SATA SSD. I was having trouble booting up after installing the RTX 2080ti from the Bootcamp drive I setup with a DVD a while back. I would just get a white screen and Windows would never boot. I couldn't find the DVD so I made the mistake of reinstalling with a USB drive thinking it was an issue with my Windows drive. I've read through the thread and seems like that was a bad idea. Looks like I installed Windows 10 in EFI mode but now the graphics card WORKS!! I get it fully working in Windows 10 EFI, and 4K full resolution with no acceleration (as expected since no drivers) but at least full resolution. Works ok.

SO I guess the RTX or at least the one I have doesn't support legacy BIOS? I dumped the bios and binwalk'ed it? (is that a word?)

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1184537 0x121319 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1250073 0x131319 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume


Based on reading the thread looks like I have 2 x509 certificates in there?
This computer has never had Windows installed in EFI mode ever and was a dedicated Mac only machine with only legacy windows 10 maybe 6 months ago.

Still works fine and boots no problem with boot screen and all as expected.

How would I go about removing those certificates. And furthermore, How can I go about preventing them from coming back if I left the EFI windows install? Can we block windows from pushing those certificates?

 

[tsialex]

So I got an RTX 2080ti for my Mac Pro 5,1 (2010) a few days ago. I had 144.0.0.0.0 initially before installing windows on a separate SATA SSD. I was having trouble booting up after installing the RTX 2080ti from the Bootcamp drive I setup with a DVD a while back. I would just get a white screen and Windows would never boot. I couldn't find the DVD so I made the mistake of reinstalling with a USB drive thinking it was an issue with my Windows drive. I've read through the thread and seems like that was a bad idea. Looks like I installed Windows 10 in EFI mode but now the graphics card WORKS!! I get it fully working in Windows 10 EFI, and 4K full resolution with no acceleration (as expected since no drivers) but at least full resolution. Works ok.

SO I guess the RTX or at least the one I have doesn't support legacy BIOS? I dumped the bios and binwalk'ed it? (is that a word?)

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1184537 0x121319 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1250073 0x131319 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume


Based on reading the thread looks like I have 2 x509 certificates in there?
This computer has never had Windows installed in EFI mode ever and was a dedicated Mac only machine with only legacy windows 10 maybe 6 months ago.

Still works fine and boots no problem with boot screen and all as expected.

How would I go about removing those certificates. And furthermore, How can I go about preventing them from coming back if I left the EFI windows install? Can we block windows from pushing those certificates?

AFAIK, RTX GPUs require EFI Windows.

EFI Windows 8.1/10 installs always will re-sign the BootROM, so it's useless to remove it since it will sign it again at the next boot.

Only Microsoft can blacklist SecureBoot with MP5,1, a user here who works at Microsoft opened an internal bug report some months ago, nothing that a user can do about it besides keeping a saved BootROM dump for any eventual problem.

 

[lxmeta]

Should be 228.0.0.0.0, since it uses the same firmware as MBP9,1, no?

Definitely 229! Can send a screenshot tomorrow.

 

[ariethekid]

AFAIK, RTX GPUs require EFI Windows.

EFI Windows 8.1/10 installs always will re-sign the BootROM, so it's useless to remove it since it will sign it again at the next boot.

Only Microsoft can blacklist SecureBoot with MP5,1, a user here who works at Microsoft opened an internal bug report some months ago, nothing that a user can do about it besides keeping a saved BootROM dump for any eventual problem.

Did we ever figure out what was causing the bricks? Was it indeed repetitive signing of the 509 certs or was it more complicated than that?

 

[tsialex]

Did we ever figure out what was causing the bricks? Was it indeed repetitive signing of the 509 certs or was it more complicated than that?

MP51.0087.B00 bricks were caused by crashing during re-sign process because the of missing microcodes, but some people never used this BootROM version and bricked anyway, so could be that the constant re-sign is triggering cell exhaustion after all these years. I had to replace the SPI flash for one of my backplanes because the memory failed write verification, other people had to do the same. Since then when I need to desolder a SPI flash to repair another backplane, I solder a new SPI flash memory instead.

 

[ariethekid]

MP51.0087.B00 bricks were caused by crashing during re-sign process because the of missing microcodes, but some people never used this BootROM version and bricked anyway, so could be that the constant re-sign is triggering cell exhaustion after all these years. I had to replace the SPI flash for one of my backplanes because the memory failed write verification, other people had to do the same. Since then when I need to desolder a SPI flash to repair another backplane, I solder a new SPI flash memory instead.

If I dump the rom image with the ROMtool would I be able to use that same dump to flash to say a MX25L3205D? That's what I have now. Do I have to modify the file or can I just use a basic programmer like a CH341A to flash it directly back on to a new chip? Or are you making dumps of the chip with a clip and programmer?

I haven't flashed Mac Pro EEPROMs before but I've done a bit of chip programming in other applications.

 

[tsialex]

If I dump the rom image with the ROMtool would I be able to use that same dump to flash to say a MX25L3205D? That's what I have now. Do I have to modify the file or can I just use a basic programmer like a CH341A to flash it directly back on to a new chip? Or are you making dumps of the chip with a clip and programmer?

I haven't flashed Mac Pro EEPROMs before but I've done a bit of chip programming in other applications.

A flashrom/ROMTool DUMP can be used without any modification. Go back around September last year and see several of my posts describing what is needed to do.

 

[lxmeta]

AFAIK, RTX GPUs require EFI Windows.

EFI Windows 8.1/10 installs always will re-sign the BootROM, so it's useless to remove it since it will sign it again at the next boot.

Only Microsoft can blacklist SecureBoot with MP5,1, a user here who works at Microsoft opened an internal bug report some months ago, nothing that a user can do about it besides keeping a saved BootROM dump for any eventual problem.

Should be 228.0.0.0.0, since it uses the same firmware as MBP9,1, no?

See screenshot below. The 9,2 either does not show up in "latest ROM" lists, or shows up as the same as 9,1. I can check which build of Catalina this ROM came with. Still have the disk somewhere at home.

 

[tsialex]

Catalina DP8 just released, build 19558d. New firmwares btw.

macOS Catalina Beta (full installer)061-11434 8,57GB
macOS Catalina Developer Beta (delta) 061-11431 8,49GB
BridgeOSUpdateCustomer 061-11430 428MB
EFICheck AllowListAll 061-03988 62,2MB

 

[tsialex]

All Catalina supported Macs got firmware updates, some EFI versions got updated to two revisions over the previously released firmwares, from DP7.

MP6,1 got updated to 133.0.0.0.0:

$IBIOSI$ MP61.88Z.F000.B00.1907241309
Copyright (c) 2005-2019 Apple Inc.  All rights reserved.
Apple ROM Version
  Model:        MP61
  EFI Version:  133.0.0.0.0
  Built by:     root@saumon
  Date:         Wed Jul 24 13:09:53 PDT 2019
  Revision:     133 (B&I)
  ROM Version:  F000_B00
  Build Type:   Official Build, Release
  Compiler:     Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)

iMac19,1 back to clang 11.0.0:

Apple ROM Version
  BIOS ID:      IM191.88Z.F000.B00.1908201755
  Model:        IM191
  EFI Version:  1037.0.62.0.0
  Built by:     _securitya@osx340
  Date:         Tue Aug 20 17:55:09 2019
  Revision:     1037.0.62 (B&I)
  ROM Version:  F000_B00
  Build Type:   Official Build, RELEASE
  Compiler:     Apple clang version 11.0.0 (clang-1100.0.32.4) (-macos10.15-objc-selec
  UUID:         E25F83A1-3371-3F04-A8E8-4F423FD7DBD8
  UUID:         3C7B961D-B425-300F-AD02-57AFA13BF1E4

[doublepost=1568148376][/doublepost]All non-BridgeOS Catalina DP8 EFI firmware versions:

Mac:	EFI version:
IM13,1	288.0.0.0.0
IM14,1	140.0.0.0.0
IM14,2	140.0.0.0.0
IM14,3	140.0.0.0.0
IM14,4	200.0.0.0.0
IM15,1	231.0.0.0.0
IM16,1	231.0.0.0.0
IM16,2	231.0.0.0.0
IM17,1	171.0.0.0.0
IM18,1	176.0.0.0.0
IM18,3	176.0.0.0.0
IM19,1	1037.0.62.0.0
MB10,1	179.0.0.0.0
MB8,1	185.0.0.0.0
MB9,1	185.0.0.0.0
MBA5,1	260.0.0.0.0
MBA6,1	118.0.0.0.0
MBA7,1	190.0.0.0.0
MBP10,1	258.0.0.0.0
MBP10,2	281.0.0.0.0
MBP11,1	157.0.0.0.0
MBP11,2	157.0.0.0.0
MBP11,4	195.0.0.0.0
MBP12,1	187.0.0.0.0
MBP13,1	238.0.0.0.0
MBP13,2	260.0.0.0.0
MBP13,3	260.0.0.0.0
MBP14,1	200.0.0.0.0
MBP14,2	200.0.0.0.0
MBP14,3	200.0.0.0.0
MBP9,1	229.0.0.0.0
MM6,1	281.0.0.0.0
MM7,1	245.0.0.0.0
MP6,1	133.0.0.0.0

 

[MisterAndrew]

See screenshot below. The 9,2 either does not show up in "latest ROM" lists, or shows up as the same as 9,1. I can check which build of Catalina this ROM came with. Still have the disk somewhere at home.

My 9,1 also had version 229 before DP8. Can't recall exactly when it updated to that. Maybe it was the last Mojave supplemental update.

 

[ariethekid]

A flashrom/ROMTool DUMP can be used without any modification. Go back around September last year and see several of my posts describing what is needed to do.

How could I go about cleaning up the ROM dump that I have just for safe keeping? and flash a new EEPROM in case I have an issue with that down the road?

Appreciate all the work you put into all this mac stuff BTW. major props.

 

[tsialex]

How could I go about cleaning up the ROM dump that I have just for safe keeping? and flash a new EEPROM in case I have an issue with that down the road?

Appreciate all the work you put into all this mac stuff BTW. major props.

Like I said, it's useless with EFI Windows. Just save your dump.

 

[Rezblah]

Ok good news and bad on my attempted update to 2 samsung 970pros on the crest I/O bifurcation riser...

Good - firmware upgrades to 144.0 all done successfully and Mojave 14.6 installed on sata SSD

the 970s I ended up formatting one at a time on my lycom D-120, all good but neither are installed now as my current 951 AHCI boot drive is on that lycom adapter (on Sierra)

Bad: the machine won't see the I/O Crest card in slot 2. It's an I/O Crest SI-PEX 40219 bifurcation riser, but it can't be seen with the 2 formatted 970's installed on it booting from the mojave drive

Probably a topic for another thread but I can find sfu all this card and this issue - only success stories!

Tried looking for drivers but no luck

Put it in slot 3 and it briefly showed up, put the lycom back in and it disappeared again and I haven't got the IO visible in any slot, but it needs to be in slot 2 to work properly doesn't it? It says windows support on the box but people are using these so I must be missing something obvious

Fingers crossed that someone can help otherwise this is looking like $300 down the drain!

Oh, all this is on a 2010 6 core 3.33ghz 5.1 btw...

Any help much appreciated!

Cheers all

 

[tsialex]

Ok good news and bad on my attempted update to 2 samsung 970pros on the crest I/O bifurcation riser...

Good - firmware upgrades to 144.0 all done successfully and Mojave 14.6 installed on sata SSD

the 970s I ended up formatting one at a time on my lycom D-120, all good but neither are installed now as my current 951 AHCI boot drive is on that lycom adapter (on Sierra)

Bad: the machine won't see the I/O Crest card in slot 2. It's an I/O Crest SI-PEX 40219 bifurcation riser, but it can't be seen with the 2 formatted 970's installed on it booting from the mojave drive

Probably a topic for another thread but I can find sfu all this card and this issue - only success stories!

Tried looking for drivers but no luck

Put it in slot 3 and it briefly showed up, put the lycom back in and it disappeared again and I haven't got the IO visible in any slot, but it needs to be in slot 2 to work properly doesn't it? It says windows support on the box but people are using these so I must be missing something obvious

Fingers crossed that someone can help otherwise this is looking like $300 down the drain!

Oh, all this is on a 2010 6 core 3.33ghz 5.1 btw...

Any help much appreciated!

Cheers all

Wrong topic, ask here Blade SSDs - NVMe & AHCI.

 

[jaysee_au]

Download the full Mac App Store installer for Mojave, the most recent one (10.14.5), open it and then do as the installer says to upgrade to 144.0.0.0.0. After the firmware upgrade reboot, you can close the installer app. This firmware upgrade requires a METAL supported GPU.

Hi - just confirming from the sticky which references 10.14.5, is this update also in 10.14.6 if I download the full installer from the App Store? Thanks!

 

[tsialex]

Hi - just confirming from the sticky which references 10.14.5, is this update also in 10.14.6 if I download the full installer from the App Store? Thanks!

Yes, same 144.0.0.0.0.

 

[handheldgames]

All Catalina supported Macs got firmware updates, some EFI versions got updated to two revisions over the previously released firmwares, from DP7.

MP6,1 got updated to 133.0.0.0.0:

$IBIOSI$ MP61.88Z.F000.B00.1907241309
Copyright (c) 2005-2019 Apple Inc.  All rights reserved.
Apple ROM Version
  Model:        MP61
  EFI Version:  133.0.0.0.0
  Built by:     root@saumon
  Date:         Wed Jul 24 13:09:53 PDT 2019
  Revision:     133 (B&I)
  ROM Version:  F000_B00
  Build Type:   Official Build, Release
  Compiler:     Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)

iMac19,1 back to clang 11.0.0:

Apple ROM Version
  BIOS ID:      IM191.88Z.F000.B00.1908201755
  Model:        IM191
  EFI Version:  1037.0.62.0.0
  Built by:     _securitya@osx340
  Date:         Tue Aug 20 17:55:09 2019
  Revision:     1037.0.62 (B&I)
  ROM Version:  F000_B00
  Build Type:   Official Build, RELEASE
  Compiler:     Apple clang version 11.0.0 (clang-1100.0.32.4) (-macos10.15-objc-selec
  UUID:         E25F83A1-3371-3F04-A8E8-4F423FD7DBD8
  UUID:         3C7B961D-B425-300F-AD02-57AFA13BF1E4

[doublepost=1568148376][/doublepost]All non-BridgeOS Catalina DP8 EFI firmware versions:

Mac:	EFI version:
IM13,1	288.0.0.0.0
IM14,1	140.0.0.0.0
IM14,2	140.0.0.0.0
IM14,3	140.0.0.0.0
IM14,4	200.0.0.0.0
IM15,1	231.0.0.0.0
IM16,1	231.0.0.0.0
IM16,2	231.0.0.0.0
IM17,1	171.0.0.0.0
IM18,1	176.0.0.0.0
IM18,3	176.0.0.0.0
IM19,1	1037.0.62.0.0
MB10,1	179.0.0.0.0
MB8,1	185.0.0.0.0
MB9,1	185.0.0.0.0
MBA5,1	260.0.0.0.0
MBA6,1	118.0.0.0.0
MBA7,1	190.0.0.0.0
MBP10,1	258.0.0.0.0
MBP10,2	281.0.0.0.0
MBP11,1	157.0.0.0.0
MBP11,2	157.0.0.0.0
MBP11,4	195.0.0.0.0
MBP12,1	187.0.0.0.0
MBP13,1	238.0.0.0.0
MBP13,2	260.0.0.0.0
MBP13,3	260.0.0.0.0
MBP14,1	200.0.0.0.0
MBP14,2	200.0.0.0.0
MBP14,3	200.0.0.0.0
MBP9,1	229.0.0.0.0
MM6,1	281.0.0.0.0
MM7,1	245.0.0.0.0
MP6,1	133.0.0.0.0

Let me guess.. APFS was updated?

 

[narcogen]

Hi.

I have two MP5,1 machines-- one was used with EFI Windows 10 booting only rarely, and the second has been used this way regularly and for quite some time.

I dumped the bootrom for the first machine. Binwalk showed no signatures, and as I had not installed or booted Windows 10 from it in some months, I upgraded it to Mojave and bootrom 144 according to the instructions at the top of the thread, and everything seems fine. The machine has a new legacy BIOS installation of Windows 10 and appears to have no issues.

I dumped the bootrom on the second machine and ran binwalk. This machine is running Sierra and has bootrom version MP51.007F.B03. It also appears to me to have no SecureBoot signatures:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1219863 0x129D17 XML document, version: "1.0"
1235036 0x12D85C XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume

This is the machine that has been used often and for a long time booting into Windows using EFI mode, so we were worried about multiple SecureBoot signatures and possibly bricking it. I would like to upgrade to bootrom 144 according to the instructions at the top of the thread (although without full update to Mojave, as I understand that is possible-- will probably stay with High Sierra).

I have an EFI capable GPU (Radeon 58xx) for the first bootrom update (MP51.0089 from the High Sierra full installer) and a Metal capable one for the 144 update from the Mojave installer (Sapphire Pulse RX580).

Is there any indication from the above binwalk that anything needs to be done to this bootrom before attempting this update, assuming I don't boot into Windows 10 with EFI mode again, ever? I will be doing an install from a Windows 10 DVD onto a vanilla SATA drive after the bootrom is upgraded-- will not be using EFI mode again.

TLDR version: Is this machine safe to update to High Sierra/bootrom MP51.0089 and then to bootrom 144 without cleaning or reconstructing the bootrom and re-flashing, or should that be done first? If I upgrade it and everything works, is there a need to clean or reconstruct the bootrom afterwards?

 

[tsialex]

Hi.

I have two MP5,1 machines-- one was used with EFI Windows 10 booting only rarely, and the second has been used this way regularly and for quite some time.

I dumped the bootrom for the first machine. Binwalk showed no signatures, and as I had not installed or booted Windows 10 from it in some months, I upgraded it to Mojave and bootrom 144 according to the instructions at the top of the thread, and everything seems fine. The machine has a new legacy BIOS installation of Windows 10 and appears to have no issues.

I dumped the bootrom on the second machine and ran binwalk. This machine is running Sierra and has bootrom version MP51.007F.B03. It also appears to me to have no SecureBoot signatures:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1219863 0x129D17 XML document, version: "1.0"
1235036 0x12D85C XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume

This is the machine that has been used often and for a long time booting into Windows using EFI mode, so we were worried about multiple SecureBoot signatures and possibly bricking it. I would like to upgrade to bootrom 144 according to the instructions at the top of the thread (although without full update to Mojave, as I understand that is possible-- will probably stay with High Sierra).

I have an EFI capable GPU (Radeon 58xx) for the first bootrom update (MP51.0089 from the High Sierra full installer) and a Metal capable one for the 144 update from the Mojave installer (Sapphire Pulse RX580).

Is there any indication from the above binwalk that anything needs to be done to this bootrom before attempting this update, assuming I don't boot into Windows 10 with EFI mode again, ever? I will be doing an install from a Windows 10 DVD onto a vanilla SATA drive after the bootrom is upgraded-- will not be using EFI mode again.

TLDR version: Is this machine safe to update to High Sierra/bootrom MP51.0089 and then to bootrom 144 without cleaning or reconstructing the bootrom and re-flashing, or should that be done first? If I upgrade it and everything works, is there a need to clean or reconstruct the bootrom afterwards?

You have two support error logs, the XML files from the binwalk report, these logs indicate that you don't have a pristine NVRAM anymore.

1219863 0x129D17 XML document, version: "1.0"
1235036 0x12D85C XML document, version: "1.0"

Save your dump somewhere, then do the firmware upgrades, after that check again. You will probably have one XML document at the end of the process.

 

[marioliv66@]

Hello, it's been a few months that I have not followed the news updates Mojave and Firmware. Currently my Mac Pro 4.1> 5.1 is under Mojave 10.14.3 with firmware 140.0.0.0.0. Are there particular preconceptions to go directly from 140.0.0.0.0 to 144.0.0.0.0 and from 10.14.3 to 10.14.6 ? Thank you

 

[JedNZ]

Shouldn’t be a problem. Use the full macOS 10.14.6 installer to upgrade the firmware to 144.0.0.0.0, and then on reboot you can install the OS using the same installer. I just did two cMP 4,1>5,1 from their original firmwares, so yours should be straight forward.

 

[marioliv66@]

To download the complete installation of 10.14.6 I use installinstallmacos.py you confirm that this is the correct method? thank you

 

[zedex]

HEY @JedNZ - do you have any issues running your NVIDIA GT-120 alongside your AMD Sapphire Pulse RX 590 8GB..?

 

[JedNZ]

HEY @JedNZ - do you have any issues running your NVIDIA GT-120 alongside your AMD Sapphire Pulse RX 590 8GB..?

Sorry, my sig isn’t up to date. We can’t run a non-metal GPU in MacOS Mojave. I haven’t tried doing it in HS either as The RX590 caused all sorts of problems with trying to logon.

I’ll go update my sig