Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

TheRacerMaster
TheRacerMaster
Posted
Posted

Clover doesn't properly detect Broadwell CPUs; well, it does, but it automatically assumes it's an i5. Here's a patch that should fix it (should autodetect Broadwell Core M, Core i3, Core i5, Core i7):

Index: rEFIt_UEFI/Platform/cpu.c
===================================================================
--- rEFIt_UEFI/Platform/cpu.c	(revision 3247)
+++ rEFIt_UEFI/Platform/cpu.c	(working copy)
@@ -778,7 +778,18 @@
             }
 						return 0x704;
           case CPU_MODEL_HASWELL_U5:
-            return 0x606;
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) M"))
+              return 0xB06; // Core M
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) i3"))
+              return 0x906; // Core i3 - Apple doesn't use it
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) i5"))
+              return 0x606; // Core i5
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) i7"))
+              return 0x706; // Core i7
+            if (gCPUStructure.Cores <= 2) {
+              return 0x606;
+            }
+            return 0x706;
           case CPU_MODEL_IVY_BRIDGE_E5:
             return 0xA01;
           case CPU_MODEL_ATOM_3700:

Core M CPU type was taken from a MacBook8,1 IOReg dump, which is attached (note: Terminal output, not IORegistryExplorer output). Also attached is a System Information report. A friend with a Broadwell i3 laptop tested it.

MacBook8,1.zip

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Clover doesn't properly detect Broadwell CPUs; well, it does, but it automatically assumes it's an i5. Here's a patch that should fix it (should autodetect Broadwell Core M, Core i3, Core i5, Core i7):

Index: rEFIt_UEFI/Platform/cpu.c
===================================================================
--- rEFIt_UEFI/Platform/cpu.c	(revision 3247)
+++ rEFIt_UEFI/Platform/cpu.c	(working copy)
@@ -778,7 +778,18 @@
             }
 						return 0x704;
           case CPU_MODEL_HASWELL_U5:
-            return 0x606;
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) M"))
+              return 0xB06; // Core M
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) i3"))
+              return 0x906; // Core i3 - Apple doesn't use it
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) i5"))
+              return 0x606; // Core i5
+            if (AsciiStrStr(gCPUStructure.BrandString, "Core(TM) i7"))
+              return 0x706; // Core i7
+            if (gCPUStructure.Cores <= 2) {
+              return 0x606;
+            }
+            return 0x706;
           case CPU_MODEL_IVY_BRIDGE_E5:
             return 0xA01;
           case CPU_MODEL_ATOM_3700:

Core M CPU type was taken from a MacBook8,1 IOReg dump, which is attached (note: Terminal output, not IORegistryExplorer output). Also attached is a System Information report. A friend with a Broadwell i3 laptop tested it.

Thanks, this is valuable info!

Accepted into 3248.

I can also note this MacBook uses 

"Intel HD Graphics 5300"

"AAPL,ig-platform-id" = 0x161e0001

May be someone found this info usefull.

  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

The code injected in DSDT by FixDarwin_0002 can be simplified...

 

Current code injected:

    Name (WXP1, "Windows 2001")
    Method (GET9, 2, NotSerialized)
    {
        CreateByteField (Arg0, Arg1, TCH9)
        Return (TCH9)
    }
    Method (STR9, 2, NotSerialized)
    {
        Name (STR8, Buffer (0x50) {})
        Name (STR9, Buffer (0x50) {})
        Store (Arg0, STR8)
        Store (Arg1, STR9)
        Store (Zero, Local0)
        Store (One, Local1)
        While (Local1)
        {
            Store (GET9 (STR8, Local0), Local1)
            Store (GET9 (STR9, Local0), Local2)
            If (LNotEqual (Local1, Local2)) { Return (Zero) }
            Increment (Local0)
        }
        Return (One)
    }
    Method (OOSI, 1, NotSerialized)
    {
        If (STR9 (WXP1, Arg0)) { Return (One) }
        Return (Zero)
    }
