SeaBIOS April 2015

seabios@seabios.org

19 participants
42 discussions

[PATCH] smbios: Use integer signature instead of string signature

by Kevin O'Connor

Change the smbios structure to use a 4 byte u32 signature field instead of a 4 byte character string field. In practice, this allows the compiler to place the signature in the initialize code segment and thus makes it less likely the signature would be found in the f-segment. (If the smbios signature is found in the f-segment it can confuse some table scans.) Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/fw/biostables.c | 2 +- src/fw/smbios.c | 2 +- src/std/smbios.h | 4 +++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/fw/biostables.c b/src/fw/biostables.c index 50a891b..450aca2 100644 --- a/src/fw/biostables.c +++ b/src/fw/biostables.c @@ -271,7 +271,7 @@ copy_smbios(void *pos) if (SMBiosAddr) return; struct smbios_entry_point *p = pos; - if (memcmp(p->anchor_string, "_SM_", 4)) + if (p->signature != SMBIOS_SIGNATURE) return; if (checksum(pos, 0x10) != 0) return; diff --git a/src/fw/smbios.c b/src/fw/smbios.c index dba0541..f3b5ad9 100644 --- a/src/fw/smbios.c +++ b/src/fw/smbios.c @@ -37,7 +37,7 @@ smbios_entry_point_setup(u16 max_structure_size, struct smbios_entry_point ep; memset(&ep, 0, sizeof(ep)); - memcpy(ep.anchor_string, "_SM_", 4); + ep.signature = SMBIOS_SIGNATURE; ep.length = 0x1f; ep.smbios_major_version = 2; ep.smbios_minor_version = 4; diff --git a/src/std/smbios.h b/src/std/smbios.h index 0513716..4ccf2ea 100644 --- a/src/std/smbios.h +++ b/src/std/smbios.h @@ -3,11 +3,13 @@ #include "types.h" // u32 +#define SMBIOS_SIGNATURE 0x5f4d535f // "_SM_" + /* SMBIOS entry point -- must be written to a 16-bit aligned address between 0xf0000 and 0xfffff. */ struct smbios_entry_point { - char anchor_string[4]; + u32 signature; u8 checksum; u8 length; u8 smbios_major_version; -- 1.9.3

5 years, 9 months

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS

by Kevin O'Connor

On Mon, Apr 06, 2015 at 10:05:36AM +0200, Jon Doe wrote: > Here's a log showing a boot into X, then switching to console, then > trying to kldload vesa.ko. Looks like X is happily probing vbe modes, > but the console chokes with "SeaVGABIOS: x86emu leal trap!". That error message indicates that the vga bios is running in an older version of the x86emu emulator that is too broken to be capable of running the vga bios. (Specifically, the "leal" instruction is not properly implemented.) Unfortunately, there isn't much that can be done about this on the vga bios side. There are newer versions of x86emu available that are capable of emulating SeaVGABIOS, but I don't know if someone has already integrated it into FreeBSD or how one would go about integrating it. Alternatively, since the log shows the vesa mode scan was run natively instead of via x86emu, it may be possible to change the code to switch modes using native execution instead of via x86emu. -Kevin

5 years, 9 months

[PATCH] vgabios: Don't use "smsww" instruction - it confuses x86emu

by Kevin O'Connor

Commit 251e2638 introduced the "smsww" instruction to the vgabios. Unfortunately, it appears at least some versions of x86emu crash when executing that instruction (eg, FC13 installer crashes). That instruction wasn't required to work around the problem fixed in 251e2638, so just avoid it. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- The fix for the "skifree bug" tickled yet another old OS problem - old versions of x86emu don't like smsww. :-( The smsww wasn't strickly necessary, so this patch just stops using it. --- vgasrc/vgabios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c index 7c1f0b8..f07e85b 100644 --- a/vgasrc/vgabios.c +++ b/vgasrc/vgabios.c @@ -304,7 +304,7 @@ vga_set_mode(int mode, int flags) SET_BDA(video_mode, 0xff); SET_BDA_EXT(vbe_mode, mode | (flags & MF_VBEFLAGS)); SET_BDA_EXT(vgamode_offset, (u32)vmode_g); - if (CONFIG_VGA_ALLOCATE_EXTRA_STACK && !(getcr0_vm86() & CR0_PE)) + if (CONFIG_VGA_ALLOCATE_EXTRA_STACK) // Disable extra stack if it appears a modern OS is in use. // This works around bugs in some versions of Windows (Vista // and possibly later) when the stack is in the e-segment. -- 1.9.3

5 years, 9 months

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS

by Kevin O'Connor

On Thu, Apr 09, 2015 at 10:59:11AM +0200, Jon Doe wrote: > On Thu, Apr 9, 2015 at 4:32 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Wed, Apr 08, 2015 at 08:48:11PM +0200, Peter Stuge wrote: > >> Kevin O'Connor wrote: > >> > (Specifically, the "leal" instruction is not properly implemented.) > >> > > >> > Unfortunately, there isn't much that can be done about this on the vga > >> > bios side. > >> > >> Really? Impossible to save flags, use other opcodes, and restore flags? > >> > >> lea isn't used in vgasrc/ besides in the trap that triggers the fault. > >> > >> In src/romlayout.S lea is used in two places to bump esp before calls. > >> If those code paths are used also by SeaVGABIOS then maybe they could > >> be rewritten with simpler instructions? > > > > The problem is not with leal in hand written assembler - the problem > > is with leal instructions generated by gcc. To see the assembler gcc > > produces for the vgabios one can look at out/vgaccode16.raw.s . Or, > > alternatively, one can run: > > objdump -m i386 -M i8086 -M suffix -ldr out/vgarom.o > > > > We've fixed up gcc assembler in the past (see scripts/vgafixup.py) to > > work around x86emu. However, the leal instruction seems painful to > > patch out - particularly so when %esp is one of the registers read or > > written in the leal instruction. If anyone wants to take a stab > > at a workaround, feel free to submit a patch. > > > > -Kevin > > Might be instructive to look at how vmware and virtualbox BIOSes is > able to work around this problem. Surely their BIOS code is written in > C? My understanding is that traditional proprietary BIOS and VGABIOS are written in assembler. There are 16bit C compilers that (almost assuredly) wont generate 32bit instructions such as leal - for example, openwatcom and bcc. However, using them results in other problems. > Fixing this in x86emu is probably the right thing to do (just checked, > PCBSD 10.1's x86emu is still broken), but this won't help if you're > stuck with an old release. It's also possible to use the older "lgpl vgabios" - http://www.nongnu.org/vgabios/ - it is written in assembler and C code (that is compiled with bcc). -Kevin

5 years, 9 months

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS

by Paolo Bonzini

On 09/04/2015 10:59, Jon Doe wrote: > Might be instructive to look at how vmware and virtualbox BIOSes is > able to work around this problem. Surely their BIOS code is written in > C? At least Bochs's vgabios was written to run exclusively in 16-bit mode, using not just a different compiler than gcc but effectively another instruction set (16-bit x86 instructions and especially 16-bit addressing modes are almost never used in 32-bit mode). Paolo

5 years, 9 months

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS

by Laszlo Ersek

On 04/09/15 10:59, Jon Doe wrote: > On Thu, Apr 9, 2015 at 4:32 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Wed, Apr 08, 2015 at 08:48:11PM +0200, Peter Stuge wrote: >>> Kevin O'Connor wrote: >>>> (Specifically, the "leal" instruction is not properly implemented.) >>>> >>>> Unfortunately, there isn't much that can be done about this on the vga >>>> bios side. >>> >>> Really? Impossible to save flags, use other opcodes, and restore flags? >>> >>> lea isn't used in vgasrc/ besides in the trap that triggers the fault. >>> >>> In src/romlayout.S lea is used in two places to bump esp before calls. >>> If those code paths are used also by SeaVGABIOS then maybe they could >>> be rewritten with simpler instructions? >> >> The problem is not with leal in hand written assembler - the problem >> is with leal instructions generated by gcc. To see the assembler gcc >> produces for the vgabios one can look at out/vgaccode16.raw.s . Or, >> alternatively, one can run: >> objdump -m i386 -M i8086 -M suffix -ldr out/vgarom.o >> >> We've fixed up gcc assembler in the past (see scripts/vgafixup.py) to >> work around x86emu. However, the leal instruction seems painful to >> patch out - particularly so when %esp is one of the registers read or >> written in the leal instruction. If anyone wants to take a stab >> at a workaround, feel free to submit a patch. >> >> -Kevin > > Might be instructive to look at how vmware and virtualbox BIOSes is > able to work around this problem. Surely their BIOS code is written in > C? Not sure about virtualbox, but vmware certainly have full control of the compiler (and any postprocessors) they build their releases with. I think users / distributors won't (can't) recompile vmware's C-language BIOS, possibly giving rise to instructions that trip up NTVDM, x86emu etc. Laszlo > Fixing this in x86emu is probably the right thing to do (just checked, > PCBSD 10.1's x86emu is still broken), but this won't help if you're > stuck with an old release. > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios >

5 years, 9 months

[PATCH] build: add opt-out for timestamp and hostname

by Gerd Hoffmann

For distro builds it is much more useful to fill .version with the exact tag for the build in question, i.e. %{name}-%{version}-%{release} in case of rpm builds, so the output can easily linked to the exact package build. Timestamp and buildhost don't carry much useful information in that case, so allow to opt-out without patching the source tree. Keep them enabled by default so (test) builds done by normal users continue to have them, to simplify trouble shooting on the mailing list. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- scripts/buildversion.sh | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/scripts/buildversion.sh b/scripts/buildversion.sh index e5ce96c..bdbf65e 100755 --- a/scripts/buildversion.sh +++ b/scripts/buildversion.sh @@ -11,7 +11,14 @@ elif [ -f .version ]; then else VERSION="?" fi -VERSION="${VERSION}-`date +"%Y%m%d_%H%M%S"`-`hostname`" + +# add timestamp +if test "${NO_TIMESTAMP}" = ""; then + VERSION="${VERSION}-`date +"%Y%m%d_%H%M%S"`" +fi +if test "${NO_HOSTNAME}" = ""; then + VERSION="${VERSION}-`hostname`" +fi echo "Version: ${VERSION}" # Build header file -- 1.8.3.1

5 years, 9 months

Read and publish firmware time stamps and boot time (was: [systemd-devel] bootloader time on a non-EFI bootloader)

by Paul Menzel

[CC’ing coreboot, GRUB, SeaBIOS, Syslinux project and Linux kernel] Am Montag, den 16.03.2015, 11:38 +0100 schrieb Kay Sievers: > On Mon, Mar 16, 2015 at 11:29 AM, Umut Tezduyar Lindskog wrote: > > I would like to pass the time it was spent in bootloader to systemd. > > Is there a kernel command line to pass this information on non EFI > > bootloader? Or is there an another way? > > No, there isn't anything I know of. > > The kernel boot protocol should probably be extended to accept a block > of values to be passed from the loader to the OS, and be exported > somewhere by the kernel itself to userspace. > > Overloading the kernel command line with that does not sound like the > right approach. We should not support anything like that from systemd. Could that approach please be discussed with all firmware, payload and firmware projects? For example, coreboot (and the depthcharge payload used on Chromebooks and Chromeboxes) already store the time stamps in its CBMEM, which can be read with the utility `cbmem` with `cbmem -t` [1] or with GRUB’s `coreboot_boottime` command. 10 entries total: 10:start of ramstage 9 30:device enumeration 441 (432) 40:device configuration 95,357 (94,915) 50:device enable 99,275 (3,918) 60:device initialization 109,246 (9,971) 70:device setup done 181,906 (72,659) 75:cbmem post 182,274 (368) 80:write tables 182,276 (2) 90:load payload 183,873 (1,597) 99:selfboot jump 283,779 (99,905) GRUB also has a `boottime` command outputting times like how long a module needed to load. One approach would be, that the Linux kernel has drivers to read the different implementations on how to store the boot time and then exports those to userspace. The other approach, and probably more feasible one, is that all firmware projects use the same standard/specification. What is actually needed? Are pairs of project, stage name, time in milliseconds since start of program where each project gets assigned a unique ID. Do you need more data? Thanks, Paul [1] http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=util/cbmem/cbmem.…

5 years, 9 months

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS

by Kevin O'Connor

On Sun, Apr 05, 2015 at 07:44:28PM +0200, Jon Doe wrote: > Hi List, > > I'm trying to get a VESA console going on FreeBSD 8.2. There seems to > be some mixup detecting available video modes (using SeaBIOS 1.7.5). > > FreeBSD's vesa.ko module refuses to load, bailing out from > vesa_bios_init() (see > http://fxr.watson.org/fxr/source/dev/fb/vesa.c?v=FREEBSD82#L816). The > whole VESA block seems to be garbage, or it is parsed incorrectly. > > Any ideas on what might be wrong? There have been problems in the past with older versions of x86emu not properly emulating some x86 instructions. However, to be sure if this is the problem, we'd need to see the output from the debug log. See: http://www.seabios.org/Debugging to enable debugging, and please post the full debug log. -Kevin

5 years, 9 months

FreeBSD VESA console not working with SeaBIOS

by Jon Doe

Hi List, I'm trying to get a VESA console going on FreeBSD 8.2. There seems to be some mixup detecting available video modes (using SeaBIOS 1.7.5). FreeBSD's vesa.ko module refuses to load, bailing out from vesa_bios_init() (see http://fxr.watson.org/fxr/source/dev/fb/vesa.c?v=FREEBSD82#L816). The whole VESA block seems to be garbage, or it is parsed incorrectly. Any ideas on what might be wrong?

5 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2015