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
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
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
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
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
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
>
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
[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/cbme...
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
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?
