[BUG] Black screen 3 minutes after booting, CoffeeLake UHD 630

[RehabMan]

There is no RMB1 operation region in my DSDT.

RMB1 is in SSDT-PNLF:

        OperationRegion(RMB1, SystemMemory, BAR1 & ~0xF, 0xe1184)
        Field(RMB1, AnyAcc, Lock, Preserve)
        {
            Offset(0x48250),
            LEV2, 32,
            LEVL, 32,
            Offset(0x70040),
            P0BL, 32,
            Offset(0xc2000),
            GRAN, 32,
            Offset(0xc8250),
            LEVW, 32,
            LEVX, 32,
            LEVD, 32,
            Offset(0xe1180),
            PCHL, 32,
        }

 

[headkaze]

I think it is a bad sign that AppleBacklightAtBoot is showing as 0x2f2f6.

What is AppleBacklightAtBoot referring to?

The latest Clover outputs backlight registers in its log file on boot.

Here is the output for my system:

8:766  0:000    LEV2 = 0x80000000, LEVL = 0x0, P0BL = 0x45E, GRAN = 0xF00
8:766  0:000    LEVW = 0x80000000, LEVX = 0x1D4C0, LEVD = 0x1D4C0, PCHL = 0x0

The LEVX (BXT_BLC_PWM_FREQ1) has the same starting value as LEVD (BXT_BLC_PWM_DUTY1) which just means 0xFFFF * BXT_BLC_PWM_FREQ1 / 0xFFFF which is 0x1D4C0 or maximum brightness.

 

[RehabMan]

What is AppleBacklightAtBoot referring to?

I believe it is the value read for the current backlight level at LEVD (BXT_BLC_PWM_DUTY1).

The latest Clover outputs backlight registers in its log file on boot.

Here is the output for my system:

8:766  0:000    LEV2 = 0x80000000, LEVL = 0x0, P0BL = 0x45E, GRAN = 0xF00
8:766  0:000    LEVW = 0x80000000, LEVX = 0x1D4C0, LEVD = 0x1D4C0, PCHL = 0x0

The LEVX (BXT_BLC_PWM_FREQ1) has the same starting value as LEVD (BXT_BLC_PWM_DUTY1) which just means 0xFFFF * BXT_BLC_PWM_FREQ1 / 0xFFFF which is 0x1D4C0 or maximum brightness.

The idea would be that after the _INI code runs from SSDT-PNLF, that LEVX and LEVD would be 0xFFFF.
Because we don't want some code in macOS to set LEVX to 0xFFFF but leave LEVD larger than 0xFFFF (or run into the overflow problem you identified), as that causes a black screen.
(and 0xFFFF*0xFFFF does not overflow 32-bits).

Maybe the SSDT-PNLF is not calculating the systemMemory address properly (BAR1 at offset 0x10 in PCI-config no longer used for BAR1 address possibly?) When I did this stuff on Haswell (way back when), I verified everything by fiddling around in RW-Everything in Windows.

 

[headkaze]

Maybe the SSDT-PNLF is not calculating the systemMemory address properly (BAR1 at offset 0x10 in PCI-config no longer used for BAR1 address possibly?)

One of the fixes I had to do to get AppleIntelInfo working in CFL was combine BAR0 and BAR1 to get the correct address.

outl(0xcf8, 0x80001010);
UInt64 mmio = inl(0xcfc);
outl(0xcf8, 0x80001014);
// Need to combine BaseAddress0 and BaseAddress1
mmio = (((UInt64)inl(0xcfc) << 32) | (mmio & 0x7FFFC00000)); // mask bits 38-22

 

[Amandeep]

There is no BAR1 in my DSDT. Only BAR0. In LPD3 in _SB.PCI0.

 

[RehabMan]

There is no BAR1 in my DSDT. Only BAR0. In LPD3 in _SB.PCI0.

Not expected in DSDT. It is defined in SSDT-PNLF.aml.

 

[headkaze]

The idea would be that after the _INI code runs from SSDT-PNLF, that LEVX and LEVD would be 0xFFFF.
Because we don't want some code in macOS to set LEVX to 0xFFFF but leave LEVD larger than 0xFFFF (or run into the overflow problem you identified), as that causes a black screen.
(and 0xFFFF*0xFFFF does not overflow 32-bits).

We're holding off on merging the backlight fix to master for now to see if you can get this working. Either way vit and I think the patch should either go into AppleBacklightFixup or everything should be merged into WEG.

 

[RehabMan]

We're holding off on merging the backlight fix to master for now to see if you can get this working. Either way vit and I think the patch should either go into AppleBacklightFixup or everything should be merged into WEG.

I'll see if I can figure how to calculate the base address correctly. Surprised Intel would change something as basic as the BAR1 though.

I think it is wise to have a SSDT-PNLF with some debug code in it first, just to see where we are.
Attached to this post.

To use:
- copy SSDT-PNLF-debug.aml in ACPI/patched
- also add SSDT-RMDT.aml
- install ACPIDebug.kext
- reboot
- collect problem reporting files as per FAQ (or at least kernel logs from the boot)

You should have kernel logs from ACPIDebug:

log show --last boot --style syslog | grep ACPIDebug

--

And yes, certain advantages would be realized if the SSDT-PNLF _INI code was in AppleBacklightFixup.kext (or more likely WhateverGreen), as these kexts would be able to determine the actual max in use (without a gigantic/complex switch statement), as the max is in the ig-platform-id data, and these kexts can know which ig-platform-id is in use.

BTW, was looking at the Clover code, and it seems to have some code to set LEVX/LEVD. Does that code not work? The code in Clover is a bit over complex (eg. device-id is NOT a factor in determining the max, it is only guessed that way in SSDT-PNLF because SSDT-PNLF has no idea which ig-platform-id is being used).

 

[Amandeep]

I'll see if I can figure how to calculate the base address correctly. Surprised Intel would change something as basic as the BAR1 though.

I think it is wise to have a SSDT-PNLF with some debug code in it first, just to see where we are.
Attached to this post.

To use:
- copy SSDT-PNLF-debug.aml in ACPI/patched
- also add SSDT-RMDT.aml
- install ACPIDebug.kext
- reboot
- collect problem reporting files as per FAQ (or at least kernel logs from the boot)

You should have kernel logs from ACPIDebug:

log show --last boot --style syslog | grep ACPIDebug

--

And yes, certain advantages would be realized if the SSDT-PNLF _INI code was in AppleBacklightFixup.kext (or more likely WhateverGreen), as these kexts would be able to determine the actual max in use (without a gigantic/complex switch statement), as the max is in the ig-platform-id data, and these kexts can know which ig-platform-id is in use.

BTW, was looking at the Clover code, and it seems to have some code to set LEVX/LEVD. Does that code not work? The code in Clover is a bit over complex (eg. device-id is NOT a factor in determining the max, it is only guessed that way in SSDT-PNLF because SSDT-PNLF has no idea which ig-platform-id is being used).

2018-10-18 00:07:30.817426+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: Version 0.1.4 starting on OS X Darwin 18.0.

2018-10-18 00:07:30.817694+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "RMCF.BKLT(Local4)", 0x1, }

2018-10-18 00:07:30.817800+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "^GDID(Local0)", 0x3e9b, }

2018-10-18 00:07:30.817941+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: "PWM fixup for CoffeeLake"

2018-10-18 00:07:30.818068+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "^LEVX(Local1), new max(Local2)", 0x1be6d, 0xffff, }

2018-10-18 00:07:30.818179+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "setting new max", 0xffff, }

2018-10-18 00:07:30.818288+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "old LEVD, new LEVD(Local0)", 0x1be6d, 0xffff, }

2018-10-18 00:07:30.818396+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "final ^LEVD,^LEVX", 0xffff, 0xffff, }

2018-10-18 00:07:30.818502+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "setting _UID for max(Local2)", 0xffff, }

2018-10-18 00:07:30.818602+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "_UID", 0x13, }

 

[RehabMan]

2018-10-18 00:07:30.817426+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: Version 0.1.4 starting on OS X Darwin 18.0.

2018-10-18 00:07:30.817694+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "RMCF.BKLT(Local4)", 0x1, }

2018-10-18 00:07:30.817800+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "^GDID(Local0)", 0x3e9b, }

2018-10-18 00:07:30.817941+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: "PWM fixup for CoffeeLake"

2018-10-18 00:07:30.818068+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "^LEVX(Local1), new max(Local2)", 0x1be6d, 0xffff, }

2018-10-18 00:07:30.818179+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "setting new max", 0xffff, }

2018-10-18 00:07:30.818288+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "old LEVD, new LEVD(Local0)", 0x1be6d, 0xffff, }

2018-10-18 00:07:30.818396+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "final ^LEVD,^LEVX", 0xffff, 0xffff, }

2018-10-18 00:07:30.818502+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "setting _UID for max(Local2)", 0xffff, }

2018-10-18 00:07:30.818602+0530  localhost kernel[0]: (ACPIDebug) ACPIDebug: { "_UID", 0x13, }

It seems to show the code is working as expected.

@headkaze: Any ideas on what happens after these values are set that might reset them? Or is there a mirror of them somewhere that might be being read?

I'm not sure where the 0x2f2f6 value is coming from in AppleBacklightAtBoot. Typically that value is the value of current backlight level (eg. would think it would be LEVD in this case).

Note @Amandeep: You're still using the wrong SMBIOS (that one is dual GPU w/GMUX). Not sure if that has an effect, but it is one problem/mistake/issue that should be eliminated. Please change to MacBookPro15,2 or MacBookPro14,1 or MacBookPro11,1.