SeaBIOS October 2012

seabios@seabios.org

27 participants
89 discussions

Get rid of a compile time dprintf warning

by Dave Frodin

This patch gets rid of a compile time dprintf warning. A 'long int' was being passed to a '%d'. Signed-off-by: Dave Frodin <dave.frodin(a)se-eng.com> --- src/post.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/post.c b/src/post.c index 924b311..b84d19e 100644 --- a/src/post.c +++ b/src/post.c @@ -345,7 +345,7 @@ reloc_init(void) panic("No space for init relocation.\n"); // Copy code and update relocs (init absolute, init relative, and runtime) - dprintf(1, "Relocating low data from %p to %p (size %d)\n" + dprintf(1, "Relocating low data from %p to %p (size %ld)\n" , datalow_start, final_datalow_start, datalow_end - datalow_start); updateRelocs(code32flat_start, _reloc_datalow_start, _reloc_datalow_end , final_datalow_start - datalow_start); -- 1.7.9

9 years

[PATCH] DSDT: Fix HPET _CRS Method

by Gabriel L. Somlo

Updated _CRS method for HPET, bringing it in line with the way it is presented on recent hardware (e.g. Dell Latitude D630, MacPro5,1, etc); Allows it to be detected and utilized from Mac OS X; Also tested OK on Linux (F16 64-bit install DVD) and Windows (Win7 64-bit install DVD). Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- src/acpi-dsdt.dsl | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl index d2575a5..065a3e5 100644 --- a/src/acpi-dsdt.dsl +++ b/src/acpi-dsdt.dsl @@ -251,6 +251,12 @@ DefinitionBlock ( Device(HPET) { Name(_HID, EISAID("PNP0103")) Name(_UID, 0) + Name(BUF0, ResourceTemplate() { + Memory32Fixed (ReadOnly, + 0xFED00000, // Address Base + 0x00000400, // Address Length + ) + }) OperationRegion(HPTM, SystemMemory , 0xFED00000, 0x400) Field(HPTM, DWordAcc, Lock, Preserve) { VEND, 32, @@ -268,17 +274,9 @@ DefinitionBlock ( } Return (0x0F) } - Name(_CRS, ResourceTemplate() { - DWordMemory( - ResourceConsumer, PosDecode, MinFixed, MaxFixed, - NonCacheable, ReadWrite, - 0x00000000, - 0xFED00000, - 0xFED003FF, - 0x00000000, - 0x00000400 /* 1K memory: FED00000 - FED003FF */ - ) - }) + Method (_CRS, 0, NotSerialized) { + Return (BUF0) + } } } -- 1.7.7.6

9 years, 2 months

[PATCH] config: add coreboot / qemu choice

by Gerd Hoffmann

Makes the config less confusing as we don't have to use "!COREBOOT" if we wanna say "QEMU". Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/Kconfig | 32 +++++++++++++++++++++----------- 1 files changed, 21 insertions(+), 11 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index b5dd63b..ee6fdb6 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -4,14 +4,24 @@ mainmenu "SeaBIOS Configuration" menu "General Features" +choice + prompt "Build Target" + default QEMU + config COREBOOT bool "Build for coreboot" - default n help Configure as a coreboot payload. + config QEMU + bool "Build for QEMU" + help + Configure as QEMU bios. + +endchoice + config XEN - depends on !COREBOOT + depends on QEMU bool "Build for Xen HVM" default y help @@ -108,25 +118,25 @@ menu "Hardware support" help Support for AHCI disk code. config VIRTIO_BLK - depends on DRIVES && !COREBOOT + depends on DRIVES && QEMU bool "virtio-blk controllers" default y help Support boot from virtio-blk storage. config VIRTIO_SCSI - depends on DRIVES && !COREBOOT + depends on DRIVES && QEMU bool "virtio-scsi controllers" default y help Support boot from virtio-scsi storage. config ESP_SCSI - depends on DRIVES && !COREBOOT + depends on DRIVES && QEMU bool "AMD PCscsi controllers" default y help Support boot from AMD PCscsi storage. config LSI_SCSI - depends on DRIVES && !COREBOOT + depends on DRIVES && QEMU bool "lsi53c895a scsi controllers" default y help @@ -211,19 +221,19 @@ menu "Hardware support" Support parallel ports. This also enables int 17 parallel port calls. config USE_SMM - depends on !COREBOOT + depends on QEMU bool "System Management Mode (SMM)" default y help Support System Management Mode (on emulators). config MTRR_INIT - depends on !COREBOOT + depends on QEMU bool "Initialize MTRRs" default y help Initialize the Memory Type Range Registers (on emulators). config PMTIMER - depends on !COREBOOT + depends on QEMU bool "Use ACPI timer" default y help @@ -327,7 +337,7 @@ menu "BIOS interfaces" endmenu menu "BIOS Tables" - depends on !COREBOOT + depends on QEMU config PIRTABLE bool "PIR table" default y @@ -377,7 +387,7 @@ menu "Debugging" Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8. config DEBUG_IO - depends on !COREBOOT && DEBUG_LEVEL != 0 + depends on QEMU && DEBUG_LEVEL != 0 bool "Special IO port debugging" default y help -- 1.7.1

9 years, 2 months

Re: [SeaBIOS] USB Problems geode lx800

by Kevin O'Connor

On Thu, Oct 18, 2012 at 12:25:58PM +0200, Christian Gmeiner wrote: > 2012/10/17 Kevin O'Connor <kevin(a)koconnor.net>: > > The controller is supposed to update the toggle bit in the qh. The > > same qh is used for all transfers, so it should already be up to date > > between transfers. It is possible something subtle is going on here. > > USB is finally working :) http://dpaste.com/815054/ Great! Can you post the EHCI patch you used to make this work? Thanks, -Kevin

9 years, 2 months

Re: [SeaBIOS] [RFC PATCH v3 00/19] ACPI memory hotplug

by Avi Kivity

On 10/31/2012 12:58 PM, Stefan Hajnoczi wrote: > On Fri, Sep 21, 2012 at 1:17 PM, Vasilis Liaskovitis > <vasilis.liaskovitis(a)profitbricks.com> wrote: >> This is v3 of the ACPI memory hotplug functionality. Only x86_64 target is supported >> for now. > > Hi Vasilis, > Regarding the hot unplug issue we've been discussing, it's possible to > progress this patch series without fully solving that problem upfront. > > Karen Noel suggested that the series could be rolled without the hot > unplug command, so that it's not possible to hit the unsafe case. > This would allow users to hot plug additional memory. They would have > to use virtio-balloon to reduce the memory footprint again. Later, > when the memory region referencing issue has been solved the hot > unplug command can be added. > > Just wanted to mention Karen's idea in case you feel stuck right now. We could introduce hotunplug as an experimental feature so people can test and play with it, and later graduate it to a fully supported feature. -- error compiling committee.c: too many arguments to function

9 years, 2 months

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 05/19] Implement dimm device abstraction

by Avi Kivity

On 10/31/2012 02:18 PM, Stefan Hajnoczi wrote: >> >> IMO we should use the same mechanism as proposed for other devices: >> address_space_map() should grab a reference on the dimm device, and >> address_space_unmap() can release it. This way device destruction will >> be deferred as soon as all devices complete I/O. >> >> We will have to be careful with network receive buffers though, since >> they can be held indefinitely. > > Network receive buffers aren't mapped. Net receive is not zero-copy. > For example, virtio-net does virtqueue_pop() inside > virtio_net_receive(). > > I don't see a problem with networking. What about vhost-net? But that is managed separately with a MemoryListener. -- error compiling committee.c: too many arguments to function

9 years, 2 months

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v3 05/19] Implement dimm device abstraction

by Avi Kivity

On 10/24/2012 10:06 AM, liu ping fan wrote: > On Tue, Oct 23, 2012 at 8:25 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >> On Fri, Sep 21, 2012 at 01:17:21PM +0200, Vasilis Liaskovitis wrote: >>> +static void dimm_populate(DimmDevice *s) >>> +{ >>> + DeviceState *dev= (DeviceState*)s; >>> + MemoryRegion *new = NULL; >>> + >>> + new = g_malloc(sizeof(MemoryRegion)); >>> + memory_region_init_ram(new, dev->id, s->size); >>> + vmstate_register_ram_global(new); >>> + memory_region_add_subregion(get_system_memory(), s->start, new); >>> + s->mr = new; >>> +} >>> + >>> +static void dimm_depopulate(DimmDevice *s) >>> +{ >>> + assert(s); >>> + vmstate_unregister_ram(s->mr, NULL); >>> + memory_region_del_subregion(get_system_memory(), s->mr); >>> + memory_region_destroy(s->mr); >>> + s->mr = NULL; >>> +} >> >> How is dimm hot unplug protected against callers who currently have RAM >> mapped (from cpu_physical_memory_map())? >> >> Emulated devices call cpu_physical_memory_map() directly or indirectly >> through DMA emulation code. The RAM pointer may be held for arbitrary >> lengths of time, across main loop iterations, etc. >> >> It's not clear to me that it is safe to unplug a DIMM that has network >> or disk I/O buffers, for example. We also need to be robust against >> malicious guests who abuse the hotplug lifecycle. QEMU should never be >> left with dangling pointers. >> > Not sure about the block layer. But I think those thread are already > out of big lock, so there should be a MemoryListener to catch the > RAM-unplug event, and if needed, bdrv_flush. IMO we should use the same mechanism as proposed for other devices: address_space_map() should grab a reference on the dimm device, and address_space_unmap() can release it. This way device destruction will be deferred as soon as all devices complete I/O. We will have to be careful with network receive buffers though, since they can be held indefinitely. -- error compiling committee.c: too many arguments to function

9 years, 2 months

Re: [SeaBIOS] [RFC PATCH v3 00/19] ACPI memory hotplug

by Stefan Hajnoczi

On Fri, Sep 21, 2012 at 1:17 PM, Vasilis Liaskovitis <vasilis.liaskovitis(a)profitbricks.com> wrote: > This is v3 of the ACPI memory hotplug functionality. Only x86_64 target is supported > for now. Hi Vasilis, Regarding the hot unplug issue we've been discussing, it's possible to progress this patch series without fully solving that problem upfront. Karen Noel suggested that the series could be rolled without the hot unplug command, so that it's not possible to hit the unsafe case. This would allow users to hot plug additional memory. They would have to use virtio-balloon to reduce the memory footprint again. Later, when the memory region referencing issue has been solved the hot unplug command can be added. Just wanted to mention Karen's idea in case you feel stuck right now. Stefan

9 years, 2 months

Re: [SeaBIOS] [PATCH] ACPI: Remove unnecessary Return(One) calls from DSDT.

by Marc Jones

On Mon, Oct 29, 2012 at 10:17 AM, Marc Jones <marc.jones(a)se-eng.com> wrote: > Acked-by: Marc Jones <marc.jones(a)se-eng.com> > > On Sat, Oct 27, 2012 at 7:33 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> Recent iasl compilers warn about spurious return calls. Remove extra >> return calls from the GPE event methods. >> >> Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> >> --- >> src/acpi-dsdt.dsl | 20 ++------------------ >> 1 file changed, 2 insertions(+), 18 deletions(-) >> >> diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl >> index d2575a5..284d70d 100644 >> --- a/src/acpi-dsdt.dsl >> +++ b/src/acpi-dsdt.dsl >> @@ -559,7 +559,6 @@ DefinitionBlock ( >> PCNT(Local0, 3) >> } >> } >> - Return(One) >> } >> >> } >> @@ -729,7 +728,6 @@ DefinitionBlock ( >> } >> Increment(Local0) >> } >> - Return(One) >> } >> } >> >> @@ -743,54 +741,40 @@ DefinitionBlock ( >> Name(_HID, "ACPI0006") >> >> Method(_L00) { >> - Return(0x01) >> } >> Method(_E01) { >> // PCI hotplug event >> - Return(\_SB.PCI0.PCNF()) >> + \_SB.PCI0.PCNF() >> } >> Method(_E02) { >> // CPU hotplug event >> - Return(\_SB.PRSC()) >> + \_SB.PRSC() >> } >> Method(_L03) { >> - Return(0x01) >> } >> Method(_L04) { >> - Return(0x01) >> } >> Method(_L05) { >> - Return(0x01) >> } >> Method(_L06) { >> - Return(0x01) >> } >> Method(_L07) { >> - Return(0x01) >> } >> Method(_L08) { >> - Return(0x01) >> } >> Method(_L09) { >> - Return(0x01) >> } >> Method(_L0A) { >> - Return(0x01) >> } >> Method(_L0B) { >> - Return(0x01) >> } >> Method(_L0C) { >> - Return(0x01) >> } >> Method(_L0D) { >> - Return(0x01) >> } >> Method(_L0E) { >> - Return(0x01) >> } >> Method(_L0F) { >> - Return(0x01) >> } >> } >> } >> -- >> 1.7.11.7 >> >> >> _______________________________________________ >> SeaBIOS mailing list >> SeaBIOS(a)seabios.org >> http://www.seabios.org/mailman/listinfo/seabios -- http://se-eng.com

9 years, 3 months

doe's seabios support retry booting from other disk if boot from one disk failed

by Eli

hi all: Does anyone know that if seabiso support booting from other disk if boot from one failed ? For instance, the PC BIOS boot specification allows only one disk to be bootable. If boot from disk fails for some reason, the BIOS won't retry booting from other disk. It still can try to boot from floppy or net, though.I want to know that if seabios support retry booting from other disk? Thanks Eli.

9 years, 3 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS October 2012