Bug #119
closed
Garbled video output in SeaBIOS with native gfx init on Lenovo T520 with Ivy Bridge chip
Added by Firstname Lastname over 7 years ago.
Updated over 5 years ago.
Description
coreboot 4.6-166-g365d97e938
Attached are two photos showing the difference between video output with native and vgabios. Unseen in the first photo is also flickering with native init.
Previously when I had a Sandy Bridge chip (i5-2520M) I tried native init and video output was fine, although the text in SeaBIOS was much smaller/sharper than my current working config (vgabios with i5-3320M).
Not only is video output in SeaBIOS messy but Windows 10 fails to boot (I get a non-graphical "loading files" screen with garbled output instead of the standard blue logo with spinning dots).
The .config I attached is for my current vgabios config which I built today after again testing native init, but all options are the same other than having native init disabled and vgabios enabled.
Files
I guess the wrong code path is selected for your case (Ivy Bridge processor paired with Cougar Point PCH) in src/northbridge/intel/sandybridge/gma_sandybridge_lvds.c
where it says:
if ((bridge_silicon_revision() & BASE_REV_MASK) == BASE_REV_IVB) {
return i915lightup_ivy(info, physbase, piobase, mmio, lfb);
}
This decision should be made by PCH and not by processor, I guess. You can try it with the above lines removed.
Nico Huber wrote:
I guess the wrong code path is selected for your case (Ivy Bridge processor paired with Cougar Point PCH) in src/northbridge/intel/sandybridge/gma_sandybridge_lvds.c
where it says:
if ((bridge_silicon_revision() & BASE_REV_MASK) == BASE_REV_IVB) {
return i915lightup_ivy(info, physbase, piobase, mmio, lfb);
}
This decision should be made by PCH and not by processor, I guess. You can try it with the above lines removed.
I did another build with the lines removed, and got this result:
http://imgur.com/a/C7Kme
After the wave of light finishes washing over the screen and fades out the machine just reboots.
Hmmm, looks like I guessed wrong. The code is possibly more broken than I thought. So your best option is to use libgfxinit, like Arthur said. Since it's written in Ada, you'd probably have to rebuild your coreboot toolchain with GNAT installed. Just install gnat (package sometimes called gcc-ada) in the same version as gcc, run make crossgcc-clean
and make crossgcc-i386
. Then apply the same changes as done in https://review.coreboot.org/#/c/19412/ for the X230 to the T520 and select "Use libgfxinit..." below the native gfx init (NGI) option. Just tell us if you need help with the patching.
Btw. Windows is currently not supported along with NGI. It needs additional help by a so called Video BIOS Table (VBT). Work to add that VBT to coreboot in a cross-platform way is in progress.
Nico Huber wrote:
Hmmm, looks like I guessed wrong. The code is possibly more broken than I thought. So your best option is to use libgfxinit, like Arthur said. Since it's written in Ada, you'd probably have to rebuild your coreboot toolchain with GNAT installed. Just install gnat (package sometimes called gcc-ada) in the same version as gcc, run make crossgcc-clean
and make crossgcc-i386
. Then apply the same changes as done in https://review.coreboot.org/#/c/19412/ for the X230 to the T520 and select "Use libgfxinit..." below the native gfx init (NGI) option. Just tell us if you need help with the patching.
Btw. Windows is currently not supported along with NGI. It needs additional help by a so called Video BIOS Table (VBT). Work to add that VBT to coreboot in a cross-platform way is in progress.
I made those changes and built coreboot with libgfxinit. The result is no power on display (not just a blank screen, the backlight never turns on at all). I tried with both VGA text mode and linear framebuffer under the display settings.
Could it be that libgfxinit is not compatible with my display panel? It is B156HW01 V.7.
It's unlikely that the panel is incompatible. Though if both code paths fail, maybe there is a problem with its EDID.
Please attach your .config
, src/mainboard/lenovo/t520/gma-mainboard.ad*
and, if possible, a coreboot log taken with CONFIG_DEBUG_ADA_CODE=y
and loglevel >= Debug.
Nico Huber wrote:
It's unlikely that the panel is incompatible. Though if both code paths fail, maybe there is a problem with its EDID.
Please attach your .config
, src/mainboard/lenovo/t520/gma-mainboard.ad*
and, if possible, a coreboot log taken with CONFIG_DEBUG_ADA_CODE=y
and loglevel >= Debug.
By 'coreboot log' I assume you meant the output of ./cbmem -c, which I fetched after returning to a working config (that still had CONFIG_DEBUG_ADA_CODE=y), not sure if it's still useful in that case. But it was not possible for me to fetch it while actually using libgfxinit of course, as the machine wasn't really booting.
- Status changed from New to Closed
Native gfx init was dropped, thus this bug won't appear in coreboot master any more.
If it happens with libgfxinit too, please open a new bug report.
Also available in: Atom
PDF