[SeaBIOS] Re: an issue with win10 boot and different compiler versions
On Mon, Feb 12, 2024 at 01:06:34PM +0100, Fiona Ebner wrote:
> Am 10.02.24 um 21:17 schrieb Michael Tokarev:
> > So.. the difference is vgabios only, not seabios (vgabios-stdvga in this
> > case).
> >
> > And I can't get it to work with debugging vgabios, it always fails even
> > with DEBUG_LEVEL=2
> > (and level-1 logging isn't useful).
> >
> > I was able to capture logs just for the non-working version, so there's
> > nothing to
> > compare it against. So I tried a different machine type in qemu, the
> > one which
> > works, which uses SMBIOS 3.0 (q35-8.2).
> >
>
>
> Hi,
>
> Windows apparently doesn't read SMBIOS 3.0 tables:
> https://gitlab.com/qemu-project/qemu/-/issues/2008#note_1712210029
>
> Not sure if this is relevant for your issue and it only "works" because
> of that with newer machine models. But it seems worth mentioning.
Note that there is an option to explicitly set the smbios version:
qemu -machine q35,smbios-entry-point-type={32,64}
That will override the machine type default.
take care,
Gerd
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: an issue with win10 boot and different compiler versions
On Sun, Feb 11, 2024 at 09:49:21AM +0300, Michael Tokarev wrote: > Hello! Thank you for the reply! > > > Just a random idea, maybe there is something wrong with windows failing to > > emulate stuff? > > (the vgafixup.py) > > Well. > > Windows might fail to emulate something. The prob with that is that we > can't fix this, Well, vgafixup.py exists exactly to workaround emulator bugs (by avoiding problematic instructions). The Xserver with vesa driver goes emulate the vgabios too, and it has bugs, especially when it comes to 32-bit instructions ... So there is a fair chance that we actually can do something about it once we know the root cause. Analyzing that kind of issues is a PITA though, especially with closed source software being involved. > > I would try to boot with non working vgabios something else, like > > grub2, and there I would do: insmod vbe videotest > > This one seems to be working (I had to add `loadfont unicode' before; > I never used grub before so don't know the details here). Booting linux kernels with vga=ask can also serve as simple vgabios test btw. But with both linux and grub running there is no emulator involved, so it is unlikely to help much ... > And the original bug report talks about windows, especially windows 10 - > just tried windows 7, and I don't see this behavior with it. Could very well be that microsoft switched to an emulator in newer versions to sandbox the vgabios. Possibly it's also different in 32-bit vs. 64-bit windows versions. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH 1/2] romfile: implement a generic loader
On Sat, Feb 10, 2024 at 08:39:15PM +, Riku Viitanen via SeaBIOS wrote: > romfile_loadfile_g: > Based on romfile_loadfile but more flexible. User has to supply pointer > to a malloc function and the number of trailing padding bytes. Thus, any > memory region may be used. I'd suggest to add a romfile_loadfile_low(), or add a 'struct zone_s' parameter instead of passing in a function pointer. Also: What the trailing bytes are used for? Patch 2/2 doesn't use that. take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH 1/2] romfile: implement a generic loader
> I'd suggest to add a romfile_loadfile_low() I can definitely do that. > or add a 'struct zone_s' > parameter instead of passing in a function pointer. Sounds sensible. I see there's a malloc that takes zone as argument. > Also: What the trailing bytes are used for? Only for re-implementing the existing loadfile function, to reduce copy-pasted code. ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
