SeaBIOS

seabios@seabios.org

2 participants
3799 discussions

[PATCH] Major bug in src/farptr.h
by william pecnik 05 Aug '24

05 Aug '24

the patch is in attach file to apply use "*patch src/farptr.h < farptr.patch*" from seabios directory This will fix the problem of calling bios service int 0x13 AH=0x42 when the drive is a ATAPI (because Outs should use DS:SI and not ES:DI) This bug affect all Outs() when called from real mode 16bits ! i save DS and restore it after, because Seabios use it

2 1

Major bug in src/farptr.h
by william pecnik 04 Aug '24

04 Aug '24

inlines outsb_fl() outsw_fl and outsl_fl are broken when used from real mode 16bits Outs use segment DS:SI not ES, so here is the fix: (assuming we save DS and restore it because Seabios use it) static inline void outsb_fl(u16 port, void *ptr_fl, u16 count) { u16 ds = GET_SEG(DS); SET_SEG(DS, FLATPTR_TO_SEG(ptr_fl)); outsb(port, (u8*)FLATPTR_TO_OFFSET(ptr_fl), count); SET_SEG(DS, ds); } static inline void outsw_fl(u16 port, void *ptr_fl, u16 count) { u16 ds = GET_SEG(DS); SET_SEG(DS, FLATPTR_TO_SEG(ptr_fl)); outsw(port, (u16*)FLATPTR_TO_OFFSET(ptr_fl), count); SET_SEG(DS, ds); } static inline void outsl_fl(u16 port, void *ptr_fl, u16 count) { u16 ds = GET_SEG(DS); SET_SEG(DS, FLATPTR_TO_SEG(ptr_fl)); outsl(port, (u32*)FLATPTR_TO_OFFSET(ptr_fl), count); SET_SEG(DS, ds); }

1 0

Thinkpad W530 Windows 10/11 BSOD
by Simon Dominic 22 Jul '24

22 Jul '24

Hi, When I compile coreboot for the Thinkpad W530 with SeaBIOS and even with vga bios roms (both integrated and discrete) and try to run Windows 10 or 11, I get BSOD "ACPI BIOS ERROR". Even just sticking in the Windows install usb and loading that, that error shows up. Thanks Simon

1 0

[PATCH] boot: Add an option to always show boot menu
by Timothy Redaelli 19 Jul '24

19 Jul '24

Always show boot menu when show-boot-menu is set to 3. A good use case for that is when you want to use SeaBIOS as secondary payload on Coreboot (for example, for GRUB2) and you need it only to boot from USB stick or stuff like that. Signed-off-by: Timothy Redaelli <tredaelli(a)redhat.com> --- docs/Runtime_config.md | 2 +- src/boot.c | 33 ++++++++++++++++++--------------- 2 files changed, 19 insertions(+), 16 deletions(-) diff --git a/docs/Runtime_config.md b/docs/Runtime_config.md index 5795382b..89c01f90 100644 --- a/docs/Runtime_config.md +++ b/docs/Runtime_config.md @@ -173,7 +173,7 @@ There are several additional configuration options available in the | Filename | Description |---------------------|--------------------------------------------------- -| show-boot-menu | Controls the display of the boot menu. Valid values are 0: Disable the boot menu, 1: Display boot menu unconditionally, 2: Skip boot menu if only one device is present. The default is 1. +| show-boot-menu | Controls the display of the boot menu. Valid values are 0: Disable the boot menu, 1: Display boot menu unconditionally, 2: Skip boot menu if only one device is present, 3: Always display boot menu without requiring a key press. The default is 1. | boot-menu-message | Customize the text boot menu message. Normally, when in text mode SeaBIOS will report the string "\\nPress ESC for boot menu.\\n\\n". This field allows the string to be changed. (This is a string field, and is added as a file containing the raw string.) | boot-menu-key | Controls which key activates the boot menu. The value stored is the DOS scan code (eg, 0x86 for F12, 0x01 for Esc). If this field is set, be sure to also customize the **boot-menu-message** field above. | boot-menu-wait | Amount of time (in milliseconds) to wait at the boot menu prompt before selecting the default boot. diff --git a/src/boot.c b/src/boot.c index 1effd802..cab41f62 100644 --- a/src/boot.c +++ b/src/boot.c @@ -708,21 +708,24 @@ interactive_bootmenu(void) return; } - while (get_keystroke(0) >= 0) - ; - - char *bootmsg = romfile_loadfile("etc/boot-menu-message", NULL); - int menukey = romfile_loadint("etc/boot-menu-key", 1); - printf("%s", bootmsg ?: "\nPress ESC for boot menu.\n\n"); - free(bootmsg); - - u32 menutime = romfile_loadint("etc/boot-menu-wait", DEFAULT_BOOTMENU_WAIT); - enable_bootsplash(); - int scan_code = get_keystroke(menutime); - disable_bootsplash(); - if (scan_code != menukey) - return; - + int menukey = 0, scan_code; + // wait for keypress + if (show_boot_menu != 3) { + while (get_keystroke(0) >= 0) + ; + + char *bootmsg = romfile_loadfile("etc/boot-menu-message", NULL); + menukey = romfile_loadint("etc/boot-menu-key", 1); + printf("%s", bootmsg ?: "\nPress ESC for boot menu.\n\n"); + free(bootmsg); + + u32 menutime = romfile_loadint("etc/boot-menu-wait", DEFAULT_BOOTMENU_WAIT); + enable_bootsplash(); + scan_code = get_keystroke(menutime); + disable_bootsplash(); + if (scan_code != menukey) + return; + } while (get_keystroke(0) >= 0) ; -- 2.45.2

1 0

regression: cannot boot from nvme anymore, disabling 64bit pci io window helps
by Marek Marczykowski-Górecki 15 Jul '24

15 Jul '24

Hi, After an update some time ago, a VM wit 8GB RAM cannot boot from nvme anymore. QEMU cmdline: /usr/bin/qemu-system-x86_64 \ -chardev ringbuf,id=serial0,logfile=serial0,logappend=on \ -serial chardev:serial0 \ -m 8192 \ -enable-kvm \ -vnc :2,share=force-shared \ -blockdev driver=file,node-name=hd0-file,filename=disk.qcow2,cache.no-flush=on,discard=unmap \ -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on,discard=unmap \ -device nvme,id=hd0-device,drive=hd0,serial=hd0 \ -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios \ -bios /home/user/seabios/out/bios.bin There is nothing fancy on the disk, just standard grub2 setup, but also I believe it doesn't matter, as it doesn't even reach grub. When it fails, the seabios log contains: PCI: 64: 0000038000000000 - 0000038040000000 PCI: map device bdf=00:04.0 bar 0, addr 38000000000, size 00004000 [mem] ... Searching bootorder for: /pci@i0cf8/isa@1/fdc@03f0/floppy@0 ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9) ATA controller 2 at 170/374/0 (irq 15 dev 9) Searching bootorder for: HALT Can not map memory bar over 4Gig ... Boot failed: could not read the boot disk Working version has this instead: PCI: map device bdf=00:04.0 bar 0, addr febf0000, size 00004000 [mem] ... Booting from Hard Disk... Booting from 0000:7c00 00:04.0 is the nvme. I'm attaching full logs for both cases. Bisect shows: 96a8d130a8c2e908e357ce62cd713f2cc0b0a2eb is the first bad commit commit 96a8d130a8c2e908e357ce62cd713f2cc0b0a2eb (HEAD) Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Fri Sep 9 10:17:15 2022 +0200 be less conservative with the 64bit pci io window Current seabios code will only enable and use the 64bit pci io window in case it runs out of space in the 32bit pci mmio window below 4G. This patch will also enable the 64bit pci io window when (a) RAM above 4G is present, and (b) the physical address space size is known, and (c) seabios is running on a 64bit capable processor. This operates with the assumption that guests which are ok with memory above 4G most likely can handle mmio above 4G too. In case the 64bit pci io window is enabled also assign more memory to prefetchable pci bridge windows and the complete 64bit pci io window. The total mmio window size is 1/8 of the physical address space. Minimum bridge windows size is 1/256 of the total mmio window size. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> I've tried the recent "[PATCH] limit address space used for pci devices, part two" patch from the ML, but it doesn't help. OTOH, the series with "only enable 64bit pci io window when RAM >64G" does help. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

3 3

[PATCH] limit address space used for pci devices, part two
by Gerd Hoffmann 24 Jun '24

24 Jun '24

This patch changes the logic added by commit a6ed6b701f0a ("limit address space used for pci devices.") a bit. Further testing showed that the limit of 46 phys-bits applies to x86_64 kernels only, for i386 kernels the limit is 44. So change the limit from 46 to 44 for better compatibility with i386 guests. Also add one more condition to refine the configuration heuristic: Apply the limit only in case the guest has less than 1 TB of memory installed, so huge guests run without address space limits. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/fw/pciinit.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index bb44dc296047..b3e359d7fe62 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -1189,11 +1189,16 @@ pci_setup(void) if (CPUPhysBits) { pci_mem64_top = 1LL << CPUPhysBits; - if (CPUPhysBits > 46) { - // Old linux kernels have trouble dealing with more than 46 - // phys-bits, so avoid that for now. Seems to be a bug in the - // virtio-pci driver. Reported: centos-7, ubuntu-18.04 - pci_mem64_top = 1LL << 46; + if (CPUPhysBits > 44) { + // Old linux kernels have trouble dealing with more than 44 (i386 + // kernels) or 46 (x86_64 kernels) phys-bits. Seems to be a bug in + // the virtio-pci driver. + // Reported: centos-7, ubuntu-18.04 + // Limit the used address space to mitigate the bug, except we are + // running in a huge guest with more than 1TB of memory installed. + if (RamSizeOver4G < (1LL << 40)) { + pci_mem64_top = 1LL << 44; + } } } -- 2.45.2

4 3

[PATCH 1/4] add debug when we set pci_pad_mem64
by John Levon 24 Jun '24

24 Jun '24

This is an interesting enough setting to add a dprintf() for. Signed-off-by: John Levon <john.levon(a)nutanix.com> --- src/fw/pciinit.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index bb44dc29..9ad4e41a 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -1197,8 +1197,10 @@ pci_setup(void) } } - if (CPUPhysBits >= 36 && CPULongMode && RamSizeOver4G) + if (CPUPhysBits >= 36 && CPULongMode && RamSizeOver4G) { + dprintf(1, "setting pci_pad_mem64=1\n"); pci_pad_mem64 = 1; + } dprintf(1, "=== PCI bus & bridge init ===\n"); if (pci_probe_host() != 0) { -- 2.34.1

5 19

no cert for git.seabios.org
by Michael Tokarev 17 Jun '24

17 Jun '24

FWIW, git.seabios.org can't be contacted anymore: $ git remote -v upstream https://git.seabios.org/seabios.git (fetch) upstream https://git.seabios.org/seabios.git (push) $ git remote update upstream Fetching upstream fatal: unable to access 'https://git.seabios.org/seabios.git/': gnutls_handshake() failed: The server name sent was not recognized error: could not fetch upstream Firefox shows SSL_ERROR_UNRECOGNIZED_NAME_ALERT error when trying https://git.seabios.org/ Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

1 0

Regression 32bit Kernel + Virtio-scsi
by Max Tottenham 13 Jun '24

13 Jun '24

Hi Folks The commits between be848676..a6ed6b701 appear to break QEMU guests using a 32bit kernel when booting from virtio_scsi devices. I end up seeing the following in dmesg: [ 2.016642] virtio_scsi: probe of virtio0 failed with error -2 Notably - I've tried modifying the amount of RAM the geust boots with, based on the comments in the commit messages, PAE *is* also enabled in the guest kernel (the kernel v6.1.76). qemu-system-x86_64 .... -m 2048M - Guest boots fine qemu-system-x86_64 .... -m 4095M - Guest does not boot. In the latter case I still see the 64 bit address space being used in the BIOS debug log in the latter case: 00.006: === PCI bus & bridge init === 00.006: PCI: pci_bios_init_bus_rec bus = 0x0 00.007: === PCI device probing === 00.007: Found 8 PCI devices (max PCI bus is 00) 00.008: PCIe: using q35 mmconfig at 0xb0000000 00.008: === PCI new allocation pass #1 === 00.008: PCI: check devices 00.009: === PCI new allocation pass #2 === 00.009: PCI: IO: c000 - c11f 00.009: PCI: 32: 00000000c0000000 - 00000000fec00000 00.009: PCI: 64: 0000380000000000 - 0000380040000000 00.009: PCI: map device bdf=00:02.0 bar 4, addr 380000000000, size 00004000 [prefmem] 00.010: PCI: map device bdf=00:03.0 bar 4, addr 380000004000, size 00004000 [prefmem] 00.010: PCI: map device bdf=00:04.0 bar 4, addr 380000008000, size 00004000 [prefmem] 00.010: PCI: map device bdf=00:02.0 bar 0, addr 0000c000, size 00000040 [io] 00.011: PCI: map device bdf=00:03.0 bar 0, addr 0000c040, size 00000040 [io] 00.011: PCI: map device bdf=00:04.0 bar 0, addr 0000c080, size 00000040 [io] 00.011: PCI: map device bdf=00:1f.3 bar 4, addr 0000c0c0, size 00000040 [io] 00.011: PCI: map device bdf=00:1f.2 bar 4, addr 0000c100, size 00000020 [io] 00.012: PCI: map device bdf=00:04.0 bar 6, addr feb80000, size 00040000 [mem] 00.012: PCI: map device bdf=00:01.0 bar 6, addr febc0000, size 00010000 [mem] 00.012: PCI: map device bdf=00:01.0 bar 2, addr febd0000, size 00001000 [mem] 00.012: PCI: map device bdf=00:02.0 bar 1, addr febd1000, size 00001000 [mem] 00.013: PCI: map device bdf=00:03.0 bar 1, addr febd2000, size 00001000 [mem] 00.013: PCI: map device bdf=00:04.0 bar 1, addr febd3000, size 00001000 [mem] 00.013: PCI: map device bdf=00:1f.2 bar 5, addr febd4000, size 00001000 [mem] 00.013: PCI: map device bdf=00:01.0 bar 0, addr fd000000, size 01000000 [prefmem] 00.014: PCI: init bdf=00:00.0 id=8086:29c0 00.014: PCI: init bdf=00:01.0 id=1234:1111 00.014: PCI: init bdf=00:02.0 id=1af4:1004 00.015: PCI: init bdf=00:03.0 id=1af4:1004 00.016: PCI: init bdf=00:04.0 id=1af4:1000 I'm happy to help test/provide more logs if they are useful. -- Max Tottenham | Senior Software Engineer /(* Akamai Technologies

3 7

Keyboard typematic rate and delay
by Eduardo Batalha 11 Jun '24

11 Jun '24

Hi, There is a UK based retro enthusiast named Andy who goes by the name rasteri or therastery in different social media networks. He is famous in the circle for his hardware hacks and creations. One of these is called the HIDMan [1], which is a USB mouse/keyboard to PS2/RS232 converter. Andy approached the wider community to get comments and to get volunteers to test the device on the VOGONS [2] forum. On page 9 of the topic, another user (Eivind) is trying to test if he can change the keyboard typematic rate and delay from Freedos using the MODE CON RATE=xx DELAY=xx command only to conclude that he cannot do it because the function [4] that passes the values to the keyboard controller [5] in the keyboard is not implemented [6] in the Seabios based computer that he is using. This is obviously a very obscure and edge case as far as Seabios is concerned, probably not worth the effort to fix but it is, anyway, interesting as it highlights the issue that the users expected a certain BIOS function to be available and it was not. There are probably others... Maybe it would be nice to have a TODO file somewhere in the documentation highlighting issues like these, which could also serve as a guide to potential new contributors. Cheers, Eduardo [1] https://github.com/rasteri/HIDman [2] https://www.vogons.org/viewtopic.php?f=24&t=89777 [3] https://www.vogons.org/viewtopic.php?f=24&t=89777&start=160 [4] http://www.techhelpmanual.com/232-int_16h_03h__set_keyboard_typematic_rate_… [5] https://github.com/Halicery/8042/blob/main/8048_AT_INTERN.TEXT [6] https://review.coreboot.org/plugins/gitiles/seabios/+/refs/heads/master/src…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS