SeaBIOS

seabios@seabios.org

1 participants
3680 discussions

Force 1024x768 resolution on SeaBIOS with coreboot native graphics

by Felix Freeman

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

5 days, 1 hour

[SeaVGABIOS] No VBE modes for card on PCIe Root Port

by Kevin Locke

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

3 weeks, 6 days

How does call16 work from protected mode

by Himanshu Chauhan

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

4 weeks

[PATCH 1/3] handle_1591: [INT15/AH=91h] Always set AH=0 and clear CF

by Lev Kujawski

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

1 month

Open-Source Firmware Conference 2022

by Christian Walter

** *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 month

[PATCH v4 0/2] use large ZoneHigh when there is enough memory

by Gerd Hoffmann

v4: - make calculations more robust. v3: - check size instead of end address. Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 23 ++++++++++++++--------- 2 files changed, 16 insertions(+), 10 deletions(-) -- 2.35.1

2 months

EHCI cpage is out of range with qemu ehci controller

by lma

Hi all, I experienced an error about ehci current page on qemu + seabios v1.14: cpage out of range (5) processing error - resetting ehci HC We know that the EHCI spec defines valid range of ehci cpage to 0-4, But here is a 5, Obviously it's an issue. I added a EHCI controller, and attached a usb mass storage to the EHCI controller as boot device: host:~# qemu-system-x86_64 \ -accel kvm \ -bios /home/test/projects/seabios/out/bios.bin \ -m 4096 \ -device usb-ehci \ -blockdev driver=file,read-only=on,filename=/isos/openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20220314-Media.iso,node-name=iso \ -device usb-storage,drive=iso,bootindex=0 The issue is not 100% reproducible, I run the test 15 times with above steps, the issue occurs 1 or 2 times. The qemu version seems doesn't matter, I used to use qemu 5.2, 6.0 and latest git master, Got the same test result. It seems that the issue was introduced since seabios v1.14, It can be reproduced on latest seabios git master as well, It can't be reproduced on seabios 1.13 or older. The seabios commit b3fa8577 "kvm: add support for reading tsc frequency from kvmclock" seems to be the suspect. Thanks, Lin

2 months

[PATCH v3 0/2] use large ZoneHigh when there is enough memory

by Gerd Hoffmann

v3: - check size instead of end address. Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 18 +++++++++++------- 2 files changed, 13 insertions(+), 8 deletions(-) -- 2.35.1

2 months, 1 week

[PATCH v2 0/2] use large ZoneHigh when there is enough memory

by Gerd Hoffmann

Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 18 +++++++++++------- 2 files changed, 13 insertions(+), 8 deletions(-) -- 2.35.1

2 months, 1 week

Re: Floppy setup

by Keith Hui

(Looping in the SeaBIOS mailing list again.) See this: https://www.seabios.org/Runtime_config It appears CMOS locations are a legacy artifact and files within the cbfs image (eg. etc/floppy0) is the preferred way of passing SeaBIOS settings. If you want a proper fix with the value stored in CMOS (and be configurable via nvramtool), you'll need to modify both SeaBIOS and the coreboot option table layout for your board. If you need help with coreboot and are not subscribed to that mailing list, I can reach out and loop you in. @Kevin - What are we to do for SeaBIOS settings that the we may want to change at runtime eg. via nvramtool? Are there any such settings? Keith On Sun, 24 Apr 2022 at 18:36, Petr Cvek <petrcvekcz(a)gmail.com> wrote: > > Linux actually reads the floppy type from the exact same CMOS location as QEMU compiled SeaBIOS: > > https://elixir.free-electrons.com/linux/v5.12.9/source/arch/x86/include/asm… > > and if I remember correctly I've had to force the type through floppy module parameter, before I modified the coreboot+SeaBIOS source codes. > > The other operating systems will probably try to read the CMOS location as well. IMO it is actually a standard bitfield in IBM PC compatible computer. Also all cmos.layout files start the configuration from bit 384 and some of them even have the first 120 bits explicitly defined as "reserved". > > Under these constraints I think it should be possible to change the line to something like this: > > if (CONFIG_QEMU || CONFIG_USE_CMOS) { > > With CONFIG_USE_CMOS be "n" by default so non floppy boards will end with the old code path. > > Petr > > > Dne 24. 04. 22 v 21:05 Keith Hui napsal(a): > > Hi Petr, > > > > Linux seems to have been able to pick up all the floppy drives on its own. > > > > But if you read a few more lines beyond the snippet you posted, you'll > > see that it only reads nvram for floppy types when compiled for and > > run on QEMU because that layout is hard coded and QEMU-specific. To > > extend it to other coreboot targets that layout will need to be > > incorporated into the option table of all coreboot mainboards, which > > isn't trivial and some boards don't even have floppy ports at all. And > > should those nvram bytes hold value for something else, results can be > > very unpredictable. > > > > You'll also see another way around it, using files etc/floppy0 and > > etc/floppy1 added to the coreboot image. Some tracing within this file > > will tell you what values to use. Downside is changing these values > > also requires reflashing. > > > > Hope this helps. > > > > Keith > > > > On Sun, 24 Apr 2022 at 07:15, Petr Cvek <petrcvekcz(a)gmail.com> wrote: > >> > >> Hello, > >> > >> I was playing with coreboot + floppy and it seems the drive type can be read from CMOS only if the machine is QEMU. > >> > >> payloads/external/SeaBIOS/seabios/src/hw/floppy.c > >> > >> floppy_setup(void) > >> { > >> ... > >> if (CONFIG_QEMU) { > >> u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE); > >> if (type & 0xf0) > >> addFloppy(0, type >> 4); > >> ... > >> } else { > >> u8 type = romfile_loadint("etc/floppy0", 0); > >> ... > >> > >> Is it possible enable this function for a real coreboot target? What way is the most acceptable way to do it (something like || CONFIG_USE_CMOS)? > >> > >> I've forced it with "always true" condition and after adding configurations to cmos table and superio in coreboot, I was able to boot msdos on kontron 986lcd-m board. > >> > >> P.S. original message got stuck somewhere in the mailserver as I forgot to subscribe to seabios mailing list. > >> > >> Regards, > >> Petr > >> _______________________________________________ > >> SeaBIOS mailing list -- seabios(a)seabios.org > >> To unsubscribe send an email to seabios-leave(a)seabios.org

2 months, 1 week

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS