SeaBIOS February 2013

seabios@seabios.org

24 participants
63 discussions

[PATCH v2 00/19] SeaBIOS as Compatibility Support Module for UEFI/OVMF

by David Woodhouse

Changes from v1: - Make CONFIG_CSM a top-level build target in parallel with COREBOOT/QEMU. - More Kconfig cleanup. - Add generic find_pmtimer() function to find the pmtimer from ACPI tables. - Make Xen and coreboot builds both use find_pmtimer(). - Merge E820 table one entry at a time instead of wholesale copy. - Add pic_save_mask() and pic_restore_mask() functions. - Less intrusive size reduction for handle_post(). - Various other cleanups. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation

7 years, 8 months

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

by Andreas Färber

Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis: > Because dimm layout needs to be configured on machine-boot, all dimm devices > need to be specified on startup command line (either with populated=on or with > populated=off). The dimm information is stored in dimm configuration structures. > > After machine startup, dimms are hot-added or removed with normal device_add > and device_del operations e.g.: > Hot-add syntax: "device_add dimm,id=mydimm0,bus=membus.0" > Hot-remove syntax: "device_del dimm,id=mydimm0" This sounds contradictory: Either all devices need to be specified on the command line, or they can be hot-added via monitor. Assuming a fixed layout at startup, I wonder if there is another clever way to model this... For CPU hotplug Anthony had suggested to have a fixed set of link<Socket> properties that get set to a CPU socket as needed. Might a similar strategy work for memory, i.e. a startup-configured amount of link<DIMM>s on /machine/dimm[n] that point to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then simply work via QMP qom-set command. (CC'ing some people) Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

7 years, 11 months

[Qemu PATCH] add a boot option to do strict boot

by Amos Kong

Current seabios will try to boot from selected devices first, if they are all failed, seabios will also try to boot from un-selected devices. We need to make it configurable. I already posted a seabios patch to add a new device type to halt booting. Qemu can add "HALT" at the end of bootindex string, then seabios will halt booting after trying to boot from selected devices. This option only effects when boot priority is changed by bootindex options, the old style(-boot order=..) will still try to boot from un-selected devices. Signed-off-by: Amos Kong <akong(a)redhat.com> --- [SeaBIOS PATCH v3] boot: add a new type to halt booting https://github.com/kongove/seabios/commit/39aeded2da6254eab2c34de92371ce1ca… bios.bin: http://kongove.fedorapeople.org/pub/added-halt-type-bios.bin --- qemu-config.c | 3 +++ qemu-options.hx | 8 ++++++-- vl.c | 28 +++++++++++++++++++++++++++- 3 files changed, 36 insertions(+), 3 deletions(-) diff --git a/qemu-config.c b/qemu-config.c index 2188c3e..dd6d249 100644 --- a/qemu-config.c +++ b/qemu-config.c @@ -612,6 +612,9 @@ QemuOptsList qemu_boot_opts = { }, { .name = "reboot-timeout", .type = QEMU_OPT_STRING, + }, { + .name = "strict", + .type = QEMU_OPT_STRING, }, { /*End of list */ } }, diff --git a/qemu-options.hx b/qemu-options.hx index 9df0cde..5408837 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -376,14 +376,14 @@ ETEXI DEF("boot", HAS_ARG, QEMU_OPTION_boot, "-boot [order=drives][,once=drives][,menu=on|off]\n" - " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time]\n" + " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n" " 'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n" " 'sp_name': the file's name that would be passed to bios as logo picture, if menu=on\n" " 'sp_time': the period that splash picture last if menu=on, unit is ms\n" " 'rb_timeout': the timeout before guest reboot when boot failed, unit is ms\n", QEMU_ARCH_ALL) STEXI -@item -boot [order=@var{drives}][,once=@var{drives}][,menu=on|off][,splash=@var{sp_name}][,splash-time=@var{sp_time}][,reboot-timeout=@var{rb_timeout}] +@item -boot [order=@var{drives}][,once=@var{drives}][,menu=on|off][,splash=@var{sp_name}][,splash-time=@var{sp_time}][,reboot-timeout=@var{rb_timeout}][,strict=on|off] @findex -boot Specify boot order @var{drives} as a string of drive letters. Valid drive letters depend on the target achitecture. The x86 PC uses: a, b @@ -407,6 +407,10 @@ when boot failed, then reboot. If @var{rb_timeout} is '-1', guest will not reboot, qemu passes '-1' to bios by default. Currently Seabios for X86 system support it. +Do strict boot via @option{strict=on} as far as firmware/BIOS +supports it. This only effects when boot priority is changed by +bootindex options. The default is non-strict boot. + @example # try to boot from network first, then from hard disk qemu-system-i386 -boot order=nc diff --git a/vl.c b/vl.c index 79e5122..de79f6c 100644 --- a/vl.c +++ b/vl.c @@ -230,6 +230,7 @@ int ctrl_grab = 0; unsigned int nb_prom_envs = 0; const char *prom_envs[MAX_PROM_ENVS]; int boot_menu; +int boot_strict; uint8_t *boot_splash_filedata; int boot_splash_filedata_size; uint8_t qemu_extra_params_fw[2]; @@ -2804,7 +2805,7 @@ int main(int argc, char **argv, char **envp) static const char * const params[] = { "order", "once", "menu", "splash", "splash-time", - "reboot-timeout", NULL + "reboot-timeout", "strict", NULL }; char buf[sizeof(boot_devices)]; char *standard_boot_devices; @@ -2847,6 +2848,19 @@ int main(int argc, char **argv, char **envp) exit(1); } } + if (get_param_value(buf, sizeof(buf), + "strict", optarg)) { + if (!strcmp(buf, "on")) { + boot_strict = 1; + } else if (!strcmp(buf, "off")) { + boot_strict = 0; + } else { + fprintf(stderr, + "qemu: invalid option value '%s'\n", + buf); + exit(1); + } + } qemu_opts_parse(qemu_find_opts("boot-opts"), optarg, 0); } @@ -3907,6 +3921,18 @@ int main(int argc, char **argv, char **envp) net_check_clients(); + if (boot_strict) { + /* do strict boot, only boot from selected devices */ + FWBootEntry *node; + + QTAILQ_FOREACH(node, &fw_boot_order, link) { + if (!node->link.tqe_next) { + add_boot_device_path(node->bootindex + 1, NULL, "HALT"); + break; + } + } + } + /* just use the first displaystate for the moment */ ds = get_displaystate(); -- 1.7.1

7 years, 12 months

[PATCH] pci vga: Support VGA behind bridges

by Alex Williamson

We currently expect to find VGA devices on the root bus but we will also support them below bridges iff the VGA routing across the bridges is pre-configured. This patch maintains that behavior, but also enables SeaBIOS to enable VGA routing to the first VGA class device it finds when there is no preconfigured device. This allows us to support VGA devices behind root ports and bridges without special setup from QEMU. Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- src/optionroms.c | 46 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/src/optionroms.c b/src/optionroms.c index caa2151..1c2a714 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -439,13 +439,47 @@ vgarom_setup(void) memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START); // Find and deploy PCI VGA rom. - struct pci_device *pci; + struct pci_device *pci, *pci_vga = NULL; + // Search for devices already enabled foreachpci(pci) { - if (!is_pci_vga(pci)) - continue; - vgahook_setup(pci); - init_pcirom(pci, 1, NULL); - break; + if (is_pci_vga(pci)) { + pci_vga = pci; + break; + } + } + + // Find and enable the first VGA device + if (!pci_vga && (pci = pci_find_class(PCI_CLASS_DISPLAY_VGA)) != NULL) { + dprintf(4, "Enabling device %02x:%02x.%x for primary VGA\n", + pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf), + pci_bdf_to_fn(pci->bdf)); + + u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND); + cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY; + pci_config_writew(pci->bdf, PCI_COMMAND, cmd); + + pci_vga = pci; + + while (pci->parent) { + pci = pci->parent; + + dprintf(4, "Setting VGA enable for bridge %02x:%02x.%x\n", + pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf), + pci_bdf_to_fn(pci->bdf)); + + u8 ctrl = pci_config_readb(pci->bdf, PCI_BRIDGE_CONTROL); + ctrl |= PCI_BRIDGE_CTL_VGA; + pci_config_writeb(pci->bdf, PCI_BRIDGE_CONTROL, ctrl); + + u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND); + cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY; + pci_config_writew(pci->bdf, PCI_COMMAND, cmd); + } + } + + if (pci_vga) { + vgahook_setup(pci_vga); + init_pcirom(pci_vga, 1, NULL); } // Find and deploy CBFS vga-style roms not associated with a device.

8 years

RFC: Primary VGA

by Alex Williamson

When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this. Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary. The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient. If it is sufficient, then I think we need to rebuild that path on system reset and we need some way to specify which device to use. One option would be some kind of per PCIDevice property, perhaps "primary_vga". A downside is that users can abuse it by trying to set it for more than one device. Maybe a better approach would be to add a machine property for it, -machine primary_vga=$id. We'll also need some reasonable way to pick a default if unspecified. Does anyone have any thoughts on managing this? Thanks, Alex

8 years

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH] Distinguish between reset types

by Laszlo Ersek

On 02/19/13 23:45, David Woodhouse wrote: > I'm beginning to wish I'd just ignored the fact that > we need a properly working "soft" reset to get back from 286 protected > mode to real mode, and wired up the damn PAM reset unconditionally. I'm > not convinced that the protected->real mode transition will work for > anyone anyway. I believe currently we must be somewhere "between" soft reset & hard reset. I estimate getting closer to a well-emulated hard reset is more important than getting closer to a soft one. If you were to extend the i440FX reset handler so that it unconditionally resets the PAMs, I'd give my Rb. (Take it for what it's worth :)) The long-term solution covering all targets is being designed, but a quick shortcut would be nice, and not only for CSM development / testing. (I gather qemu_prep_reset() in SeaBIOS would not have had to be written that way, for example.) For CSM stuff we can still carry private qemu patches of course... Thanks Laszlo

8 years

[PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()

by David Woodhouse

From: David Woodhouse <David.Woodhouse(a)intel.com> Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com> --- src/byteorder.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/byteorder.h b/src/byteorder.h index 5a8a64a..7362aeb 100644 --- a/src/byteorder.h +++ b/src/byteorder.h @@ -43,7 +43,7 @@ static inline u16 le16_to_cpu(u16 x) { static inline u32 le32_to_cpu(u32 x) { return x; } -static inline u32 le64_to_cpu(u64 x) { +static inline u64 le64_to_cpu(u64 x) { return x; } @@ -62,7 +62,7 @@ static inline u16 be16_to_cpu(u16 x) { static inline u32 be32_to_cpu(u32 x) { return swab32(x); } -static inline u32 be64_to_cpu(u64 x) { +static inline u64 be64_to_cpu(u64 x) { return swab64(x); } -- 1.8.1.2

8 years

Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

by Vasilis Liaskovitis

Hi, sorry for the delay. On Tue, Feb 19, 2013 at 07:39:40PM -0300, Erlon Cruz wrote: > On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis < > vasilis.liaskovitis(a)profitbricks.com> wrote: > > > This is v4 of the ACPI memory hotplug functionality. Only x86_64 target is > > supported (both i440fx and q35). There are still several issues, but it's > > been a while since v3 and I wanted to get some more feedback on the current > > state of the patchseries. > > > > > We are working in memory hotplug functionality on pSeries machine. I'm > wondering whether and how we can better integrate things. Do you think the > DIMM abstraction is generic enough to be used in other machine types? I think the DimmDevice is generic enough but I am open to other suggestions. A related issue is that the patchseries uses a DimmBus to hot-add and hot-remove DimmDevice. Another approach that has been suggested is to use links<> between DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc machines respectively). This would be more similar to the CPUState/qom patches - see Andreas Färber's earlier reply to this thread. I think we should get some consensus from the community/maintainers before we continue to integrate. I haven't updated the series for a while, but I can rework if there is a more clear direction for the community. Another open issue is reference counting of memoryregions in qemu memory model. In order to make memory hot-remove operations safe, we need to remove a memoryregion after all users (e.g. both guest and block layer) have stopped using it, see discussion at http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. There was a relevant ibm patchset https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html but it was not merged. > > > > Overview: > > > > Dimm device layout is modeled with a normal qemu device: > > > > "-device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0" > > > > > How does this will handle the no-hotplugable memory for example the memory > passed in '-m' parameter? The non-hotpluggable initial memory (-m) is currently not modelled at all as a DimmDevice. We may want to model it though. thanks, - Vasilis

8 years

SeaBIOS v1.7.2.1 stable release

by Kevin O'Connor

A new stable release of SeaBIOS (version 1.7.2.1) has been tagged. This release contains bug fixes, including several fixes for build problems. The release is available via git: git clone git://git.seabios.org/seabios -b 1.7.2-stable -Kevin Kevin O'Connor (4): Update tools/acpi_extract.py to handle iasl 20130117 release. Fix Makefile - don't reference "out/" directly, instead use "$(OUT)". build: Don't require $(OUT) to be a sub-directory of the main directory. Verify CC is valid during build tests. Alex Williamson (3): seabios q35: Enable all PIRQn IRQs at startup seabios q35: Add new PCI slot to irq routing function seabios: Add a dummy PCI slot to irq mapping function Avik Sil (1): USB-EHCI: Fix null pointer assignment Makefile | 10 +++++----- src/Kconfig | 2 +- src/pciinit.c | 47 ++++++++++++++++++++++++++++++++++++++++++----- src/usb-ehci.c | 2 +- tools/acpi_extract.py | 4 ++-- tools/test-build.sh | 23 +++++++++++++++-------- 6 files changed, 66 insertions(+), 22 deletions(-)

8 years

[RFC] SeaBIOS v1.7.2.1 stable release

by Kevin O'Connor

There's been requests for a stable release. Here's a list of patches that have been requested / that I think would be useful: 616fb27f - Update tools/acpi_extract.py to handle iasl 20130117 release. 7cac600a - USB-EHCI: Fix null pointer assignment 4c405cbf - Fix Makefile - don't reference "out/" directly, instead use "$(OUT)". 23219122 - build: Don't require $(OUT) to be a sub-directory of the main directory. bb0808a2 - Verify CC is valid during build tests. 555a2136 - seabios q35: Enable all PIRQn IRQs at startup b9490408 - seabios q35: Add new PCI slot to irq routing function dbb7a66f - seabios: Add a dummy PCI slot to irq mapping function Comments? -Kevin

8 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS February 2013