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, 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).


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.