Contribute
Register

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

For those with Apple Thunderbolt displays: I have Googled to no avail. I want to connect a Firewire 400 device to the Firewire port on the rear of the display. I bought a 400 to 800 cable but the 800 end is large. Is there term for the type of Frewire connector on the ATD? My google searching only returns the name "Firewire 800 connector" for the ATD FW display connector.
Thanks.
 
I managed to get the Nvidia out, but this is still the result:


Is it the right connector though?
Maybe something is wrong in the framebuffer or...?
Have you tried changing shikigva to 256 in boot-args? This affects DRM and may also affect hardware decoding in various apps.

Also, what system name are you using? iMac19,1 or iMacPro1,1?
 
For those with Apple Thunderbolt displays: I have Googled to no avail. I want to connect a Firewire 400 device to the Firewire port on the rear of the display. I bought a 400 to 800 cable but the 800 end is large. Is there term for the type of Frewire connector on the ATD? My google searching only returns the name "Firewire 800 connector" for the ATD FW display connector.
Thanks.
I don't own an Apple Thunderbolt Display, but know a thing or two about Firewire (Oh how I miss thee). Firewire 400, IEEE 1934A, has two port variations. 4 pin port found on many DV camera and 6 pin port found on old external hard drives and the original iPod. Firewire 800, IEEE 1934B, is what is on the back of the ATD.

I'm thinking if the Firewire 400 cable you have is too big, it is a 6 pin port and you need the 4 pin variety. You might be able to find a 6 pin to 4 pin adapter, or just buy a Firewire 800 to 400 4pin cable.

I hope this helps!
 
Hardware for this is as listed for Timequake in my profile.

I have an install that has never really updated properly, so I'm trying to start again from scratch. At the same time, since I was stuck at 10.15.6 due to the updating snags, I decided to do the new install straight to Big Sur and OpenCore. I did not previously update to OpenCore. I've stripped the hardware down to basics: Designaire, CPU w NZXT AiO cooler, Sapphire Rx 580, and RAM. I took out my Fenvi T919 and anything else plugged in via USB except the AiO's pump. I've created the USB install media, added OpenCore 065 with a new set of parameters created using hackindrom's basic settings for Designaire with AMD and 065.

When I boot, I get to the OC boot loader, but after selecting my Install macOS Big Sur drive to start, it locks up as soon as the Apple logo and progress bar appear. I wanted to switch to verbose boot to find the offending culprit, but for the life of me, I haven't managed to find instructions how to do that for OpenCore. Without it, I have no clue where to start troubleshooting, other than the insanity of trying the same things over and over. So far I've tried OC 063, 064, 065, both using new SMBIOS parameters and a new SSD, and using my old smbios info with the working Clover/non-updating Catalina install, each of those with resetting nvram before trying to boot to installer or OS.

How do i get to verbose on OpenCore? Or, what have I missed?
 
Hardware for this is as listed for Timequake in my profile.

I have an install that has never really updated properly, so I'm trying to start again from scratch. At the same time, since I was stuck at 10.15.6 due to the updating snags, I decided to do the new install straight to Big Sur and OpenCore. I did not previously update to OpenCore. I've stripped the hardware down to basics: Designaire, CPU w NZXT AiO cooler, Sapphire Rx 580, and RAM. I took out my Fenvi T919 and anything else plugged in via USB except the AiO's pump. I've created the USB install media, added OpenCore 065 with a new set of parameters created using hackindrom's basic settings for Designaire with AMD and 065.

When I boot, I get to the OC boot loader, but after selecting my Install macOS Big Sur drive to start, it locks up as soon as the Apple logo and progress bar appear. I wanted to switch to verbose boot to find the offending culprit, but for the life of me, I haven't managed to find instructions how to do that for OpenCore. Without it, I have no clue where to start troubleshooting, other than the insanity of trying the same things over and over. So far I've tried OC 063, 064, 065, both using new SMBIOS parameters and a new SSD, and using my old smbios info with the working Clover/non-updating Catalina install, each of those with resetting nvram before trying to boot to installer or OS.

How do i get to verbose on OpenCore? Or, what have I missed?
Add boot argument -v
 
hello I have a problem with the Bluetooth I have a card
"PC Hackintosh WiFi & BT WiFi Card 802.11a / g / n / ac + BT 4.0 PCI-E Mac compatible network adapter-Compatible Wi-Fi AirDrop Handoff Instant Hotspot MacOS MIMO 2x2 Mac OS X BCM4360 802.11ac"

I have my keyboard and my mouse but it can disconnect in Bluetooth and I no longer have the blue circles and it is impossible to reconnect them without rebooting

Did you have the case and an idea?


Thank you
 
@riverrat42

Are you running BIOS F9g or F9i? If so, have you disabled CFG-Lock from the Boot section of BIOS Setup?
 
@CaseySJ Any input as to what 4G Encoding is is needed for? Thanks.
Above 4G Decoding (not Encoding) requires a little background explanation first...

Every PCIe device that is preinstalled on the motherboard or plugged into a PCIe slot needs to be controllable by the CPU. The CPU needs to be able to (a) change the many states or parameters of the device, (b) get current status of the many states or parameters of the device, (c) initialize and power down the device, (d) get the device ID and vendor ID and lots of other device information, and (e) set/get large buffers of data to/from the device.

These and other functions are possible because each PCIe device “maps” all the necessary “control registers” and “buffers” to certain addresses in your DRAM modules. This is known as “memory mapping”.

As an example, a PCIe device might map a 32-bit control register to memory addresses 0x00000000 to 0x00000003 (4 bytes = 32 bits). Each of the 32 bits in the register can be read or written. And each read or write will perform an operation on the device. Normally, each read and write to a memory address simply reads and writes data to a memory location on the DRAM module. But in this case, memory addresses 0x00000000 through 0x00000003 are hijacked for another purpose. They no longer store data in DRAM. Instead, those 32 bits are redirected to the PCIe card, and it is the PCIe card that determines what happens when bits in that range are read and written.

And that, in a nutshell, is how the CPU controls PCIe devices. You might think that all of your memory is used as memory, but in fact many chunks of it are never used as memory. Instead, those chunks are used to control PCIe devices.

Historically we have had 32-bit CPUs and hence a limit of 4GB of memory. A 32-bit CPU cannot directly address more than 2 raised to the 32 power or 4GB of memory. There were clever ways of bypassing this limit through various virtualization techniques, but the fact remained that the limit of each contiguous chunk was 4GB.

And typically the first 1MB of that space was allocated for memory mapping. Not necessarily the entire 1MB, but sections of the first 1MB.

But when we start adding more and more PCIe devices, particularly two or more GPUs such as for crypto mining, we quickly run out of space in the first 1MB.

And so we enable “Above 4G Decoding”.

Now memory addresses above the historical 32-bit or 4GB limit can be used to map PCIe devices. And this in turn allows more devices to be attached.

Some devices require relatively large memory buffers (I/O buffers) and therefore take up more than their fair share of the memory map region. So enabling Above 4G Decoding is particularly necessary for such device types, particularly GPUs.
 
Last edited:
Above 4G Decoding (not Encoding) requires a little background explanation first...

Every PCIe device that is preinstalled on the motherboard or plugged into a PCIe slot needs to be controllable by the CPU. The CPU needs to be able to (a) change the many states or parameters of the device, (b) get current status of the many states or parameters of the device, (c) initialize and power down the device, (d) get the device ID and vendor ID and lots of other device information, and (e) set/get large buffers of data to/from the device.

These and other functions are possible because each PCIe device “maps” all the necessary “control registers” and “buffers” to certain addresses in your DRAM modules. This is known as “memory mapping”.

As an example, a PCIe device might map a 32-bit control register to memory addresses 0x00000000 to 0x00000003 (4 bytes = 32 bits). Each of the 32 bits in the register can be read or written. And each read or write will perform an operation on the device. Normally, each read and write to a memory address simply reads and writes data to a memory location on the DRAM module. But in this case, memory addresses 0x00000000 through 0x00000003 are hijacked for another purpose. They no longer store data in DRAM. Instead, those 32 bits are redirected to the PCIe card, and it is the PCIe card that determines what happens when bits in that range are read and written.

And that, in a nutshell, is how the CPU controls PCIe devices. You might think that all of your memory is used as memory, but in fact many chunks of it are never used as memory. Instead, those chunks are used to control PCIe devices.

Historically we have had 32-bit CPUs and hence a limit of 4GB of memory. A 32-bit CPU cannot directly address more than 2 raised to the 32 power or 4GB of memory. There were clever ways of bypassing this limit through various virtualization techniques, but the fact remained that the limit of each contiguous chunk was 4GB.

And typically the first 1MB of that space was allocated for memory mapping. Not necessarily the entire 1MB, but sections of the first 1MB.

But when we start adding more and more PCIe devices, particularly two or more GPUs such as for crypto mining, we quickly run out of space in the first 1MB.

And so we enable “Above 4G Decoding”.

Now memory addresses above the historical 32-bit or 4GB limit can be used to map PCIe devices. And this in turn allows more devices to be attached.

Some devices require relatively large memory buffers (I/O buffers) and therefore take up more than their fair share of the memory map region. So enabling Above 4G Decoding is particularly necessary for such device types, particularly GPUs.

It's been awhile! Hello there. Hope you're well.

This explanation is incredible. Thanks for that.

How does this play with the RebuildAppleMemoryMap quirk? Is that quirk also related to DisableIoMapper that we enable if we're using above 4G Encoding ?
 
Last edited:
Back
Top