SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS
by Laszlo Ersek 09 Apr '15

09 Apr '15

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 >

1 0

[PATCH] build: add opt-out for timestamp and hostname
by Gerd Hoffmann 09 Apr '15

09 Apr '15

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

2 2

Read and publish firmware time stamps and boot time (was: [systemd-devel] bootloader time on a non-EFI bootloader)
by Paul Menzel 08 Apr '15

08 Apr '15

[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.…

2 1

Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS
by Kevin O'Connor 06 Apr '15

06 Apr '15

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

2 1

FreeBSD VESA console not working with SeaBIOS
by Jon Doe 05 Apr '15

05 Apr '15

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?

1 0

Re: [SeaBIOS] USB serial console support?
by Kevin O'Connor 03 Apr '15

03 Apr '15

On Fri, Apr 03, 2015 at 04:54:43PM +0000, Parker, John M wrote: > Hi > > This is a new-user question. > > I am working on a platform bring-up, specifically getting a port of > SeaBIOS sorted out. So far so good, the code has made it all the > way through to the USB enumeration. > > The current task is to bring up the boot menu on a 'serial over USB' > console. So: > Is a serial port boot menu supported? > Is there a serial over USB module in the works? Unfortunately, this feature isn't currently available. I'm not aware of anyone working on it. There are two parts to getting the above to work: forwarding keyboard and video over serial, and USB serial support. In the past, we've used sgabios ( https://code.google.com/p/sgabios/ ) to provide keyboard/video over traditional serial ports. However, sgabios wont work with USB serial ports (or even some PCI serial adapters) and it's unlikely that support will be added. Getting USB serial to work is a bit of a pain because there does not appear to be a standard for initializing USB serial adapters. One possibility would be to target only one device (and in particular, a device that something like a Beagle Bone Black could emulate would be very useful). So, to get the above to work, I think it would require both adding sgabios functionality into SeaBIOS and adding USB serial support into SeaBIOS. > > Thanks for your time > John Parker (john.m.parker(a)intel.com) -Kevin PS, please post in plain text only (no html) when sending to the mailing list.

1 0

USB serial console support?
by Parker, John M 03 Apr '15

03 Apr '15

Hi This is a new-user question. I am working on a platform bring-up, specifically getting a port of SeaBIOS sorted out. So far so good, the code has made it all the way through to the USB enumeration. The current task is to bring up the boot menu on a 'serial over USB' console. So: Is a serial port boot menu supported? Is there a serial over USB module in the works? Thanks for your time John Parker (john.m.parker(a)intel.com)

1 0

[PATCH] bios-tables-test: handle false-positive smbios signature matches
by Gabriel L. Somlo 31 Mar '15

31 Mar '15

Rather than stopping at the first match for the SMBIOS signature ("_SM_") in the f-segment (0xF0000-0xFFFFF), continue scanning until either a valid entry point table is found, or the f-segment has been exhausted. Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- tests/bios-tables-test.c | 76 ++++++++++++++++++++++++++++-------------------- 1 file changed, 44 insertions(+), 32 deletions(-) diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c index 735ac61..f79d89a 100644 --- a/tests/bios-tables-test.c +++ b/tests/bios-tables-test.c @@ -599,35 +599,15 @@ static void test_acpi_asl(test_data *data) free_test_data(&exp_data); } -static void test_smbios_ep_address(test_data *data) -{ - uint32_t off; - - /* find smbios entry point structure */ - for (off = 0xf0000; off < 0x100000; off += 0x10) { - uint8_t sig[] = "_SM_"; - int i; - - for (i = 0; i < sizeof sig - 1; ++i) { - sig[i] = readb(off + i); - } - - if (!memcmp(sig, "_SM_", sizeof sig)) { - break; - } - } - - g_assert_cmphex(off, <, 0x100000); - data->smbios_ep_addr = off; -} - -static void test_smbios_ep_table(test_data *data) +static bool smbios_ep_table_ok(test_data *data) { struct smbios_entry_point *ep_table = &data->smbios_ep_table; uint32_t addr = data->smbios_ep_addr; ACPI_READ_ARRAY(ep_table->anchor_string, addr); - g_assert(!memcmp(ep_table->anchor_string, "_SM_", 4)); + if (memcmp(ep_table->anchor_string, "_SM_", 4)) { + return false; + } ACPI_READ_FIELD(ep_table->checksum, addr); ACPI_READ_FIELD(ep_table->length, addr); ACPI_READ_FIELD(ep_table->smbios_major_version, addr); @@ -636,17 +616,50 @@ static void test_smbios_ep_table(test_data *data) ACPI_READ_FIELD(ep_table->entry_point_revision, addr); ACPI_READ_ARRAY(ep_table->formatted_area, addr); ACPI_READ_ARRAY(ep_table->intermediate_anchor_string, addr); - g_assert(!memcmp(ep_table->intermediate_anchor_string, "_DMI_", 5)); + if (memcmp(ep_table->intermediate_anchor_string, "_DMI_", 5)) { + return false; + } ACPI_READ_FIELD(ep_table->intermediate_checksum, addr); ACPI_READ_FIELD(ep_table->structure_table_length, addr); - g_assert_cmpuint(ep_table->structure_table_length, >, 0); + if (ep_table->structure_table_length == 0) { + return false; + } ACPI_READ_FIELD(ep_table->structure_table_address, addr); ACPI_READ_FIELD(ep_table->number_of_structures, addr); - g_assert_cmpuint(ep_table->number_of_structures, >, 0); + if (ep_table->number_of_structures == 0) { + return false; + } ACPI_READ_FIELD(ep_table->smbios_bcd_revision, addr); - g_assert(!acpi_checksum((uint8_t *)ep_table, sizeof *ep_table)); - g_assert(!acpi_checksum((uint8_t *)ep_table + 0x10, - sizeof *ep_table - 0x10)); + if (acpi_checksum((uint8_t *)ep_table, sizeof *ep_table) || + acpi_checksum((uint8_t *)ep_table + 0x10, sizeof *ep_table - 0x10)) { + return false; + } + return true; +} + +static void test_smbios_entry_point(test_data *data) +{ + uint32_t off; + + /* find smbios entry point structure */ + for (off = 0xf0000; off < 0x100000; off += 0x10) { + uint8_t sig[] = "_SM_"; + int i; + + for (i = 0; i < sizeof sig - 1; ++i) { + sig[i] = readb(off + i); + } + + if (!memcmp(sig, "_SM_", sizeof sig)) { + /* signature match, but is this a valid entry point? */ + data->smbios_ep_addr = off; + if (smbios_ep_table_ok(data)) { + break; + } + } + } + + g_assert_cmphex(off, <, 0x100000); } static inline bool smbios_single_instance(uint8_t type) @@ -767,8 +780,7 @@ static void test_acpi_one(const char *params, test_data *data) } } - test_smbios_ep_address(data); - test_smbios_ep_table(data); + test_smbios_entry_point(data); test_smbios_structs(data); qtest_quit(global_qtest); -- 2.1.0

2 1

[PATCH] smbios: ensure comparison SMBIOS string can't be paragraph aligned
by Bruce Rogers 31 Mar '15

31 Mar '15

The SMBIOS anchor string _SM_ is stored within SeaBIOS to validate an SMBIOS entry point structure. There is the possibility (observed) that this comparison string ends up paragraph aligned and mistakenly found during a search for the real SMBIOS entry point. Ensure it will never end up on a paragraph boundary by storing it at odd alignment. Signed-off-by: Bruce Rogers <brogers(a)suse.com> --- src/fw/biostables.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/fw/biostables.c b/src/fw/biostables.c index 50a891b..b8ff86f 100644 --- a/src/fw/biostables.c +++ b/src/fw/biostables.c @@ -18,6 +18,9 @@ #include "util.h" // copy_table #include "x86.h" // outb +// ensure signature cannot be found on paragraph boundary +const char smbios_sig_str[] __aligned(2) VARFSEG = " _SM_"; + struct pir_header *PirAddr VARFSEG; void @@ -271,7 +274,7 @@ copy_smbios(void *pos) if (SMBiosAddr) return; struct smbios_entry_point *p = pos; - if (memcmp(p->anchor_string, "_SM_", 4)) + if (memcmp(p->anchor_string, smbios_sig_str + 1, 4)) return; if (checksum(pos, 0x10) != 0) return; -- 1.9.0

3 5

[coreboot] Booting Windows 8 failed
by Zheng Bao 30 Mar '15

30 Mar '15

The same SeaBIOS image and same win8 hard drive can boot Mullins and Kabini. So I believe the SeaBIOS and hard drive are both OK. Since it is a new APU, there might be some potential problem in Coreboot. But I have no way to find it out. What I am looking for is the way to debug at Windows bootloader stage, before the kernel image is loaded. Zheng On 3/25/2015 3:59 PM, Kevin O'Connor wrote: > There have been success reports with SeaBIOS booting Windows 8, so > it's not a general win8 problem. for sure - no issues booting Win8/8.1/10TP on the Haswell ChromeOS devices using SeaBIOS 1.8.0 > > If possible, try to pull the disk image into a QEMU VM and see if it > has the same crash when running QEMU with a native instance of > SeaBIOS. > > Also, make sure the problem is still present with SeaBIOS debug level > 1 - very high debug levels are known to cause issues with some > software. > > -Kevin > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS at seabios.org > http://www.seabios.org/mailman/listinfo/seabios

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS