Jump to content

R9 380, can't boot directly, have to do it via Intel 4600, Ghost monitor.

pcpaul

By pcpaul,
in ATi

 Share
146 posts in this topic

Recommended Posts

pcpaul
pcpaul
Posted
  • Author
Posted

CGThirtBitColor is just a coloring profile which is used from the EDID, you should try the same method that people with a 280 uses which is in the forums, 380 is just a rebranded 280.

No, its a rebadged 285, which is tonga,

"just a coloring profile" is unheard of... only 6 results on the whole f***ing google, all 6 regarding el capitan...

Until there's a fix, and that fix fixes something not related to this "just a coloring profile" I'll insist that this is the only cause, the other cause can be that missing reference to a AMDRadeonX4000GLDriver and for some reason doubt it has anything to do with this boot problem, maybe.... 

 

So how do I change this "just a coloring profile", since it's "just a coloring profile" I'm sure I can easily change it, can't I?  

Link to comment
Share on other sites
kkarun88
kkarun88
Posted
Posted

One more thing i noticed different in verbose, regardless of booting with IGPU or PCIe as primary:

 

Waiting for DSMOS...

bpfAttach len 64 dlt 12

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

fInterfaceSnapshots is missing

.........

Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

Ok, I've just read that HDMI twisted pair cables actually can't support the combined bandwidth of audio and "deep color", if you do send a deep color stream though it, guess what happens? you get no f***ing signal.

Just a color profile?

F*** me, this f***ing color profile must be it, it in it's name says that it's "thirty", which in turn is supposed to be a "deep color", my f***ing monitor doesn't support it, neither should my f***ing HDMI cable, lol. El Capitan probably forces on us (our card in this case) deep color, Yosemite sends 32-bit signal color which is a "true color", it's divided by 8-bits, El Capitan, when booting through PCI and connected to PCI, sends a "deep color" signal(strictly in my/our? case), I guess, because "thirty" is RGB divided by 10-bits, true color space takes alpha channel  into account hence you have ARGB, that's what Yosemite says in it's "pixel depth"  32-bit Color (ARGB888).

 

So the problem is that El Capitan sends deep color signal, how do we stop it and make it to send a true color?? 

I guess I'm right, guys what would you have been doing without me, patching framebuffers repeatedly? which I argued is not the case to our problem since the beginning? lol, because I bet some think that I'm a moron who "patches" something wrongly, because it must be a framebuffer issue....

 

BTW, it's all a guess work, so I'd be glad to be proven wrong, as long as a solution is provided to our problem. 

Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

My monitor shows up as CSGThirtyBitColor with a 280X on 10.11. Real iMac15,1 with R9 M290X shows this as well...pretty sure this is cosmetic. I'll check the AMDRadeonX4000GLDriver thing later, currently using HD 4000 (removed 280X) and testing sleep. Perhaps someone should see how it works on a R9 M295X (used in real iMac15,1, Tonga GPU).

Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

My monitor shows up as CSGThirtyBitColor with a 280X on 10.11. Real iMac15,1 with R9 M290X shows this as well...pretty sure this is cosmetic. I'll check the AMDRadeonX4000GLDriver thing later, currently using HD 4000 (removed 280X) and testing sleep. Perhaps someone should see how it works on a R9 M295X (used in real iMac15,1, Tonga GPU).

Does your monitor support deep color? in it's specs it should say that it supports billions of colors or something like that as opposed to millions, that is 16.7m true color. 

Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted

Ok, I've just read that HDMI twisted pair cables actually can't support the combined bandwidth of audio and "deep color", if you do send a deep color stream though it, guess what happens? you get no f***ing signal.

Just a color profile?

F*** me, this f***ing color profile must be it, it in it's name says that it's "thirty", which in turn is supposed to be a "deep color", my f***ing monitor doesn't support it, neither should my f***ing HDMI cable, lol. El Capitan probably forces on us (our card in this case) deep color, Yosemite sends 32-bit signal color which is a "true color", it's divided by 8-bits, El Capitan, when booting through PCI and connected to PCI, sends a "deep color" signal(strictly in my/our? case), I guess, because "thirty" is RGB divided by 10-bits, true color space takes alpha channel  into account hence you have ARGB, that's what Yosemite says in it's "pixel depth"  32-bit Color (ARGB888).

 

So the problem is that El Capitan sends deep color signal, how do we stop it and make it to send a true color?? 

I guess I'm right, guys what would you have been doing without me, patching framebuffers repeatedly? which I argued is not the case to our problem since the beginning? lol, because I bet some think that I'm a moron who "patches" something wrongly, because it must be a framebuffer issue....

 

BTW, it's all a guess work, so I'd be glad to be proven wrong, as long as a solution is provided to our problem. 

Try this area :

IGlaJkO.png

Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

Does your monitor support deep color? in it's specs it should say that it supports billions of colors or something like that as opposed to millions, that is 16.7m true color. 

 

Nope, just a standard 32-bit (8-bit x4) monitor. Also, I don't see IOOCDBundleName = AMDRadeonX4000GLDriver under GFX0 in IORegistryExplorer either; it appears it moved to GFX0/AMDTahitiGraphicsAccelerator.

Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

Yup, deleted all the profiles, generated a new one for my monitor under windows and now it injects 32-bit color profile, but still can't boot normally, my theory goes to a trash. 

Only remains AMDRadeonX4000GLDriver. 

 

Well at least I can now enjoy a True color of my monitor :lol:  and will be able to get some sleep, because now "hopefully" I'm really done with this whole f***ing nonsense.

 

the-machinist-600x450.jpg

 

Edit: just saw @TheRacerMaster's reply, so it's truly over for me, thanks god though.

  • Like 1
Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

Something maybe relevant, more relevant than color profiles for sure.

Some guys had the same problem as me on real Mac Pro's (Late 2013), they claimed that it worked on Dev Beta 1, but not on 2,3 and 4, so I've figured out d300 ID, didn't looked into other cards, and checked out the main kexts, for it, it's AMDRadeonX4000.kext and AMD7000Controller.kext.

 

4000 were identical apart from versions difference.

 

7000 didn't have "properties" sections under <key>ATY,Tako</key> at all, while beta 4 had 

	<key>aty_properties</key>
				<dict>
					<key>PP_EnableLoadPostProductionFirmware</key>
					<integer>1</integer>
				</dict>

Also checked graphics policy kext, the main difference was that Beta 1 had more EDID keys under gfx2, Beta4 had only one EDID key.

 

So I've checked 9000.kext of Yosemite against el Capitan and this time I've noticed that there's a difference under Controller - aty_properties key, under Yosemite there's a key under it called <key>PP_EnableLoadPostProductionFirmware</key> under El Capitan it's called <key>PP_EnableLoadFalconSmcFirmware</key> so just giving a quick look it's easy to miss it. 

 

I've tried changing it to PP_EnableLoadPostProductionFirmware, and after verbose system entered the same "void", but this time it did it with IGPU too, also tried with deleted all properties, it boots into "void" but with IGPU it boots fully.  Tried changing it to zero zero, the same void, igpu boots fully. 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BuildMachineOSBuild</key>
	<string>15B17c</string>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleExecutable</key>
	<string>AMD9000Controller</string>
	<key>CFBundleGetInfoString</key>
	<string>AMD9000Controller 1.38.3 15905</string>
	<key>CFBundleIdentifier</key>
	<string>com.apple.kext.AMD9000Controller</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>Radeon HD 9000 Controller</string>
	<key>CFBundlePackageType</key>
	<string>KEXT</string>
	<key>CFBundleShortVersionString</key>
	<string>1.38.3</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleSupportedPlatforms</key>
	<array>
		<string>MacOSX</string>
	</array>
	<key>CFBundleVersion</key>
	<string>1.3.8</string>
	<key>DTCompiler</key>
	<string>com.apple.compilers.llvm.clang.1_0</string>
	<key>DTPlatformBuild</key>
	<string>7A176g</string>
	<key>DTPlatformVersion</key>
	<string>GM</string>
	<key>DTSDKBuild</key>
	<string>15B17c</string>
	<key>DTSDKName</key>
	<string>macosx10.11internal</string>
	<key>DTXcode</key>
	<string>0700</string>
	<key>DTXcodeBuild</key>
	<string>7A176g</string>
	<key>IOKitPersonalities</key>
	<dict>
		<key>Controller</key>
		<dict>
			<key>ATY,Basset</key>
			<dict>
				<key>aty_config</key>
				<dict>
					<key>CFG_DEF_DITH</key>
					<integer>0</integer>
					<key>CFG_NVV</key>
					<integer>2</integer>
					<key>CFG_PTPL2_TBL</key>
					<data>
					bgAAAGwAAABpAAAAZwAAAGUAAABjAAAAYAAA
					AF4AAABcAAAAWQAAAFcAAABVAAAAUwAAAFAA
					AABOAAAAMgAAAA==
					</data>
					<key>CFG_USE_AGDC</key>
					<true/>
				</dict>
			</dict>
			<key>ATY,Labrador</key>
			<dict>
				<key>aty_config</key>
				<dict>
					<key>CFG_DEF_DITH</key>
					<integer>0</integer>
					<key>CFG_FB_LIMIT</key>
					<integer>6</integer>
					<key>CFG_NVV</key>
					<integer>2</integer>
					<key>CFG_PTPL2_TBL</key>
					<data>
					eAAAAG4AAABoAAAAZAAAAGIAAABgAAAAXgAA
					AFwAAABaAAAAWAAAAFYAAABUAAAAUgAAAFAA
					AABOAAAAMgAAAA==
					</data>
					<key>CFG_USE_AGDC</key>
					<true/>
				</dict>
			</dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.kext.AMD9000Controller</string>
			<key>IOClass</key>
			<string>AMD9000Controller</string>
			<key>IOMatchCategory</key>
			<string>IOFramebuffer</string>
			<key>IOName</key>
			<string>AMD9000Controller</string>
			<key>IOPCIMatch</key>
			<string>0x69201002 0x69211002 0x69301002 0x69381002 0x69391002 0X73001002</string>
			<key>IOProbeScore</key>
			<integer>65050</integer>
			<key>IOProviderClass</key>
			<string>IOPCIDevice</string>
			<key>aty_config</key>
			<dict>
				<key>CFG_APER_MODE</key>
				<integer>1</integer>
				<key>CFG_CAA</key>
				<integer>0</integer>
				<key>CFG_FB_LIMIT</key>
				<integer>0</integer>
				<key>CFG_FORCE_MAX_DPS</key>
				<false/>
				<key>CFG_GEN_FLAGS</key>
				<integer>0</integer>
				<key>CFG_INT_SSPC</key>
				<integer>25</integer>
				<key>CFG_NODM</key>
				<true/>
				<key>CFG_NO_HDCP</key>
				<false/>
				<key>CFG_NO_MSI</key>
				<false/>
				<key>CFG_NO_MST</key>
				<false/>
				<key>CFG_NO_PP</key>
				<false/>
				<key>CFG_NO_SLS</key>
				<false/>
				<key>CFG_PTPL2_MAX</key>
				<integer>150</integer>
				<key>CFG_PTPL2_MIN</key>
				<integer>30</integer>
				<key>CFG_PTPL2_TBL</key>
				<data>
				lgAAAI4AAACGAAAAfgAAAHYAAABuAAAAZgAAAF4AAABW
				AAAATgAAAEYAAAA+AAAANgAAAC4AAAAmAAAAHgAAAA==
				</data>
				<key>CFG_USE_AGDC</key>
				<false/>
				<key>CFG_USE_FBC</key>
				<false/>
				<key>CFG_USE_FEDS</key>
				<true/>
				<key>CFG_USE_SRRB</key>
				<false/>
				<key>CFG_USE_STUTTER</key>
				<false/>
				<key>DALReadDelayStutterOff</key>
				<integer>4</integer>
				<key>DALUseUrgencyWaterMarkOffset</key>
				<integer>0</integer>
			</dict>
			<key>aty_properties</key>
			<dict>
				<key>PP_DisableCAC</key>
				<integer>0</integer>
				<key>PP_DisableDIDT</key>
				<integer>1</integer>
				<key>PP_DisablePPLib</key>
				<integer>0</integer>
				<key>PP_DisablePowerContainment</key>
				<integer>0</integer>
				<key>PP_DisableULV</key>
				<integer>0</integer>
				<key>PP_DisableVoltageIsland</key>
				<integer>1</integer>
				<key>PP_EnableBAPM</key>
				<integer>0</integer>
				<key>PP_EnableLoadFalconSmcFirmware</key>
				<integer>1</integer>
				<key>PP_Falcon_QuickTransition_Enable</key>
				<integer>1</integer>
				<key>PP_MclkActivityTarget</key>
				<integer>5</integer>
				<key>PP_PhmUseDummyBackEnd</key>
				<integer>0</integer>
				<key>PP_PowerGatingDisable</key>
				<integer>1</integer>
			</dict>
		</dict>
	</dict>
	<key>OSBundleLibraries</key>
	<dict>
		<key>com.apple.iokit.IOACPIFamily</key>
		<string>1.2</string>
		<key>com.apple.iokit.IOGraphicsFamily</key>
		<string>1.3</string>
		<key>com.apple.iokit.IOPCIFamily</key>
		<string>1.2</string>
		<key>com.apple.kext.AMDSupport</key>
		<string>1.3.8</string>
		<key>com.apple.kpi.bsd</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.iokit</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.libkern</key>
		<string>8.0.0</string>
		<key>com.apple.kpi.mach</key>
		<string>8.0.0</string>
	</dict>
	<key>OSBundleRequired</key>
	<string>Safe Boot</string>
</dict>
</plist>
Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

Very interesting. It could very well be one of those properties, I recall that Cape Verde GPUs needed changes to cail_properties after 10.10.3 to fix a black/distorted screen on boot. Although I'm confused why FirePro D300 has this issue, it's Pitcairn (not Tonga), so it should work fine.

Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

I'm confused why FirePro D300 has this issue, it's Pitcairn (not Tonga), so it should work fine.

 

It had it in beta 2,3 and 4, later it was fixed.

Probably when all graphics kexts were messed with while integrating Metal support, some minor mistakes were made and some specific tweaks for some cards, mainly ATI models, were botched or missed on some card models, since d300 or d500/d700 are their official cards, users reported having problems and apple fixed it, most likely some minor thing in the code, I guess, but I'm obviously no coder. 

Nevertheless I took a peek into 9000.kext code and the whole "_Tonga_UploadSMUFirmwareImageDefault:" procedure is way bigger than Yosemite's 9000 code, even tried to bypass some of it and surprisingly was still able to boot still using old method(IGPU to PCI). I've landed on that procedure, because EnableLoadPostProductionFirmware was showing up there, but I've absolutely no clue wtf I was doing, main aspect of it was that it does some kind of "whether or" comparison between _falcon_kicker_tonga_smcFirmware and falcon_tonga_smcFirmware, while in Yosemite's 9000 code it's between  _PhwSIslands_LoadFalconSMCFirmware and _PECI_IsLoadKickerSmcFirmwareEnabled, but given my prior history in being wrong, it could completely not related, obviously the names could be just a cosmetic difference, but nevertheless code itself at that section does way more than on Yosemite. 

Link to comment
Share on other sites
xCatbodi
xCatbodi
Posted
Posted

It had it in beta 2,3 and 4, later it was fixed.

Probably when all graphics kexts were messed with while integrating Metal support, some minor mistakes were made and some specific tweaks for some cards, mainly ATI models, were botched or missed on some card models, since d300 or d500/d700 are their official cards, users reported having problems and apple fixed it, most likely some minor thing in the code, I guess, but I'm obviously no coder. 

Nevertheless I took a peek into 9000.kext code and the whole "_Tonga_UploadSMUFirmwareImageDefault:" procedure is way bigger than Yosemite's 9000 code, even tried to bypass some of it and surprisingly was still able to boot still using old method(IGPU to PCI). I've landed on that procedure, because EnableLoadPostProductionFirmware was showing up there, but I've absolutely no clue wtf I was doing, main aspect of it was that it does some kind of "whether or" comparison between _falcon_kicker_tonga_smcFirmware and falcon_tonga_smcFirmware, while in Yosemite's 9000 code it's between  _PhwSIslands_LoadFalconSMCFirmware and _PECI_IsLoadKickerSmcFirmwareEnabled, but given my prior history in being wrong, it could completely not related, obviously the names could be just a cosmetic difference, but nevertheless code itself at that section does way more than on Yosemite. 

I'm hoping we get some kind of fix for this, whether its a user fix or an Apple fix for users with real Mac Pro's. 

Link to comment
Share on other sites
  • 2 weeks later...
Mork vom Ork
Mork vom Ork
Posted
Posted

With 10.11.1 being released today, anybody want to give it another shot? Just to see if there is OOB support once again?

 

Just tested yesterday: same effect as with every previous version: black Screen after VERBOSE booting. System still pingable and remote access via ssh possible.

But system does NOT react to remote desktop connection attemps.

 

But anyway, one good thing to notice: with Image of 10.1.1 (which is available since yetserday) a setup of El Capitan on ASUS X99-E WS is possible without any hassle, patch or DSDT/SSDT file.

Just tested myself. Made UEFI bootable OS X 10.11.1 usbinstallstick with latest CLOVER r3292.

 

YES!

Link to comment
Share on other sites
xCatbodi
xCatbodi
Posted
Posted

Just tested yesterday: same effect as with every previous version: black Screen after VERBOSE booting. System still pingable and remote access via ssh possible.

But system does NOT react to remote desktop connection attemps.

 

But anyway, one good thing to notice: with Image of 10.1.1 (which is available since yetserday) a setup of El Capitan on ASUS X99-E WS is possible without any hassle, patch or DSDT/SSDT file.

Just tested myself. Made UEFI bootable OS X 10.11.1 usbinstallstick with latest CLOVER r3292.

 

YES!

I'm at a loss about what to do. Should I order a GTX 970 then and return this one? Will anybody in the world figure out R9 380 support?

Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

Regarding recently released late 2015 iMacs, there's an option to upgrade up to R9 M395x, which is Tonga, lets hope that some will get this model and will try to connect a secondary monitor and will get the same issue, no matter how unlikely that is, lol, because first:

iMac only have 2 thunderbolt connections which can be used for display and support HDMI, and dual-link DVI using adapters, so the whole wiring is completely different than in our case

second:

how and why on earth someone would boot an iMac using external display as a main display, lol,  in other words our hopes for apple to fix this are down to zero.

 

Maybe with 17.1 smbios and 395x device id for some unlikely reason it would work, so soon we will find out, I guess.

 

Edit: Just tested 17.1 with 395x ID, the same s**t as usual.

But noticed that with 17.1 smbios, IGPU doesn't show anything, when connecting a monitor to it, usually when booting via IGPU with a monitor connected to ATI, when you reconnect to IGPU it works OK, but with this smbios only ATI works if booted via IGPU, strange, but I don't care, since it aren't related to our issue at all, maybe this way it will use a little bit less energy, lol, and the answer most likely lies in smbios itself, since it's from a late 2015 imac and 2015 iMacs are Skylake, so 4600 id might doesn't cut it, lol or maybe there's something with a display policy,  anyways just letting you know in case someone runs into it.  

Also GraphicDevicePolicy info.plist looks a bit "weird" because it's untouched and look how many "config2" it has, usually it was only 1 or 2, my id is B809C3757DA9BB8D.

post-981248-0-59391200-1445646170_thumb.png

post-981248-0-01508300-1445647412_thumb.png

Link to comment
Share on other sites
ganxiao
ganxiao
Posted
Posted

I think if someone provide darwindump result from 27inch 5k retina imac with m295x/m395/m395x graphics would be helpful to this question,

so we can check what properties graphic efi has injected to system.

 

Be ware that 27inch retina imac use a special version of dp (edp 1.3 maybe) to connect its 5k pannel.

I wonder if apple decides to skip some detection codes but to force init boot display to an edp connector caused this problem.

Link to comment
Share on other sites
Mork vom Ork
Mork vom Ork
Posted
Posted

Just a litle update for all of you:

 

recently i switched to ASUS X99-E WS motherboard and Intel I7 5820k cpu. And this board and cpu is a hassle for a hackintosh. Took me a whole weekend to make OS X 10.10.5 and OS X 10.11.1 running on this board. GFX-card still the same ASUS R9 380 STRIX with 2GB RAM running in PCI Slot #3 (have to move it to that slot, cause Thunderbolt card needs to be plugged into Slot #2 for best results). BIOS is the latest 1302 for this board and i still use my ASUS ThunderboltII EX card in PCI slot #2. First i got memory allocation error when trying to boot. Gladly i found a working "OsxAptioFixDrv-64.efi" driver, so now i am able to boot with latest CLOVER 3305.

 

Now here is the problem:

 

tried almost every framebuffer with this card. Under YOSEMITE no problem: all of my injected fb-patches work like a charm: OS X will boot in verbose mode, when booting to desktop, all connected monitors (1 DP, 1 HDMI and 1 DVI) stop responding for about 90 seconds. After that period of time they will come back and all monitors are showing the desktop (with full acceleration). So i can live with that amount of delay when booting to desktop.

 

But no chance to make it working with latest EL CAPITAN 10.11.1 - same effect: booting verbose mode is ok, than all monitors turn black and... no response anymore! But machine still seems to be working, cause i could connect to filesharing of EL CAPITAN machine (i enabled it to test, if machine still is responding) and also responds to ping requests. Using Apple Remote Desktop Admin client, i can see also, that EL CAPITAN machine ist still alive, but it says "ARD not ready" and when i try to connect via ARD i will get a timeout message: "EL CAPITAN not responding. Verrify, if Firewall is blocking the ports" or something similar like that.

 

When i delete the "AMDRadeonX4000.kext" from System/Extensions, i could boot into desktop, but without acceleration. IORegistryExplorer shows me correct patched framebuffer with all 4 ports connected and correctly assigned to their order (port 4 still has no monitor connected). You can see in attached Screenshot. Also DPCIManager shows, that RADEON has the Framebuffer accepted successfully.

 

In my example i choose to modify GREYHOUND framebuffer from

 

Greyhound original:

00040000040300000001010710000103
00040000040300000001020720010204
00040000040300000001030711020301
00040000040300000001040721030402
00040000040300000001050712040505
00040000040300000001060722050606

000400000403000000010107100001030004000004030000000102072001020400040000040300000001030711020301000400000403000000010407210304020004000004030000000105071204050500040000040300000001060722050606

Greyhound patched:

00040000040300000001000711020401
00080000040200000001000021030403
00020000140200000001000010000405
04000000140000000001000012040406
00040000040300000001000010000402
00020000140200000001000010000404

 

000400000403000000010007110204010008000004020000000100002103040300020000140200000001000010000405040000001400000000010000120404060004000004030000000100001000040200020000140200000001000010000404

 

And now for the strange thin in üatching the framebuffers: the only work, when i set "04" for the HotPlugID to all defined connectors! If i set the HotPlugID in a normal order like 01 for DP, 02 for HDMI, 03 for DVI-I and 04 for DVI-D (05 and 06 for the last defined connectors) i will allways get errors on reboot, when system tries to show desktop on the connected monitors (w/o connector #4, which is still working correctly). Then, when i try to connect remotly to desktop with ARD from my Macbook, i can see in IORegistryExplorer, that the connectors are still in the right order, but still have no monitor connected (w/o defined port #4).

 

So when i change the HotPlugID of patched framebuffer all to "04", all Monitors will be correctly recognized and are showing their desktops. VERRY WEIRED !!!

 

Could anyone explain this to me? Also i found out, that i could define the order of connectors by switching the following entries in framebufferpatch:

 

00040000040300000001001711020401
00080000040200000001002021030403
00020000140200000001003010000405
04000000140000000001004012040406
00040000040300000001005010000402
00020000140200000001006010000404

 

Changing these values in thier order, will change the connectors order in IORegistryExploer as well. JUST TESTED AND CONFIRMED. So why do i have to change these values instead of the HotPlugID values?

And why does changing the HotPlugID makes my setup broke?

 

Any explanations to this are welcome.

 

So far... regards. Hope this will help all the other owners of a RADEON R9 380 gfx-card.

 

 

PS: all AMD9000.kext framebuffers could be patched with the above patch. BASSET still get the first 4 rows patched, cause this is a 4 connectors framebuffer. All the others use 6 connectors. When i try to use patched BALADI or EXMOOR, they will change to default RADEONFRAMEBUFFER after boot. All the others got accepted: BASSET, GREYHOUND, OPM, LABRADOR (only in 10.11.1, cause it isnt availlable in 10.10.5)

 

EDIT II: maybe i have a solution for this problem. Attached you will find a screenshot of "radeon_bios_decode"-tool, which also reads out the given HotPlugID of your cards BIOS. There you can see, that the given HotPlugIDs doesnt match to my patched framebuffer settings. So the corrected framebuffer patch should look like this one:

 

00040000040300000001001711020401 <-- DP
00080000040200000001002021030503 <-- HDMI
00020000140200000001003010000105 <-- DVI-D
04000000140000000001004012040606 <-- DVI-I
00040000040300000001005010000202 <-- not used
00020000140200000001006010000304 <-- not used

 

Will test the HPID-corrected framebuffer patch later this day, cause currently i am @ work. Will keep you informed.

post-598588-0-47482100-1445859764_thumb.jpg

post-598588-0-75162500-1445859776_thumb.jpg

CLOVER Config.txt

post-598588-0-32268300-1445888440_thumb.jpg

radeon_bios_decode.zip

Link to comment
Share on other sites
pcpaul
pcpaul
Posted
  • Author
Posted

Thanks to Pike, we have iMac17,1's device-properties now, https://pikeralpha.wordpress.com/2015/10/24/device-properties-used-in-the-new-imac171/

 

I modified this to a more readable plist file, check attachment.

thanks, I see that imac uses labrador framebuffer, dp port and card is m395 which is Tonga, like ours.

Would like to see full m395 bios rom, what I have in mind is to try to flash my uefi bios with m395 efi bios, not whole bios but just efi part, I know it's usually needed for real macs only, but who knows, with this card's efi and device id, which is accepted and works with my card, maybe it would work.

There's a part called ATY,bin_image, but that part only holds first 65536 bytes, I need the second part which is EFI, it's futile, but what else can we try...

Of course I know that you don't have it nor Pike, so just mentioning it, in case someone have access to that particular card or m395x on an iMac. 

Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted

thanks, I see that imac uses labrador framebuffer, dp port and card is m395 which is Tonga, like ours.

Would like to see full m395 bios rom, what I have in mind is to try to flash my uefi bios with m395 efi bios, not whole bios but just efi part, I know it's usually needed for real macs only, but who knows, with this card's efi and device id, which is accepted and works with my card, maybe it would work.

There's a part called ATY,bin_image, but that part only holds first 65536 bytes, I need the second part which is EFI, it's futile, but what else can we try...

Of course I know that you don't have it nor Pike, so just mentioning it, in case someone have access to that particular card or m395x on an iMac. 

Flashing Apple EFI rom to your gfx card only adds support for boot screen on real macs, doesn't help OS X identify the gfx card any better once in the OS

Link to comment
Share on other sites
xCatbodi
xCatbodi
Posted
Posted

Flashing Apple EFI rom to your gfx card only adds support for boot screen on real macs, doesn't help OS X identify the gfx card any better once in the OS

Pavo, do you reckon there is any possibility for using R9 380 in El Capitan some day? I'd like to know I won't be stuck on Yosemite forever.

 

I don't believe I can be of any assistance since the BIOS dumbs, EFI injections, and other things you guys are talking about are flying over my head but I'm hoping it is possible to be using R9 380 on El Capitan soon :(

Link to comment
Share on other sites
Mork vom Ork
Mork vom Ork
Posted
Posted

Just arrived @ home and edited my framebuffer patches for GREYHOUND, LABRADOR, OPM and BASSET to the following Settings:

 

00040000040300000001000711020401 <-- DP
00080000040200000001000021030503 <-- HDMI
00020000140200000001000010000105 <-- DVI-D
04000000140000000001000012040606 <-- DVI-I   (* just the first 4 connectors for BASSET, since it is just a 4 connectors framebuffer)
00040000040300000001000010000202 <-- not used (cause Radeon R9 380 STRIX only has 4 physical ports)
00020000140200000001000010000304 <-- not used (cause Radeon R9 380 STRIX only has 4 physical ports)

 

Working all great with YOSEMITE. All patches will be accepted and every monitor will show correct desktop afte complete bootsequence. BALADI and EXMOOR still changed to "ATY,RadeonFramebuffer"

May work also with EL CAPITAN - but still having the "monitor did not respond" after bootsequence (while machine still responds to filesharing requests, but not to screensharing requests from my MacBook). :blush:

 

Have to explain, that all patches work also on EL CAPITAN, if i remove the AMDRadeonX4000.kext from /System/Library/Extensions folder, <-- all connected monitors responds with the correct desktop, but w/o accelleration.

 

With AMDRadeonX4000.kext active it seems, that EL CAPITAN still boots into any "virtual desktop" with the effect, that all connected monitors reporting "No Signal" and went to stand-by mode.

Same effect with my old ASUS Z97 DeLuxe board when disabled the onboard Haswell INTEL GFX or setting PCIe-GFX to primary GFX. EL CAPITAN boots succesfully, when INTEL GFX is enabled and set to primary gfx.

 

Have no more idea on how to get it work. For me it seems, we need a "AMDRadeonX4000.kext"-patch.

 

Also want to mention, that i tried every possible CLOVER v3305 configuration: Inject EDID on/off, Load VBIOS on/off, patch VBIOS on/off, Dual Link set to off/0/1 <--- all w/o any noticable effect.

 

But i don't give up: next test plugging in my old Sapphire Radeon R7 260X as second GFX-Card with using the R9 380 as primary card as usual, then lets see, what happens.

So stay tuned and don't miss the next episode of this show...

 

regards,

Mork vom Ork

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...