Note: STR9 should have been marked 'Serialized' as it is using globals; not thread-safe.

 

 

Simplification:

    Method (OOSI, 1, NotSerialized) { Return (LEqual(Arg0, "Windows 2001")) }
  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

It is not "equal", it is "contain substring".

For examle true for "Windows 2001.SP1"

OK... Not really "contains substring", but rather "starts with"...

 

Actually, OOSI("Windows 2001.SP1") does not return true.  And it shouldn't either.  The intention is for it to simulate "Windows 2001", not "Windows 2001.SP1" (which according to Microsoft documentation is actually "Windows 2001 SP1" [space vs. dot]).

 

But I missed the case of OOSI("Windows"), which should return true...

(minor point: spec says to return 0xFFFFFFFF for true, not 1)

 

Modified code, still simplified, with commments, here:

Method(OOSI, 1)
{
    // simulation target...
    Store("Windows 2001", Local0)
    // longer strings cannot match
    If (LGreater(SizeOf(Arg0), SizeOf(Local0))) { Return (0) }
    // compare only characters specified in the argument       
    CreateField(Local0, 0, ShiftLeft(SizeOf(Arg0),3), CMP1)
    CreateField(Arg0, 0, ShiftLeft(SizeOf(Arg0),3), CMP2)
    Return (LEqual(CMP1,CMP2))
}
BTW, my entire point in looking at this was because I wanted to simulate "Windows 2009" instead of "Windows 2001".

 

So, I use DSDT bin patch (_OSI->XOSI):

 

find:<5f4f5349>
repl:<584f5349>
 

And then an SSDT with XOSI method...

 

Method(XOSI, 1)
{
    Store("Windows 2009", Local0)
    If (LGreater(SizeOf(Arg0), SizeOf(Local0))) { Return (0) }
    CreateField(Local0, 0, ShiftLeft(SizeOf(Arg0),3), CMP1)
    CreateField(Arg0, 0, ShiftLeft(SizeOf(Arg0),3), CMP2)
    Return (LEqual(CMP1,CMP2))
}
Note: Not many DSDTs compare just _OSI("Windows"), so practically, the result is the same.
  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I know that Windows 2001 is rather obsolete and may not be present in modern BIOSes.

But I choose Windows 2001 and not Windows Vista+ because of different drivers models.

Windows XP assumes ACPI model as well as MacOSX up to Maverics and probably higher.

Windows Vista and up assumes WHQL drivers not appeal to ACPI. This is the key difference.

You may find in DSDT compares like 0x07d2

 

The same note about Linux. Even though DSDT knows string "Linux" it sets parameters for some ancient version, not as required by real new Linux.

 

I agree that this fix should be revised and I think some customization is required.

  • Like 2
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

I know that Windows 2001 is rather obsolete and may not be present in modern BIOSes.

But I choose Windows 2001 and not Windows Vista+ because of different drivers models.

Windows XP assumes ACPI model as well as MacOSX up to Maverics and probably higher.

Windows Vista and up assumes WHQL drivers not appeal to ACPI. This is the key difference.

You may find in DSDT compares like 0x07d2 < OS < 0x07d6 but your value 0x07d9 corresponding to newer Windows will be out of range.

 

The same note about Linux. Even though DSDT knows string "Linux" it sets parameters for some ancient version, not as required by real new Linux.

 

I agree that this fix should be revised and I think some customization is required.

The correct value to use really depends on what the DSDT is doing... after careful review of all conditionals in the DSDT/SSDTs.

 

It would be nice if the patch offered by Clover provided a way to customize the comparison string instead of it being hard-coded.

 

But my method works fine too and has the same result (nice the binpatch capability for DSDT... Simple/reliable/flexible).

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

After more reading of the Microsoft documentation, my implementation now:

 

    // All _OSI calls in DSDT are routed to XOSI...
    // XOSI simulates "Windows 2009" (which is Windows 7)
    // Note: According to ACPI spec, _OSI("Windows") must also return true
    //  Also, it should return true for all previous versions of Windows.
    Method(XOSI, 1)
    {
        // simulation targets
        // source: (google 'Microsoft Windows _OSI')
        //  http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
        Name(WINV, Package()
        {
            "Windows",              // generic Windows query
            "Windows 2001",         // Windows XP
            "Windows 2001 SP2",     // Windows XP SP2
            //"Windows 2001.1",     // Windows Server 2003
            //"Windows 2001.1 SP1", // Windows Server 20003 SP1
            "Windows 2006",         // Windows Vista
            "Windows 2006 SP1",     // Windows Vista SP1
            //"Windows 2006.1",     // Windows Server 2008
            "Windows 2009",         // Windows 7/Windows Server 2008 R2
            //"Windows 2012",       // Windows 8/Windows Sesrver 2012
            //"Windows 2013",       // Windows 8.1/Windows Server 2012 R2
            //"Windows 2015",       // Windows 10/Windows Server TP
        })
        Store(0, Local0)
        While (LLess(Local0, SizeOf(WINV)))
        {
            If (LEqual(DerefOf(Index(WINV,Local0)), Arg0)) { Return (0xFFFFFFFF) }
            Increment(Local0)
        }
        Return (0)
    }
Edit... and here's an even simpler (and more efficient) version:

    // All _OSI calls in DSDT are routed to XOSI...
    // XOSI simulates "Windows 2009" (which is Windows 7)
    // Note: According to ACPI spec, _OSI("Windows") must also return true
    //  Also, it should return true for all previous versions of Windows.
    Method(XOSI, 1)
    {
        // simulation targets
        // source: (google 'Microsoft Windows _OSI')
        //  http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
        Name(WINV, Package()
        {
            "Windows",              // generic Windows query
            "Windows 2001",         // Windows XP
            "Windows 2001 SP2",     // Windows XP SP2
            //"Windows 2001.1",     // Windows Server 2003
            //"Windows 2001.1 SP1", // Windows Server 2003 SP1
            "Windows 2006",         // Windows Vista
            "Windows 2006 SP1",     // Windows Vista SP1
            //"Windows 2006.1",     // Windows Server 2008
            "Windows 2009",         // Windows 7/Windows Server 2008 R2
            //"Windows 2012",       // Windows 8/Windows Sesrver 2012
            //"Windows 2013",       // Windows 8.1/Windows Server 2012 R2
            //"Windows 2015",       // Windows 10/Windows Server TP
        })
        Return (LNotEqual(Match(WINV, MEQ, Arg0, MTR, 0, 0), Ones))
    }
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Clover has model string incorrect for 8086:0112.

 

8086:0112 is HD3000, not HD2000.

 

In gma.c, this:

  { 0x0112, "Intel HD Graphics 2000"  },
should be:

  { 0x0112, "Intel HD Graphics 3000"  },
It is cosmetic only and can be fixed by Devices/AddProperties (and Devices/NoDefaultProperites) or DSDT patch.
Link to comment
Share on other sites
calibre™
calibre™
Posted
Posted

@Slice

Hello.. Im fun of testing older builds of OSX in Clover (always latest). Here is what i found during my test using FakeCPUID feature.

 

CPU: i5-4460 Haswell

OS: SL & Lion

post-1471422-0-34835300-1437112139_thumb.png

SL = 0x0206A0

32Bit = Instant reboot!

64Bit = Working

 

LION = 0x0306A0

32Bit = Working

64Bit = Instant Reboot!

 

I can send debug report if you can tell which to enable in config.plist

 

Thanks :)

 
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Clover has model string incorrect for 8086:0112.

 

8086:0112 is HD3000, not HD2000.

 

In gma.c, this:

  { 0x0112, "Intel HD Graphics 2000"  },
should be:

  { 0x0112, "Intel HD Graphics 3000"  },
It is cosmetic only and can be fixed by Devices/AddProperties (and Devices/NoDefaultProperites) or DSDT patch.

 

Screen Shot 2015-07-18 at 9.29.09.png

@Slice

Hello.. Im fun of testing older builds of OSX in Clover (always latest). Here is what i found during my test using FakeCPUID feature.

 

CPU: i5-4460 Haswell

OS: SL & Lion

attachicon.gifCPUID_table.png

SL = 0x0206A0

32Bit = Instant reboot!

64Bit = Working

 

LION = 0x0306A0

32Bit = Working

64Bit = Instant Reboot!

 

I can send debug report if you can tell which to enable in config.plist

 

Thanks :)

May be the reboot with CPUPM?

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Must be inaccurate. I helped someone with i5-2500k. Device-id was 8086:0112.

 

http://ark.intel.com/products/52210/Intel-Core-i5-2500K-Processor-6M-Cache-up-to-3_70-GHz

 

No biggie... easy to work around with _DSM inject or config.plist/Devices/NoDefaultProperties, config.plist/Devices/AddProperties.

 

From Chameleon gma.h:

#define GMA_SANDYBRIDGE_GT1        GFX_MODEL_CONSTRUCT(INTEL, 0x0102) // HD Graphics 2000
...
#define GMA_SANDYBRIDGE_GT2        GFX_MODEL_CONSTRUCT(INTEL, 0x0112) // HD Graphics 3000
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Must be inaccurate. I helped someone with i5-2500k. Device-id was 8086:0112.

 

http://ark.intel.com/products/52210/Intel-Core-i5-2500K-Processor-6M-Cache-up-to-3_70-GHz

 

No biggie... easy to work around with _DSM inject or config.plist/Devices/NoDefaultProperties, config.plist/Devices/AddProperties.

 

From Chameleon gma.h:

#define GMA_SANDYBRIDGE_GT1        GFX_MODEL_CONSTRUCT(INTEL, 0x0102) // HD Graphics 2000
...
#define GMA_SANDYBRIDGE_GT2        GFX_MODEL_CONSTRUCT(INTEL, 0x0112) // HD Graphics 3000

Chameleon knows better then Intel!

Anyway what is the difference if System Profiler shows hd2000 or hd3000? Kexts attached to DeviceID not to Model name.

 

How to fix it then? I have removed applecpupm but still early reboot.

May be you should show something? debug.log for example?

  • Like 2
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Chameleon knows better then Intel!

Even Intel can make mistakes.

 

Anyway what is the difference if System Profiler shows hd2000 or hd3000? Kexts attached to DeviceID not to Model name.

Cosmetic only.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

OS X has no native support for HD3000 desktop (it was omitted from the Info.plist), because there are no Apple computers with this hardware.

 

My i7-2600k is 0122:8086. I use FakeID/IntelGFX=0x01268086.

 

You cannot rely on Apple's Info.plist as a reference for device-ids.

Any chance to make this work on 10.7

attachicon.gifKernelPM.png

XCPM was introduced in 10.8.5.

Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

OS X has no native support for HD3000 desktop (it was omitted from the Info.plist), because there are no Apple computers with this hardware.

 

My i7-2600k is 0122:8086. I use FakeID/IntelGFX=0x01268086.

 

You cannot rely on Apple's Info.plist as a reference for device-ids.

This is correct, Apple never used desktop CPUs with HD 3000. 2011 iMacs had desktop CPUs with model numbers that end in S - these all have HD 2000. iMacs use the IGPU for AirPlay Mirroring (using QuickSync), which is why the HD 2000 device IDs are in the kext (same thing with HD 2500 IDs in the HD 4000 kexts).

 

On another note, I was looking at the AMD injector (ati.c) and corrected some of the Tahiti IDs.

 

