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