libgxfinit + latest master gives "static noise" bootscreen (Windows)
Hi, For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations using libgfxinit. Mid-October I had created some builds that worked, but I'm not sure they were using master or something else at that point (only kept the binaries unfortunately). The symptom is that when I select the Windows boot manager from Grub, I get a very regular-looking, TV-static like screen, then black. From the HDD activity, I can tell the boot is continuing but the graphics don't recover. Interestingly, if I then force-powercycle the machine, the Windows bootloader does successfully enter its "Recovery Environment" or whatever that is. I can try to choose an OS to boot, but after that the same thing happens. Is this a known bug / issue? I'm building the latest master for the X210 using mgj59's port. Cheers, R
Hi Rafael, On 26.12.19 21:43, Rafael Send wrote:
For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations using libgfxinit.
libgfxinit just sets up a framebuffer, all the software compatibility depends on how the framebuffer info is communicated (coreboot payload mostly). Please tell us o do you run a textmode or linear (native resolution) framebuffer? o is your Windows in BIOS or EFI mode? (these are completely different cases wrt. the framebuffer) o if you use SeaBIOS, please also attach your .config and the output of `build/cbfstool build/coreboot.rom print`. There are many, many variables with SeaBIOS with too many possible combinations.
Mid-October I had created some builds that worked, but I'm not sure they were using master or something else at that point (only kept the binaries unfortunately).
coreboot binaries contain the commit hash and a defconfig they were built with. You can compare that to your current built. Nico
Hi, Thanks for the reply. To answer your questions: - I'm running linear frame buffer, but not at native resolution. If I do, the boot menu text gets too small since this is a 13" 2k screen. - Payload is Tianocore - Windows is installed in UEFI (these last two have been the same configuration as always) I didn't know the commit hash was embedded in the binary, I'll take a look and see if I can reproduce a working build. I do know that my display needed a patch to work correctly before this update <https://review.coreboot.org/c/coreboot/+/35898>, but I'm unclear if THAT's what caused Windows to not work correctly (i.e whether the patch worked better or not). I guess if I start with the commit I originally used I can play around with cherry-picking that commit vs the previous patch). R On Sat, Dec 28, 2019 at 5:00 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Rafael,
On 26.12.19 21:43, Rafael Send wrote:
For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations using libgfxinit.
libgfxinit just sets up a framebuffer, all the software compatibility depends on how the framebuffer info is communicated (coreboot payload mostly). Please tell us
o do you run a textmode or linear (native resolution) framebuffer? o is your Windows in BIOS or EFI mode? (these are completely different cases wrt. the framebuffer) o if you use SeaBIOS, please also attach your .config and the output of `build/cbfstool build/coreboot.rom print`. There are many, many variables with SeaBIOS with too many possible combinations.
Mid-October I had created some builds that worked, but I'm not sure they were using master or something else at that point (only kept the binaries unfortunately).
coreboot binaries contain the commit hash and a defconfig they were built with. You can compare that to your current built.
Nico
On 29.12.19 10:32, Rafael Send wrote:
- I'm running linear frame buffer, but not at native resolution. If I do, the boot menu text gets too small since this is a 13" 2k screen. - Payload is Tianocore - Windows is installed in UEFI (these last two have been the same configuration as always)
hmmm, three thoughts: o have you re-tested your old builds to rule out changes in Windows? o did you change the framebuffer resolution? IIRC, Windows is picky about the width of the framebuffer (try a multiple of 16). o if neither the Windows installation nor the resolution are to blame, I'd check for changes in Tianocore.
I didn't know the commit hash was embedded in the binary, I'll take a look and see if I can reproduce a working build.
I do know that my display needed a patch to work correctly before this update <https://review.coreboot.org/c/coreboot/+/35898>, but I'm unclear if THAT's what caused Windows to not work correctly (i.e whether the patch worked better or not). I guess if I start with the commit I originally used I can play around with cherry-picking that commit vs the previous patch).
That's unlikely to be related. The only thing Windows gets in touch with is the framebuffer configuration, which is merely the resolution, stride and a pointer into gfx memory. It doesn't care how the hardware was set up to get there. Nico
R
On Sat, Dec 28, 2019 at 5:00 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Rafael,
On 26.12.19 21:43, Rafael Send wrote:
For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations using libgfxinit.
libgfxinit just sets up a framebuffer, all the software compatibility depends on how the framebuffer info is communicated (coreboot payload mostly). Please tell us
o do you run a textmode or linear (native resolution) framebuffer? o is your Windows in BIOS or EFI mode? (these are completely different cases wrt. the framebuffer) o if you use SeaBIOS, please also attach your .config and the output of `build/cbfstool build/coreboot.rom print`. There are many, many variables with SeaBIOS with too many possible combinations.
Mid-October I had created some builds that worked, but I'm not sure they were using master or something else at that point (only kept the binaries unfortunately).
coreboot binaries contain the commit hash and a defconfig they were built with. You can compare that to your current built.
Nico
Hi, 1) Yes, I've been using my old builds until today; they work for the most part (I was originally trying to solve some other remaining issues, but then found that I could not build a working version anymore. Hence this thread) 2) No, I've been using 1440 x 900 the entire time 3) Will check. However, I just bricked my machine with a failed erase; so I'll have to wait until next week to swap the BIOS chip and then pick this up. Are there any other coreboot build configurations that could cause these kinds of issues? It's entirely possible that I set something before I'm no longer doing, but I'm not sure what to be looking for there. Also, does the Windows recovery environment use a different graphics stack / setup from the actual installation? As mentioned before, I can get into the former just fine, but not the latter without seeing the static. Cheers, R On Sun, Dec 29, 2019 at 6:31 AM Nico Huber <nico.h@gmx.de> wrote:
On 29.12.19 10:32, Rafael Send wrote:
- I'm running linear frame buffer, but not at native resolution. If I do, the boot menu text gets too small since this is a 13" 2k screen. - Payload is Tianocore - Windows is installed in UEFI (these last two have been the same configuration as always)
hmmm, three thoughts:
o have you re-tested your old builds to rule out changes in Windows? o did you change the framebuffer resolution? IIRC, Windows is picky about the width of the framebuffer (try a multiple of 16). o if neither the Windows installation nor the resolution are to blame, I'd check for changes in Tianocore.
I didn't know the commit hash was embedded in the binary, I'll take a
look
and see if I can reproduce a working build.
I do know that my display needed a patch to work correctly before this update <https://review.coreboot.org/c/coreboot/+/35898>, but I'm unclear if THAT's what caused Windows to not work correctly (i.e whether the patch worked better or not). I guess if I start with the commit I originally used I can play around with cherry-picking that commit vs the previous patch).
That's unlikely to be related. The only thing Windows gets in touch with is the framebuffer configuration, which is merely the resolution, stride and a pointer into gfx memory. It doesn't care how the hardware was set up to get there.
Nico
R
On Sat, Dec 28, 2019 at 5:00 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Rafael,
On 26.12.19 21:43, Rafael Send wrote:
For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations
using
libgfxinit.
libgfxinit just sets up a framebuffer, all the software compatibility depends on how the framebuffer info is communicated (coreboot payload mostly). Please tell us
o do you run a textmode or linear (native resolution) framebuffer? o is your Windows in BIOS or EFI mode? (these are completely different cases wrt. the framebuffer) o if you use SeaBIOS, please also attach your .config and the output of `build/cbfstool build/coreboot.rom print`. There are many, many variables with SeaBIOS with too many possible combinations.
Mid-October I had created some builds that worked, but I'm not sure
they
were using master or something else at that point (only kept the binaries unfortunately).
coreboot binaries contain the commit hash and a defconfig they were built with. You can compare that to your current built.
Nico
no issues here with libgfxinit + Windows with google/eve on upstream master (tested other KBL/AML devices too, no issues) If it boots to Windows recovery, then libgfxinit is fine. If you see the spinning dots and then the display becomes corrupted, then it's due to the Windows/Intel display driver. Make sure the VBT is included and correct. also, what version of Windows? On Sun, Dec 29, 2019 at 4:54 PM Rafael Send <flyingfishfinger@gmail.com> wrote:
Hi, 1) Yes, I've been using my old builds until today; they work for the most part (I was originally trying to solve some other remaining issues, but then found that I could not build a working version anymore. Hence this thread) 2) No, I've been using 1440 x 900 the entire time 3) Will check. However, I just bricked my machine with a failed erase; so I'll have to wait until next week to swap the BIOS chip and then pick this up.
Are there any other coreboot build configurations that could cause these kinds of issues? It's entirely possible that I set something before I'm no longer doing, but I'm not sure what to be looking for there.
Also, does the Windows recovery environment use a different graphics stack / setup from the actual installation? As mentioned before, I can get into the former just fine, but not the latter without seeing the static.
Cheers, R
On Sun, Dec 29, 2019 at 6:31 AM Nico Huber <nico.h@gmx.de> wrote:
On 29.12.19 10:32, Rafael Send wrote:
- I'm running linear frame buffer, but not at native resolution. If I do, the boot menu text gets too small since this is a 13" 2k screen. - Payload is Tianocore - Windows is installed in UEFI (these last two have been the same configuration as always)
hmmm, three thoughts:
o have you re-tested your old builds to rule out changes in Windows? o did you change the framebuffer resolution? IIRC, Windows is picky about the width of the framebuffer (try a multiple of 16). o if neither the Windows installation nor the resolution are to blame, I'd check for changes in Tianocore.
I didn't know the commit hash was embedded in the binary, I'll take a
look
and see if I can reproduce a working build.
I do know that my display needed a patch to work correctly before this update <https://review.coreboot.org/c/coreboot/+/35898>, but I'm unclear if THAT's what caused Windows to not work correctly (i.e whether the patch worked better or not). I guess if I start with the commit I originally used I can play around with cherry-picking that commit vs the previous patch).
That's unlikely to be related. The only thing Windows gets in touch with is the framebuffer configuration, which is merely the resolution, stride and a pointer into gfx memory. It doesn't care how the hardware was set up to get there.
Nico
R
On Sat, Dec 28, 2019 at 5:00 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Rafael,
On 26.12.19 21:43, Rafael Send wrote:
For the past month or two (I'm not actually sure WHEN it stopped working) I haven't been able to successfully boot (any) Windows installations
using
libgfxinit.
libgfxinit just sets up a framebuffer, all the software compatibility depends on how the framebuffer info is communicated (coreboot payload mostly). Please tell us
o do you run a textmode or linear (native resolution) framebuffer? o is your Windows in BIOS or EFI mode? (these are completely different cases wrt. the framebuffer) o if you use SeaBIOS, please also attach your .config and the output of `build/cbfstool build/coreboot.rom print`. There are many, many variables with SeaBIOS with too many possible combinations.
Mid-October I had created some builds that worked, but I'm not sure
they
were using master or something else at that point (only kept the binaries unfortunately).
coreboot binaries contain the commit hash and a defconfig they were built with. You can compare that to your current built.
Nico
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hmm. I exported my own vbt on Ubuntu with "cp /sys/kernel/debug/dri/0/i915_vbt vbt.bin", which worked fine in the past, but I still get the noise. Windows 10... R
participants (3)
-
Matt DeVillier -
Nico Huber -
Rafael Send