Hi,
I'd like to make the next release of SeaBIOS. I plan to make the
version number be v1.6.3 (instead of v0.6.3).
There are a few ACPI patches pending. However, I think it would be
best to tag the current code, and then add the ACPI code on top of it.
If anyone knows of any bugs, patches, or issues that need to be
addressed prior to making a release, please let me know.
Thanks,
-Kevin
On Thu, Sep 29, 2011 at 06:07:42PM +0200, Romain Vrignaud wrote:
> Hello,
> It works when I choose different driver for the 2 NIC. It could have been a
> nice work arrount if I do not had to
> use virtio driver for both NIC.
If it works with two different NICs then it is gPXE problem. Try to
complain on gPXE mailing list (or is it iPXE now). But first check that
the latest code is still broken.
> Any idea how I could use virtio in the 2 NIC and get bootindex works
> properly ?
Try disabling loading option rom on the NIC you do not want to boot
from (IIRC you need to add romfile="" property to one of virtio nics).
>
> Thanks in advance
>
> 2011/9/29 Gleb Natapov <gleb(a)redhat.com>
>
> > On Thu, Sep 29, 2011 at 11:30:08AM +0200, Romain Vrignaud wrote:
> > > We see the right bootindex option as I want to boot on gPXE from my
> > second
> > > NIC (mac=52:54:00:28:ca:e6).
> > > The problem is that during my VM boot process, seabios initialise gPXE
> > for
> > > my 2 NIC.
> > > But then gPXE try to boot (DHCP request) on the first NIC rather than on
> > the
> > > second one.
> > >
> > > It always try to boot first on the first PCI device (00:03.0 instead of
> > > 00:04.0).
> > >
> > > I don't really know if the problem comes from gPXE or Seabios but I have
> > > exactly the same problem when I try with Ubuntu's etherboot rom.
> > >
> > >
> > It is likely gPXE problem. If the option rom found on the first card
> > initializes both rtl cards it finds instead of only the one it was
> > loaded from then bootindex will not work correctly. Can you try with
> > two different nic models (rtl8139 and e1000 for instance) and see if
> > boot order works correctly for you?
> >
> > > I got this problem with Ubuntu latest qemu-kvm
> > > (0.14.1+noroms-0ubuntu3.11.04.1) / seabios (0.6.2-0ubuntu1) and etherboot
> > > (5.4.4-7ubuntu2) and Fedora qemu-kvm (qemu-kvm-0.15.0-4.fc15.x86_64) /
> > > Seabios (seabios-bin-0.6.2-2.fc15.noarch) and gPXE
> > > (gpxe-roms-qemu-1.0.1-4.fc15.noarch).
> > >
> > > I also recompiled latest Seabios (pre-0.6.3-20110929) trunk and gPXE
> > > (1.0.1+) from Git : the behaviour is exactly the same. I tried with
> > > different NIC driver (virtio and rtl8139) with also same behavior.
> > >
> > > Do you have any idea where my problem can come from ?
> > >
> > > Thanks in advance for any advice.
> > >
> > > Regards,
> > >
> > > Romain Vrignaud
> >
> > > _______________________________________________
> > > SeaBIOS mailing list
> > > SeaBIOS(a)seabios.org
> > > http://www.seabios.org/mailman/listinfo/seabios
> >
> >
> > --
> > Gleb.
> >
--
Gleb.
On Thu, Sep 29, 2011 at 11:30:08AM +0200, Romain Vrignaud wrote:
> We see the right bootindex option as I want to boot on gPXE from my second
> NIC (mac=52:54:00:28:ca:e6).
> The problem is that during my VM boot process, seabios initialise gPXE for
> my 2 NIC.
> But then gPXE try to boot (DHCP request) on the first NIC rather than on the
> second one.
>
> It always try to boot first on the first PCI device (00:03.0 instead of
> 00:04.0).
>
> I don't really know if the problem comes from gPXE or Seabios but I have
> exactly the same problem when I try with Ubuntu's etherboot rom.
>
>
It is likely gPXE problem. If the option rom found on the first card
initializes both rtl cards it finds instead of only the one it was
loaded from then bootindex will not work correctly. Can you try with
two different nic models (rtl8139 and e1000 for instance) and see if
boot order works correctly for you?
> I got this problem with Ubuntu latest qemu-kvm
> (0.14.1+noroms-0ubuntu3.11.04.1) / seabios (0.6.2-0ubuntu1) and etherboot
> (5.4.4-7ubuntu2) and Fedora qemu-kvm (qemu-kvm-0.15.0-4.fc15.x86_64) /
> Seabios (seabios-bin-0.6.2-2.fc15.noarch) and gPXE
> (gpxe-roms-qemu-1.0.1-4.fc15.noarch).
>
> I also recompiled latest Seabios (pre-0.6.3-20110929) trunk and gPXE
> (1.0.1+) from Git : the behaviour is exactly the same. I tried with
> different NIC driver (virtio and rtl8139) with also same behavior.
>
> Do you have any idea where my problem can come from ?
>
> Thanks in advance for any advice.
>
> Regards,
>
> Romain Vrignaud
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS(a)seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
--
Gleb.
Hello everybody.
I'm actualy experiencing some problem for ordering my VM boot with qemu-kvm
/ Seabios and gPXE.
I use libvirt's per-device boot option which launch my VM with this options
:
You can find libvirt's xml there : http://pastebin.com/bqizkLiZ
--
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 2048 -smp
1,maxcpus=3,sockets=3,cores=1,threads=1 -name vm-name
-uuid 32b5bf0d-fe46-2edb-b0d9-c134ba8a7636
-nodefconfig
-nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/vm-name.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control
-rtc base=utc -drive
file=/var/lib/libvirt/images/ploop2.img,if=none,id=drive-virtio-disk0,format=raw
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0
-drive
file=/var/lib/libvirt/images/vm-name.img,if=none,id=drive-virtio-disk1,format=raw
-device
virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1
-netdev tap,fd=23,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:28:ca:e5,bus=pci.0,addr=0x3,bootindex=2
-netdev tap,fd=24,id=hostnet1
-device
rtl8139,netdev=hostnet1,id=net1,mac=52:54:00:28:ca:e6,bus=pci.0,addr=0x4,bootindex=1
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0
-usb -vnc 127.0.0.1:1
-k en-us -vga cirrus
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
--
We see the right bootindex option as I want to boot on gPXE from my second
NIC (mac=52:54:00:28:ca:e6).
The problem is that during my VM boot process, seabios initialise gPXE for
my 2 NIC.
But then gPXE try to boot (DHCP request) on the first NIC rather than on the
second one.
It always try to boot first on the first PCI device (00:03.0 instead of
00:04.0).
I don't really know if the problem comes from gPXE or Seabios but I have
exactly the same problem when I try with Ubuntu's etherboot rom.
I got this problem with Ubuntu latest qemu-kvm
(0.14.1+noroms-0ubuntu3.11.04.1) / seabios (0.6.2-0ubuntu1) and etherboot
(5.4.4-7ubuntu2) and Fedora qemu-kvm (qemu-kvm-0.15.0-4.fc15.x86_64) /
Seabios (seabios-bin-0.6.2-2.fc15.noarch) and gPXE
(gpxe-roms-qemu-1.0.1-4.fc15.noarch).
I also recompiled latest Seabios (pre-0.6.3-20110929) trunk and gPXE
(1.0.1+) from Git : the behaviour is exactly the same. I tried with
different NIC driver (virtio and rtl8139) with also same behavior.
Do you have any idea where my problem can come from ?
Thanks in advance for any advice.
Regards,
Romain Vrignaud
Amos Kong wrote:
> [CS base address = CS segment selector * 16]
> F000H * 16 = F0000H
> ^^^^^^ (it's not 0xFFFF0000)
>
> ==> "CS base address" is not "base address in CS register" ?
Study real mode vs. protected mode. x86 starts in real mode. For
backwards compatibility, 386 CPUs (the first with full 32-bit
addressing) and later also start in real mode, but with CS in a
twilight state, so that the first instruction is actually fetched
from near top of 4GB, where the boot flash chip is decoded.
> 2. If I only compile seabios, and load the bios.bin to qemu,
> coreboot will not be used?
Of course not. If you compile Linux, and load bzImage from LILO, will
gPXE be used? coreboot is one project and SeaBIOS is another. They
can both be used together and separately.
> what's the relationship between coreboot and seabios ?
coreboot picks SeaBIOS as default payload, if the person building
coreboot does not explicitly provide a payload.
On qemu the initialization done by coreboot is simple, and has been
included into SeaBIOS instead, probably for convenience, I don't
know.
//Peter
On Wed, Sep 28, 2011 at 12:54:27PM -0400, Amos Kong wrote:
> Hi all,
>
> http://www.coreboot.org/Developer_Manual
> Hardware Reset(From Intel's "64 and IA-32 Architectures Software Developer’s Manual" (doc 253668-021 October 2006), Volume 3A, Section 9.1.4:)
>
[...]
> [CS base address = CS segment selector * 16]
"CS base address" will be assigned "CS segment selector * 16" when far
jumping in 16bit real mode. However, on reset the "CS base address"
is set to 0xFFFF0000.
> ==> Why the reset mem addresses are different? Which one is correct?
They are both correct - the execution address is always CS_base +
%eip, and CS_base is set to %cs * 16 when far jumping - however, the
machine starts with CS_base set to a value that one couldn't normally
obtain by far jumping.
> Other Questions:
> 1. which point does the BIOS start from? reset_vector? transition32? entry_elf?
On QEmu, SeaBIOS starts at 0xfffffff0, which is an alias to
reset_vector (QEmu maps the bios to both 0xffff0000 and 0xf0000).
reset_vector far jumps to entry_post (f000:e05b), which then calls
transition32 to go into 32bit mode and invoke handle_post.
On Coreboot, coreboot is called at system start (0xfffffff0) - it does
a whole bunch of system initialization and then uncompresses seabios
to 0xf0000 and jumps to entry_elf, which then calls handle_post.
> 2. If I only compile seabios, and load the bios.bin to qemu, coreboot will not be used?
Correct.
> what's the relationship between coreboot and seabios ?
Coreboot does very early hardware initialization (eg, initializing
memory controller). SeaBIOS implements a 16bit legacy BIOS. SeaBIOS
is usable by both coreboot and QEmu (and other emulators).
-Kevin
Hi all,
http://www.coreboot.org/Developer_Manual
Hardware Reset(From Intel's "64 and IA-32 Architectures Software Developer’s Manual" (doc 253668-021 October 2006), Volume 3A, Section 9.1.4:)
"""
The first instruction that is fetched and executed following a hardware reset is located at physical address 0xFFFFFFF0. This address is 16 bytes below the processor’s uppermost physical address. The EPROM containing the software-initialization code must be located at this address.
The address 0xFFFFFFF0 is beyond the 1-MByte addressable range of the processor while in real-address mode. The processor is initialized to this starting address as follows. The CS register has two parts: the visible segment selector part and the hidden base address part. In real-address mode, the base address is normally formed by shifting the 16-bit segment selector value 4 bits to the left to produce a 20-bit base address. However, during a hardware reset, the segment selector in the CS register is loaded with 0xF000 and the base address is loaded with 0xFFFF0000. The starting address is thus formed by adding the base address to the value in the EIP register (that is, 0xFFFF0000 + 0xFFF0 = 0xFFFFFFF0).
The first time the CS register is loaded with a new value after a hardware reset, the processor will follow the normal rule for address translation in real-address mode (that is, [CS base address = CS segment selector * 16]). To insure that the base address in the CS register remains unchanged until the EPROM based software-initialization code is completed, the code must not contain a far jump or far call or allow an interrupt to occur (which would cause the CS selector value to be changed).
"""
[CS base address = CS segment selector * 16]
F000H * 16 = F0000H
^^^^^^ (it's not 0xFFFF0000)
==> "CS base address" is not "base address in CS register" ?
BOOK: ISA system architecture
http://books.google.com/books?id=-pz8rvnhFDkC&lpg=PA115&ots=HIiNT97ZPV&dq=I…
CS F0000h
IP + FFF0h
------
FFFF0h = physical memory address
==> Why the reset mem addresses are different? Which one is correct?
-------------------
Other Questions:
1. which point does the BIOS start from? reset_vector? transition32? entry_elf?
2. If I only compile seabios, and load the bios.bin to qemu, coreboot will not be used?
what's the relationship between coreboot and seabios ?
Thanks,
Amos
