SeaBIOS

seabios@seabios.org

3775 discussions

SeaVGABIOS ignores preserve-memory flag
by felix 13 Jul '20

13 Jul '20

Hello, here’s another defect I’ve found, this time in SeaVGABIOS. Video BIOS interrupt 0x10 subfunction 0 accepts a flag that determines whether video memory should be preserved after mode change. SeaVGABIOS ignores this flag. The reason is a buggy implementation of the interrupt call in vgasrc/vgabios.c: > static void > handle_1000(struct bregs *regs) > { > int mode = regs->al & 0x7f; > > // Set regs->al > if (mode > 7) > regs->al = 0x20; > else if (mode == 6) > regs->al = 0x3f; > else > regs->al = 0x30; > > int flags = MF_LEGACY | (GET_BDA(modeset_ctl) & > (MF_NOPALETTE|MF_GRAYSUM)); > if (regs->al & 0x80) > flags |= MF_NOCLEARMEM; > > vga_set_mode(mode, flags); > } The AL register’s structure member is overwritten by the chained if before the flag is checked, which means the flag is never picked up. This is a regression from commit 5108c69c47e18244206593c0c7918711311d8ef3, which removed the noclearmem variable that stashed the flag for later.[0] Sloppy refactoring aside, there was no explanation for this condition chain, so I became puzzled as to why the register was being overwritten in the first place. It seems this was meant to mimic a behaviour described in Ralf Brown’s: > Return: AL = video mode flag (Phoenix, AMI BIOS) > 20h mode > 7 > 30h modes 0-5 and 7 > 3Fh mode 6 > AL = CRT controller mode byte (Phoenix 386 BIOS v1.10) I have checked this with an Intel video BIOS on a physical machine, and it left the register untouched, so this behaviour seems hardly universal. Not even DOSBox emulates this, and I think they do have some incentives to emulate these calls as faithfully (to old hardware) as possible, so that is saying something. (Not to mention RBIL itself describes two conflicting behaviours here.) So I doubt that this condition chain needs to be kept in the first place. But even if it is kept, I think it should be moved a little later. And probably commented too. [0]: https://git.seabios.org/cgit/seabios.git/commit/vgasrc/vgabios.c?id=5108c69… — Regards, f

2 1

ld: cannot use executable file 'out/rom16.strip.o' as input to a link
by Paul Menzel 09 Jul '20

09 Jul '20

Dear SeaBIOS folks, Updating Debian Sid/unstable to binutils 2.34.90.20200706-1, the SeaBIOS for coreboot build fails with the error below. > Building ld scripts > Version: rel-1.13.0-47-g4d3f03d > Fixed space: 0xe05b-0x10000 total: 8101 slack: 9 Percent slack: 0.1% > 16bit size: 35712 > 32bit segmented size: 1665 > 32bit flat size: 32271 > 32bit flat init size: 54112 > Lowmem size: 2224 > f-segment var size: 1232 > Linking out/rom16.o > Linking out/rom32seg.o > Stripping out/rom32seg.strip.o > Stripping out/rom16.strip.o > Linking out/rom.o > ld: cannot use executable file 'out/rom16.strip.o' as input to a link > make: *** [Makefile:190: out/rom.o] Fehler 1 Kind regards, Paul

2 1

[PATCH v2] timer: Handle decrements of PIT counter
by Roman Bolshakov 26 Jun '20

26 Jun '20

2 1

[PATCH] timer: Handle decrements of PIT counter
by Roman Bolshakov 26 Jun '20

26 Jun '20

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 25 Jun '20

25 Jun '20

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 24 Jun '20

24 Jun '20

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 23 Jun '20

23 Jun '20

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 22 Jun '20

22 Jun '20

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 11 Jun '20

11 Jun '20

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

Boot order?
by Mogens Jensen 25 May '20

25 May '20

First posted this question to coreboot mailing list, but on second thought, I think this is the right place. I have experimentet with coreboot on my CompuLab Intense PC (Ivy Bridge) for some time, and I think everything is working now, with Intel ME disabled. Although, I have some troubles with boot selection. I'm currently running coreboot [4cea00a64] with default SeaBIOS payload [v1.13.0] and a bootorder file. The boot device search order is this: 1. USB 2.0 device 2. USB 3.0 device 3. SATA devices (in order: 2.5″ internal, mSATA, eSATA, FACE module) During testing I have been running the system from a USB 3.0 flash disk. This worked as expected and system would automatically select this device during boot/reboot. I then wanted to use the internal 2.5" SATA disk, so I installed an OS and confirmed it working by manually selecting the SATA disk in boot menu. I then removed boot sector from flash disk, reboot and expected that the system would now automatically boot from internal SATA disk, but this happened instead: === Booting from Hard Disk... Boot failed: not a bootable disk Booting from Floppy... Boot failed: not a bootable disk No bootable device. Retrying in 60 seconds. === Not sure what is going on with "Floppy". No such thing exists on the system. If I remove flash disk from USB port before power on, the system will boot correctly from internal SATA disk. Is this correct behaviour? I would expect that it should not matter that flash disk is inserted in USB port, as long as no boot sector is present on the device. If this is NOT correct behaviour, then what could be the problem here? Thanks in advance. Regards, Mogens Jensen

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS