April 2026 - SeaBIOS - mail.coreboot.org

[PATCH 1/1] boot: try one disk after another until system boots successfully
by Dongli Zhang May 12, 2026

May 12, 2026

SeaBIOS relies on the "bootorder" provided by QEMU to determine the boot device order. If QEMU does not configure "bootorder", SeaBIOS may instead prioritize disks based on the order in which they are probed. In that case, only the first disk may be tried. If booting from it fails, SeaBIOS may move on to other media rather than attempting the remaining disks. As a result, if QEMU provides an incorrect "bootorder", or if SeaBIOS's probe-based ordering does not place the boot disk first, SeaBIOS may fail to boot from the intended boot disk. Below is an example demonstrating how SeaBIOS can fail to boot due to a QEMU bug. 1. Create a QEMU instance with a virtio-scsi HBA and keep it in the prelaunch state. Use SeaBIOS rather than UEFI. -device virtio-scsi-pci,id=scsi0,num_queues=4 \ -S \ 2. First, attach the boot disk, then attach the secondary disk. (qemu) drive_add 0 file=boot.qcow2,if=none,id=drive0 (qemu) device_add scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=1,bootindex=1 (qemu) drive_add 0 file=secondary.qcow2,if=none,id=drive1 (qemu) device_add scsi-hd,drive=drive1,bus=scsi0.0,channel=0,scsi-id=0,lun=2,bootindex=-1 3. Start the VM from the prelaunch state. QEMU doesn't update "bootorder" due to a QEMU bug. SeaBIOS attempts to boot from the secondary disk only once and then stops. As a result, the VM fails to boot. The symptom is not reproducible with EDK2/UEFI boot. While this issue needs to be fixed in QEMU, enhance SeaBIOS to try each disk in turn until the system boots successfully. Signed-off-by: Dongli Zhang <dongli.zhang(a)oracle.com> --- The QEMU bugfix has been sent to: https://lore.kernel.org/qemu-devel/20260225220556.11049-1-dongli.zhang@orac… src/boot.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/boot.c b/src/boot.c index 5c37daf..84743a6 100644 --- a/src/boot.c +++ b/src/boot.c @@ -1000,8 +1000,14 @@ do_boot(int seq_nr) boot_disk(0x00, CheckFloppySig); break; case IPL_TYPE_HARDDISK: + struct bios_data_area_s *bda = MAKE_FLATPTR(SEG_BDA, 0); + int i; printf("Booting from Hard Disk...\n"); - boot_disk(0x80, 1); + if (bda) { + for (i = 0; i < bda->hdcount; i++) + boot_disk(0x80 + i, 1); + } else + boot_disk(0x80, 1); break; case IPL_TYPE_CDROM: boot_cdrom((void*)ie->vector); -- 2.39.3

2 1

[PATCH] Implement semantic OFW path matching and unit address parsing
by Glenn Griffin May 12, 2026

May 12, 2026

Introduce a robust semantic matcher for Open Firmware (OFW) device paths to replace the previous prefix-based string matching logic. This change enables SeaBIOS to accurately correlate bootorder entries with concrete hardware devices by understanding the topological structure and addressing scheme of IEEE 1275-compliant paths. Key changes: - Implement parse_hex to handle standard and relaxed unit addresses (e.g., treating "@1,0" and "@1" as equivalent for function 0). - Implement fw_path_match to perform node-by-node comparisons, supporting wildcards ('*') for both node names and unit addresses. - Incorporate a generic name fallback mechanism where nodes match based solely on unit addresses if names differ, essential for Broadcom/standard PCI addressing compatibility. - Update find_prio and boot_lchs_find to utilize the new semantic matcher, ensuring consistent behavior across boot priority and disk geometry selection. These improvements ensure that boot ordering remains predictable and flexible even when host-side tools use generic labels or when controller driver names vary within the guest. Signed-off-by: Glenn Griffin <glenng(a)google.com> --- src/boot.c | 142 +++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 126 insertions(+), 16 deletions(-) diff --git a/src/boot.c b/src/boot.c index 5c37dafd..d60950c1 100644 --- a/src/boot.c +++ b/src/boot.c @@ -29,24 +29,134 @@ // See if 'str' starts with 'glob' - if glob contains an '*' character // it will match any number of characters in str that aren't a '/' or // the next glob character. -static char * -glob_prefix(const char *glob, const char *str) +// Parse a hex number from a string. +static int +parse_hex(const char **ptr) { - for (;;) { - if (!*glob && (!*str || *str == '/')) - return (char*)str; - if (*glob == '*') { - if (!*str || *str == '/' || *str == glob[1]) - glob++; - else - str++; + const char *p = *ptr; + int val = 0; + while (1) { + char c = *p; + if (c >= '0' && c <= '9') + val = (val << 4) | (c - '0'); + else if (c >= 'a' && c <= 'f') + val = (val << 4) | (c - 'a' + 10); + else if (c >= 'A' && c <= 'F') + val = (val << 4) | (c - 'A' + 10); + else + break; + p++; + } + *ptr = p; + return val; +} + +// Perform semantic matching of an Open Firmware path glob against a concrete path. +// Supports: +// - '*' wildcard for node names (e.g., /pci@* matches /pci@i0cf8) +// - Generic fallback: if addresses match, node name is ignored (e.g. /disk@3,0 matches /nvme@3) +// - Relaxed unit address matching (e.g., @3,0 matches @3) +static int +fw_path_match(const char *glob, const char *path) +{ + while (*glob && *path) { + // match separators + if (*glob == '/') { + if (*path != '/') + return 0; + glob++; + path++; continue; } - if (*glob != *str) - return NULL; - glob++; - str++; + + // parse node name + const char *glob_end = strchr(glob, '@'); + const char *path_end = strchr(path, '@'); + // Handle cases where @ is missing (malformed or root?) or next char is / + const char *glob_slash = strchr(glob, '/'); + const char *path_slash = strchr(path, '/'); + + if (!glob_end || (glob_slash && glob_slash < glob_end)) + glob_end = glob_slash ? glob_slash : glob + strlen(glob); + if (!path_end || (path_slash && path_slash < path_end)) + path_end = path_slash ? path_slash : path + strlen(path); + + int glob_len = glob_end - glob; + int path_len = path_end - path; + + // Check Name Match + int name_match = 0; + if (glob[0] == '*') + name_match = 1; // Wildcard matches anything + else if (glob_len == path_len && memcmp(glob, path, glob_len) == 0) + name_match = 1; // Exact match + + glob = glob_end; + path = path_end; + + // Check Address Match + int glob_has_addr = (*glob == '@'); + int path_has_addr = (*path == '@'); + + if (glob_has_addr != path_has_addr) + return 0; // Structure mismatch + + if (glob_has_addr) { + glob++; + path++; + + // Check for wildcard in address + if (glob[0] == '*') { + // Wildcard address matches any path address + // But we still require structure match (both had @) + // We advance pointers past address + // Consume glob address until / or end + while (*glob && *glob != '/') glob++; + // Consume path address until / or end + while (*path && *path != '/') path++; + + // If name matched (or was *) AND address is *, then match. + if (!name_match) return 0; + continue; + } + + // Parse Address + // Format: N[,M] + int glob_val1 = parse_hex(&glob); + int path_val1 = parse_hex(&path); + + if (glob_val1 != path_val1) + return 0; + + int glob_val2 = 0; + int path_val2 = 0; + + if (*glob == ',') { + glob++; + glob_val2 = parse_hex(&glob); + } + if (*path == ',') { + path++; + path_val2 = parse_hex(&path); + } + + // Semantic Address Match: Treat missing secondary address as 0 + // If addresses match, we consider the node a match even if names differed! + // (Generic PCI fallback logic: /ethernet@3 == /scsi@3 if address is 3) + if (glob_val2 != path_val2) + return 0; + + // If we are here, addresses matched. + // We ignore 'name_match' result (allow mismatch/alias) + } else { + // No addresses. Strict name match required (or wildcard) + if (!name_match) + return 0; + } } + + // Both must end or have matched fully + return (*glob == '\0' && *path == '\0'); } #define FW_PCI_DOMAIN "/pci@i0cf8" @@ -177,7 +287,7 @@ boot_lchs_find(const char *glob) dprintf(1, "Searching bios-geometry for: %s\n", glob); int i; for (i = 0; i < BiosGeometryCount; i++) - if (glob_prefix(glob, BiosGeometry[i].name)) + if (fw_path_match(glob, BiosGeometry[i].name)) return &BiosGeometry[i]; return NULL; } @@ -290,7 +400,7 @@ find_prio(const char *glob) dprintf(1, "Searching bootorder for: %s\n", glob); int i; for (i = 0; i < BootorderCount; i++) - if (glob_prefix(glob, Bootorder[i])) + if (fw_path_match(glob, Bootorder[i])) return i+1; return -1; } -- 2.52.0.457.g6b5491de43-goog

2 1

[PATCH 1/13] scripts: Increase BUILD_MIN_BIOSTABLE for auto-sized and 128KB ROMs
by Mike Banon May 6, 2026

May 6, 2026

scripts: Increase BUILD_MIN_BIOSTABLE for auto-sized and 128KB ROMs When CONFIG_ROM_SIZE is left at 0 (auto), checkrom.py will automatically determine the ROM size based on the actual binary size (up to 256KB). However, layoutrom.py only increased BUILD_MIN_BIOSTABLE to 8192 when CONFIG_ROM_SIZE was explicitly set to 256 or larger. This meant that if the code grew large enough to require a 256KB ROM, layoutrom.py would still use the smaller 2048-byte F-segment reserve, potentially causing resource allocation problems in case of a big number of boot entries. Also, 128KB ROMs should have a larger 4096-byte F-segment reserve. Fix this erroneous behavior for non-specified CONFIG_ROM_SIZE case by calculating the total raw size of all sections that will be placed in the ROM. This raw sum underestimates the final binary size by roughly 5% due to alignment padding and relocation tables, so if it exceeds 64KB we can reliably conclude the final ROM will be at least 128KB and set BUILD_MIN_BIOSTABLE = 4096; if it exceeds 128KB the final ROM will be 256KB and we set BUILD_MIN_BIOSTABLE = 8192, matching the behavior for explicitly configured 128KB and 256KB ROMs. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> See the attached " 0001-scripts-Increase-BUILD_MIN_BIOSTABLE-for-auto-sized-and-128KB-ROMs.patch ". NOTE: this patch is a part of a large patch series that is also published at https://review.coreboot.org/c/coreboot/+/91769 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

3 3

[PATCH 3/13] config: Raise MPTABLE and SMBIOS F-segment size limits from 600 to 768
by Mike Banon May 6, 2026

May 6, 2026

config: Raise MPTABLE and SMBIOS F-segment size limits from 600 to 768 The current 600-byte limit for copying MPTABLE and SMBIOS tables to the F-segment is arbitrary and not aligned with power-of-two sizes. Some platforms require slightly larger tables (up to ~740 bytes), causing them to be truncated. Increase the limit to 768 bytes, a rounder value that provides ample headroom while remaining within the F-segment space. Adjust both limits for consistency. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> See the attached " 0003-config-Raise-MPTABLE-and-SMBIOS-F-segment-size-limits-from-600-to-768.patch ". NOTE: this patch is a part of a large patch series that is also published at https://review.coreboot.org/c/coreboot/+/91769 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 7

[PATCH 4/13] config: Increase BUILD_MAX_HIGHTABLE from 16MB to 80MB for large ramdisk support
by Mike Banon May 5, 2026

May 5, 2026

config: Increase BUILD_MAX_HIGHTABLE from 16MB to 80MB for large ramdisk support The BUILD_MAX_HIGHTABLE constant defines the maximum space that can be reserved in high-memory (ZoneHigh) for runtime tables and buffers. The current 16MB limit is sufficient for standard SeaBIOS operation but is inadequate to support custom-sized ramdisks as large as 63MB, the code for which is being added. A single ramdisk can be as large as 63 MB (2 heads * 1024 cylinders * 63 sectors per track * 512 bytes sector size). The ramdisk shared buffer must be allocated in ZoneHigh to persist across the boot process. Only one ramdisk is loaded at a time, its buffer must accommodate the full image. Raising BUILD_MAX_HIGHTABLE to 80MB provides headroom for a 63MB ramdisk plus additional runtime allocations, while remaining well within typical system RAM limits on modern hardware. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> See the attached " 0004-config-Increase-BUILD_MAX_HIGHTABLE-from-16MB-to-80M-for-large-ramdisk-support.patch ". NOTE: this patch is a part of a large patch series that is also published at https://review.coreboot.org/c/coreboot/+/91769 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

3 3

[PATCH 9/13] boot, ramdisk: Multiple ramdisk precise support with F-segment conservation
by Mike Banon April 29, 2026

April 29, 2026

boot, ramdisk: Multiple ramdisk precise support with F-segment conservation Extend ramdisk support to handle multiple images with full boot menu integration. Ramdisks and "BootList devices" (physical devices and secondary payloads) appear in a merged boot menu, sorted by bootorder priority. Ramdisks boot directly before PMM finalize, with automatic fallback to the next entry on failure. Meanwhile, the "BootList devices" hand off to the standard BEV flow. CRITICAL: Ramdisks use a separate pool (ramdisk_pool[]) rather than adding to BootList like BEV/BCV entries. This avoids F-segment exhaustion that would occur if each ramdisk allocated a separate drive_s structure in VARFSEG. Instead, a single shared buffer in ZoneHigh holds the selected image, while pool metadata resides in VARLOW. This design scales to multiple ramdisks without consuming precious F-segment space needed for option ROMs and ACPI / SMBIOS tables. To support this: - Add ramdisk_pool[] in VARLOW to store multiple ramdisk entries - Implement prepare_bootmenu() to merge ramdisks and BootList entries - Add apply_boot_selection() for unified boot selection handling - Move BEV[] and BootSequence to VARLOW to conserve F-segment space - Save/restore complete BDA state (media_state, motor_counter, DPT) - Set FDC data rate via PORT_FD_DIR and floppy_media_state BDA field - Support dual prefixes: "ramdisk/" and "floppyimg/" for backward compat - Defer bootorder name matching until after ramdisk pool initialization - Export boot_disk() for ramdisk.c to call directly This enables hobby OS developers/enthusiasts to test and use multiple floppies and ramdisk images from a single coreboot+SeaBIOS build without ROM reflashings, with bootorder control over ramdisk versus physical device / secondary payload priority. The implementation matches SeaBIOS floppy behavior, ensuring a better compatibility with OSes that expect standard floppy geometry and FDC config. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> See the attached " 0009-boot-ramdisk-Multiple-ramdisk-precise-support-with-F-segment-conservation.patch ". NOTE: this patch is a part of a large patch series that is also published at https://review.coreboot.org/c/coreboot/+/91769 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 6

[PATCH 1/2] bochsvga: use closest value in set_dacformat
by Daniel Verkamp April 22, 2026

April 22, 2026

Per the VBE 2.0 and 3.0 specs, for VBE function 08h (Set/Get DAC Palette format), if the caller requests a bits per color value that the hardware does not support, then the next lower value supported by the hardware is used. However, bochsvga_set_dacformat() was checking for exact matches of either 6 or 8 bits per color channel. Adjust the checks to allow larger values, clamping to either 8 or 6, and still indicating failure if a value lower than 6 is requested, as there are no lower supported values. Signed-off-by: Daniel Verkamp <daniel(a)drv.nu> --- vgasrc/bochsvga.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c index 3ef0f181..99ce26ca 100644 --- a/vgasrc/bochsvga.c +++ b/vgasrc/bochsvga.c @@ -176,10 +176,10 @@ bochsvga_set_dacformat(struct vgamode_s *curmode_g, int val) if (!bochsvga_dispi_enabled()) return stdvga_set_dacformat(curmode_g, val); u16 en = dispi_read(VBE_DISPI_INDEX_ENABLE); - if (val == 6) - en &= ~VBE_DISPI_8BIT_DAC; - else if (val == 8) + if (val >= 8) en |= VBE_DISPI_8BIT_DAC; + else if (val >= 6) + en &= ~VBE_DISPI_8BIT_DAC; else return -1; dispi_write(VBE_DISPI_INDEX_ENABLE, en); -- 2.53.0

3 7

[PATCH 2/13] config: Increase BUILD_MAX_EXTDRIVE from 16 to 36
by Mike Banon April 14, 2026

April 14, 2026

config: Increase BUILD_MAX_EXTDRIVE from 16 to 36 Raise the maximum number of drives per type (floppy, hard disk, CD-ROM) to 36. This provides additional headroom for systems with many drives, such as multiple hard disks, CD-ROMs, or virtual floppies. All arrays dimensioned by BUILD_MAX_EXTDRIVE expand accordingly, consuming negligible additional memory. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> See the attached " 0002-config-Increase-BUILD_MAX_EXTDRIVE-from-16-to-36.patch ". NOTE: this patch is a part of a large patch series that is also published at https://review.coreboot.org/c/coreboot/+/91769 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 4

[PATCH] README: update developer documentation link
by Daniel Verkamp April 9, 2026

April 9, 2026

The old URL doesn't work anymore; point it at the updated path. Signed-off-by: Daniel Verkamp <daniel(a)drv.nu> --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index e18be16f..4f906d6f 100644 --- a/README +++ b/README @@ -3,7 +3,7 @@ bios that is built with standard GNU tools. Please see build and developer information at: - http://seabios.org/Developer_Documentation + https://seabios.org/Developer_Documentation.html For the impatient, SeaBIOS is built for QEMU and tested on QEMU with: -- 2.53.0

4 3

[PATCH 13/13] boot: Increase menu timeout and ESC delay for slow-display compatibility
by Mike Banon April 6, 2026

April 6, 2026

boot: Increase menu timeout and ESC delay for slow-display compatibility Extend the default boot menu wait time to 9 seconds and the ESC key acceptance delay to 3 seconds. These adjustments accommodate systems with slow display initialization, ensuring the menu is fully visible before timeout or accidental dismissal. The longer delays prevent users from missing the prompt on sluggish screens and reduce the risk of unintended boots caused by habitual key mashing during the display warm-up period. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> See the attached " 0013-boot-Increase-menu-timeout-and-ESC-delay-for-slow-display-compatibility.patch ". NOTE: this patch is a part of a large patch series that is also published at https://review.coreboot.org/c/coreboot/+/91769 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0