SeaBIOS August 2022

seabios@seabios.org

8 participants
11 discussions

[PATCH v4 0/4] Make seabios linkable with lld
by Fangrui Song 07 Dec '22

07 Dec '22

Another try after https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/KBHQU4… The only change is the removal of `Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf` since 699a4e5d6919cc8eae5342443025ceb6909dc276 ("ldnoexec: Add script to remove ET_EXEC flag from intermediate build objects") has done the same thing. For your convenience, the patch series is available on https://github.com/MaskRay/seabios/tree/lld Re-sending. I posted this 3 days but got bounced. I have now ensured there is my email address record on (previously not) https://mail.coreboot.org/postorius/lists/seabios.seabios.org/ as well as https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/ Fangrui Song (4): romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr Make rom16.o linkable with lld romlayout32flag.lds: Use `. +=` instead of `. =` test-build.sh: Delete unneeded LD capability test scripts/layoutrom.py | 8 +++++++- scripts/test-build.sh | 42 +----------------------------------------- src/romlayout.S | 2 +- 3 files changed, 9 insertions(+), 43 deletions(-) -- 2.37.0.144.g8ac04bfd2-goog

3 7

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

[BUG] Could not read from CDROM (code 0003)
by Petr Cvek 31 Aug '22

31 Aug '22

Hello, I've tried to boot a coreboot supported machine (Kontron 986lcd-m) from CD and it hangs. The drive is correctly identified (AHCI ATAPI). Petr Log follows: Booting from DVD/CD... scsi_is_ready (drive=0x000f5820) disk_op d=0x000f5820 lba=0 buf=0x00000000 count=0 cmd=32 AHCI/2: send cmd ... AHCI/2: ... intbits 0x1, status 0x50 ... AHCI/2: ... finished, status 0x50, OK disk_op d=0x000f5820 lba=17 buf=0x000067a8 count=1 cmd=2 AHCI/2: send cmd ... handle_08 handle_hwpic1 irq=1 ... repeats ... handle_08 handle_hwpic1 irq=1 WARNING - Timeout at ahci_command:153! Boot failed: Could nothandle_08 handle_hwpic1 irq=1 read from CDROM (code 0003) enter handle_18: NULL Booting from Hard Disk... enter handle_13: a=00000201 b=00000000 c=00000001 d=00000080 ds=0000 es=07c0 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=f000 ip=ca99 f=0202 disk_op d=0x000f5870 lba=0 buf=0x00007c00 count=1 cmd=2 AHCI/1: send cmd ... AHCI/1: ... intbits 0x1, status 0x50 ... AHCI/1: ... finished, status 0x50, OK ahci disk read, lba 0, count 1, buf 0x00007c00, rc 0 Booting from 0000:7c00 ... continues with sata hdd ...

1 1

Re: Animated GIF bootsplash: Failure to decode ImageMagick generated GIFs (invalid GIF signature)
by Paul Menzel 29 Aug '22

29 Aug '22

Dear Michael, Am 23.08.22 um 16:30 schrieb Michael Bacarella: > On Tue, Aug 23, 2022 at 12:06 AM Paul Menzel wrote: >> Am 22.08.22 um 21:23 schrieb Michael Bacarella: >>> On Sat, Aug 20, 2022 at 11:45 PM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> >>>> Thank you for implementing this. If you send a patch, I can test on real >>>> hardware. >> >> […] >> >>> Patch attached. I replied here rather than with a new email with a PATCH subject >>> because I don't consider it ready to merge, more like a POC. >>> >>> Also I'm using gmail, hope I don't embarrass myself. >> >> Unfortunately, Gmail wraps lines after 72(?) characters so the diff is >> malformed. Maybe attach the file generated by `git format-patch -1`? > > My apologies. Attached here. I noticed another thing, that GIFs created by ImageMagick’s convert cannot be decoded. With your converted example image [1] $ dpkg -l imagemagick […] ii imagemagick 8:6.9.11.60+dfsg-1.3+b3 amd64 image manipulation programs -- binaries $ convert bootsplash.gif -resize 1280x1024+32 bootsplash2.gif $ identify bootsplash2.gif bootsplash2.gif[0] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 0.000u 0:00.001 bootsplash2.gif[1] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 0.000u 0:00.000 bootsplash2.gif[2] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 2.05915MiB 0.000u 0:00.000 or bb.gif [2] $ identify bb.gif bb.gif[0] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[1] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[2] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[3] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[4] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[5] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[6] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[7] GIF 100x100 100x100+0+0 8-bit sRGB 2c 1446B 0.000u 0:00.000 I get: Decoding bootsplash.gif invalid GIF signature gif_decode failed with return code -1... Kind regards, Paul [1]: https://michael.bacarella.com/bootsplash.gif [2]: https://www.opensourcecook.in/sites/default/files/bb.gif

