SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[Qemu-devel][PATCH 0/6] change acpi numa info format passed from qemu to seabios
by liguang 15 Feb '13

15 Feb '13

orginally, numa info was packed into an array of 64-bit data which was implicit and hard to maintain, so we define a struct for these info, hope to be as clear as enough. these changes also involved seabios paches which was sent to seabios mail-list. Li Guang(6) [PATCH 1/6] pc/bios: move common BIOS_CFG_IOPORT into fw_cfg.h [PATCH 2/6] pc/numa: refactor bios_init function [PATCH 3/6] bitops: change BITS_TO_LONGS [PATCH 4/6] pc: format load_linux() [PATCH 5/6] load_linux: report open kernel file & its size error [PATCH 6/6] load_linux: change kernel header size allocation hw/fw_cfg.h | 4 ++++ hw/pc.c | 163 +++++++++++++++++++++++++++++++------------------------------- hw/sun4u.c | 3 +-- 3 files changed, 89 insertions(+), 81 deletions(-)

4 15

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support
by Peter Stuge 14 Feb '13

14 Feb '13

Fred . wrote: > I propose the name running_on_Xen() The proper way to do that is to send a perfect patch, created using git, with your commit on top of current seabios.git code. //Peter

1 0

[PATCH 0/5][RFC] Simultaneous multi-platform support
by Kevin O'Connor 14 Feb '13

14 Feb '13

This patch series enables SeaBIOS to be compiled for multiple platforms (eg, CSM, QEMU, Coreboot) at the same time. This is useful for cases where SeaBIOS is running under coreboot which is running under QEMU, for example. This series is an RFC - some things are not ideal. For example, if CSM or COREBOOT is enabled then CONFIG_DEBUG_IO is automatically disabled (even if ultimately the image is run directly under QEMU). Also, some features of QEMU wont be available when SeaBIOS is launched from CSM/coreboot, even if it is ultimately running under QEMU. Kevin O'Connor (5): POST: Consolidate platform preinit() calls. Introduce framework for detecting what platform SeaBIOS is running on. Convert common compile time checks to started/runningOnX() checks. Determine century during init and store in VARLOW mem during runtime. Enable simultaneous multi-platform support in Kconfig. src/Kconfig | 23 ++++++-------- src/ata.c | 3 +- src/block.c | 3 +- src/blockcmd.c | 2 +- src/boot.c | 10 +++--- src/clock.c | 26 +++++++++------ src/coreboot.c | 17 +++++++--- src/csm.c | 2 ++ src/esp-scsi.c | 3 +- src/floppy.c | 3 +- src/lsi-scsi.c | 3 +- src/mtrr.c | 4 +-- src/optionroms.c | 3 +- src/paravirt.c | 24 ++++++++++---- src/paravirt.h | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- src/pciinit.c | 4 +-- src/post.c | 53 +++++++++++++++---------------- src/ramdisk.c | 2 +- src/resume.c | 6 +--- src/shadow.c | 12 ++++--- src/smm.c | 10 ++---- src/smp.c | 4 +-- src/virtio-blk.c | 4 +-- src/virtio-scsi.c | 2 +- src/xen.c | 67 +++++++++++++++++++++------------------ src/xen.h | 7 ---- 26 files changed, 253 insertions(+), 139 deletions(-) -- 1.7.11.7

5 23

[PATCH] vgabios: Bochs/QEMU vgabios support should depend on CONFIG_QEMU.
by Kevin O'Connor 14 Feb '13

14 Feb '13

The Cirrus, Standard VGA, and Bochs VGA should depend on CONFIG_QEMU and not CONFIG_COREBOOT. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- vgasrc/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/vgasrc/Kconfig b/vgasrc/Kconfig index 089a447..0901c04 100644 --- a/vgasrc/Kconfig +++ b/vgasrc/Kconfig @@ -11,14 +11,14 @@ menu "VGA ROM" Do not build a VGA BIOS. config VGA_STANDARD_VGA - depends on !COREBOOT + depends on QEMU bool "QEMU/Bochs Original IBM 256K VGA" help Build basic VGA BIOS support (pre Super-VGA) for use on emulators. config VGA_CIRRUS - depends on !COREBOOT + depends on QEMU bool "QEMU/Bochs Cirrus SVGA" help Build support for Cirrus VGA emulation found on QEMU @@ -26,7 +26,7 @@ menu "VGA ROM" intended for use on real Cirrus hardware. config VGA_BOCHS - depends on !COREBOOT + depends on QEMU bool "QEMU/Bochs VBE SVGA" help Build support for Bochs DISPI interface (a custom VBE -- 1.7.11.7

1 0

Re: [SeaBIOS] [PATCH 8/8] Convert some QEMU cmos config variables to the romfile interface.
by Kevin O'Connor 14 Feb '13

14 Feb '13

On Mon, Feb 11, 2013 at 09:21:29AM +0100, Paolo Bonzini wrote: > Il 10/02/2013 05:48, Kevin O'Connor ha scritto: > > @@ -300,9 +300,8 @@ timer_setup(void) > > SET_BDA(timer_counter, ticks); > > > > // Setup Century storage > > - if (CONFIG_QEMU) { > > - Century = inb_cmos(CMOS_CENTURY); > > - } else { > > + Century = romfile_loadint("etc/century", 0); > > + if (!Century) { > > // Infer current century from the year. > > u8 year = inb_cmos(CMOS_RTC_YEAR); > > if (year > 0x80) > > The right thing to would be to use the FADT century field. In fact we > should also set the century field to 0x32 under QEMU. I'm not much of a fan of storing content in the CMOS. It's fine on QEMU, but on real-hardware it tends to cause conflicts when switching between the factory bios and coreboot. Since the century field isn't going to change for another 87 years I think it's safe to avoid cmos in this case. -Kevin

2 2

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
by David Woodhouse 13 Feb '13

13 Feb '13

On Wed, 2013-02-13 at 12:50 +0100, Fred . wrote: > Would it be possible to boot in a resolution any more modern than the > old IBM PC BIOS of 1980? > Which probably used same resolution as something from 1960 or 1970. > Maybe 132*60 instead of 40*25 or 80*25 rows/columns of text? Please don't top-post. Do me the courtesy of properly trimming your citations to quote *only* what is needed for context, and place your reply *below* it, if you want me to do you the courtesy of taking the time to reply. I will not reply to another top-posted message. I really don't understand what you're even trying to achieve. The whole *POINT* of SeaBIOS is to emulate the old IBM PC BIOS of 1980. Well, and a few later developments, but basically that's the point. DOS, and various other 16-bit bootloaders and operating systems, will expect the standard 80x25 text mode. If they don't find that, then they will fail to work correctly. Anything *else* can call the standard INT 10h video BIOS calls to set whatever mode it wants. What user experience do you actually expect to achieve, from the changes that you're suggesting? Bootloaders like Grub these days will already use graphical modes. The SeaBIOS splash screen can also be graphical, and you can go seamlessly from one to the other. What is it that you actually *want*, in real terms? I'm not even sure you know... -- dwmw2

2 1

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
by Gerd Hoffmann 13 Feb '13

13 Feb '13

Hi, > So the computer boots up and passes it to the bootloader And here does the plan fail. There is simply no way to do that. Bootloaders expect the vga being in 80x25 text mode, period. > Doesn't Apple's computers do that? I don't know. Yes, they do. > Would it be possible to boot in a resolution any more modern than the old > IBM PC BIOS of 1980? As long as we are using the IBM PC BIOS interfaces if 1980 (which seabios is all about): No way. With EFI (which apple uses btw) it's another story ... cheers, Gerd

1 0

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
by David Woodhouse 13 Feb '13

13 Feb '13

On Wed, 2013-02-13 at 10:44 +0100, Fred . wrote: > Can SeaBIOS init to a high resolution video mode such as 1920x1200? I'm not entirely sure what you're asking. Can SeaVGABIOS initialise a high-resolution mode? Yes. It supports 1920x1200 and 2560x1600 modes. All you have to do is call INT 10h with the appropriate mode-setting request. Or are you asking if it can do so *power-up*, setting a graphical mode so that nothing displays as expected, because operating systems and bootloaders expect the screen to be in *text* mode? To which the answer would be that yes it *can* be patched to do so, but that would be bad. Or are you asking if it can do so for the OVMF/CSM case? In which case again it *could* but OVMF is about to set the mode for itself anyway so it would be pointless. -- dwmw2

2 1

[RFC PATCH] VGA BIOS init fails if first mode used is graphical
by David Woodhouse 13 Feb '13

13 Feb '13

When booting with OVMF+CSM, the first video mode that we ask for is mode 0x143. This doesn't seem to work; the qemu display window doesn't change size, and remains blank. If the first thing we ask for is a *text* mode, then things work fine. This is arguably a bug, but I'm not about to go chasing it. Most video BIOSes will enter mode 3 for themselves as part of the POST anyway, won't they? And that's sufficient to work around the problem for me... Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com> diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c index 3e26e32..82aa5fc 100644 --- a/vgasrc/vgabios.c +++ b/vgasrc/vgabios.c @@ -1320,4 +1320,6 @@ vga_post(struct bregs *regs) u8 sum = -checksum_far(get_global_seg(), 0, GET_GLOBAL(_rom_header_size) * 512); SET_VGA(_rom_header_checksum, sum); + + vga_set_mode(3, 0); } -- dwmw2

3 4

Re: [SeaBIOS] [edk2] [PATCH 2/2] LegacyBbs: add boot entries for virtio-blk devices
by Laszlo Ersek 12 Feb '13

12 Feb '13

On 02/08/13 09:00, David Woodhouse wrote: > On Fri, 2013-02-08 at 04:44 +0000, Li, Elvin wrote: >> >> I guess this virtual disk comes from a virtual disk >> controller. Now you only fill an entry in BBS table to show legacy >> boot options, I am unclear that how you enable real legacy boot for >> this virtual disk finally? The bbs entry you filled does not include >> the BCV/BEV address and is more like a dummy entry. > > Which is exactly like the entries for IDE devices. If you care, take a > look at the way it's handled in the SeaBIOS CSM, with csm_bootprio_pci() > funding the appropriate entry in the table and ordering the boot option > accordingly. > > [...] I think we should squeeze device paths through the BbsTable. Either UEFI device paths or OpenFirmware device paths. Seabios seems to work like this (with CONFIG_BOOT enabled -- which is disabled for the CSM build): - the Bootorder array is filled with OpenFirmware device paths from fw_cfg, - when device drivers (virtio-blk, virtio-scsi etc) initialize/add a device, they all need a boot priority for it, apparently. So they call a bootprio_find_XXXX_device() function, where XXXX corresponds to the specific device type ("pci" for virtio-blk, "scsi" for virtio-scsi and other scsi drivers). - bootprio_find_XXXX_device() has XXXX-specific parameters. It formats an OpenFirmware device path, with wildcards, based on the incoming parameters (BDF for pci, +target +lun for scsi). Then the Bootorder array is searched with glob_prefix(). In short, each specific device brings itself to OpenFirmware "wildcard format", then the Bootorder array can be searched by common code. IIUC, David has changed this code so that, in the CSM build, bootprio_find_XXXX_device() does not format an OpenFirmware glob, nor does it search the Bootorder array. (Actually, Bootorder is not initialized in the CSM build.) Instead, bootprio_find_XXXX_device() searches the BbsTable exported by the edk2 CSM code. Unfortunately, the BbsTable record is not flexible enough to relay all information in a broken-out format. Currently the code can find: - virtio-blk devices, because for those only the PCI BDF is needed, and those are passed in BbsTable[n].{Bus,Device,Function}, - floppy & ATA disks -- these take a fixed position (record offset) in the BbsTable. For more flexibility, I think the following should be possible to implement: - Allocate a thus far unreserved flag in BbsTable[n].StatusFlags (and/or use BBS_BEV_DEVICE in BbsTable[n].DeviceType), - when it is set, guarantee that the DescString is a textual UEFI device path (which doesn't hurt when "naively" displayed either), and set the usual broken-out fields to invalid/nonexistent devices, - in edk2's LegacyBiosBuildBbs(), enumerate all handles with EFI_BLOCK_IO_PROTOCOL, and tack their textual devpaths after the existing 5 entries to the BbsTable, as BBS_UNPRIORITIZED_ENTRY, - in the CSM build of seabios, bootprio_find_XXXX_device() should format an UEFI device path fragment, and search csm_boot_table->BbsTable[*].DescString for it (filtered for records that have the special flag). This would eliminate yet another OFW<->UEFI devpath conversion, hopefully be flexible enough for SeaBIOS, and shouldn't confuse non-SeaBIOS CSMs. (We can of course make the entire functionality dependent on a new IntelFrameworkModulePkg PCD whose value we override in OvmfPkg.) ... BTW why can't SeaBIOS grab the bootorder fw_cfg file just the same in the CSM build? (Commit 60258aa4 in David's repo.) Thanks Laszlo

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS