Jump to content

Clover test and patches for Polaris GPU


fantomas
279 posts in this topic

Recommended Posts

  • 2 months later...

Polaris 12 = Lexa gpu

Clover work with him?

My hackintosh ever Give me this output

 

Dev os 0x699f1002

Set RadeonDeInit=YES in config.plist.

What is a market name of your card?

  • Like 1
Link to comment
Share on other sites

My card is one Asus radeon rx550

A lot of fórum say that is one polaris 12 but when i search i discover one thing

Is a lexa chipset.

The id is 699f and i dont found notinhg in the kext with this id.

Look the clover source of Clover 4330 for this gpu the id is 67EF.

But my gpu dont load kext and stay with 5mb of ram

Link to comment
Share on other sites

My card is one Asus radeon rx550

A lot of fórum say that is one polaris 12 but when i search i discover one thing

Is a lexa chipset.

The id is 699f and i dont found notinhg in the kext with this id.

Look the clover source of Clover 4330 for this gpu the id is 67EF.

But my gpu dont load kext and stay with 5mb of ram

You may set FakeID=0x67EF1002 and FixDispaly=YES

Link to comment
Share on other sites

I tried this and it did not work

I also tried all fakeids from AMD and none made the board to be loaded.

no kext is loaded

 

I try fakeid and load vbios and nothing

FakeID will work only with DSDT FixDisplay.

Link to comment
Share on other sites

RX 550 don't work in macOS at all... 

 

True, I tested it over and over but nothing worked, fake ID, edit of every possible info.plist for controller and accelerator kexts + HW kexts, added vbios to Clover ROM folder and Load vBios.   Nothing got more than Display status 7mb.   It has half the CUs of the RX 560, lower ram frequency and lower GPU frequency.    It just would not take no matter what I tried in High Sierra and HS betas as well.    Maybe if someone rewrote the controller and accelerator + HW kexts for the card it would work but that would be a very large project for a little card.     

  • Like 3
Link to comment
Share on other sites

  • 2 months later...

Update:   There is a new version of the RX 550 that has the device ID 0x67FF1002 but it is very specific as far as a brand and model number.    I will try to find it and link it later.   It has the RX 560 ID but has lower Compute Units count so it may work.    

This is it a Sapphire RX 500 based on Polaris 21 similar to RX 560.

https://www.techpowerup.com/241121/sapphire-intros-radeon-rx-550-graphics-cards-with-640-stream-processors

Edited by Gigamaxx
  • Like 1
Link to comment
Share on other sites

1 minute ago, telepati said:

Probably it will deliver tomorrow which setting should I need?

If you are going to use WhateverGreen you won't be needing anything, just lilu and the WhateverGreen kexts. make sure to use the latest versions.

  • Thanks 1
Link to comment
Share on other sites

  • 8 months later...

Hi Folks,

 

I have a Dell T3500 with a Xeon W3690 and a Gigabyte Radeon RX 560 Gaming OC 4G running under High Sierra 10.13.6.

 

Unfortunately any attempt to upgrade to Mojave, boot its installer, or indeed install the "Security Update 2018-003 10.3.6" fails, reporting a failure to access the GPU card.

 

A verbose boot using "-v debug=0x8 serial=1" bootargs allows me to log the output to another machine. It can been seen in the log extract below that there is an attempt to access a register at 0xc0500198 and Googling this number has led me to this thread, specifically HERE. I've tried running the RadeonDump2 utility, but I just get all zeroes under 10.13.6, however that number is clearly still lurking in there somewhere!

 

I have the GPU card named PSX1 as per the recommendation HERE as I have SMBIOS set to MacPro5,1. Setting to any other name doesn't have any effect.

 


[AGPM Controller] build gpuDict by GPU PSX1.
IOConsoleUsers: time(0) 0->0, lin 0, llk 1, 
IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sm 0x0
GTrace EDncablnicrtio -point 5
Invalid Register Offset: 0xc0500198 >= 0x40000.
Invalid Register Offset: 0xc0500198 >= 0x40000.
Invalid Register Offset: 0xc0500198 >= 0x40000.
--> [2:0:0] !!! Failed to read register 0xc0500198..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x12480..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x12480..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x12488..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x1248c..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x1257c..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x1257c..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!
--> [2:0:0] !!! Failed to read register 0x400..
FATAL ERROR : ATIController failed to access PCI device [2:0:0]!

 

I'm using the attached SSDT file which successfully sets the frame buffer to be Acre, but I need to patch the DVI connector with the following.

 


                        <dict>

                                <key>Comment</key>

                                <string>ATI Connector patch for DVI</string>

                                <key>Disabled</key>

                                <false/>

                                <key>Find</key>

                                <data>BAAAAAQCAAAAAQMAAAAAAAAAAwUAAAAA</data>

                                <key>InfoPlistPatch</key>

                                <false/>

                                <key>Name</key>

                                <string>AMD9500Controller</string>

                                <key>Replace</key>

                                <data>BAAAABQCAAAAAQEAAAAAABAABAUAAAAA</data>

                        </dict>

 

My attempts to resolve this, including using Lilu/WEG have been recorded HERE which hasn't really led anywhere, but this thread looks more promising.

 

Does anybody have any idea what's setting the 0xc0500198 register address and how I might fix this to allow me to upgrade to Mojave.

 

Thanks,

 

Steve

 

SSDT-AMD-Acre.aml

Link to comment
Share on other sites

13 hours ago, apianti said:

Do you have CSM disabled? Because that region of memory is where traditionally the legacy video rom is placed.

No, this is MMIO radeon register. I used some of them in RadeonMonitor.kext.

#define	CG_CI_MULT_THERMAL_STATUS		0xC0300014
#define		CI_ASIC_MAX_TEMP(x)			((x) << 0)
#define		CI_ASIC_MAX_TEMP_MASK		0x000001ff
#define		CI_ASIC_MAX_TEMP_SHIFT		0
#define		CI_CTF_TEMP(x)				((x) << 9)
#define		CI_CTF_TEMP_MASK			0x0003fe00
#define		CI_CTF_TEMP_SHIFT			9

@Steve Evans

If you are famous with C++ then you can look details in HWSensors3 project. The link is in my signature.

About the register 0xc0500198 I have no information.

I may propose that for access to it a program should get MMIO address which is different for different Radeon families and use indirect register access which can be found in RadeonMonitor.

All of this are for Developer not for user.

  • Like 1
Link to comment
Share on other sites

8 hours ago, Slice said:

No, this is MMIO radeon register. I used some of them in RadeonMonitor.kext.


#define	CG_CI_MULT_THERMAL_STATUS		0xC0300014
#define		CI_ASIC_MAX_TEMP(x)			((x) << 0)
#define		CI_ASIC_MAX_TEMP_MASK		0x000001ff
#define		CI_ASIC_MAX_TEMP_SHIFT		0
#define		CI_CTF_TEMP(x)				((x) << 9)
#define		CI_CTF_TEMP_MASK			0x0003fe00
#define		CI_CTF_TEMP_SHIFT			9

 

 

There is no way that is the actual register address offset as that would mean that the MMIO region is around ~3GB, as 0xC0300014 is 3224371220 bytes, which is not possible. You are making an assumption that is incorrect as I looked at the code and you read from 0x1AC0 + register offset. Because:

IOReturn ATICard::HawaiiTemperatureSensor(UInt16* data)
{
	UInt32 temp, actual_temp = 0;
	for (int i=0; i<1000; i++) {  //attempts to ready
		temp = (read_smc(CG_CI_MULT_THERMAL_STATUS) & CI_CTF_TEMP_MASK) >> CI_CTF_TEMP_SHIFT;
		if ((temp >> 10) & 1)
			actual_temp = 0;
		else if ((temp >> 9) & 1)
			actual_temp = 255;
		else {
			actual_temp = temp & 0x1ff; //(temp >> 1) & 0xff;
			break;
		}
		IOSleep(10);
	}
	
	*data = (UInt16)(actual_temp & 0x1ff);
	//data[1] = 0;
	return kIOReturnSuccess;
}

IOReturn ATICard::ArcticTemperatureSensor(UInt16* data)
{
  UInt32 temp, actual_temp = 0;
  for (int i=0; i<1000; i++) {  //attempts to ready
    temp = (read_ind(CG_CI_MULT_THERMAL_STATUS) & CI_CTF_TEMP_MASK) >> CI_CTF_TEMP_SHIFT;
    if ((temp >> 10) & 1)
      actual_temp = 0;
    else if ((temp >> 9) & 1)
      actual_temp = 255;
    else {
      actual_temp = temp & 0x1ff; //(temp >> 1) & 0xff;
      break;
    }
    IOSleep(10);
  }

  *data = (UInt16)(actual_temp & 0x1ff);
  //data[1] = 0;
  return kIOReturnSuccess;
}
#define INVID(offset) OSReadLittleInt32((mmio_base), offset)
#define OUTVID(offset,val) OSWriteLittleInt32((mmio_base), offset, val)

UInt32 ATICard::read_smc(UInt32 reg)
{
  UInt32 r;
  OUTVID(SMC_IND_INDEX_0, (reg));
  r = INVID(SMC_IND_DATA_0);
  return r;
}


UInt32 ATICard::read_ind(UInt32 reg)
{
    //	unsigned long flags;
	UInt32 r;
    //	spin_lock_irqsave(&rdev->smc_idx_lock, flags);
  OUTVID(mmSMC_IND_INDEX_11, (reg));
  r = INVID(mmSMC_IND_DATA_11);
    //	spin_unlock_irqrestore(&rdev->smc_idx_lock, flags);
	return r;
}
OS_INLINE
UInt32
OSReadLittleInt32(
    volatile void               * base,
    volatile UInt                 offset
)
{
    return *(UInt32 *)((UInt8 *)base + offset);
}

OS_INLINE
void
OSWriteLittleInt32(
    volatile void               * base,
    volatile UInt                 offset,
    volatile UInt32               data
)
{
    *(UInt32 *)((UInt8 *)base + offset) = data;
}

The MMIO region is usually of size 0x40000, which means the register offset cannot be more than 0x3FFFF. The only reason this seems to be working is because the legacy video rom is always present in the region 0xC0000000, which is not guaranteed if CSM is disabled. You appear to actually be accessing register 0x1AD4 from region at 0xC0300000.

 

EDIT: Or you are reading 0x200 + register offset, which is 0x214 from 0xC0300000.

Edited by apianti
Link to comment
Share on other sites

This is indirect access

UInt32 ATICard::read_smc(UInt32 reg)
{
  UInt32 r;
  OUTVID(SMC_IND_INDEX_0, (reg));
  r = INVID(SMC_IND_DATA_0);
  return r;
}

And there is no restriction to value of (reg).

  • Like 1
Link to comment
Share on other sites

On 12/21/2018 at 4:37 PM, apianti said:

Do you have CSM disabled? Because that region of memory is where traditionally the legacy video rom is placed.

Apologies for the slow response; I became a grandfather for the first time on 19th Dec and have consequently been distracted somewhat from tech. issues! :)

 

The [ur=https://www.dell.com/support/home/uk/en/ukbsdt1/drivers/driversdetails?driverid=cn9vg]A17 BIOS[/url] on this machine lacks a CSM setting.

Link to comment
Share on other sites

On 12/23/2018 at 8:13 PM, Slice said:

This is indirect access


UInt32 ATICard::read_smc(UInt32 reg)
{
  UInt32 r;
  OUTVID(SMC_IND_INDEX_0, (reg));
  r = INVID(SMC_IND_DATA_0);
  return r;
}

And there is no restriction to value of (reg).

 

It's interesting that this is an indirect access. I'd not appreciated that.

 

@slice

Note though, from my log quoted above that we have:

Invalid Register Offset: 0xc0500198 >= 0x40000

@apianti

The driver is thus expecting the register to fall within the MMIO region which is stated above to usually be of size 0x40000. It's as if the driver is erroneously applying some register offset range checks that should only be applied to direct, not indirect accesses.

 

But why should the driver be attempting such an access on my system when other people are using the RX560 on Mojave without issue?

 

Thanks,

 

Steve

Link to comment
Share on other sites

@Slice

I'm not sure what indirect access has to do with anything. Indirect access means that a register contains the address of another address to use for a read or write, direct access means a register contains the address itself. Absolutely nothing to do with the fact that you should be reading the location of the memory mapped region from the BAR of the PCI configuration space and using the offset of the register into that region not some random huge offset from another memory location, why even bother with the small offset that that macro provides at all and just read directly from that memory location? It would save a call and an addition instruction at least. But, you should be reading register offsets 0x1AD4 and 0x214 respectively for those registers from the region that is provided in the configuration space. There is no reason to assume that address is the correct address as the memory mapped region could be placed anywhere, especially with multiple devices.

 

@Steve Evans

The problem is most likely you have a patch or something that is creating these offsets and the code is checking to make sure that the register offset is actually within the region. Its not erroneous, it is correct as it will cause a segfault or gpfault otherwise. Most likely the drivers just being worked on more and they made it more secure to prevent malicious code from taking advantage of this.

Link to comment
Share on other sites

This is AMD logic. I think 0xc0500198 contains address + flags.

The message 

Invalid Register Offset: 0xc0500198 >= 0x40000

means that the driver uses direct access instead of indirect that is may be if the driver mistaken about Radeon family.

Some families requires direct access and other indirect.

Link to comment
Share on other sites

@apianti

I understand indirect vs direct register access. I’ve been developing real-time embedded software since the 80s :) I’ve also written PCI bus drivers (I ported Windows NT to PowerPC and had to add an understanding of PCI bridges as at the time Microsoft assumed a single bus!) and dealt with BARs etc., so I understand why there’s a range check against a 256k byte window.

 

I’m testing using the Mojave installer in preference to the latest security update to 10.13.6 to avoid tripping over anything in SLE. I’m trying to use a minimal Clover config to keep things simple.

 

The only reference I’ve ever found to 0xc0500198 is in this thread. I’m suspecting that my BIOS is performing some initialisation of the RX 560 card that Clover isn’t correcting, and MacOS doesn’t like.

 

@Slice

Can you please suggest some device IDs to try to explore your suggestion. Also, have you ever seen 0xc0500198 as reported earlier in this thread? Any idea what extra initialisation I could perform to reset the GPU to a better state for MacOS to handle?

 

Thanks,

 

Steve

 

Link to comment
Share on other sites

×
×
  • Create New...