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
7 years, 6 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.
7 years, 7 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
>
>
>
7 years, 9 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
7 years, 10 months
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.
>
7 years, 10 months
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?AspxAutoDetectCook...
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
7 years, 11 months
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=0d14905b5eb...
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.
>
>
>
7 years, 11 months
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
7 years, 11 months
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
>
7 years, 11 months