Original:

    { 0x6780,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x6784,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x6788,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x678A,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x6790,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x6791,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x6792,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7900 Series",	kFutomaki	},
    { 0x6798,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7970X/8970/R9 280X",	kFutomaki	},
    { 0x6799,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7990 Series",	kAji		},
    { 0x679A,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7950/8950/R9 280",	kFutomaki	},
    { 0x679B,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7990 Series",	kFutomaki	},
    { 0x679E,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7870 XT",      kFutomaki	},
    { 0x679F,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7950 Series",	kFutomaki	},
 

Is there a reason for having 0x00000000 as the fake_ids for all of the cards by default, even for cards that don't have native support? I added them for some of the non-native cards. I also changed some of the framebuffers to ones that better fit the cards' port layouts.

 

Edited (commented out some IDs I'm not sure about/couldn't find info about, and used only one name for device IDs that multiple cards share) Version:

	{ 0x6780,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD FirePro W9000",	kIkuraS		},
 //	{ 0x6784,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD FirePro ?????",	kFutomaki	},
 //	{ 0x6788,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD FirePro ?????",	kFutomaki	},
	{ 0x678A,	0x679A1002, CHIP_FAMILY_TAHITI,	"AMD FirePro W8000",	kEbiS		}, // AMD FirePro S9000/S9050/S10000
	{ 0x6790,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7970",	kFutomaki	}, // Gigabyte is dumb and used this for some of their cards
 //	{ 0x6791,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD ????",	kFutomaki	},
 //	{ 0x6792,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD ????",	kFutomaki	},
	{ 0x6798,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7970",	kFutomaki	}, // AMD Radeon HD 8970/AMD Radeon R9 280X/AMD FirePro D700
	{ 0x6799,	0x67981002, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7990",	kChutoro	}, // AMD Radeon HD 8990?
	{ 0x679A,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7950",	kFutomaki	}, // AMD Radeon HD 8950/AMD Radeon R9 280
	{ 0x679B,	0x67981002, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7990",	kChutoro	}, // AMD Radeon HD 8990?
	{ 0x679E,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD 7870 XT",kFutomaki	},
 //	{ 0x679F,	0x00000000, CHIP_FAMILY_TAHITI,	"AMD Radeon HD ????",	kFutomaki	},

Maybe the different cards sharing the same device ID could be distinguished using the subsystem IDs. Chameleon does this, but they combine the subsystem and vendor IDs, which results in super long lists for each card with different vendor IDs but the same subsystem ID. Maybe detection using the subsystem ID itself could be used.

AMD FirePro W9000:
 - Reference Ports: 6x Mini DisplayPort
 - Recommended Framebuffer: IkuraS, KaniS, OPM, or Junsai
AMD FirePro W8000:
 - Reference Ports: 4x DisplayPort
 - Recommended Framebuffer: No proper match, may work with Ebi or Chutoro (5 ports with 4x Mini DisplayPort)
 - Notes (1): Needs FakeID (device ID not present in the kext), set to 7950 device ID (closest match)
 - Notes (2): FirePro S9000/S9050/S10000 have same device ID and 1x DisplayPort, no proper match for framebuffer (could be any)
AMD Radeon HD 7990:
 - Reference Ports: 4x Mini DisplayPort, 1x DVI
 - Recommended Framebuffer: Ebi or Chutoro (note that these framebuffers have SL-DVI, the card has DL-DVI)
 - Notes (1): Needs FakeID 
AMD Radeon HD 7970:
 - Reference Ports: 1x HDMI, 2x Mini DisplayPort, 1x DVI
 - Recommended Framebuffer: Futomaki, Aji, Buri, Dashimaki, Hamachi, or DashimakiS
 - Notes (1): Sapphire Dual-X/Vapor-X, ASUS DirectCU II, or other cards with custom port layout need patched framebuffer
 - Notes (2): Radeon HD 8970/R9 280X/FirePro D700 have the same device IDs but different subsystem IDs; 7970 has 3000, 280X has 3001, D700 has 0128 for one card (0127 too?)
AMD Radeon HD 7950:
 - Same as above
AMD Radeon HD 7870 XT:
 - Same as above
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...