SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] [coreboot] seabios feature request : reboot VM or retry boot devices when no valid boot disk is found
by Maurits van de Lande 11 May '12

11 May '12

>On Fri, May 11, 2012 at 6:28 AM, Maurits van de Lande <M.vandeLande(a)vdl-fittings.com> wrote: >> I would prefer to automatically reboot the VM (or retry the boot >> devices) when no bootable device is found, then when the iSCSI storage >> is available again the VM can boot normally. >> >> (when I manually sent CTRL+ALT+DEL to the VM the system booted normally >> again) >It would be an interesting option. Sometimes, for hardware, you really want it to wait with the error message on the screen for a while so you can tell what happened. At the same time, there's nothing more annoying than having it wait forever when you know the hardware finally is ready for a boot ... Perhaps it would be possible to set a reasonable optional timeout and then have it reboot or, better, just redo the hardware scan and try again. >ron A reasonable optional timeout and just redo the hardware scan and try again sounds perfect. On a HP Proliant server the system is rebooted after a timeout when no boot device is detected. I don't know which option is better. When a new bios is available I'll be happy to test it! Maurits

1 0

patches from Google
by ron minnich 11 May '12

11 May '12

Let me know if this format is ok, this is the first in a series :-) ron

1 0

Re: [SeaBIOS] [coreboot] seabios feature request : reboot VM or retry boot devices when no valid boot disk is found
by ron minnich 11 May '12

11 May '12

On Fri, May 11, 2012 at 6:28 AM, Maurits van de Lande <M.vandeLande(a)vdl-fittings.com> wrote: > I would prefer to automatically reboot the VM (or retry the boot devices) > when no bootable device is found, then when the iSCSI storage is available > again the VM can boot normally. > > (when I manually sent CTRL+ALT+DEL to the VM the system booted normaly > again) It would be an interesting option. Sometimes, for hardware, you really want it to wait with the error message on the screen for a while so you can tell what happened. At the same time, there's nothing more annoying than having it wait forever when you know the hardware finally is ready for a boot ... Perhaps it would be possible to set a reasonable optional timeout and then have it reboot or, better, just redo the hardware scan and try again. ron

1 0

Re: [SeaBIOS] [coreboot] seabios feature request : reboot VM or retry boot devices when no valid boot disk is found
by Peter Stuge 11 May '12

11 May '12

Hi, Note that SeaBIOS has it's own mailing list. I'm forwarding the post there. Maurits van de Lande wrote: > Hello, > > I'm using KVM on Centos 6.2. Currently I switched to iSCSI storage to host the virtual machines. > > When I was simulation some worst case scenario's I noticed that when no boot device is found the bios just stops at displaying "No bootable device" > > I would prefer to automatically reboot the VM (or retry the boot devices) when no bootable device is found, then when the iSCSI storage is available again the VM can boot normally. > (when I manually sent CTRL+ALT+DEL to the VM the system booted normaly again) > > Is there a way to use seabios this way? > If not, can it be added to the bios? > > Best regards, > > Maurits van de Lande

1 0

Website broken
by Fred . 11 May '12

11 May '12

Database error Jump to: navigation, search A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "Revision::fetchFromConds". Database returned error "1: no such column: rev_sha1".

1 0

[Qemu-devel] : Memory problem with Qemu/SeaBIOS
by Alain Ribière 10 May '12

10 May '12

Hello, I have a memory trouble with an old DOS OS from Digital Research called Concurrent DOS. It worked fine till Qemu v0.11.1. I use Qemu to make a legacy application run without any modification. Starting with Qemu 0.12, my legacy application has not enough memory to run. Actually it seems that the SeaBIOS doesn't use the same memory mapping than PC-BIOS used to, causing trouble to my application. Is there any way to get SeaBIOS use (more or less) the same memory amount and memory mapping than the older PC-BIOS ? I tried to recomplie SeaBIOS 1.7.0 with less options but the result is the same. Here is my .config file : CONFIG_RELOCATE_INIT=y CONFIG_ATA=y CONFIG_FLOPPY=y CONFIG_PS2PORT=y CONFIG_SERIAL=y CONFIG_LPT=y CONFIG_DRIVES=y CONFIG_OPTIONROMS=y CONFIG_PMM=y CONFIG_BOOT=y CONFIG_KEYBOARD=y CONFIG_KBD_CALL_INT15_4F=y CONFIG_MOUSE=y CONFIG_NO_VGABIOS=y CONFIG_DEBUG_LEVEL=0 I also join two print screen of the same C-DOS utility. One with Qemu 1.0 and SeaBIOS 1.7.0 and the other with Qemu 0.10.0. The amount of memory is quite different between the versions. If you want to try, get this floppy : https://docs.google.com/open?id=0B7mz0vq6Rpb7Q0tYbmxMVzVqTms and then type : STOP If you have any idea... Thanks, Alain

3 8

[PATCH v2] pci: clean all funcs when hot-removing multifunc device
by Amos Kong 09 May '12

09 May '12

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=737720#c8 (dmesg and DSDT were attached in bz) Boot up a Linux VM with 8 pci block devices which are the 8 functions in one pci slot. | # qemu-kvm ... | -drive file=images/u0,if=none,id=drv0,format=qcow2,cache=none \ | -device virtio-blk-pci,drive=drv0,id=v0,multifunction=on,addr=0x03.0 \ | .... | -drive file=images/u7,if=none,id=drv7,format=qcow2,cache=none \ | -device virtio-blk-pci,drive=drv7,id=v7,multifunction=on,addr=0x03.7 \ Check devices in guest. | vm)# ls /dev/vd* | vda vdb vdc vde vdf vdg vdh | vm)# lspci |grep block | 00:03.0 SCSI storage controller: Red Hat, Inc Virtio block device | ... | 00:03.7 SCSI storage controller: Red Hat, Inc Virtio block device | Func1~7 still exist in guest after hot-removing the whole slot by qemu monitor cmd. | vm)# lspci |grep block (00:03.0 disappeared) | 00:03.1 SCSI storage controller: Red Hat, Inc Virtio block device (rev ff) | ... | 00:03.7 SCSI storage controller: Red Hat, Inc Virtio block device (rev ff) | vm)# ls /dev/vd* (vda disappeared) | vdb vdc vde vdf vdg vdh | vm)# mkfs /dev/vdb | INFO: task mkfs.ext2:1784 blocked for more than 120 seconds. We process pci slot as a whole device, in seabios only defines one device for a slot in ACPI DSDT table, then there is only one entry (for func#0) would be added into 'slot->funcs' list. When we release the whole slot, only the entry in 'slot->funcs' will be cleaned, so func#1~7 could not be cleaned from system. | drivers/pci/hotplug/acpiphp_glue.c: | static int disable_device(struct acpiphp_slot *slot) { | list_for_each_entry(func, &slot->funcs, sibling) { | pdev = pci_get_slot(slot->bridge->pci_bus, | PCI_DEVFN(slot->device, func->function)); | ..clean code.. // those code is only executed 1 time(for func#0) | __pci_remove_bus_device(pdev); | pci_dev_put(pdev); I try to add entries for all hotpluged device in enable_device(), but it doesn't work, because 'slot->funcs' is used in many place which we only need to process func#0. This patch just try to clean all funcs in disable_device(). Hotpluging multifunc of guests(WinXp/Win7) is fine. --- v1 thread: http://marc.info/?t=131597601700003&r=1&w=2 Changes from v1: - rebase patch to latest linux.git - remove unnecessary multiplefunction check - rename 'i' to meaningful 'fn' - fix coding style Signed-off-by: Amos Kong <akong(a)redhat.com> --- drivers/pci/hotplug/acpiphp_glue.c | 20 +++++++++++--------- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index 806c44f..42f9bb9 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -887,6 +887,7 @@ static int disable_device(struct acpiphp_slot *slot) struct acpiphp_func *func; struct pci_dev *pdev; struct pci_bus *bus = slot->bridge->pci_bus; + int fn; /* The slot will be enabled when func 0 is added, so check func 0 before disable the slot. */ @@ -902,16 +903,17 @@ static int disable_device(struct acpiphp_slot *slot) func->bridge = NULL; } - pdev = pci_get_slot(slot->bridge->pci_bus, - PCI_DEVFN(slot->device, func->function)); - if (pdev) { - pci_stop_bus_device(pdev); - if (pdev->subordinate) { - disable_bridges(pdev->subordinate); - pci_disable_device(pdev); + for (fn = 0; fn < 8; fn++) { + pdev = pci_get_slot(bus, PCI_DEVFN(slot->device, fn)); + if (pdev) { + pci_stop_bus_device(pdev); + if (pdev->subordinate) { + disable_bridges(pdev->subordinate); + pci_disable_device(pdev); + } + __pci_remove_bus_device(pdev); + pci_dev_put(pdev); } - __pci_remove_bus_device(pdev); - pci_dev_put(pdev); } }

1 0

[PATCH] pciinit: make pci ressources configurable
by Gerd Hoffmann 07 May '12

07 May '12

Using kevins ssdt approach. Also trying to address the winxp issue by only adding the 64bit window to the _crs in case we actually have mapped pci bars high. That bit doesn't work though, the "LEqual(QW2, 0x00)" expression seems to never evaluate to true for some reason. Ideas anyone? --- src/acpi-dsdt.dsl | 47 ++++++++++++++++++++++++++++++++++++++++++++--- src/acpi.c | 25 ++++++++++++++++++++++++- src/pci.h | 2 ++ src/pciinit.c | 22 +++++++++++++++++----- 4 files changed, 87 insertions(+), 9 deletions(-) diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl index 227e4a3..17d6d87 100644 --- a/src/acpi-dsdt.dsl +++ b/src/acpi-dsdt.dsl @@ -132,7 +132,7 @@ DefinitionBlock ( B0EJ, 32, } - Name (_CRS, ResourceTemplate () + Name (CRES, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Address Space Granularity @@ -174,15 +174,56 @@ DefinitionBlock ( 0xFEBFFFFF, // Address Range Maximum 0x00000000, // Address Translation Offset 0x1EC00000, // Address Length - ,, , AddressRangeMemory, TypeStatic) + ,, PW32, AddressRangeMemory, TypeStatic) + }) + Name (CR64, ResourceTemplate () + { QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Address Space Granularity 0x8000000000, // Address Range Minimum 0xFFFFFFFFFF, // Address Range Maximum 0x00000000, // Address Translation Offset 0x8000000000, // Address Length - ,, , AddressRangeMemory, TypeStatic) + ,, PW64, AddressRangeMemory, TypeStatic) }) + Method (_CRS, 0) + { + External (\_SB.BDAT) + Field(\_SB.BDAT, QWordAcc, NoLock, Preserve) { + QW0, 64, + QW1, 64, + QW2, 64, + QW3, 64, + } + + /* fixup 32bit pci io window */ + CreateDWordField (CRES,\_SB.PCI0.PW32._MIN, PS32) + CreateDWordField (CRES,\_SB.PCI0.PW32._MAX, PE32) + CreateDWordField (CRES,\_SB.PCI0.PW32._LEN, PL32) + Store (QW0, PS32) + Store (QW1, PE32) + Subtract (QW1, QW0, PL32) + + If (LEqual(QW2, 0x00)) { + DBUG("PCI0 _CRS: 32bit only") + Return (CRES) + } Else { + DBUG("PCI0 _CRS: add 64bit window") + DBUG(QW2) + DBUG(QW3) + + /* fixup and add 64bit pci io window */ + CreateQWordField (CR64,\_SB.PCI0.PW64._MIN, PS64) + CreateQWordField (CR64,\_SB.PCI0.PW64._MAX, PE64) + CreateQWordField (CR64,\_SB.PCI0.PW64._LEN, PL64) + Store (QW2, PS64) + Store (QW3, PE64) + Subtract (QW3, QW2, PL64) + + ConcatenateResTemplate (CRES, CR64, Local0) + Return (Local0) + } + } } } diff --git a/src/acpi.c b/src/acpi.c index 30888b9..930924c 100644 --- a/src/acpi.c +++ b/src/acpi.c @@ -415,7 +415,8 @@ build_ssdt(void) int length = ((1+3+4) + (acpi_cpus * SD_SIZEOF) + (1+2+5+(12*acpi_cpus)) - + (6+2+1+(1*acpi_cpus))); + + (6+2+1+(1*acpi_cpus)) + + 17); u8 *ssdt = malloc_high(sizeof(struct acpi_table_header) + length); if (! ssdt) { warn_noalloc(); @@ -477,6 +478,28 @@ build_ssdt(void) for (i=0; i<acpi_cpus; i++) *(ssdt_ptr++) = (i < CountCPUs) ? 0x01 : 0x00; + // store pci io windows + u64 *pcimem = malloc_high(sizeof(*pcimem) * 4); + pcimem[0] = pcimem_start; + pcimem[1] = pcimem_end - 1; + pcimem[2] = pcimem64_start; + pcimem[3] = pcimem64_end - 1; + + // build "OperationRegion(BDAT, SystemMemory, 0x12345678, 0x87654321)" + *(ssdt_ptr++) = 0x5B; // ExtOpPrefix + *(ssdt_ptr++) = 0x80; // OpRegionOp + *(ssdt_ptr++) = 'B'; + *(ssdt_ptr++) = 'D'; + *(ssdt_ptr++) = 'A'; + *(ssdt_ptr++) = 'T'; + *(ssdt_ptr++) = 0x00; // SystemMemory + *(ssdt_ptr++) = 0x0C; // DWordPrefix + *(u32*)ssdt_ptr = (u32)pcimem; + ssdt_ptr += 4; + *(ssdt_ptr++) = 0x0C; // DWordPrefix + *(u32*)ssdt_ptr = sizeof(*pcimem)*4; + ssdt_ptr += 4; + build_header((void*)ssdt, SSDT_SIGNATURE, ssdt_ptr - ssdt, 1); //hexdump(ssdt, ssdt_ptr - ssdt); diff --git a/src/pci.h b/src/pci.h index 6be838c..ebf934c 100644 --- a/src/pci.h +++ b/src/pci.h @@ -56,6 +56,8 @@ struct pci_device { // Local information on device. int have_driver; }; +extern u64 pcimem_start, pcimem_end; +extern u64 pcimem64_start, pcimem64_end; extern struct pci_device *PCIDevices; extern int MaxPCIBus; int pci_probe_host(void); diff --git a/src/pciinit.c b/src/pciinit.c index 8374603..b85d45e 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -29,6 +29,11 @@ static const char *region_type_name[] = { [ PCI_REGION_TYPE_PREFMEM ] = "prefmem", }; +u64 pcimem_start = BUILD_PCIMEM_START; +u64 pcimem_end = BUILD_PCIMEM_END; +u64 pcimem64_start = BUILD_PCIMEM64_START; +u64 pcimem64_end = BUILD_PCIMEM64_END; + struct pci_region_entry { struct pci_device *dev; int bar; @@ -517,13 +522,13 @@ static int pci_bios_init_root_regions(struct pci_bus *bus) } u64 sum = pci_region_sum(r_end); u64 align = pci_region_align(r_end); - r_end->base = ALIGN_DOWN((BUILD_PCIMEM_END - sum), align); + r_end->base = ALIGN_DOWN((pcimem_end - sum), align); sum = pci_region_sum(r_start); align = pci_region_align(r_start); r_start->base = ALIGN_DOWN((r_end->base - sum), align); - if ((r_start->base < BUILD_PCIMEM_START) || - (r_start->base > BUILD_PCIMEM_END)) + if ((r_start->base < pcimem_start) || + (r_start->base > pcimem_end)) // Memory range requested is larger than available. return -1; return 0; @@ -601,14 +606,17 @@ static void pci_bios_map_devices(struct pci_bus *busses) if (pci_bios_init_root_regions(busses)) panic("PCI: out of 32bit address space\n"); - r64_mem.base = BUILD_PCIMEM64_START; + r64_mem.base = pcimem64_start; u64 sum = pci_region_sum(&r64_mem); u64 align = pci_region_align(&r64_pref); r64_pref.base = ALIGN(r64_mem.base + sum, align); - if (r64_pref.base + pci_region_sum(&r64_pref) > BUILD_PCIMEM64_END) + if (r64_pref.base + pci_region_sum(&r64_pref) > pcimem64_end) panic("PCI: out of 64bit address space\n"); pci_region_map_entries(busses, &r64_mem); pci_region_map_entries(busses, &r64_pref); + } else { + // no bars mapped high -> drop 64bit window + pcimem64_start = 0; } // Map regions on each device. int bus; @@ -634,6 +642,10 @@ pci_setup(void) } dprintf(3, "pci setup\n"); + u64 pcimem64_size = (1LL << 36); // 64 MB + pcimem_start = RamSize; + pcimem64_start = (RamSizeOver4G + pcimem64_size) & ~(pcimem64_size-1); + pcimem64_end = pcimem64_start + pcimem64_size; dprintf(1, "=== PCI bus & bridge init ===\n"); if (pci_probe_host() != 0) { -- 1.7.1

1 0

Re: [SeaBIOS] SeaBIOS vs other BIOS?
by Peter Stuge 07 May '12

07 May '12

Fred . wrote: > And in terms of standards compliance? The nature of BIOS is that there isn't a standard to comply with. > I know proprietary BIOS have advantage when it comes to SMBIOS due > to the implementation in SeaBIOS lagging behind several versions. Do you know of concrete issues because of this lag, or did you notice a number that is smaller in SeaBIOS than somewhere else? Ie. do you see a technical disadvantage because of the difference in SMBIOS versions? //Peter

2 1

Re: [SeaBIOS] SeaBIOS vs other BIOS?
by Gleb Natapov 07 May '12

07 May '12

On Mon, May 07, 2012 at 10:44:21AM +0200, Fred . wrote: > On Mon, May 7, 2012 at 9:40 AM, Gleb Natapov <gleb(a)redhat.com> wrote: > > On Sun, May 06, 2012 at 10:26:31PM +0200, Fred . wrote: > >> And in terms of standards compliance? > >> > >> I know proprietary BIOS have advantage when it comes to SMBIOS due to > >> the implementation in SeaBIOS lagging behind several versions. > >> > >> On Sun, May 6, 2012 at 8:00 PM, Peter Stuge <peter(a)stuge.se> wrote: > >> > Fred . wrote: > >> >> How is SeaBIOS working towards the non-technical goals of the project? > >> > > >> > This is not so clear. I'm not even sure that there are non-technical > >> > goals for the project. > >> > > >> > Competing with commercial BIOS products would require a company to > >> > put a SeaBIOS-based PC firmware to market, quite likely in concert > >> > with coreboot. I know of one company which offers among other things > >> > coreboot services, Sage Engineering, who are quite active in the > >> > coreboot community. http://www.se-eng.com/coreboot.html > >> > > >> > But even so you can see that the business model is different from > >> > commercial BIOS products, and already this small difference presents > >> > a non-technical challenge. > >> > >> SeaBIOS lacks documentation. > >> It lacks communication. > >> The website is not updated with news about the development. > >> There is no mention of what's new, whats planned, etc. > > Now I am curious what other BIOSes give you all that? In all that points > > Seabios in not different from most other open source project. > > > > -- > > Gleb. > > Perhaps other BIOS have private channels to make such communications > directly to their customers. SeaBIOS customers pretty much define SeaBIOS roadmap, so perhaps such communication is unnecessary. > Or perhaps they don't need to due to having been in the BIOS game > pretty much since it started. Or perhaps they do not care because most of the BIOS "customers" do not aware of its existence or that they have an alternative? > > I think information, documentation, roadmaps, public announcements, > timely communication would be good. -- Gleb.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS