Contribute
Register

Haswell GT1 no QE/CI on Mavericks

Status
Not open for further replies.
Hi, so I spent a couple of hours tonight to retry. Good news is, the "no signal" is gone, it turned out that I accidentally left DSDT.aml in patched folder, and it overrides Clover ID injection. Does that mean connector is alright?
Anyway, no matter which device-id & ig-platform-id I tried (0x0c06, 0x0426, 0x0412. etc.), still no QE/CI, and it's still showing Graphics as "Unknown 1024MB". Right now, I'm using device-id=0x0406, and ig-platform-id=0x04060000, which I extracted from Pike's AppleIntelFramebufferAzul.sh. Below is the full list:


I attached here the DSDT.aml and exported IOReg. Hopefully someone can find a clue about what to do next.

You have CI, but no QE. It means the framebuffer is loaded but the accelerator kext is not.

You're currently using ig-platform-id 0xa260005. It is a mobile ig-platform-id and probably doesn't make sense for a desktop configuration (it has an LVDS connector and two DP connectors). Of course, if it works, it just means that the DP connectors are kicking in. I can see from ioreg that your display is connected to the second such DP connector.

You are currently using a fake device-id 0x0a16 and the kext is loading. It would probably be better to use a FakeID that represents a GT1 device (0xa16 is HD4400 mobile.. GT2).

To get the QE, you will need FakePCIID: https://github.com/RehabMan/OS-X-Fake-PCI-ID/. You will need to create a custom injector to fake the PCI device ID to a supported GT1 device.
 
I'm injecting using DSDT, so it's irrelevant.

Ok, you mentioned that you accidentally left the DSDT in your patched folder so I figured you weren't using it.
 
Ok, well I don't use the 0x and it works fine for me. I have mine entered for use with AirPlay Mirroring.

From Clover source, settings.c:
Code:
      Prop = GetProperty (DictPointer, "ig-platform-id");
      if (Prop != NULL) {
        gSettings.IgPlatform = (UINT32)GetPropertyInteger (Prop, 0);
      }

And...
Code:
INTN
GetPropertyInteger (
  TagPtr Prop,
  INTN Default
  )
{
  if (Prop == NULL) {
    return Default;
  }

  if (Prop->type == kTagTypeInteger) {
    return (INTN)Prop->string;    
  } else if ((Prop->type == kTagTypeString) && Prop->string) {
    if ((Prop->string[1] == 'x') || (Prop->string[1] == 'X')) {
      return (INTN)AsciiStrHexToUintn (Prop->string);
    }

    if (Prop->string[0] == '-') {
      return -(INTN)AsciiStrDecimalToUintn (Prop->string + 1);
    }

    return (INTN)AsciiStrDecimalToUintn (Prop->string);
  }
  return Default;
}

Without the 'x' or 'X' in the second character (first character can be anything...), it is treated as decimal, not hex.

I looked at AsciiStrDecimalToUintn as well. It does not deal with hex...

Code:
UINTN
EFIAPI
AsciiStrDecimalToUintn (
  IN      CONST CHAR8      	        *String
  )
{
  UINTN     Result;
  
  ASSERT (String != NULL);
  ASSERT (AsciiStrLen (String) < PcdGet32 (PcdMaximumAsciiStringLength));

  //
  // Ignore the pad spaces (space or tab)
  //
  while ((*String == ' ') || (*String == '\t')) {
    String++;
  }

  //
  // Ignore leading Zeros after the spaces
  //
  while (*String == '0') {
    String++;
  }

  Result = 0;

  while (InternalAsciiIsDecimalDigitCharacter (*String)) {
    //
    // If the number represented by String overflows according 
    // to the range defined by UINTN, then ASSERT().
    //
    ASSERT ((Result < QUIENT_MAX_UINTN_DIVIDED_BY_10) ||
      ((Result == QUIENT_MAX_UINTN_DIVIDED_BY_10) && 
      (*String - '0') <= REMINDER_MAX_UINTN_DIVIDED_BY_10)
      );

    Result = Result * 10 + (*String - '0');
    String++;
  }
  
  return Result;
}

What will happen is gSettings.IgPlatform will be set to zero (because AsciiStrDecimalToUintn will process the leading 0 only, and then stop when it sees a non-decimal character 'x'), ignoring your ig-platform-id specification in config.plist, which will cause you to receive the default ig-platform-id...

Note code from Clover's gma.c:
Code:
      [B]if (!gSettings.IgPlatform)[/B] {
        switch (gma_dev->device_id) {
          case 0x162:
          case 0x16a:
            devprop_add_value(device, "AAPL,ig-platform-id", GMAX3100_vals[23], 4);
            devprop_add_value(device, "class-code",	(UINT8*)ClassFix, 4);
            break;
          case 0x152:
            devprop_add_value(device, "AAPL,ig-platform-id", GMAX3100_vals[24], 4);
            break;           
          case 0x166:
          case 0x156:
            devprop_add_value(device, "AAPL,ig-platform-id", GMAX3100_vals[25], 4);
            break;
          case 0x0102:
          case 0x0106:
          case 0x0112:
          case 0x0116:
          case 0x0122:
          case 0x0126:
            break;
          default:
            devprop_add_value(device, "AAPL,ig-platform-id", GMAX3100_vals[26], 4);
            break;
        }
      } else {
        devprop_add_value(device, "AAPL,ig-platform-id", (UINT8*)&gSettings.IgPlatform, 4);
      }

So... your ig-platform-id is ignored and it is as if you didn't specify it at all. You're getting the default.
 
Good to know. Thanks for the info!
 
First of all, I have to say this: wow, you're amazing, ReHabMan :D

You're currently using ig-platform-id 0xa260005. It is a mobile ig-platform-id and probably doesn't make sense for a desktop configuration (it has an LVDS connector and two DP connectors). Of course, if it works, it just means that the DP connectors are kicking in. I can see from ioreg that your display is connected to the second such DP connector.

You are currently using a fake device-id 0x0a16 and the kext is loading. It would probably be better to use a FakeID that represents a GT1 device (0xa16 is HD4400 mobile.. GT2).
Your comment reminds me about the ID I left in config.plist. At first, I thought DSDT will override those in config. Because whatever I use in config, I always saw the value I set in DSDT. But it seems that both values affect the final value. The strange thing is, my DSDT is: 0x0406 + 0x04060000, and config is: 0x0426 + 0x0d220003 (the result in System Information is: Unknown 1024MB, with device-id as 0x0406). I'm not sure why you still saw 0x0a16 + 0x0a260005 in my IOReg, it's the values I used long ago.
So this morning, I removed the values in config. And now System Information is showing Intel HD 5000, device-id 0x0406 as screenshots. Now it's not showing "loading driver...." in boot console, and seems a bit slower than before removing (that's weird).
I also re-exported ioreg after I removed ID in config.

To get the QE, you will need FakePCIID: https://github.com/RehabMan/OS-X-Fake-PCI-ID/. You will need to create a custom injector to fake the PCI device ID to a supported GT1 device.
Let me recap my questions:
1. 0x0406 + 0x04060000 is good enough to proceed to next steps?
2. Please help check my latest ioreg if 0x0a16 is still there.
3. PCI device ID is a new thing, where i can find any clue about which value I can use? which ones are supported GT1 IDs?

Again, thank you very much for your help, if it wasn't you, I wouldn't go this far :)
 

Attachments

  • HP_Stream_without_ID_in_config.ioreg
    2 MB · Views: 154
  • system_information.png
    system_information.png
    948.5 KB · Views: 220
  • DSDT_patch.png
    DSDT_patch.png
    41.1 KB · Views: 188
Your comment reminds me about the ID I left in config.plist. At first, I thought DSDT will override those in config. Because whatever I use in config, I always saw the value I set in DSDT.

An injection with _DSM will always override any injection via config.plist (which uses EFI injection).

But it seems that both values affect the final value. The strange thing is, my DSDT is: 0x0406 + 0x04060000, and config is: 0x0426 + 0x0d220003 (the result in System Information is: Unknown 1024MB, with device-id as 0x0406). I'm not sure why you still saw 0x0a16 + 0x0a260005 in my IOReg, it's the values I used long ago.

There are two separate properties here. device-id is controlled by config.plist/Devices/FakeID/IntelGFX. And AAPL,ig-platform-id controlled by config.plist/Graphics/ig-platform-id. Both can be overridden in DSDT with a _DSM method.

So this morning, I removed the values in config. And now System Information is showing Intel HD 5000, device-id 0x0406 as screenshots.

It is best to use config.plist exclusively as a method of setting these properties. Especially when experimenting. They are easier to change there.

In any case, choose one method to inject your properties and use only that method (eg. DSDT or config.plist).

Let me recap my questions:
1. 0x0406 + 0x04060000 is good enough to proceed to next steps?

The framebuffer is still loading with device-id 0x406. Any ig-platform-id that works can be used.

2. Please help check my latest ioreg if 0x0a16 is still there.

Look under the GFX0 node for device-id.

3. PCI device ID is a new thing, where i can find any clue about which value I can use? which ones are supported GT1 IDs?

Use the FakePCIID_HD4600_HD4400.kext as an example. If you're going to use 0x0406 as device-id, the IOPCIPrimaryMatch has to include that ID (0x04068086). That will allow FakePCIID to load/attach to that device. Then modify RM,device-id in FakeProperties to actually fake the ID returned from configRead32. For example, set to <06040000> to fake 0x0406.

You'll need to do some research on devices that are GT1 and supported by the kext. Look at IOPCIPrimary match in the Info.plist for AppleIntelHD5000Graphics.kext. I see on Yosemite: 0x0d268086 0x0a268086 0x0a2e8086 0x0d228086 0x04128086, which I know are all GT2 devices (GT1 support seems removed). It could be that Mavericks doesn't really support GT1 and that's why the devices were removed from Mavericks->Yosemite. Find out whether any of the IDs in the Mavericks Info.plist are GT1, then try them as RM,device-id in FakeProperties.
 
Use the FakePCIID_HD4600_HD4400.kext as an example. If you're going to use 0x0412 as device-id, the IOPCIPrimaryMatch has to include that ID (0x04068086).
Thanks RehabMan, I think I understand your explanations :)
Except you mentioned about 0x0412, and then 0x0406, which confused me a little bit.
So am I going to reach the end of the road? I hope I can report some good news here in a few days :)
 
Quick update:
Greate news: I finally saw QE/CI for the first time on HP Stream Mini, whoohoo!!!
Not-so-good news: it seems not to like device-id 0x0406.
At first, I modified your FakePCIID_HD4600_HD4400.kext to add 0x0406. After reboot, the screen kept flickering as heck, and images were scattered all over. I thought: that's it, what an epic fail. But when I turn on/off monitor for the 3rd time, some magic happened. It actually worked, but just for a few minute :D
Graphics was hang for some seconds, and then restarted itself. I can't even reply using it, and have to login to Windows instead :D
There is only one GT1 ID left (I think). Will try it tomorrow and update result here.
 
Status
Not open for further replies.
Back
Top