Closed walterchris closed 3 years ago
Hi @walterchris, it should work as far as I can see. It looks like as long as the read from PCI device 0:2:0 offset 0x0 (aka the vendor ID for the internal graphics device) returns 0xFFFF then the graphics init routine should return and do nothing.
My understanding is that the fusing on those Gfx disabled parts should cause 0:2:0 to not exist. Can you check if reading from that location in PCI config space returns 0xFFFF for me?
HI @nate-desimone I will check the PCI config space. Also I noticed if I disable InternalGfx (Setting the UPD InternalGfx to 0) it also hangs in the FSPM with a CPU which has IGD on it. I also set IgdDvmt50PreAlloc to 0. Any ideas on that behaviour?
Looks like if no IGD is available, also PanelPowerEnable needs to be set to zero. @nate-desimone
@walterchris, Good Catch! I have implemented the fix for it. It is available starting with 201b361 (Coffee Lake FSP 7.0.74.20). Can you try the new FSP and see if the issue is resolved?
Hi, we observed the behaviour that if we do not have a IGD present the FSP-M seems to hang in coreboot. The last Postcode that we see is 0xda50 which is according to the Integration Guide "Initializing Graphics". We turned the graphics off via the UPD options InternalGfx = 0 and set IgdDvmt50PreAlloc to 0. Does it has been tested on CPUs without IGD yet? Do we have to set more UPDs in order to make it work without IGD?
@nate-desimone