May 2026 - SeaBIOS - mail.coreboot.org

regression: cannot boot from nvme anymore, disabling 64bit pci io window helps
by Marek Marczykowski-Górecki July 7, 2026

July 7, 2026

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 6

[PATCH v3 1/1] e820: Add E820_SOFT_RESERVED type support
by fanhuang May 18, 2026

May 18, 2026

Recognize E820 type 0xEFFFFFFF (Soft Reserved) emitted by QEMU's '-numa node,memmap-type=spm' option, propagate it to the guest E820, and bump RamSizeOver4G past the region. See the inline comment in qemu_early_e820() for the rationale. Signed-off-by: FangSheng Huang <FangSheng.Huang(a)amd.com> --- Changes since v2: - Per Gerd's review, drop the redundant below-4G WARNING branch. The unconditional region print already shows the address; an extra dprintf adds noise without information. The 4G guard itself is kept (silently skips the RamSizeOver4G update) to avoid u64 underflow if SPM ever lands below 4G. - Per Paul's review, expand the commit message with motivation and add the test transcript below. - Re-align the existing E820_* defines in e820map.h How tested: The QEMU 'memmap-type=spm' option is approved upstream [1] and will land in QEMU 11.1 (missed the 11.0 window). Tested with the series applied: qemu-system-x86_64 -m 16G \ -object memory-backend-memfd,size=8G,id=m0 \ -object memory-backend-memfd,size=8G,id=m1 \ -numa node,nodeid=0,memdev=m0 \ -numa node,nodeid=1,memdev=m1,memmap-type=spm \ ... SeaBIOS log: qemu/e820: addr 0x0000000280000000 len 0x0000000200000000 [soft-reserved] Guest dmesg: BIOS-e820: [mem 0x0000000280000000-0x000000047fffffff] soft reserved [1] https://lore.kernel.org/qemu-devel/20260306082735.1106690-2-FangSheng.Huang… src/e820map.h | 11 ++++++----- src/fw/paravirt.c | 22 ++++++++++++++++++++++ 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/src/e820map.h b/src/e820map.h index 07ce16ec..c23ccb0d 100644 --- a/src/e820map.h +++ b/src/e820map.h @@ -3,11 +3,12 @@ #include "types.h" // u64 -#define E820_RAM 1 -#define E820_RESERVED 2 -#define E820_ACPI 3 -#define E820_NVS 4 -#define E820_UNUSABLE 5 +#define E820_RAM 1 +#define E820_RESERVED 2 +#define E820_ACPI 3 +#define E820_NVS 4 +#define E820_UNUSABLE 5 +#define E820_SOFT_RESERVED 0xEFFFFFFF struct e820entry { u64 start; diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index e5d4eca0..a98bd6fc 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -768,6 +768,28 @@ static int qemu_early_e820(void) dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [reserved]\n", table.address, table.length); break; + case E820_SOFT_RESERVED: + e820_add(table.address, table.length, table.type); + dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [soft-reserved]\n", + table.address, table.length); + /* + * SPM (Specific Purpose Memory, e.g. GPU HBM exposed to the + * guest) is not RAM that SeaBIOS uses, but it occupies guest + * physical address space. Bump RamSizeOver4G so the 64-bit PCI + * MMIO window in pciinit.c (anchored at 0x100000000 + + * RamSizeOver4G) does not overlap the SPM region. + * + * This is slightly hacky -- SPM is not real RAM -- but is safe + * because SeaBIOS runs in 32-bit mode and never accesses memory + * above 4G itself. SPM regions are placed above 4G by + * convention; the guard below avoids u64 underflow if that ever + * changes. + */ + if (table.address >= 0x100000000LL) { + if (RamSizeOver4G < table.address + table.length - 0x100000000LL) + RamSizeOver4G = table.address + table.length - 0x100000000LL; + } + break; case E820_RAM: e820_add(table.address, table.length, table.type); dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [RAM]\n", -- 2.34.1

4 4

[PATCH v2 1/1] e820: Add E820_SOFT_RESERVED type support
by fanhuang May 13, 2026

May 13, 2026

Add support for E820 Soft Reserved Memory type which is used by QEMU to expose Specific Purpose Memory (SPM) regions. Changes: - Define E820_SOFT_RESERVED in e820map.h - Handle E820_SOFT_RESERVED in qemu_early_e820() Signed-off-by: FangSheng Huang <FangSheng.Huang(a)amd.com> --- Changes since v1: - Per Gerd's review, drop the above/below 4G dispatch in qemu_early_e820() and only update RamSizeOver4G; RamSize is no longer touched. Add the explanatory comment Gerd asked for, covering both the motivation (64-bit PCI window placement in pciinit.c) and why bumping RamSizeOver4G for non-RAM is safe (SeaBIOS is 32-bit and never accesses memory above 4G). - Keep an outer `if (table.address >= 0x100000000LL)` guard around the RamSizeOver4G update. This is *not* the original above/below dispatch coming back -- it is purely defensive, to avoid u64 underflow in `table.address + table.length - 0x100000000LL` if the SPM region ever lands below 4G. In that case we log a warning and leave RamSizeOver4G unchanged. In practice the guard never triggers: today's SPM producers (GPU HBM, CXL) are multi-GB and above 4G by platform convention. - Commit message unchanged. src/e820map.h | 1 + src/fw/paravirt.c | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/src/e820map.h b/src/e820map.h index 07ce16ec..a46fcc42 100644 --- a/src/e820map.h +++ b/src/e820map.h @@ -8,6 +8,7 @@ #define E820_ACPI 3 #define E820_NVS 4 #define E820_UNUSABLE 5 +#define E820_SOFT_RESERVED 0xEFFFFFFF struct e820entry { u64 start; diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index e5d4eca0..1e6ec336 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -768,6 +768,31 @@ static int qemu_early_e820(void) dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [reserved]\n", table.address, table.length); break; + case E820_SOFT_RESERVED: + e820_add(table.address, table.length, table.type); + dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [soft reserved]\n", + table.address, table.length); + /* + * SPM (Specific Purpose Memory, e.g. GPU HBM exposed to the + * guest) is not RAM that SeaBIOS uses, but it occupies guest + * physical address space. Bump RamSizeOver4G so the 64-bit PCI + * MMIO window in pciinit.c (anchored at 0x100000000 + + * RamSizeOver4G) does not overlap the SPM region. + * + * This is slightly hacky -- SPM is not real RAM -- but is safe + * because SeaBIOS runs in 32-bit mode and never accesses memory + * above 4G itself. SPM regions are placed above 4G by + * convention; the guard below avoids u64 underflow if that ever + * changes. + */ + if (table.address >= 0x100000000LL) { + if (RamSizeOver4G < table.address + table.length - 0x100000000LL) + RamSizeOver4G = table.address + table.length - 0x100000000LL; + } else { + dprintf(1, "qemu/e820: WARNING: SPM region below 4G is invalid; " + "RamSizeOver4G not updated\n"); + } + break; case E820_RAM: e820_add(table.address, table.length, table.type); dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [RAM]\n", -- 2.34.1

4 3

[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] e820: Add E820_SOFT_RESERVED type support
by fanhuang May 11, 2026

May 11, 2026

Add support for E820 Soft Reserved Memory type which is used by QEMU to expose Specific Purpose Memory (SPM) regions. Changes: - Define E820_SOFT_RESERVED in e820map.h - Handle E820_SOFT_RESERVED in qemu_early_e820() Signed-off-by: FangSheng Huang <FangSheng.Huang(a)amd.com> --- src/e820map.h | 1 + src/fw/paravirt.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+) diff --git a/src/e820map.h b/src/e820map.h index 07ce16ec..a46fcc42 100644 --- a/src/e820map.h +++ b/src/e820map.h @@ -8,6 +8,7 @@ #define E820_ACPI 3 #define E820_NVS 4 #define E820_UNUSABLE 5 +#define E820_SOFT_RESERVED 0xEFFFFFFF struct e820entry { u64 start; diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index e5d4eca0..802e30d0 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -768,6 +768,20 @@ static int qemu_early_e820(void) dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [reserved]\n", table.address, table.length); break; + case E820_SOFT_RESERVED: + e820_add(table.address, table.length, table.type); + dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [soft reserved]\n", + table.address, table.length); + if (table.address < 0x100000000LL) { + // below 4g + if (RamSize < table.address + table.length) + RamSize = table.address + table.length; + } else { + // above 4g + if (RamSizeOver4G < table.address + table.length - 0x100000000LL) + RamSizeOver4G = table.address + table.length - 0x100000000LL; + } + break; case E820_RAM: e820_add(table.address, table.length, table.type); dprintf(1, "qemu/e820: addr 0x%016llx len 0x%016llx [RAM]\n", -- 2.34.1

3 4

[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