1 0

Re: Animated GIF bootsplash
by Paul Menzel 27 Aug '22

27 Aug '22

Dear Michael, Am 23.08.22 um 16:30 schrieb Michael Bacarella: > On Tue, Aug 23, 2022 at 12:06 AM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> Am 22.08.22 um 21:23 schrieb Michael Bacarella: >>> On Sat, Aug 20, 2022 at 11:45 PM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> >>>> Thank you for implementing this. If you send a patch, I can test on real >>>> hardware. >> >> […] >> >>> Patch attached. I replied here rather than with a new email with a PATCH subject >>> because I don't consider it ready to merge, more like a POC. >>> >>> Also I'm using gmail, hope I don't embarrass myself. >> >> Unfortunately, Gmail wraps lines after 72(?) characters so the diff is >> malformed. Maybe attach the file generated by `git format-patch -1`? > > My apologies. Attached here. No problems. Thank you for providing the patch. I tried it on the ASUS F2A85-M PRO, and the GIF you provided [1], and got the results below. $ identify bootsplash.gif bootsplash.gif[0] GIF 640x480 640x480+0+0 8-bit sRGB 256c 0.000u 0:00.000 bootsplash.gif[1] GIF 640x480 640x480+0+0 8-bit sRGB 256c 0.000u 0:00.012 bootsplash.gif[2] GIF 640x480 640x480+0+0 8-bit sRGB 256c 640039B 0.000u 0:00.012 Checking for bootsplash Copying romfile 'bootsplash.gif' (len 640039) Copying data 640039@0xff8c07a8 to 640039@0x5ed93b70 start showing bootsplash VESA 3.0 VENDOR: (C) 1988-2010, Advanced Micro Devices, Inc. PRODUCT: DVST Decoding bootsplash.gif Finding vesa mode with dimensions 640/480 Unable to find vesa video mode dimensions 640/480 failed to find a videomode with 640x480 24bpp (0=any). According to `videoinfo` from GRUB (MBR), the video modes from the Video BIOS/VGA Option ROM seem to be: ``` List of supported video modes: Legend: mask/position=red/green/blue/reserved Adapter `Cirrus CLGD 5446 PCI Video Driver': No info available Adapter `Bochs PCI Video Driver': No info available Adapter `VESA BIOS Extension Video Driver': VBE info: version: 3.0 OEM software rev: 15.31 total memory: 16384 KiB 0x100 640 x 400 x 8 ( 640) Paletted 0x101 640 x 480 x 8 ( 640) Paletted 0x103 800 x 600 x 8 ( 832) Paletted 0x105 1024 x 768 x 8 (1024) Paletted 0x107 1280 x 1024 x 8 (1280) Paletted 0x110 640 x 480 x 16 (1280) Direct color, mask: 5/5/5/0 pos: 10/5/0/0 0x111 640 x 480 x 16 (1280) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x113 800 x 600 x 16 (1664) Direct color, mask: 5/5/5/0 pos: 10/5/0/0 0x114 800 x 600 x 16 (1664) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x116 1024 x 768 x 16 (2048) Direct color, mask: 5/5/5/0 pos: 10/5/0/0 0x117 1024 x 768 x 16 (2048) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x119 1280 x 1024 x 16 (2560) Direct color, mask: 5/5/5/0 pos: 10/5/0/0 0x11a 1280 x 1024 x 16 (2560) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x163 1280 x 960 x 8 (1280) Paletted 0x165 1280 x 960 x 16 (2560) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x166 1280 x 960 x 32 (5120) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 0x121 640 x 480 x 32 (2560) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 0x122 800 x 600 x 32 (3328) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 0x123 1024 x 768 x 32 (4096) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 * 0x124 1280 x 1024 x 32 (5120) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 0x143 1400 x 1050 x 8 (1408) Paletted 0x145 1400 x 1050 x 16 (2816) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x146 1400 x 1050 x 32 (5632) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 0x173 1600 x 1200 x 8 (1600) Paletted 0x175 1600 x 1200 x 16 (3200) Direct color, mask: 5/6/5/0 pos: 11/5/0/0 0x176 1600 x 1200 x 32 (6400) Direct color, mask: 8/8/8/0 pos: 16/8/0/0 EDID version: 1.3 No preferred mode available Adapter `VGA Video Driver': No info available ``` So no 640 x 480 x 24 mode is in there. I never tried bootsplash before, so no idea, if misconfigured something, or just need a different GIF. Kind regards, Paul [1]: https://michael.bacarella.com/bootsplash.gif

1 0

Animated GIF bootsplash
by Michael Bacarella 23 Aug '22

23 Aug '22

Hello, I've added animated GIF bootsplash support to SeaBIOS. Demo: https://www.youtube.com/watch?v=0mmMk40uDJk Is this only of interest to me, or should I submit a patch for consideration? I adapted this public domain gif decoder https://github.com/lecram/gifdec It is my understanding that the patents that were encumbering GIF use in open source have long since expired so there should not be regulatory blockers. Thank you kindly.

3 7

Creating a new release.
by Sakib Sajal 17 Aug '22

17 Aug '22

qemu-x86-64 v7.0.0 hangs on reboot (as shown below) without kvm when using bios.bin before commit: 0177400 reset: force standard PCI configuration access qemu on master uses bios.bin at v1.16.0: commit d877ada1b8c768d10c39b63bb70c9e5ed1c0a4bc Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Fri Mar 4 15:27:59 2022 +0100 update seabios binaries to 1.16.0 Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> I was able successfully reboot by checkingout 0177400, make-ing, and using the bios.bin using "-bios <path/to/bios.bin> to qemu-x86-64. Is it possible to create a release that contains the above commit which the qemu and yocto (https://www.yoctoproject.org/) community will be able to use? Sincerely, Sakib --------------------------------------------------------------------------------------------- root@qemux86-64:~# reboot Broadcast message from root@qemux86-64 (ttyS0) (Wed Aug 17 19:45:13 2022): The system is going down for reboot NOW! INIT: Switching to runlevel: 6 INIT: Sending processes configured via /etc/inittab the TERM signal Stopping syslogd/klogd: stopped syslogd (pid 269) stopped klogd (pid 272) done Unmounting remote filesystems... Deconfiguring network interfaces... ifdown: interface lo not configured done. Sending all processes the TERM signal... Sending all processes the KILL signal... Deactivating swap... Unmounting local filesystems... [ 27.350393] EXT4-fs (vda): re-mounted. Quota mode: disabled. Rebooting... [ 27.615867] reboot: Restarting system [ 27.616288] reboot: machine restart

1 0

[PATCH] floppy: Support CMOS setting outside QEMU
by Petr Cvek 12 Aug '22

12 Aug '22

SeaBIOS can be used for booting legacy OS and also Linux is still using CMOS address 0x10 to configure floppy controller. Under these assumptions it makes sense to allow boot from CMOS defined floppy drives. Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com> --- src/Kconfig | 7 +++++++ src/hw/floppy.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/src/Kconfig b/src/Kconfig index 3a8ffa1..42b9614 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -227,6 +227,13 @@ menu "Hardware support" default y help Support floppy drive access. + config LEGACY_FLOPPY + depends on FLOPPY && COREBOOT + bool "Get floppy type from CMOS" + default n + help + Support boot from CMOS defined floppy. Used by legacy OSes + on IBM PC compatible machine under coreboot. config FLASH_FLOPPY depends on DRIVES bool "Floppy images from CBFS or fw_cfg" diff --git a/src/hw/floppy.c b/src/hw/floppy.c index 9e6647d..40af360 100644 --- a/src/hw/floppy.c +++ b/src/hw/floppy.c @@ -155,7 +155,7 @@ floppy_setup(void) return; dprintf(3, "init floppy drives\n"); - if (CONFIG_QEMU) { + if (CONFIG_QEMU || CONFIG_LEGACY_FLOPPY) { u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE); if (type & 0xf0) addFloppy(0, type >> 4); -- 2.37.0

3 3

[PATCH] timer: Configure timer1 to a standard settings
by Petr Cvek 12 Aug '22

12 Aug '22

ASPI2DOS.SYS and KEYB.COM from Win 98 SE installation CD (and most likely other DOS versions too) depend on I/O port 0x61 bit 4 to be toggled. This requires timer 1 (I/O 0x41, legacy DRAM refresh) to be correctly set. Also Intel ICH7 Family Datasheet, chapter 5.8 states: Programming the counter to anything other than Mode 2 will result in undefined behavior for the REF_TOGGLE bit. Failing to have the timer 1 configured indeed causes affected OSes to freeze during the boot. Signed-off-by: Petr Cvek <petrcvekcz(a)gmail.com> --- src/hw/timer.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/hw/timer.c b/src/hw/timer.c index b6f102e..b272f44 100644 --- a/src/hw/timer.c +++ b/src/hw/timer.c @@ -280,4 +280,10 @@ pit_setup(void) // maximum count of 0000H = 18.2Hz outb(0x0, PORT_PIT_COUNTER0); outb(0x0, PORT_PIT_COUNTER0); + + // timer1: binary count, 16bit count, mode 2 + outb(PM_SEL_TIMER1|PM_ACCESS_WORD|PM_MODE2|PM_CNT_BINARY, PORT_PIT_MODE); + // maximum count of 0012H = 66.3kHz + outb(0x12, PORT_PIT_COUNTER1); + outb(0x0, PORT_PIT_COUNTER1); } -- 2.37.0

3 3

[PATCH 0/2] Add support for all standard resolutions
by Elliot Killick 01 Aug '22

01 Aug '22

This patch series adds support for all the standard resolutions as listed on Wikipedia. I've fixed the issue Gerd pointed out and rebased onto master. I also see that Gerd himself has recently put out a patch for 4K resolutions, however, my own ultrawide resolution of 3440x1440 remains unsupported by SeaBIOS. I've heard from some others that they have unique resolutions that are still not in SeaBIOS but they should be with this patch so I hope we can get it in. Regarding 24 bpp, probably yes, most software doesn't care about it but for maximal compatability (and because Windows has been finicky in my experience), I think we should include it. Also, there's still the chance that some people may want to use it in some unlikely scenarios which they should be able to do without recompilation. One last thing to consider is that we would then have to decide at what point do the resolutions being added with this patch become modern/new enough that it no longer makes sense to keep the 24 bpp variants. It seems like we would basically just have to draw an arbitrary line in the sand. However, if you would still like to remove 24 bpp variants then please provide me with a cut off point and I'll put it in the next patch version. Again, if we could get this in that would be fantastic because I've personally had people raise this issue with me in regards to an issue they're having in relation to one of my projects. Thanks, Elliot Elliot Killick (2): svgamodes: Add support for all standard resolutions svgamodes: Improve formatting vgasrc/svgamodes.c | 225 ++++++++++++++++++++++++++++----------------- 1 file changed, 141 insertions(+), 84 deletions(-) -- 2.34.3

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS August 2022