Re: [SeaBIOS] [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI DSDT tables
by Michael S. Tsirkin
On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote:
> ----- Original Message -----
> > On Tue, Sep 20, 2011 at 06:45:57AM -0400, Amos Kong wrote:
> > > From 48ea1c9188334b89a60b4f9e853e86fc04fda4a5 Mon Sep 17 00:00:00
> > > 2001
> > > From: Amos Kong <akong(a)redhat.com>
> > > Date: Tue, 20 Sep 2011 15:38:43 +0800
> > > Subject: [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI
> > > DSDT tables
> > >
> > > Only func 0 is registered to guest driver (we can
> > > only found func 0 in slot->funcs list of driver),
> > > the other functions could not be cleaned when
> > > hot-removing the whole slot. This patch adds
> > > device per function in ACPI DSDT tables.
> > >
> > > Have tested with linux/winxp/win7, hot-adding/hot-remving,
> > > single/multiple function device, they are all fine.
> > > ---
> > > Changes from v1:
> > > - cleanup the macros, bios.bin gets back to 128K
> > > - notify only when func0 is added and removed
> >
> > How about moving code into functions so that it isn't duplicated for
> > each PCI device. See the patch below as an example (100% untested).
Hmm, I sent patches that did a similar thing but
in a slightly more compact way.
Message ids:
20110919092932.GB4501(a)redhat.com
20110919093644.GC4501(a)redhat.com
20110919100434.GA6764(a)redhat.com
Did they not reach you or something's wrong with them?
>
> Tested, it works as my original patch-v2.
>
> > The CPU hotplug stuff works this way, except it run-time generates
> > the
> > equivalent of "Device(S???)" and "PCNT". (It may make sense to
> > run-time generate the PCI hotplug as well - it consumes about 10K of
> > space to statically generate the 31 devices.)
>
> I'm ok with the new version.
>
> Acked-by: Amos Kong <akong(a)redhat.com>
>
> > -Kevin
> >
> >
> > diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> > index 08412e2..31ac5eb 100644
> > --- a/src/acpi-dsdt.dsl
> > +++ b/src/acpi-dsdt.dsl
> > @@ -128,48 +128,6 @@ DefinitionBlock (
> > PCRM, 32,
> > }
> >
> > -#define hotplug_slot(name, nr) \
> > - Device (S##name) { \
> > - Name (_ADR, nr##0000) \
> > - Method (_EJ0,1) { \
> > - Store(ShiftLeft(1, nr), B0EJ) \
> > - Return (0x0) \
> > - } \
> > - Name (_SUN, name) \
> > - }
> > -
> > - hotplug_slot(1, 0x0001)
> > - hotplug_slot(2, 0x0002)
> > - hotplug_slot(3, 0x0003)
> > - hotplug_slot(4, 0x0004)
> > - hotplug_slot(5, 0x0005)
> > - hotplug_slot(6, 0x0006)
> > - hotplug_slot(7, 0x0007)
> > - hotplug_slot(8, 0x0008)
> > - hotplug_slot(9, 0x0009)
> > - hotplug_slot(10, 0x000a)
> > - hotplug_slot(11, 0x000b)
> > - hotplug_slot(12, 0x000c)
> > - hotplug_slot(13, 0x000d)
> > - hotplug_slot(14, 0x000e)
> > - hotplug_slot(15, 0x000f)
> > - hotplug_slot(16, 0x0010)
> > - hotplug_slot(17, 0x0011)
> > - hotplug_slot(18, 0x0012)
> > - hotplug_slot(19, 0x0013)
> > - hotplug_slot(20, 0x0014)
> > - hotplug_slot(21, 0x0015)
> > - hotplug_slot(22, 0x0016)
> > - hotplug_slot(23, 0x0017)
> > - hotplug_slot(24, 0x0018)
> > - hotplug_slot(25, 0x0019)
> > - hotplug_slot(26, 0x001a)
> > - hotplug_slot(27, 0x001b)
> > - hotplug_slot(28, 0x001c)
> > - hotplug_slot(29, 0x001d)
> > - hotplug_slot(30, 0x001e)
> > - hotplug_slot(31, 0x001f)
> > -
> > Name (_CRS, ResourceTemplate ()
> > {
> > WordBusNumber (ResourceProducer, MinFixed, MaxFixed,
> > PosDecode,
> > @@ -762,6 +720,119 @@ DefinitionBlock (
> > Zero /* reserved */
> > })
> >
> > + /* PCI hotplug */
> > + Scope(\_SB.PCI0) {
> > + /* Methods called by bulk generated PCI devices below */
> > + Method (PCEJ, 1, NotSerialized) {
> > + // _EJ0 method - eject callback
> > + Store(ShiftLeft(1, Arg0), B0EJ)
> > + Return (0x0)
> > + }
> > +
> > + /* Bulk generated PCI hotplug devices */
> > +#define hotplug_func(nr, fn) \
> > + Device (S##nr##fn) { \
> > + Name (_ADR, 0x##nr##000##fn) \
> > + Method (_EJ0, 1) { Return(PCEJ(0x##nr)) } \
> > + Name (_SUN, 0x##nr) \
> > + }
The fundamental question is still why would
we have _EJ0 methods in functions >0 when they are
not individually hotpluggable.
I think only function 0 should have _EJ0.
> > +
> > +#define hotplug_slot(nr) \
> > + hotplug_func(nr, 0) \
> > + hotplug_func(nr, 1) \
> > + hotplug_func(nr, 2) \
> > + hotplug_func(nr, 3) \
> > + hotplug_func(nr, 4) \
> > + hotplug_func(nr, 5) \
> > + hotplug_func(nr, 6) \
> > + hotplug_func(nr, 7)
> > +
> > + hotplug_slot(01)
> > + hotplug_slot(02)
> > + hotplug_slot(03)
> > + hotplug_slot(04)
> > + hotplug_slot(05)
> > + hotplug_slot(06)
> > + hotplug_slot(07)
> > + hotplug_slot(08)
> > + hotplug_slot(09)
> > + hotplug_slot(0a)
> > + hotplug_slot(0b)
> > + hotplug_slot(0c)
> > + hotplug_slot(0d)
> > + hotplug_slot(0e)
> > + hotplug_slot(0f)
> > + hotplug_slot(10)
> > + hotplug_slot(11)
> > + hotplug_slot(12)
> > + hotplug_slot(13)
> > + hotplug_slot(14)
> > + hotplug_slot(15)
> > + hotplug_slot(16)
> > + hotplug_slot(17)
> > + hotplug_slot(18)
> > + hotplug_slot(19)
> > + hotplug_slot(1a)
> > + hotplug_slot(1b)
> > + hotplug_slot(1c)
> > + hotplug_slot(1d)
> > + hotplug_slot(1e)
> > + hotplug_slot(1f)
> > +
> > + /* PCI hotplug notify method */
> > + Method(PCNF, 0) {
> > + // Local0 = iterator
> > + Store (Zero, Local0)
> > + While (LLess(Local0, 31)) {
> > + Increment(Local0)
> > + If (And(PCIU, ShiftLeft(1, Local0))) {
> > + PCNT(Local0, 1)
> > + }
> > + If (And(PCID, ShiftLeft(1, Local0))) {
> > + PCNT(Local0, 3)
> > + }
> > + }
> > + Return(One)
> > + }
> > +
> > +#define hotplug_notify(nr) \
> > + If (LEqual(Arg0, 0x##nr)) {Notify(S##nr##0, Arg1)}
> > +
> > + Method(PCNT, 2) {
> > + hotplug_notify(01)
> > + hotplug_notify(02)
> > + hotplug_notify(03)
> > + hotplug_notify(04)
> > + hotplug_notify(05)
> > + hotplug_notify(06)
> > + hotplug_notify(07)
> > + hotplug_notify(08)
> > + hotplug_notify(09)
> > + hotplug_notify(0a)
> > + hotplug_notify(0b)
> > + hotplug_notify(0c)
> > + hotplug_notify(0d)
> > + hotplug_notify(0e)
> > + hotplug_notify(0f)
> > + hotplug_notify(10)
> > + hotplug_notify(11)
> > + hotplug_notify(12)
> > + hotplug_notify(13)
> > + hotplug_notify(14)
> > + hotplug_notify(15)
> > + hotplug_notify(16)
> > + hotplug_notify(17)
> > + hotplug_notify(18)
> > + hotplug_notify(19)
> > + hotplug_notify(1a)
> > + hotplug_notify(1b)
> > + hotplug_notify(1c)
> > + hotplug_notify(1d)
> > + hotplug_notify(1e)
> > + hotplug_notify(1f)
> > + }
> > + }
> > +
> > /* CPU hotplug */
> > Scope(\_SB) {
> > /* Objects filled in by run-time generated SSDT */
> > @@ -842,49 +913,9 @@ DefinitionBlock (
> > Return(0x01)
> > }
> >
> > -#define gen_pci_hotplug(nr) \
> > - If (And(\_SB.PCI0.PCIU, ShiftLeft(1, nr))) { \
> > - Notify(\_SB.PCI0.S##nr, 1) \
> > - } \
> > - If (And(\_SB.PCI0.PCID, ShiftLeft(1, nr))) { \
> > - Notify(\_SB.PCI0.S##nr, 3) \
> > - }
> > -
> > Method(_L01) {
> > - gen_pci_hotplug(1)
> > - gen_pci_hotplug(2)
> > - gen_pci_hotplug(3)
> > - gen_pci_hotplug(4)
> > - gen_pci_hotplug(5)
> > - gen_pci_hotplug(6)
> > - gen_pci_hotplug(7)
> > - gen_pci_hotplug(8)
> > - gen_pci_hotplug(9)
> > - gen_pci_hotplug(10)
> > - gen_pci_hotplug(11)
> > - gen_pci_hotplug(12)
> > - gen_pci_hotplug(13)
> > - gen_pci_hotplug(14)
> > - gen_pci_hotplug(15)
> > - gen_pci_hotplug(16)
> > - gen_pci_hotplug(17)
> > - gen_pci_hotplug(18)
> > - gen_pci_hotplug(19)
> > - gen_pci_hotplug(20)
> > - gen_pci_hotplug(21)
> > - gen_pci_hotplug(22)
> > - gen_pci_hotplug(23)
> > - gen_pci_hotplug(24)
> > - gen_pci_hotplug(25)
> > - gen_pci_hotplug(26)
> > - gen_pci_hotplug(27)
> > - gen_pci_hotplug(28)
> > - gen_pci_hotplug(29)
> > - gen_pci_hotplug(30)
> > - gen_pci_hotplug(31)
> > -
> > - Return (0x01)
> > -
> > + // PCI hotplug event
> > + Return(\_SB.PCI0.PCNF())
> > }
> > Method(_L02) {
> > // CPU hotplug event
> >
7 years, 5 months
[PATCH] Probe PCI existence
by Jan Kiszka
From: Jan Kiszka <jan.kiszka(a)siemens.com>
This prevents lockups when trying to allocate PCI resources on an
ISA-only system like QEMU can emulate.
Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
---
src/pci.c | 14 +++++++++++++-
src/pci.h | 3 ++-
src/pciinit.c | 7 +++++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/pci.c b/src/pci.c
index 49698ac..6031c9f 100644
--- a/src/pci.c
+++ b/src/pci.c
@@ -88,9 +88,21 @@ pci_next(int bdf, int bus)
struct pci_device *PCIDevices;
int MaxPCIBus VAR16VISIBLE;
+// Check if PCI is available at all
+int
+pci_probe_host(void)
+{
+ outl(0x80000000, PORT_PCI_CMD);
+ if (inl(PORT_PCI_CMD) != 0x80000000) {
+ dprintf(1, "Detected non-PCI system\n");
+ return -1;
+ }
+ return 0;
+}
+
// Find all PCI devices and populate PCIDevices linked list.
void
-pci_probe(void)
+pci_probe_devices(void)
{
dprintf(3, "PCI probe\n");
struct pci_device *busdevs[256];
diff --git a/src/pci.h b/src/pci.h
index 3e28af2..a2a5a4c 100644
--- a/src/pci.h
+++ b/src/pci.h
@@ -62,7 +62,8 @@ struct pci_device {
};
extern struct pci_device *PCIDevices;
extern int MaxPCIBus;
-void pci_probe(void);
+int pci_probe_host(void);
+void pci_probe_devices(void);
static inline u32 pci_classprog(struct pci_device *pci) {
return (pci->class << 8) | pci->prog_if;
}
diff --git a/src/pciinit.c b/src/pciinit.c
index 597c8ea..a857da0 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -577,7 +577,7 @@ pci_setup(void)
{
if (CONFIG_COREBOOT || usingXen()) {
// PCI setup already done by coreboot or Xen - just do probe.
- pci_probe();
+ pci_probe_devices();
return;
}
@@ -587,10 +587,13 @@ pci_setup(void)
u32 end = BUILD_PCIMEM_END;
dprintf(1, "=== PCI bus & bridge init ===\n");
+ if (pci_probe_host() != 0) {
+ return;
+ }
pci_bios_init_bus();
dprintf(1, "=== PCI device probing ===\n");
- pci_probe();
+ pci_probe_devices();
dprintf(1, "=== PCI new allocation pass #1 ===\n");
busses = malloc_tmp(sizeof(*busses) * busses_count);
--
1.7.3.4
7 years, 7 months
[PATCH] acpi: add Local APIC NMI Structure to MADT.
by Kenji Kaneshige
Add Local APIC NMI Structure to ACPI MADT.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji(a)jp.fujitsu.com>
---
src/acpi.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
Index: seabios/src/acpi.c
===================================================================
--- seabios.orig/src/acpi.c
+++ seabios/src/acpi.c
@@ -134,6 +134,14 @@ struct madt_intsrcovr {
u16 flags;
} PACKED;
+struct madt_local_nmi {
+ ACPI_SUB_HEADER_DEF
+ u8 processor_id; /* ACPI processor id */
+ u16 flags; /* MPS INTI flags */
+ u8 lint; /* Local APIC LINT# */
+} PACKED;
+
+
/*
* ACPI 2.0 Generic Address Space definition.
*/
@@ -288,7 +296,9 @@ build_madt(void)
int madt_size = (sizeof(struct multiple_apic_table)
+ sizeof(struct madt_processor_apic) * MaxCountCPUs
+ sizeof(struct madt_io_apic)
- + sizeof(struct madt_intsrcovr) * 16);
+ + sizeof(struct madt_intsrcovr) * 16
+ + sizeof(struct madt_local_nmi) * MaxCountCPUs);
+
struct multiple_apic_table *madt = malloc_high(madt_size);
if (!madt) {
warn_noalloc();
@@ -340,7 +350,17 @@ build_madt(void)
intsrcovr++;
}
- build_header((void*)madt, APIC_SIGNATURE, (void*)intsrcovr - (void*)madt, 1);
+ struct madt_local_nmi *local_nmi = (void*)intsrcovr;
+ for (i = 0; i < MaxCountCPUs; i++) {
+ local_nmi->type = APIC_LOCAL_NMI;
+ local_nmi->length = sizeof(*local_nmi);
+ local_nmi->processor_id = i;
+ local_nmi->flags = 0;
+ local_nmi->lint = 1; /* LINT1 */
+ local_nmi++;
+ }
+
+ build_header((void*)madt, APIC_SIGNATURE, (void*)local_nmi - (void*)madt, 1);
return madt;
}
7 years, 7 months
Next version
by Kevin O'Connor
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
7 years, 7 months
Re: [SeaBIOS] Boot ordering problem with qemu-kvm / seabios / gPXE
by Gleb Natapov
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.
7 years, 7 months
Re: [SeaBIOS] Boot ordering problem with qemu-kvm / seabios / gPXE
by Gleb Natapov
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.
7 years, 7 months
Boot ordering problem with qemu-kvm / seabios / gPXE
by Romain Vrignaud
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
7 years, 7 months
Re: [SeaBIOS] seabios: About the reset mem address
by Peter Stuge
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
7 years, 7 months
Re: [SeaBIOS] seabios: About the reset mem address
by Kevin O'Connor
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
7 years, 7 months
seabios: About the reset mem address
by Amos Kong
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...
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
7 years, 7 months