SeaBIOS

seabios@seabios.org

2 participants
3799 discussions

Re: [SeaBIOS] Reset bug in SeaBIOS / qemu?
by Kevin O'Connor 13 Mar '11

13 Mar '11

Hi Matthew. I'm forwarding your mail to the seabios list. I'll also take a look at this later on. On Wed, Mar 09, 2011 at 06:29:20PM +0000, Matthew Bloch wrote: > Hi Kevin - > > I'm not sure whether this is a qemu bug or SeaBIOS' but your commit > 244caf86f11f5f65d166d91704f64cb673167abc seems to have broken qemu's > ability to reset the system. I reported it on qemu's bug tracker as > qemu behaves differently if KVM is turned on (i.e. you only see this > behaviour with qemu, not kvm). > > I found that commenting this out in post.c seems to allow it to > reboot properly - once: > > if (CONFIG_COREBOOT && HaveRunPost) > // This is a soft reboot - invoke a hard reboot. > tryReboot(); > > The second reset seems to break the VGA but continues to boot, the > third hangs at "Scanning for VGA ROM". > > Hope that's useful, not entirely sure how to work around it at > present, other than "always use KVM". > > qemu is stil bundling a 0.5 build of seabios, but if they upgrade > this is going to be a bit more visible. > > Regards, > > -- > Matthew Bloch

1 1

Re: [SeaBIOS] [Qemu-devel] OVMF Google Summer of Code ideas
by Kevin O'Connor 09 Mar '11

09 Mar '11

On Tue, Mar 08, 2011 at 09:00:05AM -0800, Jordan Justen wrote: > On Mon, Mar 7, 2011 at 23:18, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > > On Tue, Mar 8, 2011 at 12:54 AM, Jordan Justen <jljusten(a)gmail.com> wrote: > >> The biggest issue that you guys care about for OVMF is a lack of > >> legacy bios compatibility (CSM). There has been no progress in this > >> area. (However, it has now been suggested by someone on our dev list > >> for a potential Google Summer of Code project. We will have to see if > >> anything comes of this...) > > > > That would be cool. Is there a way to just embed SeaBIOS? Or do the > > UEFI APIs still need to be around when CSM kicks in? > > Yes, the UEFI system is still in place. The UEFI part still handles > the majority of platform init, and calls into the CSM at various > points. The CSM returns back to UEFI for all CSM calls, except the > legacy boot. Is there a concise list of these various callbacks between UEFI and CSM? If SeaBIOS just needs to be loaded up for legacy boots, that doesn't sound too difficult. However, if SeaBIOS would need to translate various BIOS calls into UEFI calls - that sounds like it could be complex. -Kevin

3 4

[PATCH] Allow to run option roms with bad checksums
by Stefan Reinauer 07 Mar '11

07 Mar '11

See patch -- Stefan Reinauer Google Inc.

2 2

[PATCH] Add config option to disable MTRR initialization.
by Kevin O'Connor 07 Mar '11

07 Mar '11

Some versions of Bochs don't like the MTRR initialization, so add CONFIG_MTRR_INIT to control whether SeaBIOS will touch the MTRRs. --- src/Kconfig | 6 ++++++ src/mtrr.c | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index fca73e4..f064b27 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -194,6 +194,12 @@ menu "Hardware support" default y help Support System Management Mode (on emulators). + config MTRR_INIT + depends on !COREBOOT + bool "Initialize MTRRs" + default y + help + Initialize the Memory Type Range Registers (on emulators). endmenu menu "BIOS interfaces" diff --git a/src/mtrr.c b/src/mtrr.c index ed239c8..0502c18 100644 --- a/src/mtrr.c +++ b/src/mtrr.c @@ -32,7 +32,7 @@ void mtrr_setup(void) { - if (CONFIG_COREBOOT) + if (!CONFIG_MTRR_INIT || CONFIG_COREBOOT) return; u32 eax, ebx, ecx, edx, cpuid_features; -- 1.7.4

1 0

[ANNOUNCE] SeaBIOS 0.6.2
by Kevin O'Connor 05 Mar '11

05 Mar '11

I've tagged a new release of SeaBIOS. For more information on the release, please see: http://seabios.org/Releases New in this release: * Setup code can relocate to high-memory to save space in c-f segments * Build now configured via Kconfig * Experimental support for AHCI controllers * Support for run-time configuration of the boot order (via CBFS/fw_cfg "bootorder" file) * Support T13 EDD3.0 spec * Improved bounds checking on PCI memory allocation * Several bug fixes For information on obtaining SeaBIOS, please see: http://seabios.org/Download -Kevin

2 2

Next version
by Kevin O'Connor 25 Feb '11

25 Feb '11

I think it's about time to release a new version of SeaBIOS (0.6.2). Does anyone know of any feature or bug that needs to be addressed prior to a release? Also, there have been some inquiries about making a 1.0 release of SeaBIOS - I'm inclined to bump the major number in the release after this one (eg, 1.6.3). Let me know if there are any major features that you'd like to see added prior to a "1.0" release. -Kevin

3 2

Re: [SeaBIOS] QEMU regression problems - Update FPU
by Gerhard Wiesinger 24 Feb '11

24 Feb '11

Hello, Good news: Seems to be that 2 of 3 issues have been fixed with QEMU: :-) Summary of previous discussion: http://www.mail-archive.com/qemu-devel@nongnu.org/msg29465.html 2.) Realtime clock: fixed 3.) Base Memory: fixed Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general? QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct) Code: fninit ; init FPU fld1 ; Pushes 1 on the stack, ST0=1 fadd st(0), st(0) ; ST0=ST0+ST0=2 fld1 ; Pushes 1 on the stack, ST0=1, ST1=2 fadd st(1), st(0) ; ST1=ST1+ST0=3, ST0=1 fdivrp st(1), st(0) ; ST0=ST0/ST1=1/3 f2xm1 ; ST0=2^ST0-1 (ST0 must be in range -1 to +1)=2^(1/3)-1=0.25992104989487316476721060727823 fldpi ; pushes pi on the stack; ST0=pi, ST1=0.25992104989487316476721060727823 fyl2x ; ST0=ST1*log2(ST0)=0.25992104989487316476721060727823*1.651496129472318798043279295108=0.42925860786976448643152122341584 fwait ; wait *.ASM/*.COM file is also present for debugging. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Mon, 12 Apr 2010, Gerhard Wiesinger wrote: > Hello, > > Checkit reports some problems under DOS: > 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. Seems > to be a problem of the instruction set. > 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the > KVM problem, see my previous post). Seems to be that real-time clock is not > working correct. > 3.) There is also a problem with the reported base memory under QEMM386 > (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. > Therefore base memory test fails. I guess that reporting memory CMOS > tables/interrupt functions are not implemented correctly. > > Details are listed below. > > All issues are NOT present under VMWare Server 2.0 and with real hardware. > > QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II > Quad Core, x86_64-softmmu. > > Any comments? > > Thnx. > > Ciao, > Gerhard > > -- > http://www.wiesinger.com/ > > Details: > 1.) > NPU Trigonometric Functions.................................FAILED *** > Step 1, Expected 0.42926, received 0.42926 > > Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h). > Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h). > Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h). > > 2.) > Compare Current Time............................................Passed > DOS: 16:24:39.89 Real-Time Clock: 16:24:39.00 (.89 apart) > > Compare Current Date............................................Passed > DOS: 04/11/2010 Real-Time Clock: 04/11/2010. > > Real-Time Clock Alarm...........................................FAILED *** > > Compare Elapsed Time............................................Passed > DOS: 11.97 Seconds Real-Time Clock: 12.00 Seconds (.03 apart) > > 3.) Known Memory: > Base 646K From 0K to 646K (0000000h to 00A17FFh) > Base Memory.................................................FAILED *** > ERROR at Address 0A0000h, Bits FEDCBA9876543210 > ERROR at Address 0A0004h, Bits FEDCBA9876543210 > ERROR at Address 0A0006h, Bits FEDCBA9876543210 > ERROR at Address 0A0008h, Bits FEDCBA9876543210 > ERROR at Address 0A000Ah, Bits FEDCBA9876543210 > ERROR at Address 0A000Ch, Bits FEDCBA9876543210 > ERROR at Address 0A000Eh, Bits FEDCBA9876543210 > ERROR at Address 0A0010h, Bits FEDCBA9876543210 > ERROR at Address 0A0012h, Bits FEDCBA9876543210 > ERROR at Address 0A0014h, Bits FEDCBA9876543210 > ERROR at Address 0A0016h, Bits FEDCBA9876543210 > ERROR at Address 0A0018h, Bits FEDCBA9876543210 > ERROR at Address 0A001Ah, Bits FEDCBA9876543210 > ERROR at Address 0A001Ch, Bits FEDCBA9876543210 > ERROR at Address 0A001Eh, Bits FEDCBA9876543210 > ERROR at Address 0A0020h, Bits FEDCBA9876543210 > ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE. >

5 8

Help for motherboard
by sh4r4d＠gmail.com 18 Feb '11

18 Feb '11

Hi All, I wanted to build a new Desktop workstation with currently available CPU and motherboard that is supported by Coreboot bios, I have searched few links for it e.g. Ubuntu-certified hardware http://www.ubuntu.com/certification/ Zareason http://zareason.com/shop/home.php AMD Processors - Recommended Motherboards http://products.amd.com/pages/recommendedmbfilter.aspx?AspxAutoDetectCookie… But these site mention hardware where gnu/linux could run easily, but they do not inform about coreboot bios compatibility. And checked http://www.coreboot.org/Supported_Motherboards for searching suitable motherboard, seen coreboot related video in youtube. But I did not found here new Intel and AMD cpu for motherboards in Desktop/Workstation section (except Laptop) mentioned for e.g. Intel Core 3i Intel Core 2 Duo Intel Dual Core So finally I like to know do these newer CPU's any motherboard going to be supported in near future, So I will purchase that motherboard. Please suggest which CPU/motherboard combination is good with coreboot. -- Regards, -sharad

2 1

Re: [SeaBIOS] [Qemu-devel] Re: QEMU-KVM and video performance - Update
by Gerhard Wiesinger 18 Feb '11

18 Feb '11

Hello, Some update on this issue, archive: http://www.mail-archive.com/kvm@vger.kernel.org/msg32600.html Seems to be that cirrus VGA is now ok (>1000MB/s up to 2000MB/s). But cirrus has only 320x200x256colors (Mode 13h) mode implemented in VESA BIOS. VMWare and std VGA still have the performance issue. I guess improvement is related to the following commit: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=0d14905b5eb8a… Especially i guess the change in hw/cirrus_vga.c. Any idea how to fix: 1.) More VESA modes in cirrus VGA (is VESA emulation done by Seabios or by KVM cirrus BIOS?) 2.) fix in VMWare and std VGA modes the performance, too Versions are latest dev versions of KVM user part and Seabios from GIT. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ On Wed, 12 May 2010, Avi Kivity wrote: > On 05/12/2010 09:14 AM, Gerhard Wiesinger wrote: >> On Mon, 10 May 2010, Avi Kivity wrote: >> >>> On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote: >>>>>> >>> >>> For 256 color more the first priority is to find out why direct mapping is >>> not used. I'd suggest tracing the code that makes this decision (in >>> hw/*vga.c) and seeing if it's right or not. >> >> I think this is because A000 is not initialized for KVM (see log below and >> logging patch attached). > > Why isn't it initialized? > > Did the guest configure things such as it is impossible to map it directly? > Or does the configuration allow direct mapping and qemu incorrectly decides > that it cannot direct map? > > Best would be to print out all the configuration registers and interpret them > according to the specification. > > >> >> vga_dirty_log_start >> vga_dirty_log_start_mapping_lfb_vram_mapped, start=0x000A0000, >> len=0x00008000 >> BUG: kvm_dirty_pages_log_change: invalid parameters >> 00000000000a0000-00000000000a7fff > > Why does this happen? > > -- > Do not meddle in the internals of kernels, for they are subtle and quick to > panic. > > >

1 0

non-emulated AHCI hardware
by Jonathan A. Kollasch 17 Feb '11

17 Feb '11

Hi, I've been trying SeaBIOS's AHCI driver on AMD SB710 hardware under coreboot. Both AMD's AHCI BIOS and NetBSD's ahcisata(4) drivers are happy enough with the hardware's state after coreboot/SeaBIOS. However, SeaBIOS's AHCI driver just falls into a dead loop waiting for commands to complete. This is due to at least two problems. The immediate problem is that we tell the HBA that a Host To Device FIS is 4 dwords. The correct value is 5 dwords if I read the specs right. But, when the H2D FIS length we give to the HBA is 5, I have a more perplexing problem. The machine hardlocks when HBA registers are read after the command has been issued. When I examine the Command List and Receive FIS Area, etc. before and after issuing the command, they have not changed. Jonathan Kollasch

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS