SeaBIOS June 2022

seabios@seabios.org

7 participants
6 discussions

Re: INT 14H
by Paul Edwards 29 Sep '22

29 Sep '22

Hi Gerd. Thanks for your reply. Sorry for the delay, was swamped with other things. >> Currently I don't know what to recommend, because I >> don't understand the other side of the INT 13H/14H, >> only the OS side. > Well, the other side talks to the hardware, > and needs drivers to do so. See src/hw > Surely one can write a serial driver which connects to a remote place > using some bluetooth protocol instead of talking to a 16550. That'll > be *alot* of work though, you basically have to implement both > bluetooth stack and hardware driver. I expected to assemble, rather than write, such a thing. If not from the Linux source code, then FreeBSD or ReactOS. If for some reason (what would that be?) no-one has abstracted bluetooth to have a clean interface that I could have trivially reused, then I will put aside my bluetooth dreams and switch to a different technology. How about Wifi? Does that exist in a state usable for my purposes? >> Sure. For now, I want PDOS/386 to remain traditional. >> When I have exhausted everything that is possible >> via the BIOS, I will consider adding UEFI support. > If you want your firmware provide drivers to you for modern hardware you > are in a *much* better position with UEFI. Well, on some/many/most modern machines there is absolutely no other choice - the BIOS doesn't exist, even as CSM. > There is a bluetooth > protocol specification for example, although I'm not sure how common it > is to find an actual uefi driver for bluetooth hardware in the firmware. > Talking to ethernet using the firmware-provided uefi driver shouldn't be > much of a problem though b/c network boot is a rather standard feature. Ok, maybe in the medium term I should use a hardware device, forget the name, that turns ethernet into Wifi. So then the problem is reduced to me needing to provide a BOOTX64.EFI that converts INT 14H into UEFI ethernet calls. >> But I'd like to transport all of that software, designed for >> that environment, and change nothing at all, and have >> it work on a new environment that includes Wifi, bluetooth >> and maybe ethernet, and maybe infrared, and maybe >> other things I don't know about, but make sense (at >> some level) to be accessed via INT 14H. > Well. In the server world it is rather common to provide access to the > serial line over the network for system management purposes. > One approach for that is to have a separate management controller (bmc), > and the serial port of the machine is linked to the management > controller instead of a D9 socket. You can then connect to the bmc to > manage the machine, and one of the options available is to get serial > console access. Ok, this would allow me to have a BBS. But not allow me to have a "virtual modem" so that I can dial out. > Another approach is to have a virtual 16550 provided by the firmware. > Accessing the virtual 16550 will trap into SMM mode where the firmware > emulates a serial device and allows to access the serial port remotely > over the network, roughly comparable to how qemu provides an virtual > 16550 to virtual machines. Ok, but in the case of qemu I have the same issue - at the end of the day I want to drive a modem, so with qemu I can get it to talk to a "virtual modem". If the firmware is providing the serial to network conversion, I also need to stick in a virtual modem there. And that's what I was hoping SeaBIOS would allow me to do. > Note that both approaches work at hardware level not int14h level, > because modern operating systems use int14h services in bootloaders > only if at all. My operating system, PDOS/386, may not be considered "modern", even though it is in active development, but I do wish to use INT 14H, as that was the traditional BIOS service provided, and I wish to maintain contact with the original 80386 machines. I expect a modern environment to have the CPU, memory etc required to support this basic interface. BFN. Paul.

2 4

Force 1024x768 resolution on SeaBIOS with coreboot native graphics
by Felix Freeman 01 Jul '22

01 Jul '22

Hello, I have noticed several problems when using coreboot native graphics ("high resolution" linear framebuffer) with a resolution of 1024x768, on SeaBIOS + SeaVGABIOS: - Boot menus (GRUB, Syslinux) look at a resolution of 640x480. - I get a warning in Debian "graphical" installer "Undefined video mode number: 314", asking me to select a mode, if I select a resolution of 1024x768 it boots fine, if I don't, after 30 seconds, it crashes. - When I use iPXE with SeaBIOS I can't get video on "text based installers" (which use ncurses, for example Debian text based installers). However: - In iPXE I get video on other "graphical" installers (e.g. Debian graphical installer). - I have noticed that in "video mode" it is able to change resolution to show a bootsplash (mode 0x144 on vgasrc/svgamodes.c) and then goes back to 640x480 on "text console". - In iPXE the text display resolution is 1024x7480, however the menus are 640x480. I don't know if its implementation is incomplete, or because of technical reasons SeaVGABIOS is unable to behave correctly without a proprietary VGA BIOS. I think a first step might be to be able to force a minimum resolution in text and video modes. So, my first question is: what is needed to force SeaBIOS/SeaVGABIOS to display a resolution of 1024x768 instead of 640x480 when in "text mode" and "video mode"? And my second question is whether with some work the coreboot native graphics implementation could behave as good as (or close to) a proprietary VGA BIOS. Best regards, Felix

2 3

[SeaVGABIOS] No VBE modes for card on PCIe Root Port
by Kevin Locke 09 Jun '22

09 Jun '22

Hi All, With QEMU 7.0.0 and SeaBIOS 1.16.0, virtual machines with a PCIe graphics card connected to a PCIe Root Port, rather than the Root Complex, as recommended by the QEMU PCI Express Guidelines[1], are unable to use VESA BIOS Extensions display modes. For example, qemu-system-x86_64 \ -no-user-config \ -nodefaults \ -machine q35,accel=kvm \ -m 1G \ -cdrom "$iso" \ -device VGA works well and can use many VBE display modes, while qemu-system-x86_64 \ -no-user-config \ -nodefaults \ -machine q35,accel=kvm \ -m 1G \ -cdrom "$iso" \ -device pcie-root-port,id=pci.1,bus=pcie.0 \ -device VGA,bus=pci.1 only shows a few text display modes. This is the case for VGA, qxl-vga, and virtio-vga devices. `info qtree` shows the device as `type: PCIE` in both configurations. High-resolution graphics modes are available when using UEFI (OVMF) in both configurations. Am I correct in assuming this is a limitation of SeaVGABIOS? Is this expected behavior, or a bug? If it's unlikely to change soon, would it make sense for me to propose documenting this limitation in the QEMU PCI Express Guidelines? I'd appreciate any insights you might have. Thanks, Kevin [1]: https://github.com/qemu/qemu/blob/v7.0.0/docs/pcie.txt

2 2

How does call16 work from protected mode
by Himanshu Chauhan 07 Jun '22

07 Jun '22

Hi, I am trying to understand the call of 16-bit code from protected mode. I am tracing the code from "enable_vga_console" function. I see that it further calls "call16_int10". Further down somewhere (probably check_irqs), pause instruction is executed. I am trying to understand what is expected here. I assume pause is executed and SeaBIOS waits for an interrupt to arrive to finish the call16 processing. But I don't see RTC being programmed for interrupt. For which interrupt is SeaBIOS waiting? NMI? Regards Himanshu

1 0

[PATCH 1/3] handle_1591: [INT15/AH=91h] Always set AH=0 and clear CF
by Lev Kujawski 03 Jun '22

03 Jun '22

References: R. Brown, "INT 15 - OS HOOK - DEVICE POST (AT,PS)", in The x86 Interrupt List. https://www.cs.cmu.edu/~ralf/files.html [Updated: 2018-02-28]. F. v. Gilluwe, The Undocumented PC. Boston, MA: Addison-Wesley, 1997, p. 780. Signed-off-by: Lev Kujawski <lkujaw(a)member.fsf.org> --- src/system.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/system.c b/src/system.c index 438e60e..ec99347 100644 --- a/src/system.c +++ b/src/system.c @@ -232,6 +232,7 @@ handle_1590(struct bregs *regs) static void handle_1591(struct bregs *regs) { + set_code_success(regs); } // keyboard intercept -- 2.34.1

2 5

Open-Source Firmware Conference 2022
by Christian Walter 02 Jun '22

02 Jun '22

** *Dear SeaBIOS community,* * the OSFC is the biggest open-source firmware conference worldwide made by and for developers. After two years we can finally meet in person again. This year's OSFC will take place in Gothenburg, Sweden from September 19th - 21th. We will have a two day conference, followed by a one-day hackathon where we can hack together on hardware and firmware. Currently the Call for Participation is open, and I’d like to invite everyone in this community to submit talks and present new innovations, updates or problem talks. Additionally, you can already buy early bird tickets, so feel free to check out the homepage https://www.osfc.io <https://www.osfc.io>for more information. SeaBIOS and it's community has been a constant part of open-source firmware - and we'd love to see contributions from you on the OSFC 2022! If you have any questions feel free to drop me an email! Thank you! Chris * -- *Christian Walter* *Head of Firmware Development / Cyber Security * 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: christian.walter(a)9elements.com Phone: _+49 234 68 94 188 <tel:+492346894188>_ Mobile: _+49 176 70845047 <tel:+4917670845047>_ Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS June 2022