[SeaBIOS] Re: an issue with win10 boot and different compiler versions
On Wed, Feb 07, 2024 at 03:21:15AM +0300, Michael Tokarev wrote: > 07.02.2024 02:17, Michael Tokarev пишет: [...] > > The binary in question is vgabios-stdvga.bin. [...] >"SMBIOS 2.1 table length 66822 exceeds 65535" > > Which wont help with 7.2 machine types (it changes defaults for 8.1+). > > And yes, running current qemu with -M pc-q35-7.2 shows the same issue > again. > > So it might not be a gcc issue really, but just a too large bios and > gcc-13 is able to produce more compact code which actually fits. Ah, that makes sense. In the future, if you enable the seabios logs it should help track these things down. (Take the log from the working version and compare it to the log from the non-working version.) I suspect in the log would be messages from seabios/seavgabios hinting to the issue. Cheers, -Kevin ___ 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
10.02.2024 22:09, Kevin O'Connor : On Wed, Feb 07, 2024 at 03:21:15AM +0300, Michael Tokarev wrote: 07.02.2024 02:17, Michael Tokarev пишет: [...] The binary in question is vgabios-stdvga.bin. [...] "SMBIOS 2.1 table length 66822 exceeds 65535" Which wont help with 7.2 machine types (it changes defaults for 8.1+). And yes, running current qemu with -M pc-q35-7.2 shows the same issue again. So it might not be a gcc issue really, but just a too large bios and gcc-13 is able to produce more compact code which actually fits. Ah, that makes sense. In the future, if you enable the seabios logs it should help track these things down. (Take the log from the working version and compare it to the log from the non-working version.) I suspect in the log would be messages from seabios/seavgabios hinting to the issue. Ok, that's a good idea indeed. Somehow I forgot about this. So, I rebuilt seabios with DEBUG=8. I did NOT rebuilt vgabios though, since after rebuilding it with debug added, the whole thing seem to work. However, the "bad" vgabios is just a bit larger than the "good" one: -rw-r--r-- 1 mjt mjt 39936 Jan 24 09:35 bios-bad/vgabios-stdvga.bin -rw-r--r-- 1 mjt mjt 39424 Nov 30 20:20 bios-good/vgabios-stdvga.bin this is from debian seabios package 1.16.3-2 (good, compiled with gcc-13) and 1.16.3-2~bpo12+1 (bad, compiled with gcc-12). There's no difference in there besides the version string and gcc used to compile it, all the rest is exactly the same. This is debug level 1 difference (qemu machine pc-q35-7.2) -- bpo12+1 is the bad one: diff -U1 debugcon-good debugcon-bad --- debugcon-good 2024-02-10 22:36:01.432450772 +0300 +++ debugcon-bad2024-02-10 22:36:23.477127564 +0300 @@ -1,3 +1,3 @@ -SeaBIOS (version 1.16.3-debian-1.16.3-2) -BUILD: gcc: (Debian 13.2.0-7) 13.2.0 binutils: (GNU Binutils for Debian) 2.41 +SeaBIOS (version 1.16.3-debian-1.16.3-2~bpo12+1) +BUILD: gcc: (Debian 12.2.0-14) 12.2.0 binutils: (GNU Binutils for Debian) 2.40 No Xen hypervisor found. @@ -14,3 +14,3 @@ qemu/e820: addr 0x0001 len 0x4000 [RAM] -Relocating init from 0x000d4020 to 0x7efeb120 (size 85568) +Relocating init from 0x000d3b00 to 0x7efeae00 (size 86368) Moving pm_base to 0x600 @@ -18,3 +18,3 @@ 1: /pci@i0cf8/pci8086,2922@3/drive@0/disk@0 -kvmclock: at 0xe8580 (msr 0x4b564d01) +kvmclock: at 0xe8380 (msr 0x4b564d01) kvmclock: stable tsc, 3792 MHz @@ -62,5 +62,5 @@ Found 2 cpu(s) max supported 2 cpu(s) -Copying PIR from 0x7efffbe0 to 0x000f5560 -Copying MPTABLE from 0x6cfc/7efe1bf0 to 0x000f5450 -Copying SMBIOS from 0x6cfc to 0x000f5290 +Copying PIR from 0x7efffbe0 to 0x000f5500 +Copying MPTABLE from 0x6cfc/7efe18d0 to 0x000f53f0 +Copying SMBIOS from 0x6cfc to 0x000f5220 table(50434146)=0x7ffe2134 (via rsdt) @@ -69,7 +69,7 @@ Running option rom at c000:0003 -Start SeaVGABIOS (version 1.16.3-debian-1.16.3-2) -VGABUILD: gcc: (Debian 13.2.0-7) 13.2.0 binutils: (GNU Binutils for Debian) 2.41 +Start SeaVGABIOS (version 1.16.3-debian-1.16.3-2~bpo12+1) +VGABUILD: gcc: (Debian 12.2.0-14) 12.2.0 binutils: (GNU Binutils for Debian) 2.40 enter vga_post: a=0008 b= c= d= ds= es=f000 ss= - si= di=60c0 bp= sp=6d16 cs=f000 ip=d00f f= + si= di=6060 bp= sp=6d1a cs=f000 ip=d04a f= VBE DISPI: bdf 00:01.0, bar 0 @@ -81,8 +81,8 @@ Removing mode 19e -Attempting to allocate 512 bytes lowmem via pmm call to f000:d0c0 +Attempting to allocate 512 bytes lowmem via pmm call to f000:d0e6 pmm call arg1=0 -VGA stack allocated at e8380 +VGA stack allocated at e8180 Turning on vga text mode console set VGA mode 3 -SeaBIOS (version 1.16.3-debian-1.16.3-2) +SeaBIOS (version 1.16.3-debian-1.16.3-2~bpo12+1) EHCI init on dev 00:1d.7 (regs=0xfebf2020) @@ -111,5 +111,5 @@ Searching bootorder for: HALT -drive 0x000f5200: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=67108864 +drive 0x000f5190: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=67108864 Running option rom at cb00:0003 -Space available for UMB: cd800-e7800, f4de0-f51e0 +Space available for UMB: cd800-e7800, f4d80-f5170 Returned 16637952 bytes of ZoneHigh @@ -180,4 +180 @@ VBE mode info request: 118 -VBE mode set: 4144 -set VGA mode 144 -VBE current mode=4144 So it looks like it is stuck at setting VBE mode. Attached are 2 level-8 debug logs from good and bad runs. Unfortunately I see about the same picture as above, with lots of details before last 3 lines, and the same 3 last lines difference. Trying to find a working combination for vgabios debugging.. Does it make any sense so far? Thanks, /mjt debugcon-l8.tar.gz Description: application/gzip ___ 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
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). I also tried to compile the same vgabios with different compilers (gcc-13 vs gcc-12), in a hope to have working one with gcc-13 (the same way it works without debug). This one produces extra output at the end. This should make a bit more sense, but I'm not sure, never tried to debug this stuff.. Thanks! /mjt vgabios-dbg.tar.gz Description: application/gzip ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 1/2] romfile: implement a generic loader
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.
romfile_loadfile:
It is now a wrapper around romfile_loadfile_g. Functionality is the same.
Signed-off-by: Riku Viitanen
---
src/romfile.c | 25 -
src/romfile.h | 2 ++
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/src/romfile.c b/src/romfile.c
index b598274e..8bf95713 100644
--- a/src/romfile.c
+++ b/src/romfile.c
@@ -47,10 +47,12 @@ romfile_find(const char *name)
return __romfile_findprefix(name, strlen(name) + 1, NULL);
}
-// Helper function to find, malloc_tmphigh, and copy a romfile. This
-// function adds a trailing zero to the malloc'd copy.
+// Generic function to find romfile, malloc (using provided function
+// pointer), and copy a romfile. add_len specifies how many additional
+// trailing bytes to reserve. The extra bytes will not be initialised.
void *
-romfile_loadfile(const char *name, int *psize)
+romfile_loadfile_g(const char *name, int *psize,
+ void *(*malloc_fn)(), int add_len)
{
struct romfile_s *file = romfile_find(name);
if (!file)
@@ -60,7 +62,7 @@ romfile_loadfile(const char *name, int *psize)
if (!filesize)
return NULL;
-char *data = malloc_tmphigh(filesize+1);
+char *data = malloc_fn(filesize+add_len);
if (!data) {
warn_noalloc();
return NULL;
@@ -74,7 +76,20 @@ romfile_loadfile(const char *name, int *psize)
}
if (psize)
*psize = filesize;
-data[filesize] = '\0';
+
+return data;
+}
+
+// Helper function to find, malloc_tmphigh, and copy a romfile. This
+// function adds a trailing zero to the malloc'd copy.
+void *
+romfile_loadfile(const char *name, int *psize)
+{
+char *data = romfile_loadfile_g(name, psize, &malloc_tmphigh, 1);
+if (!data)
+return NULL;
+
+data[*psize] = '\0';
return data;
}
diff --git a/src/romfile.h b/src/romfile.h
index 3e0f8200..a320a5bc 100644
--- a/src/romfile.h
+++ b/src/romfile.h
@@ -13,6 +13,8 @@ struct romfile_s {
void romfile_add(struct romfile_s *file);
struct romfile_s *romfile_findprefix(const char *prefix, struct romfile_s
*prev);
struct romfile_s *romfile_find(const char *name);
+void *romfile_loadfile_g(const char *name, int *psize,
+ void *(*malloc_fn)(), int add_len);
void *romfile_loadfile(const char *name, int *psize);
u64 romfile_loadint(const char *name, u64 defval);
--
2.43.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] [PATCH 2/2] vgahooks, optionroms: implement mxm 3.0 interrupts
VGAROMs on MXM graphics cards need certain int15h functions present.
Tested on a HP EliteBook 8560w with coreboot and Quadro 2000M. A warning
is displayed for 30 seconds and performance is nerfed:
ERROR: Valid MXM Structure not found.
POST halted for 30 seconds, P-state limited to P10...
This patch implements the minimum required on this system (and implemented
by the OEM BIOS): functions 0 and 1.
These functions are specific to the MXM 3.0 Software Specification,
earlier versions are not implemented due to lack of hardware. Documentation
for versions 2.1 and 3.0 can be found freely online.
Functions aren't specific to mainboards or GPUs (though some mainboards
could need more functions implemented). The structure is
mainboard-specific and is read from romfile "mxm-30-sis".
It can be extracted from vendor BIOS by running those same interrupts.
I wrote a tool to do it on Linux: https://codeberg.org/Riku_V/mxmdump/
Signed-off-by: Riku Viitanen
---
src/optionroms.c | 9 +++
src/vgahooks.c | 69
src/vgahooks.h | 9 +++
3 files changed, 87 insertions(+)
create mode 100644 src/vgahooks.h
diff --git a/src/optionroms.c b/src/optionroms.c
index e906ab97..fcce7900 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -22,6 +22,7 @@
#include "string.h" // memset
#include "util.h" // get_pnp_offset
#include "tcgbios.h" // tpm_*
+#include "vgahooks.h" // MXM30SIS
static int EnforceChecksum, S3ResumeVga, RunPCIroms;
@@ -463,6 +464,14 @@ vgarom_setup(void)
RunPCIroms = romfile_loadint("etc/pci-optionrom-exec", 2);
ScreenAndDebug = romfile_loadint("etc/screen-and-debug", 1);
+// Load MXM 3.0 System Information Structure
+void *mxm_sis = romfile_loadfile_g("mxm-30-sis", NULL, &malloc_low, 0);
+if (mxm_sis) {
+MXM30SIS = (u32)mxm_sis;
+} else {
+MXM30SIS = 0;
+}
+
// Clear option rom memory
memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START);
diff --git a/src/vgahooks.c b/src/vgahooks.c
index 1f149532..a94840b2 100644
--- a/src/vgahooks.c
+++ b/src/vgahooks.c
@@ -18,8 +18,10 @@
#define VH_VIA 1
#define VH_INTEL 2
#define VH_SMI 3
+#define VH_MXM 4
int VGAHookHandlerType VARFSEG;
+u32 MXM30SIS VARFSEG;
static void
handle_155fXX(struct bregs *regs)
@@ -59,6 +61,7 @@ via_155f02(struct bregs *regs)
dprintf(1, "Warning: VGA TV/CRT output type is hardcoded\n");
}
+
static void
via_155f18(struct bregs *regs)
{
@@ -296,6 +299,69 @@ winent_mb6047_setup(struct pci_device *pci)
SmiBootDisplay = 0x02;
}
+/
+ * MXM VGA hooks
+ /
+
+// Function 0: Return Specification Support Level
+static void
+mxm_V30_F00(struct bregs *regs)
+{
+regs->ax = 0x005f; // Success
+regs->bl = 0x30; // MXM 3.0
+regs->cx = 0x0003; // Supported Functions
+set_success(regs);
+}
+
+// Function 1: Return a Pointer to the MXM Structure
+static void
+mxm_V30_F01(struct bregs *regs)
+{
+switch (regs->cx) {
+case 0x0030:
+regs->ax = 0x005f; // Success
+regs->es = GET_GLOBAL(MXM30SIS)/16;
+regs->di = GET_GLOBAL(MXM30SIS)%16;
+set_success(regs);
+break;
+default:
+handle_155fXX(regs);
+break;
+}
+}
+
+static void
+mxm_V30(struct bregs *regs)
+{
+switch (regs->bx) {
+case 0xff00: mxm_V30_F00(regs); break;
+case 0xff01: mxm_V30_F01(regs); break;
+default: handle_155fXX(regs); break;
+}
+}
+
+static void
+mxm_155f80(struct bregs *regs)
+{
+// TODO: implement other versions, like 2.1
+mxm_V30(regs);
+}
+
+static void
+mxm_155f(struct bregs *regs)
+{
+switch (regs->al) {
+case 0x80: mxm_155f80(regs); break;
+default: handle_155fXX(regs); break;
+}
+}
+
+void
+mxm_setup(void)
+{
+VGAHookHandlerType = VH_MXM;
+}
+
/
* Entry and setup
/
@@ -313,6 +379,7 @@ handle_155f(struct bregs *regs)
switch (htype) {
case VH_VIA: via_155f(regs); break;
case VH_INTEL: intel_155f(regs); break;
+case VH_MXM: mxm_155f(regs); break;
default: handle_155fXX(regs); break;
}
}
@@ -352,4 +419,6 @@ vgahook_setup(struct pci_device *pci)
via_setup(pci);
else if (pci->vendor == PCI_VENDOR_ID_INTEL)
intel_setup(pci);
+else if (GET_GLOBAL(MXM30SIS))
+mxm_setup();
}
diff --git a/src/vgahooks.h b/src/vgahooks.h
new file mode 100644
index ..f0c203af
--- /dev/null
+++ b/src/vgahooks.h
@@ -0,0 +1,9 @@
+#ifndef __VGAHOOKS_H
+#define __VGAHOOKS_H
+
+#include "types.h" // u32
+
+extern u32 MXM30SIS;
+
+
+#endif // vgahooks.h
--
2.43.0
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscr
[SeaBIOS] Re: an issue with win10 boot and different compiler versions
Hi, Dne 10. 02. 24 v 20:09 Kevin O'Connor napsal(a): So it might not be a gcc issue really, but just a too large bios and gcc-13 is able to produce more compact code which actually fits. Ah, that makes sense. In the future, if you enable the seabios logs it should help track these things down. (Take the log from the working version and compare it to the log from the non-working version.) I suspect in the log would be messages from seabios/seavgabios hinting to the issue. Just a random idea, maybe there is something wrong with windows failing to emulate stuff? (the vgafixup.py) # It is also known that the Windows vgabios emulator has issues with # addressing negative offsets to the %esp register. That has been # worked around by not using the gcc parameter "-fomit-frame-pointer" # when compiling. I would try to boot with non working vgabios something else, like grub2, and there I would do: insmod vbe videotest And then probably one can use videotest to try to setup the mode. Or boot some payload with set gfxpayload. Thanks, Rudolf ___ 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
11.02.2024 00:10, Rudolf Marek: Hi, Hello! Thank you for the reply! Dne 10. 02. 24 v 20:09 Kevin O'Connor napsal(a): So it might not be a gcc issue really, but just a too large bios and gcc-13 is able to produce more compact code which actually fits. Ah, that makes sense. In the future, if you enable the seabios logs it should help track these things down. (Take the log from the working version and compare it to the log from the non-working version.) I suspect in the log would be messages from seabios/seavgabios hinting to the issue. 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, we have to find where it is failing and work around this, because there are lots of systems running all around the world which works, and even if there's some quirk it all relies upon, and seabios is the only one which works correctly, this knowledge doesn't help, - we have to implement the same quirk to be compatible with the world. Also, it seem strange at best that the thing depends on the compiler being used to compile seabios (vgabios) (I can't say for sure it is the size, but so far it seems like it is). # It is also known that the Windows vgabios emulator has issues with # addressing negative offsets to the %esp register. That has been # worked around by not using the gcc parameter "-fomit-frame-pointer" # when compiling. 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). I guess if the prob existed with grub, it'd be reported more widely, since many linux distros use grub in graphics mode. And the original bug report talks about windows, especially windows 10 - just tried windows 7, and I don't see this behavior with it. Probably should try with win11 - though this one is a bit more difficult to install in bios mode. Thanks, /mjt ___ 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
11.02.2024 09:49, Michael Tokarev wrote: .. And the original bug report talks about windows, especially windows 10 - just tried windows 7, and I don't see this behavior with it. Probably should try with win11 - though this one is a bit more difficult to install in bios mode. So, win11 (in bios mode) fails in exactly the same way as win10, with exactly the same debugging produced by seabios/vgabios. /mjt ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
