June 2020 - SeaBIOS - mail.coreboot.org

[PATCH v3 0/5] Make seabios linkable with lld
by Fangrui Song Aug. 12, 2021

Aug. 12, 2021

This patch series make seabios linkable with lld. This is beneficial for FreeBSD ports as well https://svnweb.freebsd.org/ports/head/misc/seabios/Makefile as they can drop an LLD_UNSAFE As a maintainer of lld ELF, I have triaged numerous pieces of software. seabios is the only one making use of This drops the only instance https://sourceware.org/bugzilla/show_bug.cgi?id=12726 1, 2, 3 and 4 are really independent and can be applied in arbitrary order. 5 depends on 4. I originally combined 4 and 5 and that was why I don't think a patch series made sense. Fangrui Song (5): romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr Make rom16.o linkable with lld Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf romlayout32flag.lds: Use `. +=` instead of `. =` test-build.sh: Delete unneeded LD capability test Makefile | 4 ++++ scripts/layoutrom.py | 13 ++++++++++--- scripts/test-build.sh | 42 +----------------------------------------- src/romlayout.S | 2 +- 4 files changed, 16 insertions(+), 45 deletions(-) -- 2.26.0.292.g33ef6b2f38-goog

4 16

release planning
by Gerd Hoffmann July 28, 2020

July 28, 2020

Hi, qemu 5.1 is coming closer, with freeze in a week and release in August. See https://wiki.qemu.org/Planning/5.1 We'll need a new seabios release for qemu 5.1, and the options we have are: (1) cherry-pick bugfixes (at least the cirrus vga fix, probably more) into 1.13-stable, tag a 1.13.1 stable release. (2) tag a 1.14 release from master branch. Given we have several useful changes in the master branch which I would not consider being bugfixes a 1.14 released would be nice. Freeze in a week and release in three weeks should work fine with the qemu release schedule. What do you think? take care, Gerd

3 7

[PATCH v2] timer: Handle decrements of PIT counter
by Roman Bolshakov June 26, 2020

June 26, 2020

There's a fallback to PIT if TSC is not present but it doesn't work properly. It prevents boot from floppy on isapc and 486 cpu [1][2]. SeaBIOS configures PIT in Mode 2. PIT counter is decremented in the mode but timer_adjust_bits() thinks that the counter overflows and increases 32-bit tick counter on each detected "overflow". Invalid overflow detection results in 55ms time advance (1 / 18.2Hz) on each read from PIT counter. So all timers expire much faster and 5-second floppy timeout expires in 83 real microseconds (or just a bit longer). It can be fixed by making the counter recieved from PIT an increasing value so it can be passed to timer_adjust_bits(): 0, 1, 2 and up to 65535 and then the counter is re-loaded with 0. 1. https://bugs.launchpad.net/seabios/+bug/1840719 2. https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg03924.html Fixes: eac11944019 ("Unify pmtimer_read() and pittimer_read() code.") Reported-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com> --- Changes since v1: - Simplified change of counter direction (Kevin) src/hw/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/timer.c b/src/hw/timer.c index 56bb289..b6f102e 100644 --- a/src/hw/timer.c +++ b/src/hw/timer.c @@ -180,7 +180,7 @@ timer_read(void) // Read from PIT. outb(PM_SEL_READBACK | PM_READ_VALUE | PM_READ_COUNTER0, PORT_PIT_MODE); u16 v = inb(PORT_PIT_COUNTER0) | (inb(PORT_PIT_COUNTER0) << 8); - return timer_adjust_bits(v, 0xffff); + return timer_adjust_bits(-v, 0xffff); } // Return the TSC value that is 'msecs' time in the future. -- 2.26.1

2 1

[PATCH] timer: Handle decrements of PIT counter
by Roman Bolshakov June 26, 2020

June 26, 2020

There's a fallback to PIT if TSC is not present but it doesn't work properly. It prevents boot from floppy on isapc and 486 cpu [1][2]. SeaBIOS configures PIT in Mode 2. PIT counter is decremented in the mode but timer_adjust_bits() thinks that the counter overflows and increases 32-bit tick counter on each detected "overflow". Invalid overflow detection results in 55ms time advance (1 / 18.2Hz) on each read from PIT counter. So all timers expire much faster and 5-second floppy timeout expires in 83 real microseconds (or just a bit longer). Provide counter direction to timer_adjust_bits() and normalize the counter to advance ticks in monotonically increasing TimerLast. 1. https://bugs.launchpad.net/seabios/+bug/1840719 2. https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg03924.html Fixes: eac11944019 ("Unify pmtimer_read() and pittimer_read() code.") Reported-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> Cc: Kevin O'Connor <kevin(a)koconnor.net> Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com> --- src/hw/timer.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/hw/timer.c b/src/hw/timer.c index 56bb289..2441402 100644 --- a/src/hw/timer.c +++ b/src/hw/timer.c @@ -156,10 +156,15 @@ u32 TimerLast VARLOW; // Add extra high bits to timers that have less than 32bits of precision. static u32 -timer_adjust_bits(u32 value, u32 validbits) +timer_adjust_bits(u32 value, u32 validbits, u8 countup) { u32 last = GET_LOW(TimerLast); - value = (last & ~validbits) | (value & validbits); + u32 validvalue; + if (countup) + validvalue = value & validbits; + else + validvalue = validbits - (value & validbits); + value = (last & ~validbits) | validvalue; if (value < last) value += validbits + 1; SET_LOW(TimerLast, value); @@ -176,11 +181,11 @@ timer_read(void) return rdtscll() >> GET_GLOBAL(ShiftTSC); if (CONFIG_PMTIMER && port != PORT_PIT_COUNTER0) // Read from PMTIMER - return timer_adjust_bits(inl(port), 0xffffff); + return timer_adjust_bits(inl(port), 0xffffff, 1); // Read from PIT. outb(PM_SEL_READBACK | PM_READ_VALUE | PM_READ_COUNTER0, PORT_PIT_MODE); u16 v = inb(PORT_PIT_COUNTER0) | (inb(PORT_PIT_COUNTER0) << 8); - return timer_adjust_bits(v, 0xffff); + return timer_adjust_bits(v, 0xffff, 0); } // Return the TSC value that is 'msecs' time in the future. -- 2.26.1

2 3

[PATCH] vga: fix cirrus bios
by Gerd Hoffmann June 25, 2020

June 25, 2020

Little mistake, big effect. The patch adding the ati driver broke cirrus due to a missing "else", which effectively downgrades cirrus to standard vga. Fixes: 34b6ecc16074 ("vga: add atiext driver") Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- vgasrc/vgahw.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vgasrc/vgahw.h b/vgasrc/vgahw.h index c774f4f2c6b7..8b64660e5ef7 100644 --- a/vgasrc/vgahw.h +++ b/vgasrc/vgahw.h @@ -36,7 +36,7 @@ static inline int vgahw_set_mode(struct vgamode_s *vmode_g, int flags) { static inline void vgahw_list_modes(u16 seg, u16 *dest, u16 *last) { if (CONFIG_VGA_CIRRUS) clext_list_modes(seg, dest, last); - if (CONFIG_VGA_ATI) + else if (CONFIG_VGA_ATI) ati_list_modes(seg, dest, last); else if (CONFIG_VGA_BOCHS) bochsvga_list_modes(seg, dest, last); -- 2.18.4

3 3

[PATCH v2] Preserve Xen DebugOutputPort
by Jason Andryuk June 24, 2020

June 24, 2020

xen_preinit() runs early and changes DebugOutputPort. qemu_preinit() runs soon after. inb on DebugOutputPort doesn't work on Xen, so the check will always fail and DebugOutputPort will be cleared to 0 disabling output. Quick exit the function when running on Xen to preserve the modified DebugOutputPort. Signed-off-by: Jason Andryuk <jandryuk(a)gmail.com> v2 Re-word comment --- src/hw/serialio.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/hw/serialio.c b/src/hw/serialio.c index 3163344..fa663b9 100644 --- a/src/hw/serialio.c +++ b/src/hw/serialio.c @@ -106,6 +106,10 @@ u16 DebugOutputPort VARFSEG = 0x402; void qemu_debug_preinit(void) { + /* Xen doesn't support checking if debug output is active. */ + if (runningOnXen()) + return; + /* Check if the QEMU debug output port is active */ if (CONFIG_DEBUG_IO && inb(GET_GLOBAL(DebugOutputPort)) != QEMU_DEBUGCON_READBACK) -- 2.25.1

2 2

[PATCH] Preserve Xen DebugOutputPort
by Jason Andryuk June 23, 2020

June 23, 2020

xen_preinit() runs early and changes DebugOutputPort. qemu_preinit() runs soon after. inb on DebugOutputPort doesn't work on Xen, so the check will always fail and DebugOutputPort will be cleared to 0 disabling output. Quick exit the function when running on Xen to preserve the modified DebugOutputPort. Signed-off-by: Jason Andryuk <jandryuk(a)gmail.com> --- src/hw/serialio.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/hw/serialio.c b/src/hw/serialio.c index 3163344..c6297bc 100644 --- a/src/hw/serialio.c +++ b/src/hw/serialio.c @@ -106,6 +106,10 @@ u16 DebugOutputPort VARFSEG = 0x402; void qemu_debug_preinit(void) { + /* Xen already overrode DebugOutputPort in xen_preinit(). */ + if (runningOnXen()) + return; + /* Check if the QEMU debug output port is active */ if (CONFIG_DEBUG_IO && inb(GET_GLOBAL(DebugOutputPort)) != QEMU_DEBUGCON_READBACK) -- 2.25.1

2 2

SeaBIOS and superformatted floppies
by felix June 22, 2020

June 22, 2020

Hello, Not so long ago, I have stumbled upon some rather disappointing behaviour in the SeaBIOS floppy driver. After some investigations, I concluded it would in fact be worthy of a bug report. So here it is. The problem is that when SeaBIOS starts, it looks up the type of the floppy drive in firmware configuration variables and internally stores a maximum disk geometry corresponding to the type of the drive. This geometry is later used to validate interrupt 0x13 requests and internally convert them to use LBA sector numbers, which are later converted back into CHS when communicating with the floppy controller. This design – apart from being somewhat silly in itself, with the shoehorned CHS-to-LBA-to-CHS conversion – prevents using SeaBIOS’s interrupt 0x13 service with superformatted floppies, i.e. those with geometries larger than typical for the initially detected drive type, even if the drive itself could handle such floppies without problems. Originally I ran into this problem in a VM setting, as I wanted to create and use larger-than-usual floppy images (without ever actually writing them to physical media); in QEMU source code, I noticed a table of geometries⁰ that are matched against floppy image sizes so that QEMU knows which geometry to present via the virtual floppy controller. The largest image size that is transparently handled by QEMU is 3840 KiB, corresponding to a geometry 48 sectors per track × 80 tracks × 2 sides in a ‘2880 KiB’ drive. SeaBIOS will however refuse to access sectors beyond the 36th (on whichever track), no matter what I do. And unless I remember to configure the floppy drive to use the ‘2880 KiB’ type, I am unable to access even DMF disk images (21 sect/trk × 80 trk × 2 sides) that are apparently supposed to be readable in ‘1440 KiB’ drives. So I would like to ask that for floppy drives, the interrupt 0x13 service should skip geometry validation and the back-and-forth address conversion, and pass the CHS coordinates unmodified to the floppy controller. As I have no idea how this change would impact real hardware (I have read some reports that superformatted floppies were less reliable than normal ones and sometimes even damaged the drive), I am not asking that validation be disabled on bare metal (!CONFIG_QEMU), although I suppose it would be useful there as well. For completeness though, I would also like to highlight XDF, which is a superformat with a non-uniform sector size. With the appropriate drivers installed, XDF disks are treated by the operating system as relatively ordinary floppies with a virtual geometry of 23 sect/trk × 80 trk × 2 sides × 512 B/sect. A virtual machine is usually able to present this geometry directly via the floppy controller (since it operates on flat disk images anyway), obviating the need for the driver, so the abovementioned workaround should be enough for a VM. On real hardware though, things are a little more complicated. Following OS/2 Museum¹: > Given XDF’s highly non-standard format, one might think that the DOS-based XDF utilities needed to use direct FDC access. They did not—instead, they showed just how far the standard floppy BIOS services can be convinced to go. > > For formatting, the BIOS user supplies a buffer containing per-sector parameters that the FDC then transfers during execution of the FORMAT TRACK command. For reads and writes, XDF dynamically changed the DPT (Diskette Parameter Table) and used the standard BIOS read/write services to access one sector at a time. I skimmed SeaBIOS floppy code, and apparently SeaBIOS only *sets* the DPT once at boot time with parameters like the sector size hardcoded, and later ignores it completely. Which means that if the XDF driver operates as the blog post says, it is not going to work with SeaBIOS. I imagine modifying the floppy driver to also take the DPT into account would be much more involved, so I am not requesting that. (Not to mention that I don’t even have the hardware to test.) But it sure would be nice, so it’s probably worth being written down in a TODO list somewhere. If there’s any. Regards, —f ⁰: <https://github.com/qemu/qemu/blob/eea8f5df4ecc607d64f091b8d916fcc11a697541/…> ¹: <http://www.os2museum.com/wp/the-xdf-diskette-format/>

4 6

Seabios Xen TPM check
by Jason Andryuk June 12, 2020

June 12, 2020

Hi, SeaBIOS commit 67643955c746 (make SeaBios compatible with Xen vTPM.) made tpm_start() exit before calling tpm_startup(). The commit message has no explanation why this change was made. Does anyone remember why it was made? The code today means SeaBIOS will not populate PCRs when running on Xen. If I revert the patch, SeaBIOS populates PCRs as one would expect. This is with a QEMU-emulated TPM backed by swtpm in TPM 1.2 mode (qemu & swtpm running in a linux stubdom). Any insight is appreciated. Thanks, Jason

2 2