Lilu not firing early without working GOP/UGA display output on macOS 11

[internetzel]

AppleALC is not fully working (it's loading but there's no audio devices available) on my iMac 11,1 (late 2009 27" core-i5, AMD RX480 graphics card upgrade) when there's no actually working EFI display output available.

I'm using OpenCore-Legacy-Patcher, revision 0ac3353 for setting up and installing OpenCore. I added liludump=200 manually in order to get the lilu logs.

There are some differences in the lilu logs, that might indicate some timing issues.
Lilu_1.5.2_20.4 ALC working.txt
Lilu_1.5.2_20.4 ALC not working.txt

[internetzel]

OpenCore-Legacy-Patcher issue 180 was discovered while trying to find the cause for this AppleALC issue.

[vit9696]

This is OCLP issue, not AppleALC. You got it wrong again :) On AppleALC side I may try recommending adding timeouts like alcdelay=1000. CC @khronokernel

[internetzel]

Thanks for that tip!
Obviously not obvious who is actually responsible for which problem - in this case impossible for anyone not involved in AppleALC code.

[internetzel]

alcdelay doesn't help so far, even the maximum of 3000 doesn't.
The lilu logs stay the same other than the changed kernel address;
only the non-working boots show those two lines one time very early, even before kext loading has actually started:

AppleALC iokit: @ (DBG) getOSData alc-verbs was not found
AppleALC client: @ (DBG) device disallows to send custom verbs

Both working and non-working boots show those lines after HDA kexts have started loading.

[khronokernel]

@internetzel Can you provide an IOReg of both working and non-working AppleALC? File -> SaveAs:
https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-210.zip?raw=true

[internetzel]

Here are the IOReg dumps - although I created them using IORegistryExplorer 3.0.2, which are incompatible to the version 2.1.0 you posted.
iMac11,1_ALC_IOReg_dumps.zip
The device properties of the HDEF node seem to not have been set correctly.

[internetzel]

In case you cannot open the files, here screenshots of the HDEF node in both cases:

[khronokernel]

With OCLP, we inject the following properties:

self.config["DeviceProperties"]["Add"][hdef_path] = {"apple-layout-id": 90, "use-apple-layout-id": 1, "use-layout-id": 1, }

Checking your IOReg, I see that these 3 properties are in fact present however AppleALC seems to have ignored them as layout-id is untouched in the second IOReg. Could you test with alcid=81 in OpenCore's NVRAM -> boot-args entry? As well as remove the PciRoot(0x0)/Pci(0x1b,0x0) entry under DeviceProperties

[internetzel]

alcid=81 does not seem to have any effect - moreover once again I cannot boot Mojave without display when using that setting?!
iMac11,1_ALC_alcid81.zip

[internetzel]

Using -alcdbg reveals the following difference (last line):
(working)

Lilu iokit: @ (DBG) getOSData apple-layout-id has 5A value
Lilu dev: @ (DBG) found property layout id override to 90
AppleALC iokit: @ (DBG) getOSData vendor-id has 8086 value
AppleALC iokit: @ (DBG) getOSData alctcsel was not found
AppleALC alc: @ (DBG) disabling TCSEL update
AppleALC iokit: @ (DBG) getOSData alc-layout-id was not found
AppleALC iokit: @ (DBG) getOSData layout-id has 51 value
AppleALC alc: @ (DBG) found legacy layout-id 81 property
AppleALC alc: @ (DBG) fixing MaximumBootBeepVolumeAlt in hdef
AppleALC alc: @ (DBG) fixing built-in

(not working)

Lilu iokit: @ (DBG) getOSData apple-layout-id has 5A value
Lilu dev: @ (DBG) found property layout id override to 90
AppleALC iokit: @ (DBG) getOSData vendor-id has 8086 value
AppleALC iokit: @ (DBG) getOSData alctcsel was not found
AppleALC alc: @ (DBG) disabling TCSEL update
AppleALC iokit: @ (DBG) getOSData alc-layout-id was not found
AppleALC iokit: @ (DBG) getOSData layout-id has 51 value
AppleALC alc: @ (DBG) found legacy layout-id 81 property
AppleALC alc: @ (DBG) fixing MaximumBootBeepVolumeAlt in hdef
AppleALC alc: @ (DBG) found existing built-in

[internetzel]

The above difference only occurs when having set use-layout-id to 0, instead of the 1 being set by OCLP.
Nevertheless it's working in one case and not working in the other.

[vit9696]

Please provide debug logs for AppleALC in file format. -liludbgall liludump=60 and then upload /var/log/Lilu_x.x.x.txt. Do it for both working and not working cases. Remove the file every time you make a new log.

[internetzel]

I cannot reproduce the above log message difference any longer.
Nevertheless here the logs for use-layout-id=0 and use-layout-id=1, in both working and non-working cases.
Seem to be equal to the first ones posted, with use-layout-id not having made any difference this time.
Lilu_1.5.2_20.4_use-layout-id0_working.txt
Lilu_1.5.2_20.4_use-layout-id0_not_working.txt
Lilu_1.5.2_20.4_use-layout-id1_working.txt
Lilu_1.5.2_20.4_use-layout-id1_not_working.txt

BTW I need liludump=200 because booting from USB2.0 connected spinning hard drive is painfully slow; Firewire booting used to be much faster.

[vit9696]

It is really all about timing. AppleHDA is probed before Lilu detects all the hardware. Currently Lilu startup on macOS 11 happens on screen enablement, so it is quite logical that the patching fails. The issue is not reproducible on macOS 10.15, correct? I am not sure we want to change this behaviour, fixing up the GPU may be a better idea.

[internetzel]

Did not test Catalina again, but Mojave does boot blindly with AppleALC working.
Good to know the details and thanks for your time!

[vit9696]

I guess I will reopen this as it is technically a bug, but I am not sure I will get there any soon.

[Piipperi]

Has there been a workaround for this issue yet? Currently, every time I want to boot macOS my laptop is in docked/clamshell mode, I need to take the laptop and boot it with the lid open as it does not recognize the external displays on boot. It's a slight annoyance as I do swap between Windows and macOS often.

[joevt]

My Lilu fork might have early booting improvements for Big Sur and later. All Lilu based kexts need to be compiled using the same Lilu.kext.