Re: [SeaBIOS] (no subject)
Hi, >>> +*(addr->pcimem_start) = s; >>> +*(addr->pcimem_end) = e; >>> +} >> >> This must be adapted too to not hard-code things. >> > > Is it reasonable to pull these out of the dsdt acpi table? It's a solved problem ;) acpi.c builds a ssdt BDAT entry, then places the pcimem addresses there. The DSDT table has AML code to pick up the values and stick them into a RessourceTemplate, so the guest OS can see it just fine (you'll see it show up in /proc/iomem in linux guests). You can basically just copy \_SB.PCI0._CRS logic from the piix dtst. Maybe it is a good idea to separate out common stuff into a include file while being at it. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Fri, Sep 14, 2012 at 10:08:19AM +0200, Gerd Hoffmann wrote: > On 09/13/12 22:12, Jason Baron wrote: > > jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de, > > yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de, > > arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com > > Message-Id: > > <491ff0e77a2359c098540aa24fbbfeec573bea91.1347565443.git.jba...@redhat.com> > > In-Reply-To: > > References: > > Subject: [PATCH 9/9] seabios: q35: add basic hotplug support > > > > Add support for acpi hotplug to q35. Copied from the piix acpi table. > > Do we really wanna bring that in? > > q35 has pcie slots which are hot-pluggable. > > qemu also has a pci-pci bridge which supports hotplug for all devices > behind it. > > It's not like we can't hotplug pci devices at all like it used to be > back in the days when acpi hotplug was added to piix4. > > cheers, > Gerd > So I was trying to get q35 to be on feature parity with piix, with the least amount of work :) I'm not sure how hard pcie hotplug would be to implement, Michael, do you have any idea? Thanks, -Jason ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Fri, Sep 14, 2012 at 09:52:24AM +0200, Gerd Hoffmann wrote:
> On 09/13/12 22:12, Jason Baron wrote:
> > +void mch_mem_addr_init(struct pci_device *dev, void *arg)
> > +{
> > +struct pci_mem_addr *addr = arg;
> > +u64 s, e;
> > +
> > +#if BUILD_MAX_HIGHMEM != 0xe000
> > +# error "please adjust memory mapping area"
> > +#endif
> > +
> > +/*
> > + * BUILD_MAX_HIGHMEM == 0xe000
> > + * [0xe000 , 0xf000 ) for MCFG
> > + * 4GB - 512MB, 4GB - 256MB
> > + * [0xf000 , 0xfec0 ) for DMI interface(subtractive decode)
> > + * 4GB - 256MB, 4GB - 20MB
> > + */
> > +s = BUILD_MAX_HIGHMEM + 256 * 1024 * 1024;
> > +e = s + 128 * 1024 * 1024 - 1;
> > +*(addr->pcimem_start) = s;
> > +*(addr->pcimem_end) = e;
> > +}
>
> This must be adapted too to not hard-code things.
>
Is it reasonable to pull these out of the dsdt acpi table?
Thanks,
-Jason
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Fri, Sep 14, 2012 at 10:00:46AM +0200, Gerd Hoffmann wrote: > Guess we want CONFIG_QEMU_PIIX and CONFIG_QEMU_Q35 to build the two bios > variants[1]. Or include both acpi tables, then select at runtime. I think two binaries is better to save on memory. -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On 09/13/12 22:12, Jason Baron wrote: > jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de, > yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de, > arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com > Message-Id: > <491ff0e77a2359c098540aa24fbbfeec573bea91.1347565443.git.jba...@redhat.com> > In-Reply-To: > References: > Subject: [PATCH 9/9] seabios: q35: add basic hotplug support > > Add support for acpi hotplug to q35. Copied from the piix acpi table. Do we really wanna bring that in? q35 has pcie slots which are hot-pluggable. qemu also has a pci-pci bridge which supports hotplug for all devices behind it. It's not like we can't hotplug pci devices at all like it used to be back in the days when acpi hotplug was added to piix4. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On 09/13/12 22:12, Jason Baron wrote: > add dsdt for q35 chipset of qemu. Not used anywhere. We probaby want build it into the seabios binary so we don't depend on qemu passing it to us. Or we just make qemu pass the dsdt to seabios unconditionally. Not sure if that is possible given the dsdt patching we do. Guess we want CONFIG_QEMU_PIIX and CONFIG_QEMU_Q35 to build the two bios variants[1]. Or include both acpi tables, then select at runtime. cheers, Gerd [1] And while being at it also CONFIG_QEMU so we can replace the slightly irritating "if (!CONFIG_COREBOOT)" with "if (CONFIG_QEMU)" ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On 09/13/12 22:12, Jason Baron wrote:
> +void mch_mem_addr_init(struct pci_device *dev, void *arg)
> +{
> +struct pci_mem_addr *addr = arg;
> +u64 s, e;
> +
> +#if BUILD_MAX_HIGHMEM != 0xe000
> +# error "please adjust memory mapping area"
> +#endif
> +
> +/*
> + * BUILD_MAX_HIGHMEM == 0xe000
> + * [0xe000 , 0xf000 ) for MCFG
> + * 4GB - 512MB, 4GB - 256MB
> + * [0xf000 , 0xfec0 ) for DMI interface(subtractive decode)
> + * 4GB - 256MB, 4GB - 20MB
> + */
> +s = BUILD_MAX_HIGHMEM + 256 * 1024 * 1024;
> +e = s + 128 * 1024 * 1024 - 1;
> +*(addr->pcimem_start) = s;
> +*(addr->pcimem_end) = e;
> +}
This must be adapted too to not hard-code things.
cheers,
Gerd
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On 09/13/12 22:12, Jason Baron wrote: > jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de, > yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de, > arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com > Message-Id: > > In-Reply-To: > References: > Subject: [PATCH 2/9] seabios: pciinit: initialize pcimem_start and pcimem_end > depending on chipset. > > From: Isaku Yamahata > > initialize pcimem_start and pcimem_end based on chipset. Should not be needed. There is no hard-coded range any more. PCI address space starts above lowmem (see pcimem_start assignment in pci_bios_map_devices()). Probably the q35 dsdt table must be updated to handle this (see \_SB.PCI0._CRS). Probably you also want to grab some address space for mmconfig, i.e. place mmconfig above lowmem and set pcimem_start to the end of mmconfig space. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
In-Reply-To:
References:
Subject: [PATCH 3/9] seabios: acpi, fadt: make while fadt initialization
chipset specific
From: Isaku Yamahata
make while fadt initialization chipset specific.
Signed-off-by: Isaku Yamahata
Signed-off-by: Jason Baron
---
src/acpi.c | 34 ++
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 780c0ac..3577c70 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -234,13 +234,31 @@ build_header(struct acpi_table_header *h, u32 sig, int
len, u8 rev)
#define PIIX4_GPE0_BLK 0xafe0
#define PIIX4_GPE0_BLK_LEN 4
+#define PIIX4_PM_INTRRUPT 9 // irq 9
+
static void piix4_fadt_init(struct pci_device *pci, void *arg)
{
struct fadt_descriptor_rev1 *fadt = arg;
+
+fadt->model = 1;
+fadt->reserved1 = 0;
+fadt->sci_int = cpu_to_le16(PIIX4_PM_INTRRUPT);
+fadt->smi_cmd = cpu_to_le32(PORT_SMI_CMD);
fadt->acpi_enable = PIIX4_ACPI_ENABLE;
fadt->acpi_disable = PIIX4_ACPI_DISABLE;
+fadt->pm1a_evt_blk = cpu_to_le32(PORT_ACPI_PM_BASE);
+fadt->pm1a_cnt_blk = cpu_to_le32(PORT_ACPI_PM_BASE + 0x04);
+fadt->pm_tmr_blk = cpu_to_le32(PORT_ACPI_PM_BASE + 0x08);
fadt->gpe0_blk = cpu_to_le32(PIIX4_GPE0_BLK);
+fadt->pm1_evt_len = 4;
+fadt->pm1_cnt_len = 2;
+fadt->pm_tmr_len = 4;
fadt->gpe0_blk_len = PIIX4_GPE0_BLK_LEN;
+fadt->plvl2_lat = cpu_to_le16(0xfff); // C2 state not supported
+fadt->plvl3_lat = cpu_to_le16(0xfff); // C3 state not supported
+/* WBINVD + PROC_C1 + SLP_BUTTON + RTC_S4 + USE_PLATFORM_CLOCK */
+fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 5) | (1 << 7) |
+ (1 << 15));
}
static const struct pci_device_id fadt_init_tbl[] = {
@@ -282,23 +300,7 @@ build_fadt(struct pci_device *pci)
fadt->firmware_ctrl = cpu_to_le32((u32)facs);
fadt->dsdt = 0; /* dsdt will be filled later in acpi_bios_init()
by fill_dsdt() */
-fadt->model = 1;
-fadt->reserved1 = 0;
-int pm_sci_int = pci_config_readb(pci->bdf, PCI_INTERRUPT_LINE);
-fadt->sci_int = cpu_to_le16(pm_sci_int);
-fadt->smi_cmd = cpu_to_le32(PORT_SMI_CMD);
-fadt->pm1a_evt_blk = cpu_to_le32(PORT_ACPI_PM_BASE);
-fadt->pm1a_cnt_blk = cpu_to_le32(PORT_ACPI_PM_BASE + 0x04);
-fadt->pm_tmr_blk = cpu_to_le32(PORT_ACPI_PM_BASE + 0x08);
-fadt->pm1_evt_len = 4;
-fadt->pm1_cnt_len = 2;
-fadt->pm_tmr_len = 4;
-fadt->plvl2_lat = cpu_to_le16(0xfff); // C2 state not supported
-fadt->plvl3_lat = cpu_to_le16(0xfff); // C3 state not supported
pci_init_device(fadt_init_tbl, pci, fadt);
-/* WBINVD + PROC_C1 + SLP_BUTTON + RTC_S4 + USE_PLATFORM_CLOCK */
-fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 5) | (1 << 7) |
- (1 << 15));
build_header((void*)fadt, FACP_SIGNATURE, sizeof(*fadt), 1);
--
1.7.1
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de, yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de, arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com Message-Id: In-Reply-To: References: Subject: [PATCH 4/9] seabios: pci: enable SERR of normal device. From: Isaku Yamahata enable SERR of normal device for AER. Signed-off-by: Isaku Yamahata Signed-off-by: Jason Baron --- src/pciinit.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/pciinit.c b/src/pciinit.c index e604fd9..3b8525e 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -211,7 +211,8 @@ static void pci_bios_init_device(struct pci_device *pci) pci_init_device(pci_class_tbl, pci, NULL); /* enable memory mappings */ -pci_config_maskw(bdf, PCI_COMMAND, 0, PCI_COMMAND_IO | PCI_COMMAND_MEMORY); +pci_config_maskw(bdf, PCI_COMMAND, 0, + PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR); /* map the interrupt */ int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN); -- 1.7.1 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
<1b8c2892dae068eec68c1523151246c665a7675c.1347565443.git.jba...@redhat.com>
In-Reply-To:
References:
Subject: [PATCH 1/9] seabios: acpi: add mcfg table.
From: Isaku Yamahata
add mcfg table.
mcfg isn't populated at the moment. dev-q35 will use it later.
[jba...@redhat.com: moved header from post.h -> acpi.h]
Signed-off-by: Isaku Yamahata
Signed-off-by: Jason Baron
---
src/acpi.c | 73
src/acpi.h | 17 ++
2 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index 6d239fa..780c0ac 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -13,6 +13,7 @@
#include "pci_regs.h" // PCI_INTERRUPT_LINE
#include "ioport.h" // inl
#include "paravirt.h" // qemu_cfg_irq0_override
+#include "memmap.h"
//
/* ACPI tables init */
@@ -734,6 +735,77 @@ build_srat(void)
return srat;
}
+struct acpi_mcfg
+{
+u32 nr;
+struct acpi_table_mcfg *mcfg;
+struct e820entry *e820;
+};
+
+static const struct pci_device_id mcfg_find_tbl[] = {
+PCI_DEVICE_END,
+};
+
+static const struct pci_device_id mcfg_init_tbl[] = {
+PCI_DEVICE_END,
+};
+
+static void *
+build_mcfg(void)
+{
+struct pci_device *dev;
+int bdf;
+
+struct acpi_mcfg acpi_mcfg = {
+.nr = 0,
+.mcfg = NULL,
+.e820 = NULL,
+};
+dev = pci_find_init_device(mcfg_find_tbl, &acpi_mcfg);
+bdf = dev->bdf;
+if (bdf < 0) {
+return NULL;
+}
+if (acpi_mcfg.nr == 0) {
+return NULL;
+}
+
+struct acpi_table_mcfg *mcfg;
+int len = sizeof(*mcfg) + acpi_mcfg.nr * sizeof(mcfg->allocation[0]);
+mcfg = malloc_high(len);
+if (!mcfg) {
+dprintf(1, "Not enough memory for mcfg table!\n");
+return NULL;
+}
+memset(mcfg, 0, len);
+acpi_mcfg.mcfg = mcfg;
+
+
+struct e820entry *e820;
+int e820_len = acpi_mcfg.nr * sizeof(*e820);
+e820 = malloc_tmphigh(e820_len);
+if (!e820) {
+dprintf(1, "Not enough memory for e820 table!\n");
+free(mcfg);
+return NULL;
+}
+memset(e820, 0, e820_len);
+acpi_mcfg.e820 = e820;
+
+pci_init_device(mcfg_init_tbl, dev, &acpi_mcfg);
+
+/* Linux checks if e820 covers mcfg area as reserved.
+ * If no, Linux thinks bios is buggy and won't use MCFG */
+int i;
+for (i = 0; i < acpi_mcfg.nr; i++) {
+add_e820(e820[i].start, e820[i].size, E820_RESERVED);
+}
+free(e820);
+
+build_header((void *)mcfg, MCFG_SIGNATURE, len, 1);
+return mcfg;
+}
+
static const struct pci_device_id acpi_find_tbl[] = {
/* PIIX4 Power Management device. */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, NULL),
@@ -774,6 +846,7 @@ acpi_bios_init(void)
ACPI_INIT_TABLE(build_madt());
ACPI_INIT_TABLE(build_hpet());
ACPI_INIT_TABLE(build_srat());
+ACPI_INIT_TABLE(build_mcfg());
u16 i, external_tables = qemu_cfg_acpi_additional_tables();
diff --git a/src/acpi.h b/src/acpi.h
index cb21561..715d19d 100644
--- a/src/acpi.h
+++ b/src/acpi.h
@@ -107,4 +107,21 @@ struct bfld {
u64 p1l; /* pci window 1 (above 4g) - length */
} PACKED;
+/* PCI fw r3.0 MCFG table. */
+/* Subtable */
+struct acpi_mcfg_allocation {
+u64 address;/* Base address, processor-relative */
+u16 pci_segment;/* PCI segment group number */
+u8 start_bus_number; /* Starting PCI Bus number */
+u8 end_bus_number; /* Final PCI Bus number */
+u32 reserved;
+} PACKED;
+
+#define MCFG_SIGNATURE 0x4746434d // MCFG
+struct acpi_table_mcfg {
+ACPI_TABLE_HEADER_DEF;
+u8 reserved[8];
+struct acpi_mcfg_allocation allocation[0];
+} PACKED;
+
#endif // acpi.h
--
1.7.1
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
In-Reply-To:
References:
Subject: [PATCH 7/9] seabios: q35: Register PCI IRQs as active high in APIC mode
From: Jan Kiszka
Allows windows to work.
Signed-off-by: Jan Kiszka
Signed-off-by: Jason Baron
---
src/q35-acpi-dsdt.dsl | 46 +-
1 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/src/q35-acpi-dsdt.dsl b/src/q35-acpi-dsdt.dsl
index 0f9c4cb..8a4ebcf 100644
--- a/src/q35-acpi-dsdt.dsl
+++ b/src/q35-acpi-dsdt.dsl
@@ -161,19 +161,10 @@ DefinitionBlock (
#define prt_slot_lnkH(nr) prt_slot_lnk(nr, LNKH, LNKE, LNKF, LNKG)
#define prt_slot_gsi(nr, gsi0, gsi1, gsi2, gsi3) \
- Package() { nr##, 0, 0, gsi0 }, \
- Package() { nr##, 1, 0, gsi1 }, \
- Package() { nr##, 2, 0, gsi2 }, \
- Package() { nr##, 3, 0, gsi3 }
-
-#define GSIA0x10
-#define GSIB0x11
-#define GSIC0x12
-#define GSID0x13
-#define GSIE0x14
-#define GSIF0x15
-#define GSIG0x16
-#define GSIH0x17
+ Package() { nr##, 0, gsi0, 0 }, \
+ Package() { nr##, 1, gsi1, 0 }, \
+ Package() { nr##, 2, gsi2, 0 }, \
+ Package() { nr##, 3, gsi3, 0 }
#define prt_slot_gsiA(nr) prt_slot_gsi(nr, GSIA, GSIB, GSIC, GSID)
#define prt_slot_gsiB(nr) prt_slot_gsi(nr, GSIB, GSIC, GSID, GSIA)
@@ -718,6 +709,35 @@ DefinitionBlock (
define_link(LNKF, 5, \_SB.PCI0.LPC.PRQF)
define_link(LNKG, 6, \_SB.PCI0.LPC.PRQG)
define_link(LNKH, 7, \_SB.PCI0.LPC.PRQH)
+
+#define define_gsi_link(link, uid, gsi) \
+Device(link){ \
+Name(_HID, EISAID("PNP0C0F")) \
+Name(_UID, uid) \
+Name(_PRS, ResourceTemplate() { \
+Interrupt (, Level, ActiveHigh, \
+ Shared) \
+{ gsi } \
+}) \
+Method (_CRS, 0, NotSerialized) \
+{ \
+Return (ResourceTemplate () { \
+Interrupt (, Level, ActiveHigh, \
+ Shared) \
+ { gsi }\
+}) \
+} \
+Method (_SRS, 1, NotSerialized) { } \
+} \
+
+define_gsi_link(GSIA, 0, 0x10)
+define_gsi_link(GSIB, 0, 0x11)
+define_gsi_link(GSIC, 0, 0x12)
+define_gsi_link(GSID, 0, 0x13)
+define_gsi_link(GSIE, 0, 0x14)
+define_gsi_link(GSIF, 0, 0x15)
+define_gsi_link(GSIG, 0, 0x16)
+define_gsi_link(GSIH, 0, 0x17)
}
/*
--
1.7.1
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
<2e91e45f5e8650cc8eb3a021626e9a20f82df908.1347565443.git.jba...@redhat.com>
In-Reply-To:
References:
Subject: [PATCH 6/9] seabios: q35: add dsdt
From: Isaku Yamahata
add dsdt for q35 chipset of qemu.
Cc: Matthew Garrett
Signed-off-by: Isaku Yamahata
Signed-off-by: Jason Baron
---
Makefile |2 +-
src/q35-acpi-dsdt.dsl | 875 +
2 files changed, 876 insertions(+), 1 deletions(-)
create mode 100644 src/q35-acpi-dsdt.dsl
diff --git a/Makefile b/Makefile
index 5486f88..79abab6 100644
--- a/Makefile
+++ b/Makefile
@@ -233,7 +233,7 @@ $(OUT)%.hex: src/%.dsl ./tools/acpi_extract_preprocess.py
./tools/acpi_extract.p
$(Q)$(PYTHON) ./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off
$(Q)cat $(OUT)$*.off > $@
-$(OUT)ccode32flat.o: $(OUT)acpi-dsdt.hex $(OUT)ssdt-proc.hex
$(OUT)ssdt-pcihp.hex $(OUT)ssdt-susp.hex
+$(OUT)ccode32flat.o: $(OUT)acpi-dsdt.hex $(OUT)ssdt-proc.hex
$(OUT)ssdt-pcihp.hex $(OUT)ssdt-susp.hex $(OUT)q35-acpi-dsdt.hex
Kconfig rules
diff --git a/src/q35-acpi-dsdt.dsl b/src/q35-acpi-dsdt.dsl
new file mode 100644
index 000..0f9c4cb
--- /dev/null
+++ b/src/q35-acpi-dsdt.dsl
@@ -0,0 +1,875 @@
+/*
+ * Bochs/QEMU ACPI DSDT ASL definition
+ *
+ * Copyright (c) 2006 Fabrice Bellard
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License version 2 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+/*
+ * Copyright (c) 2010 Isaku Yamahata
+ *yamahata at valinux co jp
+ * Based on acpi-dsdt.dsl, but heavily modified for q35 chipset.
+ */
+
+DefinitionBlock (
+"q35-acpi-dsdt.aml",// Output Filename
+"DSDT", // Signature
+0x01, // DSDT Compliance Revision
+"BXPC", // OEMID
+"BXDSDT", // TABLE ID
+0x2 // OEM Revision
+)
+{
+Scope (\)
+{
+/* Debug Output */
+OperationRegion (DBG, SystemIO, 0x0402, 0x01)
+Field (DBG, ByteAcc, NoLock, Preserve)
+{
+DBGB, 8,
+}
+
+/* Debug method - use this method to send output to the QEMU
+ * BIOS debug port. This method handles strings, integers,
+ * and buffers. For example: DBUG("abc") DBUG(0x123) */
+Method(DBUG, 1) {
+ToHexString(Arg0, Local0)
+ToBuffer(Local0, Local0)
+Subtract(SizeOf(Local0), 1, Local1)
+Store(Zero, Local2)
+While (LLess(Local2, Local1)) {
+Store(DerefOf(Index(Local0, Local2)), DBGB)
+Increment(Local2)
+}
+Store(0x0A, DBGB)
+}
+}
+
+
+Scope (\_SB)
+{
+OperationRegion(PCST, SystemIO, 0xae00, 0x0c)
+OperationRegion(PCSB, SystemIO, 0xae0c, 0x01)
+Field (PCSB, AnyAcc, NoLock, WriteAsZeros)
+{
+PCIB, 8,
+}
+}
+
+/* Zero => PIC mode, One => APIC Mode */
+Name (\PICF, Zero)
+Method (\_PIC, 1, NotSerialized)
+{
+Store (Arg0, \PICF)
+}
+
+/* PCI Bus definition */
+Scope(\_SB) {
+
+Device(PCI0) {
+Name (_HID, EisaId ("PNP0A08"))
+Name (_CID, EisaId ("PNP0A03"))
+Name (_ADR, 0x00)
+Name (_UID, 1)
+
+// _OSC: based on sample of ACPI3.0b spec
+Name(SUPP,0) // PCI _OSC Support Field value
+Name(CTRL,0) // PCI _OSC Control Field value
+Method(_OSC,4)
+{
+// Create DWORD-addressable fields from the Capabilities Buffer
+CreateDWordField(Arg3,0,CDW1)
+
+// Check for proper UUID
+If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766")))
+{
+// Create DWORD-addressable fields from the Capabilities
Buffer
+CreateDWordField(Arg3,4,CDW2)
+CreateDWordField(Arg3,8,CDW3)
+
+// Save Capabilities DWORD2 & 3
+Store(CDW2,SUPP)
+Store(CDW3,CTRL)
+
+// Always allow native PME, AER (no dependencies)
+// Never allow SHPC (n
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
<4177a0d7afe06338939d3d7a720492a591c48c97.1347565443.git.jba...@redhat.com>
In-Reply-To:
References:
Subject: [PATCH 8/9] seabios: remove acpi suspend blocks from the q35 dsdt table
Since suspend is now broken out separately as ssdt-susp.dsl, we
need to drop it from the q35 dsdt.
Signed-off-by: Jason Baron
---
src/q35-acpi-dsdt.dsl | 26 --
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/src/q35-acpi-dsdt.dsl b/src/q35-acpi-dsdt.dsl
index 8a4ebcf..3180624 100644
--- a/src/q35-acpi-dsdt.dsl
+++ b/src/q35-acpi-dsdt.dsl
@@ -740,32 +740,6 @@ DefinitionBlock (
define_gsi_link(GSIH, 0, 0x17)
}
-/*
- * S3 (suspend-to-ram), S4 (suspend-to-disk) and S5 (power-off) type codes:
- * must match piix4 emulation.
- */
-Name (\_S3, Package (0x04)
-{
-0x01, /* PM1a_CNT.SLP_TYP */
-0x01, /* PM1b_CNT.SLP_TYP */
-Zero, /* reserved */
-Zero /* reserved */
-})
-Name (\_S4, Package (0x04)
-{
-Zero, /* PM1a_CNT.SLP_TYP */
-Zero, /* PM1b_CNT.SLP_TYP */
-Zero, /* reserved */
-Zero /* reserved */
-})
-Name (\_S5, Package (0x04)
-{
-Zero, /* PM1a_CNT.SLP_TYP */
-Zero, /* PM1b_CNT.SLP_TYP */
-Zero, /* reserved */
-Zero /* reserved */
-})
-
/* CPU hotplug */
Scope(\_SB) {
/* Objects filled in by run-time generated SSDT */
--
1.7.1
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
<3552c1f47b1af1abef3e4806935f19babab0ac7c.1347565443.git.jba...@redhat.com>
In-Reply-To:
References:
Subject: [PATCH 5/9] seabios: add q35 initialization functions.
From: Isaku Yamahata
add q35 initialization functions.
[jba...@redhat.com: restructured to current seabios base]
Signed-off-by: Isaku Yamahata
Signed-off-by: Jason Baron
---
src/acpi.c| 69 +++-
src/dev-q35.h | 46 +
src/pciinit.c | 89 -
src/shadow.c | 13
src/smm.c | 37 +++
5 files changed, 251 insertions(+), 3 deletions(-)
create mode 100644 src/dev-q35.h
diff --git a/src/acpi.c b/src/acpi.c
index 3577c70..6cf345a 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -14,6 +14,7 @@
#include "ioport.h" // inl
#include "paravirt.h" // qemu_cfg_irq0_override
#include "memmap.h"
+#include "dev-q35.h"
//
/* ACPI tables init */
@@ -261,11 +262,37 @@ static void piix4_fadt_init(struct pci_device *pci, void
*arg)
(1 << 15));
}
+/* PCI_VENDOR_ID_INTEL && PCI_DEVICE_ID_INTEL_ICH9_LPC */
+void ich9_lpc_fadt_init(struct pci_device *dev, void *arg)
+{
+struct fadt_descriptor_rev1 *fadt = arg;
+
+fadt->model = 1;
+fadt->reserved1 = 0;
+fadt->sci_int = cpu_to_le16(9);
+fadt->smi_cmd = cpu_to_le32(PORT_SMI_CMD);
+fadt->acpi_enable = ICH9_ACPI_ENABLE;
+fadt->acpi_disable = ICH9_ACPI_DISABLE;
+fadt->pm1a_evt_blk = cpu_to_le32(PORT_ACPI_PM_BASE);
+fadt->pm1a_cnt_blk = cpu_to_le32(PORT_ACPI_PM_BASE + 0x04);
+fadt->pm_tmr_blk = cpu_to_le32(PORT_ACPI_PM_BASE + 0x08);
+fadt->gpe0_blk = cpu_to_le32(PORT_ACPI_PM_BASE + ICH9_PMIO_GPE0_STS);
+fadt->pm1_evt_len = 4;
+fadt->pm1_cnt_len = 2;
+fadt->pm_tmr_len = 4;
+fadt->gpe0_blk_len = ICH9_PMIO_GPE0_BLK_LEN;
+fadt->plvl2_lat = cpu_to_le16(0xfff); // C2 state not supported
+fadt->plvl3_lat = cpu_to_le16(0xfff); // C3 state not supported
+/* WBINVD + PROC_C1 + SLP_BUTTON + FIX_RTC + RTC_S4 */
+fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 5) | (1 << 6) | (1
<< 7));
+}
+
static const struct pci_device_id fadt_init_tbl[] = {
/* PIIX4 Power Management device (for ACPI) */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3,
piix4_fadt_init),
-
+PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_LPC,
+ ich9_lpc_fadt_init),
PCI_DEVICE_END
};
@@ -744,11 +771,49 @@ struct acpi_mcfg
struct e820entry *e820;
};
+/* PCI_VENDOR_ID_INTEL && DEVICE_ID_INTEL_Q35_MCH */
+void mch_mcfg_find(struct pci_device *dev, void *arg)
+{
+struct acpi_mcfg *mcfg = arg;
+
+mcfg->nr = 1;
+}
+
+/* PCI_VENDOR_ID_INTEL && DEVICE_ID_INTEL_Q35_MCH */
+void mch_mcfg_init(struct pci_device *dev, void *arg)
+{
+u16 bdf = dev->bdf;
+
+u64 addr = Q35_HOST_BRIDGE_PCIEXBAR_ADDR | Q35_HOST_BRIDGE_PCIEXBAREN;
+u32 upper = addr >> 32;
+u32 lower = addr & 0x;
+
+/* at first disable the region. and then update/enable it. */
+pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, 0);
+pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR + 4, upper);
+pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, lower);
+
+struct acpi_mcfg *mcfg = arg;
+struct acpi_mcfg_allocation *alloc = &mcfg->mcfg->allocation[0];
+alloc->address = Q35_HOST_BRIDGE_PCIEXBAR_ADDR;
+alloc->pci_segment = Q35_HOST_PCIE_PCI_SEGMENT;
+alloc->start_bus_number = Q35_HOST_PCIE_START_BUS_NUMBER;
+alloc->end_bus_number = Q35_HOST_PCIE_END_BUS_NUMBER;
+
+mcfg->e820->start = Q35_HOST_BRIDGE_PCIEXBAR_ADDR;
+mcfg->e820->size = Q35_HOST_BRIDGE_PCIEXBAR_SIZE;
+mcfg->e820->type = E820_RESERVED;
+}
+
static const struct pci_device_id mcfg_find_tbl[] = {
+PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
+ mch_mcfg_find),
PCI_DEVICE_END,
};
static const struct pci_device_id mcfg_init_tbl[] = {
+PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
+ mch_mcfg_init),
PCI_DEVICE_END,
};
@@ -811,7 +876,7 @@ build_mcfg(void)
static const struct pci_device_id acpi_find_tbl[] = {
/* PIIX4 Power Management device. */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, NULL),
-
+PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_LPC, NULL),
PCI_DEVICE_END,
};
diff --git a/src/dev-q35.h b/src/dev-q35.h
new file mode 100644
index 000..91310b5
--- /dev/null
+++ b/src/dev-q35.h
@@ -0,0 +1,46 @@
+#ifndef __DEV_Q35_H
+#define __DEV_Q35_H
+
+#include "types.h" // u16
+
+#define PCI_DEVICE_ID_INTEL_Q35_MCH 0x29c0
+
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de, yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de, arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com Message-Id: Subject: [PATCH 0/9] q35 seabios support take #1 Hi, Seabios bits for q35 support, I'm posting the qemu changes separately. The patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the qemu command line. Hopefully, we can make it the default for x86 at some future point when we feel comfortable with it. Since q35 patches have been posted before I've tried to keep the authorship as clear as possible. The current patches have been tested with basic install testing and memory testing on f16, f17, windows 7 and windows 8. They can be run on the various BSD flavors by adding a 'piix4-ide' device to the pci bus. ie: -device piix4-ide. I've also added a few new features to try and get us on par with the current piix, including: 1) migration I've added support for ahci migration. I've done basic testing but this support is incomplete. We should probably be migration more state than we currently are. 2) hotplug I've added piix acpi style hotplug to ich9. I'm hoping this series will spark a discussion as to what areas I need to focus in order to make this patch series acceptable. For those interested in git trees, see: git://github.com/jibaron/q35-qemu.git git://github.com/jibaron/q35-seabios.git Thanks, -Jason Isaku Yamahata (6): seabios: acpi: add mcfg table. seabios: pciinit: initialize pcimem_start and pcimem_end depending on chipset. seabios: acpi, fadt: make while fadt initialization chipset specific seabios: pci: enable SERR of normal device. seabios: add q35 initialization functions. seabios: q35: add dsdt Jan Kiszka (1): seabios: q35: Register PCI IRQs as active high in APIC mode Jason Baron (2): seabios: remove acpi suspend blocks from the q35 dsdt table seabios: q35: add basic hotplug support Makefile |2 +- src/acpi.c| 176 +- src/acpi.h| 17 + src/dev-q35.h | 46 +++ src/pci.h |6 + src/pciinit.c | 115 ++- src/q35-acpi-dsdt.dsl | 920 + src/shadow.c | 13 + src/smm.c | 37 ++ 9 files changed, 1311 insertions(+), 21 deletions(-) create mode 100644 src/dev-q35.h create mode 100644 src/q35-acpi-dsdt.dsl ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
<491ff0e77a2359c098540aa24fbbfeec573bea91.1347565443.git.jba...@redhat.com>
In-Reply-To:
References:
Subject: [PATCH 9/9] seabios: q35: add basic hotplug support
Add support for acpi hotplug to q35. Copied from the piix acpi table.
Signed-off-by: Jason Baron
---
src/q35-acpi-dsdt.dsl | 61 +
1 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/src/q35-acpi-dsdt.dsl b/src/q35-acpi-dsdt.dsl
index 3180624..a6cca0e 100644
--- a/src/q35-acpi-dsdt.dsl
+++ b/src/q35-acpi-dsdt.dsl
@@ -83,6 +83,21 @@ DefinitionBlock (
Name (_ADR, 0x00)
Name (_UID, 1)
+
+OperationRegion(PCST, SystemIO, 0xae00, 0x08)
+Field (PCST, DWordAcc, NoLock, WriteAsZeros)
+{
+PCIU, 32,
+PCID, 32,
+}
+
+OperationRegion(SEJ, SystemIO, 0xae08, 0x04)
+Field (SEJ, DWordAcc, NoLock, WriteAsZeros)
+{
+B0EJ, 32,
+}
+
+
// _OSC: based on sample of ACPI3.0b spec
Name(SUPP,0) // PCI _OSC Support Field value
Name(CTRL,0) // PCI _OSC Control Field value
@@ -812,6 +827,41 @@ DefinitionBlock (
}
}
+/
+ * PCI hotplug
+ /
+
+Scope(\_SB.PCI0) {
+/* Methods called by bulk generated PCI devices below */
+
+/* Methods called by hotplug devices */
+Method (PCEJ, 1, NotSerialized) {
+// _EJ0 method - eject callback
+Store(ShiftLeft(1, Arg0), B0EJ)
+Return (0x0)
+}
+
+/* Hotplug notification method supplied by SSDT */
+External (\_SB.PCI0.PCNT, MethodObj)
+
+/* 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)
+}
+
+}
+
Scope (\_GPE)
{
Name(_HID, "ACPI0006")
@@ -819,12 +869,13 @@ DefinitionBlock (
Method(_L00) {
Return(0x01)
}
-Method(_L01) {
- // CPU hotplug event
-Return(\_SB.PRSC())
+Method(_E01) {
+// PCI hotplug event
+Return(\_SB.PCI0.PCNF())
}
-Method(_L02) {
-Return(0x01)
+Method(_E02) {
+// CPU hotplug event
+Return(\_SB.PRSC())
}
Method(_L03) {
Return(0x01)
--
1.7.1
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
jan.kis...@siemens.com, juzh...@redhat.com, ag...@suse.de,
yamah...@valinux.co.jp, mklet...@redhat.com, afaer...@suse.de,
arm...@redhat.com, lcapitul...@redhat.com, alex.william...@redhat.com
Message-Id:
In-Reply-To:
References:
Subject: [PATCH 2/9] seabios: pciinit: initialize pcimem_start and pcimem_end
depending on chipset.
From: Isaku Yamahata
initialize pcimem_start and pcimem_end based on chipset.
[jba...@redhat.com: re-structured to current seabios]
Signed-off-by: Isaku Yamahata
Signed-off-by: Jason Baron
---
src/pci.h |6 ++
src/pciinit.c | 23 +++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/src/pci.h b/src/pci.h
index fe663b8..ef0c158 100644
--- a/src/pci.h
+++ b/src/pci.h
@@ -156,5 +156,11 @@ extern struct pir_header *PirAddr;
#define PIR_SIGNATURE 0x52495024 // $PIR
+struct pci_mem_addr {
+u64 *pcimem_start;
+u64 *pcimem_end;
+};
+
+
#endif
diff --git a/src/pciinit.c b/src/pciinit.c
index 68f302a..e604fd9 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -636,6 +636,22 @@ static void pci_bios_map_devices(struct pci_bus *busses)
* Main setup code
/
+
+void i440fx_mem_addr_init(struct pci_device *dev, void *arg)
+{
+struct pci_mem_addr *addr = arg;
+
+*(addr->pcimem_start) = BUILD_PCIMEM_START;
+*(addr->pcimem_end) = BUILD_PCIMEM_END;
+}
+
+
+static const struct pci_device_id pci_mem_addr_tbl[] = {
+PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82441,
+ i440fx_mem_addr_init),
+PCI_DEVICE_END,
+};
+
void
pci_setup(void)
{
@@ -653,6 +669,13 @@ pci_setup(void)
}
pci_bios_init_bus();
+struct pci_mem_addr addr = {
+.pcimem_start = &pcimem_start,
+.pcimem_end = &pcimem_end,
+};
+pci_find_init_device(pci_mem_addr_tbl, &addr);
+
+
dprintf(1, "=== PCI device probing ===\n");
pci_probe_devices();
--
1.7.1
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Tue, Dec 13, 2011 at 1:34 AM, Peter Stuge wrote: > Fred . wrote: >> A BIOS password would add an additional line of defense and protect >> against booting from a removable device such as CD or USB. > > Compile out those drivers. But those drivers and functionality are great. I would like _ME_ to be able to boot from CD and USB. I just don't want other people to be able to boot from CD and USB. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
Fred . wrote: > A BIOS password would add an additional line of defense and protect > against booting from a removable device such as CD or USB. Compile out those drivers. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
Fred . wrote: > Since we already have support for 32-bit PCI, then it would be great > if 64-bit PCI support could be added if it perhaps only require a > slight modification to the existing code. You have misunderstood. The release notes refer to 32bit PCI BIOS, in this case the CPU mode, and has nothing to do with bus width. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Mon, Dec 12, 2011 at 11:53 PM, David Hendricks wrote: > On Sun, Dec 11, 2011 at 8:47 AM, Fred . wrote: >> >> > The ability for SeaBIOS to launch a "setup program" is already present >> > - it just requires the creation of this setup program. Several >> > coreboot payloads already have some menu drawing code, so this >> > shouldn't be too difficult. Frankly though, there isn't much to >> > configure (and that is a good thing). >> > >> >> * Competition have password protection. SeaBIOS does not. >> > >> > Again - this is part of the "setup program" - there is nothing in >> > SeaBIOS to protect. >> The BIOS of the competition have two types of passwords. >> One to boot the system and one to access the setup screen. >> Password for bootup has nothing todo with the "setup program". >> Since there is currently no such setup program, the initial >> implementation for a bootup password could use a password configured >> at compile-time. > > > I think it's useful to step back and look at it in a different light. The > "competition" follows a very different usage model than coreboot and > SeaBIOS; Many commercial BIOS products are essentially OSes in themselves, > which has historically been considered a bad thing in the coreboot community > and by extension the SeaBIOS community. Much of the competition and also SeaBIOS is modular. So you can enable/disable features and modules to make it heavier/lighter depending on needs through configuration at compile-time. > From that perspective, it doesn't make much sense for SeaBIOS to have a boot > password when every modern OS has a robust authentication mechanism already. > > (you have some good ideas, but keep in mind many people simply want SeaBIOS > to do its job and get out of the way) A BIOS password would add an additional line of defense and protect against booting from a removable device such as CD or USB. An OS password would not protect against booting from removable media. Adding password support would probably be pretty trivial. > >> > >> >> * SeaBIOS supports 32-bit PCI. It should support 64-bit PCI. >> > >> > I'm not sure what you mean here. >> I've read that SeaBIOS supports 32-bit PCI. >> http://www.seabios.org/Releases#SeaBIOS_0.5.1 >> PCI also have 64-bit. >> http://en.wikipedia.org/wiki/Conventional_PCI#64-bit_PCI > > > 64-bit PCI is actually obsolete. It was used for a period in server > platforms, but has been supplanted by PCI Express. > > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. Indeed. But 32-bit PCI is also obsolete, yet it is implemented in SeaBIOS. So 64-bit PCI should be added to a not-yet-implemented list or a low-priority list and then if anyone wants to work on it, they may do so. Since we already have support for 32-bit PCI, then it would be great if 64-bit PCI support could be added if it perhaps only require a slight modification to the existing code. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Sun, Dec 11, 2011 at 8:47 AM, Fred . wrote: > > The ability for SeaBIOS to launch a "setup program" is already present > > - it just requires the creation of this setup program. Several > > coreboot payloads already have some menu drawing code, so this > > shouldn't be too difficult. Frankly though, there isn't much to > > configure (and that is a good thing). > > > >> * Competition have password protection. SeaBIOS does not. > > > > Again - this is part of the "setup program" - there is nothing in > > SeaBIOS to protect. > The BIOS of the competition have two types of passwords. > One to boot the system and one to access the setup screen. > Password for bootup has nothing todo with the "setup program". > Since there is currently no such setup program, the initial > implementation for a bootup password could use a password configured > at compile-time. > I think it's useful to step back and look at it in a different light. The "competition" follows a very different usage model than coreboot and SeaBIOS; Many commercial BIOS products are essentially OSes in themselves, which has historically been considered a bad thing in the coreboot community and by extension the SeaBIOS community. >From that perspective, it doesn't make much sense for SeaBIOS to have a boot password when every modern OS has a robust authentication mechanism already. (you have some good ideas, but keep in mind many people simply want SeaBIOS to do its job and get out of the way) > > >> * SeaBIOS supports 32-bit PCI. It should support 64-bit PCI. > > > > I'm not sure what you mean here. > I've read that SeaBIOS supports 32-bit PCI. > http://www.seabios.org/Releases#SeaBIOS_0.5.1 > PCI also have 64-bit. > http://en.wikipedia.org/wiki/Conventional_PCI#64-bit_PCI 64-bit PCI is actually obsolete. It was used for a period in server platforms, but has been supplanted by PCI Express. David Hendricks (dhendrix) Systems Software Engineer, Google Inc. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Sat, Dec 10, 2011 at 8:20 PM, Kevin O'Connor wrote: > On Sat, Dec 10, 2011 at 07:30:19PM +0100, Fred . wrote: >> Analyze of the current state and proposed future path for SeaBIOS. >> >> == Website == >> The current SeaBIOS website lacks information and is very basic. >> SeaBIOS needs a more informative website with documentation and information. > > It would be a good thing to expand the website. I've wanted to add > more technical information to the website, but I have not been able to > set aside the time to do it. If accounts were given someone else could improve it. Currently the website uses a wiki, but is not runned as a wiki, so in the long-term we might want to move to something else, such as a CMS, perhaps Drupal. What content would need to be added? * A feature page * Page with contact email for press, ISV, IHV, IBV, etc * Compile/build guide * TODO list * Guide for integration with coreboot, qemu, kvm, etc * A roadmap? What else? > >> == Logo == >> SeaBIOS have no logo. >> Award/Phoenix, AMI, Insyde, etc have a logo. >> Perhaps SeaBIOS should have a logo too? > > If someone is willing to put together a logo, I will consider using > it. I have no talent in that area myself. :-) Anyone on the mailling list have the skillset? We should put a request on the website. Perhaps put a request for voluntary contributions on some art community. Logo should be in a scaleable graphics format (such as SVG), and should look good in print. Should look good on black background (system boot) and white background (paper print). > >> == Features & Standards == >> In many aspects SeaBIOS is behind the competition. >> >> * Award/Phoenix, AMI, Inside have setup screen. SeaBIOS does not. >> SeaBIOS _needs_ a setup menu in order to win the minds of enthusiasts, >> geeks and non-embedded systems. > > This may be a semantic distinction, but I believe SeaBIOS should > launch an application for system setup and SeaBIOS should not itself > have a menu system. Yes having it as a separate application might be a good idea. At least as a separate module that can be configured whether or not it should be included in compile-time. > > The ability for SeaBIOS to launch a "setup program" is already present > - it just requires the creation of this setup program. Several > coreboot payloads already have some menu drawing code, so this > shouldn't be too difficult. Frankly though, there isn't much to > configure (and that is a good thing). > >> * Competition have password protection. SeaBIOS does not. > > Again - this is part of the "setup program" - there is nothing in > SeaBIOS to protect. The BIOS of the competition have two types of passwords. One to boot the system and one to access the setup screen. Password for bootup has nothing todo with the "setup program". Since there is currently no such setup program, the initial implementation for a bootup password could use a password configured at compile-time. > >> * SeaBIOS is behind in standards. SeaBIOS supports SMBIOS 2.4, while >> the competition is ahead, and the recent standard is SMBIOS 2.7.1. >> >> * SeaBIOS does not support ESCD. The competition supports this. > > There are a plethora of old "standards" for PC machines. Supporting > all of these "standards" would take eons and provide little > appreciable gain. The SeaBIOS approach (inherited from Bochs BIOS) is > to support those standards which common operating systems use. I > think this is the right approach. I was not aware that there is a plethora of standards for PC BIOS. Which are the most essential parts that are needed but not implemented yet? > >> * SeaBIOS does not support (GUID Partition Table) GPT. It seems the >> competition does not either. However it is possible to implement GPT >> support in BIOS. Doing so would give SeaBIOS a competitive advantage >> over the competition. > > This is a common misconception - a standard BIOS has nothing to do > with the partition table. The BIOS doesn't do partition tables - it's > the task of the bootloader and OS to support them. > >> * SeaBIOS supports USB UHCI and OHCI. It should support the latest xHCI. > > Agreed. This needs to be added to the TODO list, and also added on the website. Perhaps something for GSoC students? > >> * SeaBIOS supports 32-bit PCI. It should support 64-bit PCI. > > I'm not sure what you mean here. I've read that SeaBIOS supports 32-bit PCI. http://www.seabios.org/Releases#SeaBIOS_0.5.1 PCI also have 64-bit. http://en.wikipedia.org/wiki/Conventional_PCI#64-bit_PCI > >> * Competition supports small logos in the corners. SeaBIOS only >> supports fullscreen logos. >> >> What features are under development? >> What features & standards are not supported yet? >> What features would we like to have? >> What features are planned? >> We need to document this. >> >> == Unimportant features == >> * SeaBIOS does not support the PNG format which is superior to >> currently BMP and JPG. >> * SeaBIOS uses LZMA compression. The successor L
Re: [SeaBIOS] (no subject)
On Sat, Dec 10, 2011 at 07:30:19PM +0100, Fred . wrote: > Analyze of the current state and proposed future path for SeaBIOS. > > == Website == > The current SeaBIOS website lacks information and is very basic. > SeaBIOS needs a more informative website with documentation and information. It would be a good thing to expand the website. I've wanted to add more technical information to the website, but I have not been able to set aside the time to do it. > == Logo == > SeaBIOS have no logo. > Award/Phoenix, AMI, Insyde, etc have a logo. > Perhaps SeaBIOS should have a logo too? If someone is willing to put together a logo, I will consider using it. I have no talent in that area myself. :-) > == Features & Standards == > In many aspects SeaBIOS is behind the competition. > > * Award/Phoenix, AMI, Inside have setup screen. SeaBIOS does not. > SeaBIOS _needs_ a setup menu in order to win the minds of enthusiasts, > geeks and non-embedded systems. This may be a semantic distinction, but I believe SeaBIOS should launch an application for system setup and SeaBIOS should not itself have a menu system. The ability for SeaBIOS to launch a "setup program" is already present - it just requires the creation of this setup program. Several coreboot payloads already have some menu drawing code, so this shouldn't be too difficult. Frankly though, there isn't much to configure (and that is a good thing). > * Competition have password protection. SeaBIOS does not. Again - this is part of the "setup program" - there is nothing in SeaBIOS to protect. > * SeaBIOS is behind in standards. SeaBIOS supports SMBIOS 2.4, while > the competition is ahead, and the recent standard is SMBIOS 2.7.1. > > * SeaBIOS does not support ESCD. The competition supports this. There are a plethora of old "standards" for PC machines. Supporting all of these "standards" would take eons and provide little appreciable gain. The SeaBIOS approach (inherited from Bochs BIOS) is to support those standards which common operating systems use. I think this is the right approach. > * SeaBIOS does not support (GUID Partition Table) GPT. It seems the > competition does not either. However it is possible to implement GPT > support in BIOS. Doing so would give SeaBIOS a competitive advantage > over the competition. This is a common misconception - a standard BIOS has nothing to do with the partition table. The BIOS doesn't do partition tables - it's the task of the bootloader and OS to support them. > * SeaBIOS supports USB UHCI and OHCI. It should support the latest xHCI. Agreed. > * SeaBIOS supports 32-bit PCI. It should support 64-bit PCI. I'm not sure what you mean here. > * Competition supports small logos in the corners. SeaBIOS only > supports fullscreen logos. > > What features are under development? > What features & standards are not supported yet? > What features would we like to have? > What features are planned? > We need to document this. > > == Unimportant features == > * SeaBIOS does not support the PNG format which is superior to > currently BMP and JPG. > * SeaBIOS uses LZMA compression. The successor LZMA2 is out. > * Linux and Windows have animated splash screens on bootup. It would > be cool if SeaBIOS could have animated flash, via APNG or MNG. SeaBIOS boots fast - there's no time to show a splash screen. That's its real advantage. Should someone wish to see a pretty picture during boot, they can easily add it to the bootloader (eg, as winldr and grub do). That said, should someone wish to add new splash screen support, I don't see it as an issue. > == Usage & Community == > SeaBIOS is used by coreboot, KVM, QEMU and Bochs. Bochs doesn't use SeaBIOS (at least by default). Xen is in the process of using SeaBIOS as well. > SeaBIOS should be used more widely on platforms and platform virtual machines. > SeaBIOS should be supported by VirtualBox and VMware, can this be > accomplished? how? I believe VirtualBox uses (or at least used to use) Bochs BIOS, and it should be possible to migrate to SeaBIOS. It would be up to VMware if they wished to change BIOS. > What other platform virtual machines can SeaBIOS be supported/integrated with? > The different communities needs to work tighter together to commonly > develop SeaBIOS into a tier one BIOS. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (no subject)
Analyze of the current state and proposed future path for SeaBIOS. == Website == The current SeaBIOS website lacks information and is very basic. SeaBIOS needs a more informative website with documentation and information. == Logo == SeaBIOS have no logo. Award/Phoenix, AMI, Insyde, etc have a logo. Perhaps SeaBIOS should have a logo too? == Features & Standards == In many aspects SeaBIOS is behind the competition. * Award/Phoenix, AMI, Inside have setup screen. SeaBIOS does not. SeaBIOS _needs_ a setup menu in order to win the minds of enthusiasts, geeks and non-embedded systems. * Competition have password protection. SeaBIOS does not. * SeaBIOS is behind in standards. SeaBIOS supports SMBIOS 2.4, while the competition is ahead, and the recent standard is SMBIOS 2.7.1. * SeaBIOS does not support ESCD. The competition supports this. * SeaBIOS does not support (GUID Partition Table) GPT. It seems the competition does not either. However it is possible to implement GPT support in BIOS. Doing so would give SeaBIOS a competitive advantage over the competition. * SeaBIOS supports USB UHCI and OHCI. It should support the latest xHCI. * SeaBIOS supports 32-bit PCI. It should support 64-bit PCI. * Competition supports small logos in the corners. SeaBIOS only supports fullscreen logos. What features are under development? What features & standards are not supported yet? What features would we like to have? What features are planned? We need to document this. == Unimportant features == * SeaBIOS does not support the PNG format which is superior to currently BMP and JPG. * SeaBIOS uses LZMA compression. The successor LZMA2 is out. * Linux and Windows have animated splash screens on bootup. It would be cool if SeaBIOS could have animated flash, via APNG or MNG. == Usage & Community == SeaBIOS is used by coreboot, KVM, QEMU and Bochs. SeaBIOS should be used more widely on platforms and platform virtual machines. SeaBIOS should be supported by VirtualBox and VMware, can this be accomplished? how? What other platform virtual machines can SeaBIOS be supported/integrated with? The different communities needs to work tighter together to commonly develop SeaBIOS into a tier one BIOS. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
