SeaBIOS February 2011

seabios@seabios.org

20 participants
25 discussions

Re: [SeaBIOS] [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel

by Kevin O'Connor

On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote: > > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > >> Should a kernel fail during boot, I'd suspect it doesn't like one of > >> the apm/pcibios callbacks, or it doesn't like one of the > >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code > >> (see http://seabios.org/Download ) and increasing the debugging by > >> modifying src/config.h. Specifically, you could increase > >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to > >> 1. Also, you could try disabling some of the features to see if that > >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / > >> CONFIG_MPTABLE). > > > > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the > image boots up fine. Gleb, have you seen this thread? Some of the recent changes to smbios that look like possible culprits are: Make SMBIOS table pass MS SVVP test Use MaxCountCPUs during building of per cpu tables. Add malloc_high/fseg() and rework bios table creation to use them. There were other changes, but the comments indicate they were only ports of changes already in bochs. I suppose it's also possible the lack of smbios is turning off some other feature in the guest (eg, acpi) that's the real culprit. -Kevin

9 years, 7 months

[PATCH] support piix PAM registers in KVM

by Gleb Natapov

Without this BIOS fails to remap 0xf0000 memory from ROM to RAM so writes to F-segment modify ROM content instead of memory copy. Since QEMU does not reloads ROMs during reset on next boot modified copy of BIOS is used. Signed-off-by: Gleb Natapov <gleb(a)redhat.com> diff --git a/hw/piix_pci.c b/hw/piix_pci.c index 933ad86..0bf435d 100644 --- a/hw/piix_pci.c +++ b/hw/piix_pci.c @@ -99,10 +99,6 @@ static void i440fx_update_memory_mappings(PCII440FXState *d) int i, r; uint32_t smram, addr; - if (kvm_enabled()) { - /* FIXME: Support remappings and protection changes. */ - return; - } update_pam(d, 0xf0000, 0x100000, (d->dev.config[I440FX_PAM] >> 4) & 3); for(i = 0; i < 12; i++) { r = (d->dev.config[(i >> 1) + (I440FX_PAM + 1)] >> ((i & 1) * 4)) & 3; -- Gleb.

9 years, 8 months

Re: [SeaBIOS] Some questions

by Kevin O'Connor

Hi Stefan, I'm CC'ing the mailing list. On Wed, Nov 24, 2010 at 11:45:17AM -0500, Stefan Berger wrote: > Hi Kevin, > > while I am porting the BIOS code for TCG support to SeaBIOS, I am > wondering about the following: > > 'When' is it recommendable to switch from 16 bit to 32bit. To be honest, this has never really been done before in SeaBIOS, so I think we'll have to figure this out as we go. Since you need to access full memory, it looks like it will be required to jump into 32bit mode. >I am > asking because the interface I am implementing allows callers to > pass input and output data structures using es:di and ds:si, with es > and ds allowed to be loaded with anything possible. So my strategy > in the Bochs BIOS was to switch to 32 bit even before calling the > interrupt handler, there doing the case statement for branching into > the actual functions (switch (regs->al)) and passing 32 bit pointers > converted from es:di and ds:si to the functions doing the work and > reading from those memory locations. This sounds okay to me - it should be possible to implement handle_1abb(regs) which does a call32(tcg32_1abb, regs). It's possible to do all the pointer conversion while in 32bit mode. >The 'thing' is also that > several ones of the functions that can be called through the > interrupt interface are also called from the implemented functions. > Example: > > Functions A,B,C can be called via the interrupt handler. > > Function B also calls A. > Function C also calls B. This shouldn't really be an issue. The build should take care of this. > > This is due to the hierarchical nature of the functions. Also, while > for example B calls A, B fills a data structure (on the stack) that > it passes to A. A of course can get the same data structure from the > user calling the interrupt interface. So, by switching to 32 bit > mode and converting to 32 bit pointers early I could previously > avoid a lot of headaches with the segment registers in 16 bit mode > and reading the data from wherever they may be. Would you have any > concerns about switching to 32 bit mode early, so that the interrupt > handler and anything subsequent runs in 32 bit mode? I can't say for sure what will make sense without seeing the code first, but it sounds okay to me. -Kevin > > Regards, > Stefan > > >

9 years, 11 months

[PATCH] Allow to run option roms with bad checksums

by Stefan Reinauer

See patch -- Stefan Reinauer Google Inc.

9 years, 12 months

Next version

by Kevin O'Connor

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

10 years

Re: [SeaBIOS] QEMU regression problems - Update FPU

by Gerhard Wiesinger

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

10 years

Help for motherboard

by sh4r4d＠gmail.com

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

10 years

Re: [SeaBIOS] [Qemu-devel] Re: QEMU-KVM and video performance - Update

by Gerhard Wiesinger

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

10 years

non-emulated AHCI hardware

by Jonathan A. Kollasch

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

10 years

Re: [SeaBIOS] Next version

by Prasad Joshi

> 2. Next version (Kevin O'Connor) > ------------------------------ > > Message: 2 > Date: Wed, 16 Feb 2011 01:12:28 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: seabios(a)seabios.org > Subject: [SeaBIOS] Next version > Message-ID: <20110216061228.GA635(a)morn.localdomain> > Content-Type: text/plain; charset=us-ascii > > 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? The current PCI memory space is limited to 236MB. It would be good to increase it to at-least 512MB. KVM supports for device assignment to the VM. For most of the PCI devices the 236MB memory might be enough, but when you pass-through a graphics device, this memory is very limited. I don't know if the PCI memory space can be dynamically expanded, but it would be good to increase the PCI memory space to 512MB at-least. > > 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 >

10 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS February 2011