Hi,
I am developing coreboot along with Uefipayload for CFL H RVP11 CRB.
I have added the required binary files (me, desc, ec and gbe) by extracting from the BIOS image.
I have also extracted and added the vbt.bin from BIOS to coreboot.
For graphics initialisation, i selected "Run a GOP driver" and for Framebuffer mode, i selected "Linear high resolution framebuffer".
Compiled and loaded the coreboot image with above configuration. Coreboot booted and the debug prints are displayed in UART port, but nothing came in the graphics.
The Display is connected to the DP port of the CRB.
And i checked the debug prints, there it is mentioned as "GMA: Found valid VBT in CBFS" and in the next line "Graphics hand-off block not found".
From the above prints i assume that the vbt.bin is proper but still the FSP is not returning the graphics HOB.
I am using coreboot 4.17 for my development.
Is there any other configurations need to be done with respect to integrated graphics?
Regards, Moorthi S
Hi Moorthi,
On 19.08.22 07:32, Moorthi M.s wrote:
I have also extracted and added the vbt.bin from BIOS to coreboot.
did you get that from the binary or from the running system? It's possible that your BIOS patches it at runtime, and the one in flash might be unusable. On Linux, you can find the active VBT in debugfs, usually `/sys/kernel/debug/dri/0/i915_vbt`.
For graphics initialisation, i selected "Run a GOP driver" and for
Note, for Coffee Lake there's an open-source alternative[1]. It needs a little per-board configuration, but then usually works out of the box. And in case it doesn't work, it comes with extensive logging and debug capabilities, down to attaching a debugger in Linux user-space.
And i checked the debug prints, there it is mentioned as "GMA: Found valid VBT in CBFS" and in the next line "Graphics hand-off block not found".
From the above prints i assume that the vbt.bin is proper but still the FSP is not returning the graphics HOB.
Alas, that is not enough to tell if the VBT is correct. However, if you extracted it from a running system where the display came up, it should be. In any case, you can examine the file with `intel_vbt_decode` from `intel-gpu-tools`. The most important part is that the DP you are trying to use is enabled.
Is there any other configurations need to be done with respect to integrated graphics?
Are you using vboot by any chance? It's the only other thing in the code that I see that should make a difference.
You could have another look at the log, there's another printk earlier "Found a VBT of %zu bytes after decompression\n" That would either come directly before the lines you mentioned above (if the GOP is not executed), or much earlier (if executed).
Nico
Hi Nico,
did you get that from the binary or from the running system? It's
possible that your BIOS patches it at runtime, and the one in flash might be unusable. On Linux, you can find the active VBT in debugfs, usually `/sys/kernel/debug/dri/0/i915_vbt`.
I have added the VBT file copied from the running system (fedora 30). Still the graphics is not up.
Note, for Coffee Lake there's an open-source alternative[1]. It needs
a little per-board configuration, but then usually works out of the box.
I tried using the libgfxinit for graphics initialisation. With that the graphics is up and i am able to see the Uefipayload screen output in the display. Thanks for your guidance.
But i tried booting the Operating System (windows 10 & fedora 30) after the selecting the operating system in the grub, nothing came in the display.
So tried booting the fedora 30 in command line with init 3 option. With that the OS boot prints are coming upto the print "fb: conflicting fb hw usage Inteldrmfb vs EFI VGA - removing generic driver" . And after that the display goes off.. I browsed for this, and i added the "nomedeset" flag in the grub command line. With that the fedora 30 is booting with generic framebuffer driver.
Is there anything need to be added in coreboot to invoke the integrated graphics driver in the OS?
Thanks, Moorthi S
On Fri, Aug 19, 2022, 20:40 Nico Huber nico.h@gmx.de wrote:
Hi Moorthi,
On 19.08.22 07:32, Moorthi M.s wrote:
I have also extracted and added the vbt.bin from BIOS to coreboot.
did you get that from the binary or from the running system? It's possible that your BIOS patches it at runtime, and the one in flash might be unusable. On Linux, you can find the active VBT in debugfs, usually `/sys/kernel/debug/dri/0/i915_vbt`.
For graphics initialisation, i selected "Run a GOP driver" and for
Note, for Coffee Lake there's an open-source alternative[1]. It needs a little per-board configuration, but then usually works out of the box. And in case it doesn't work, it comes with extensive logging and debug capabilities, down to attaching a debugger in Linux user-space.
And i checked the debug prints, there it is mentioned as "GMA: Found
valid
VBT in CBFS" and in the next line "Graphics hand-off block not found".
From the above prints i assume that the vbt.bin is proper but still the
FSP
is not returning the graphics HOB.
Alas, that is not enough to tell if the VBT is correct. However, if you extracted it from a running system where the display came up, it should be. In any case, you can examine the file with `intel_vbt_decode` from `intel-gpu-tools`. The most important part is that the DP you are trying to use is enabled.
Is there any other configurations need to be done with respect to integrated graphics?
Are you using vboot by any chance? It's the only other thing in the code that I see that should make a difference.
You could have another look at the log, there's another printk earlier "Found a VBT of %zu bytes after decompression\n" That would either come directly before the lines you mentioned above (if the GOP is not executed), or much earlier (if executed).
Nico
Hi,
On 25.08.22 08:53, Moorthi M.s wrote:
Hi Nico,
did you get that from the binary or from the running system? It's possible that your BIOS patches it at runtime, and the one in flash might be unusable. On Linux, you can find the active VBT in debugfs, usually `/sys/kernel/debug/dri/0/i915_vbt`.
I have added the VBT file copied from the running system (fedora 30). Still the graphics is not up.
that is unfortunate. But knowing that this VBT actually works when booting with another firmware can give us more clues. You could get a debug log from the working boot and compare that to a failing one. Add this to your kernel command line: `drm.debug=0xe`. It will make the i915 driver very chatty.
Note, for Coffee Lake there's an open-source alternative[1]. It needs
a little per-board configuration, but then usually works out of the box.
I tried using the libgfxinit for graphics initialisation. With that the graphics is up and i am able to see the Uefipayload screen output in the display. Thanks for your guidance.
I'm glad to hear that :)
Is there anything need to be added in coreboot to invoke the integrated graphics driver in the OS?
But i tried booting the Operating System (windows 10 & fedora 30) after the selecting the operating system in the grub, nothing came in the display.
You might still need a valid VBT for Intel's OS drivers. If you had it in your coreboot image already, comparing logs might be the best next step. With the VBT, Linux' i915 driver should be capable to fully ini- tialize the display even if the firmware did nothing.
Cheers, Nico
-
Moorthi M.s -
Nico Huber