Cometlake U graphics initilaization problem

[miczyg1]

I have a problem with Intel graphics on a i5-10310u SoC ported to coreboot. I am using Debian 10 with 4.19.x kernel for testing, but it cannot start X session, because /dev/dri/card0 when installed in UEFI mode. When booted in legacy mode X session is starting and the platform is usable till the moment when the screen blanks due to inactivity, then the platform resets. coreboot logs show the PMC firmware requested global reset (from the global reset cause registers). So I suspect a problem with graphics initialization. Tried various scenarios:

1. Debian 10, kernel 4.19.x, legacy. Graphics initialized with VGA OROM. X is working until one gets the system occupied. When it goes inactive and screen blanks, then global reset happens
2. Debian 10, kernel 4.19.x, UEFI with TianoCore UEFI payload package. Graphics initialized with FSP GOP driver. X is not working, from the log I see /dev/dri/card0 is not found, but platform is stable.
3. Debian 10, kernel 5.10 installed from backports, UEFI with TianoCore UEFI payload package. Graphics initialized with FSP GOP driver. I noticed the i915 driver does not bind to graphics device in previous cases, so I upgraded the kernel, because Cometlake graphics is supported since Linux 5.2. Now the DRM is initialized and X starts, but the login prompt is shown only briefly, then the system crashes and displays some garbage on the screen and performs global reset after few seconds.

Ubuntu 20.04.2 has similar behaviour like Debian 10 with kernel 5.10.

Using public FSP for silicon initialization (Cometlake1 FSP to be precise). The original firmware from AMI has no problems with any of the above scenarios. Using OROM and VBT extracted from the original AMI firmware image.

[nate-desimone]

@miczyg1, I believe the problem is happening because you are exclusively using the FSP's built-in GOP and you are not running the Comet Lake DXE GOP after FSP-S. The FSP's framebuffer init code is very barebones and is only intended to enable basic early video for simple cases like recovery, or initial OS installation. The DXE GOP contains additional initialization that is required for the high performance graphics drivers to function properly.

The legacy VGA OROM is also dependent on the DXE GOP for initialization. As much code as possible has been moved out of the 16-bit real mode OROM. It is mostly just a 16-bit wrapper on top of the DXE GOP now.

[miczyg1]

@nate-desimone thank you for clarification. So there is no way around the DXE GOP? What about full legacy firmware? DXE GOP implies using UEFI (and optionally CSM). I have been using the VGA OROM only for the past few years on many Intel platforms without issues, of course assuming the i915 driver takes over in the target system.

I somehow worked it around by removing VBT and disabled OpRegion initialization. It seemed to conflict with the i915 driver which caused those crashes. However, the OS idling is not working when the screen goes blank on older kernels which do not probe i915 driver for this graphics device, but this case is rather understandable.

If the VGA OROM is a wrapper for the DXE GOP how is Intel validating the OROM? Is there any reference code or drivers for UEFI so I can test it?

[nate-desimone]

@miczyg1, we officially stopped supporting full legacy firmware starting with Sandy Bridge, however the reduced VGA OROM was not implemented until later. If my memory is correct, the reduced VGA OROM was introduced in the Coffee Lake/Whiskey Lake generation.

The OROM is validated using the Intel reference BIOS. The supported method of booting a legacy OS on Comet Lake is using a CSM along with a UEFI firmware implementation.

[miczyg1]

@miczyg1, we officially stopped supporting full legacy firmware starting with Sandy Bridge, however the reduced VGA OROM was not implemented until later. If my memory is correct, the reduced VGA OROM was introduced in the Coffee Lake/Whiskey Lake generation.

@nate-desimone understood. Since Coffe Lake/Whiskey Lake you say... Well I might have been lucky then because I was using VGA OROM only up to Kaby Lake (Refresh) and thus didn't hit the issue.

The OROM is validated using the Intel reference BIOS. The supported method of booting a legacy OS on Comet Lake is using a CSM along with a UEFI firmware implementation.

Intel reference BIOS is different than the FSP and SIC right? There is no R&DC ID of the kit that would help me enable CSM and check the implementation myslef?

[nate-desimone]

@miczyg1, yeah it should work still with Kaby Lake. The reference BIOS includes the FSP and SiC. In addition, it also has a full UEFI platform code implementation for Intel RVPs. If you have a CML RVP and an Intel account, reference BIOS binaries are available in sw kit# 635722 on RDC. The reference BIOS has a CSM and the legacy VGA OROM.

[miczyg1]

@nate-desimone I am not using an RVP platform, but working on the customer's hardware. In such a case how may I verify the VGA OROM functionality using reference BIOS?

[nate-desimone]

@miczyg1, the reference BIOS won't run on customer platforms, however it sounds like you were able to verify the legacy OROM using the original AMI BIOS that shipped with the system. As far as the Intel GOP is concerned, their implementation should match ours aside from having a different VBT.

I also am aware of Intel customers that are using Intel graphics successfully on Comet Lake platforms that have coreboot + TianoCore payload. The DXE GOP does need to be integrated into the TianoCore payload in this case.

[miczyg1]

@miczyg1, the reference BIOS won't run on customer platforms, however it sounds like you were able to verify the legacy OROM using the original AMI BIOS that shipped with the system. As far as the Intel GOP is concerned, their implementation should match ours aside from having a different VBT.

Yes I was able to verify it. Also that goes without question that reference BIOS won't work, but having the code and creating a target for customer platform is not that hard.

I also am aware of Intel customers that are using Intel graphics successfully on Comet Lake platforms that have coreboot + TianoCore payload. The DXE GOP does need to be integrated into the TianoCore payload in this case.

But the problem here is that TianoCore payload has no working CSM implementation. The only working one is in OVMF for the older Intel chipset. I have already approached implementing it for newer microarchitecture and it is not a trivial task.

[nate-desimone]

@miczyg1, the Intel reference BIOS uses a CSM licensed from an IBV, so I don't think that would help much. I do know that SeaBIOS has been successfully used as a CSM and is in fact used as the CSM for OVMF. Admittedly I have not looked into what is needed to get SeaBIOS running on as the CSM for newer Intel chipsets.

I guess its not clear to me why legacy boot is so important. Especially when one considers that CSM support has been completely dropped from Tiger Lake and Rocket Lake. A legacy VGA OROM does not exist for Tiger Lake and Rocket Lake and won't be implemented for any new Intel chipsets going forward. Additionally, chipset features required for legacy boot (the 8254 for example) are going away. 16-bit legacy boot is a architectural dead end at this point so I strongly recommend that any new work be put into supporting newer boot standards like UEFI.

[miczyg1]

@miczyg1, the Intel reference BIOS uses a CSM licensed from an IBV, so I don't think that would help much. I do know that SeaBIOS has been successfully used as a CSM and is in fact used as the CSM for OVMF. Admittedly I have not looked into what is needed to get SeaBIOS running on as the CSM for newer Intel chipsets.

Okay, that will not help much if it is provided by IBV. Yes, SeaBIOS is running as CSM with OVMF AFAIK. There was also some work presented on OFSC(?) that enabled CSM in EDK2. I will have to look into it deeper.

I guess its not clear to me why legacy boot is so important. Especially when one considers that CSM support has been completely dropped from Tiger Lake and Rocket Lake. A legacy VGA OROM does not exist for Tiger Lake and Rocket Lake and won't be implemented for any new Intel chipsets going forward. Additionally, chipset features required for legacy boot (the 8254 for example) are going away. 16-bit legacy boot is a architectural dead end at this point so I strongly recommend that any new work be put into supporting newer boot standards like UEFI.

When it comes to Tiger Lake and Rocket Lake I heard about legacy stuff being removed. However I was not aware of the VGA OROM reduction you have mentioned. That said, I have offered the customer a legacy firmware for his Comet Lake platform and I am obliged to deliver it. I hope this makes it more understandable.

I appreciate your assistance. Given the information you provided, I will restrain myself from offering legacy firmware on the newer Intel silicon to avoid problems. Closing the issue since I have resolved the problem and got it working.