SeaBIOS April 2022

seabios@seabios.org

11 participants
16 discussions

Re: INT 14H
by Paul Edwards 29 Sep '22

29 Sep '22

Hi Gerd. Thanks for your reply. Sorry for the delay, was swamped with other things. >> Currently I don't know what to recommend, because I >> don't understand the other side of the INT 13H/14H, >> only the OS side. > Well, the other side talks to the hardware, > and needs drivers to do so. See src/hw > Surely one can write a serial driver which connects to a remote place > using some bluetooth protocol instead of talking to a 16550. That'll > be *alot* of work though, you basically have to implement both > bluetooth stack and hardware driver. I expected to assemble, rather than write, such a thing. If not from the Linux source code, then FreeBSD or ReactOS. If for some reason (what would that be?) no-one has abstracted bluetooth to have a clean interface that I could have trivially reused, then I will put aside my bluetooth dreams and switch to a different technology. How about Wifi? Does that exist in a state usable for my purposes? >> Sure. For now, I want PDOS/386 to remain traditional. >> When I have exhausted everything that is possible >> via the BIOS, I will consider adding UEFI support. > If you want your firmware provide drivers to you for modern hardware you > are in a *much* better position with UEFI. Well, on some/many/most modern machines there is absolutely no other choice - the BIOS doesn't exist, even as CSM. > There is a bluetooth > protocol specification for example, although I'm not sure how common it > is to find an actual uefi driver for bluetooth hardware in the firmware. > Talking to ethernet using the firmware-provided uefi driver shouldn't be > much of a problem though b/c network boot is a rather standard feature. Ok, maybe in the medium term I should use a hardware device, forget the name, that turns ethernet into Wifi. So then the problem is reduced to me needing to provide a BOOTX64.EFI that converts INT 14H into UEFI ethernet calls. >> But I'd like to transport all of that software, designed for >> that environment, and change nothing at all, and have >> it work on a new environment that includes Wifi, bluetooth >> and maybe ethernet, and maybe infrared, and maybe >> other things I don't know about, but make sense (at >> some level) to be accessed via INT 14H. > Well. In the server world it is rather common to provide access to the > serial line over the network for system management purposes. > One approach for that is to have a separate management controller (bmc), > and the serial port of the machine is linked to the management > controller instead of a D9 socket. You can then connect to the bmc to > manage the machine, and one of the options available is to get serial > console access. Ok, this would allow me to have a BBS. But not allow me to have a "virtual modem" so that I can dial out. > Another approach is to have a virtual 16550 provided by the firmware. > Accessing the virtual 16550 will trap into SMM mode where the firmware > emulates a serial device and allows to access the serial port remotely > over the network, roughly comparable to how qemu provides an virtual > 16550 to virtual machines. Ok, but in the case of qemu I have the same issue - at the end of the day I want to drive a modem, so with qemu I can get it to talk to a "virtual modem". If the firmware is providing the serial to network conversion, I also need to stick in a virtual modem there. And that's what I was hoping SeaBIOS would allow me to do. > Note that both approaches work at hardware level not int14h level, > because modern operating systems use int14h services in bootloaders > only if at all. My operating system, PDOS/386, may not be considered "modern", even though it is in active development, but I do wish to use INT 14H, as that was the traditional BIOS service provided, and I wish to maintain contact with the original 80386 machines. I expect a modern environment to have the CPU, memory etc required to support this basic interface. BFN. Paul.

2 4

[PATCH v4 0/2] use large ZoneHigh when there is enough memory
by Gerd Hoffmann 03 May '22

03 May '22

v4: - make calculations more robust. v3: - check size instead of end address. Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 23 ++++++++++++++--------- 2 files changed, 16 insertions(+), 10 deletions(-) -- 2.35.1

2 4

EHCI cpage is out of range with qemu ehci controller
by lma 30 Apr '22

30 Apr '22

Hi all, I experienced an error about ehci current page on qemu + seabios v1.14: cpage out of range (5) processing error - resetting ehci HC We know that the EHCI spec defines valid range of ehci cpage to 0-4, But here is a 5, Obviously it's an issue. I added a EHCI controller, and attached a usb mass storage to the EHCI controller as boot device: host:~# qemu-system-x86_64 \ -accel kvm \ -bios /home/test/projects/seabios/out/bios.bin \ -m 4096 \ -device usb-ehci \ -blockdev driver=file,read-only=on,filename=/isos/openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20220314-Media.iso,node-name=iso \ -device usb-storage,drive=iso,bootindex=0 The issue is not 100% reproducible, I run the test 15 times with above steps, the issue occurs 1 or 2 times. The qemu version seems doesn't matter, I used to use qemu 5.2, 6.0 and latest git master, Got the same test result. It seems that the issue was introduced since seabios v1.14, It can be reproduced on latest seabios git master as well, It can't be reproduced on seabios 1.13 or older. The seabios commit b3fa8577 "kvm: add support for reading tsc frequency from kvmclock" seems to be the suspect. Thanks, Lin

2 1

[PATCH v3 0/2] use large ZoneHigh when there is enough memory
by Gerd Hoffmann 28 Apr '22

28 Apr '22

v3: - check size instead of end address. Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 18 +++++++++++------- 2 files changed, 13 insertions(+), 8 deletions(-) -- 2.35.1

2 6

[PATCH v2 0/2] use large ZoneHigh when there is enough memory
by Gerd Hoffmann 26 Apr '22

26 Apr '22

Gerd Hoffmann (2): malloc: use variable for ZoneHigh size malloc: use large ZoneHigh when there is enough memory src/config.h | 3 ++- src/malloc.c | 18 +++++++++++------- 2 files changed, 13 insertions(+), 8 deletions(-) -- 2.35.1

2 4

Re: Floppy setup
by Keith Hui 25 Apr '22

25 Apr '22

(Looping in the SeaBIOS mailing list again.) See this: https://www.seabios.org/Runtime_config It appears CMOS locations are a legacy artifact and files within the cbfs image (eg. etc/floppy0) is the preferred way of passing SeaBIOS settings. If you want a proper fix with the value stored in CMOS (and be configurable via nvramtool), you'll need to modify both SeaBIOS and the coreboot option table layout for your board. If you need help with coreboot and are not subscribed to that mailing list, I can reach out and loop you in. @Kevin - What are we to do for SeaBIOS settings that the we may want to change at runtime eg. via nvramtool? Are there any such settings? Keith On Sun, 24 Apr 2022 at 18:36, Petr Cvek <petrcvekcz(a)gmail.com> wrote: > > Linux actually reads the floppy type from the exact same CMOS location as QEMU compiled SeaBIOS: > > https://elixir.free-electrons.com/linux/v5.12.9/source/arch/x86/include/asm… > > and if I remember correctly I've had to force the type through floppy module parameter, before I modified the coreboot+SeaBIOS source codes. > > The other operating systems will probably try to read the CMOS location as well. IMO it is actually a standard bitfield in IBM PC compatible computer. Also all cmos.layout files start the configuration from bit 384 and some of them even have the first 120 bits explicitly defined as "reserved". > > Under these constraints I think it should be possible to change the line to something like this: > > if (CONFIG_QEMU || CONFIG_USE_CMOS) { > > With CONFIG_USE_CMOS be "n" by default so non floppy boards will end with the old code path. > > Petr > > > Dne 24. 04. 22 v 21:05 Keith Hui napsal(a): > > Hi Petr, > > > > Linux seems to have been able to pick up all the floppy drives on its own. > > > > But if you read a few more lines beyond the snippet you posted, you'll > > see that it only reads nvram for floppy types when compiled for and > > run on QEMU because that layout is hard coded and QEMU-specific. To > > extend it to other coreboot targets that layout will need to be > > incorporated into the option table of all coreboot mainboards, which > > isn't trivial and some boards don't even have floppy ports at all. And > > should those nvram bytes hold value for something else, results can be > > very unpredictable. > > > > You'll also see another way around it, using files etc/floppy0 and > > etc/floppy1 added to the coreboot image. Some tracing within this file > > will tell you what values to use. Downside is changing these values > > also requires reflashing. > > > > Hope this helps. > > > > Keith > > > > On Sun, 24 Apr 2022 at 07:15, Petr Cvek <petrcvekcz(a)gmail.com> wrote: > >> > >> Hello, > >> > >> I was playing with coreboot + floppy and it seems the drive type can be read from CMOS only if the machine is QEMU. > >> > >> payloads/external/SeaBIOS/seabios/src/hw/floppy.c > >> > >> floppy_setup(void) > >> { > >> ... > >> if (CONFIG_QEMU) { > >> u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE); > >> if (type & 0xf0) > >> addFloppy(0, type >> 4); > >> ... > >> } else { > >> u8 type = romfile_loadint("etc/floppy0", 0); > >> ... > >> > >> Is it possible enable this function for a real coreboot target? What way is the most acceptable way to do it (something like || CONFIG_USE_CMOS)? > >> > >> I've forced it with "always true" condition and after adding configurations to cmos table and superio in coreboot, I was able to boot msdos on kontron 986lcd-m board. > >> > >> P.S. original message got stuck somewhere in the mailserver as I forgot to subscribe to seabios mailing list. > >> > >> Regards, > >> Petr > >> _______________________________________________ > >> SeaBIOS mailing list -- seabios(a)seabios.org > >> To unsubscribe send an email to seabios-leave(a)seabios.org

3 2

Floppy setup
by Petr Cvek 24 Apr '22

24 Apr '22

Hello, I was playing with coreboot + floppy and it seems the drive type can be read from CMOS only if the machine is QEMU. payloads/external/SeaBIOS/seabios/src/hw/floppy.c floppy_setup(void) { ... if (CONFIG_QEMU) { u8 type = rtc_read(CMOS_FLOPPY_DRIVE_TYPE); if (type & 0xf0) addFloppy(0, type >> 4); ... } else { u8 type = romfile_loadint("etc/floppy0", 0); ... Is it possible enable this function for a real coreboot target? What way is the most acceptable way to do it (something like || CONFIG_USE_CMOS)? I've forced it with "always true" condition and after adding configurations to cmos table and superio in coreboot, I was able to boot msdos on kontron 986lcd-m board. P.S. original message got stuck somewhere in the mailserver as I forgot to subscribe to seabios mailing list. Regards, Petr

1 0

CDROM/DVD timeouts on real hardware
by Petr Cvek 24 Apr '22

24 Apr '22

Hi, Has anybody tried to boot from CDROM/DVD non-QEMU seabios lately? I've tried to boot a few CDs/DVDs on AHCI and IDE drives and although the drive is detected, it will fail to boot. There is a timeout after which the next drive will boot. It seems the timeout is located somewhere in payloads/external/SeaBIOS/seabios/src/cdrom.c in function cdrom_boot(). When I tried to comment out this test: int ret = scsi_is_ready(&dop); if (ret) dprintf(5, "scsi_is_ready returned %d\n", ret); I was able to boot windows 98SE installation CD, but it failed after a few sectors (probably when the readiness was needed to be tested :D). If somebody can confirm it is not just my board setup (kontron 986lcd-m with the current coreboot branch) I would be grateful. P.S. original message got stuck somewhere in the mailserver as I forgot to subscribe to seabios mailing list. regards, Petr

1 0

[PATCH] memory: reserve more space for ZoneHigh
by Gerd Hoffmann 22 Apr '22

22 Apr '22

Bump BUILD_MAX_HIGHTABLE from 256k to 1M to avoid running out of memory with very large smbios tables. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/config.h b/src/config.h index 93c8dbc2d530..f4b19898a1f0 100644 --- a/src/config.h +++ b/src/config.h @@ -17,7 +17,7 @@ // Maximum number of map entries in the e820 map #define BUILD_MAX_E820 32 // Space to reserve in high-memory for tables -#define BUILD_MAX_HIGHTABLE (256*1024) +#define BUILD_MAX_HIGHTABLE (1024*1024) // Largest supported externaly facing drive id #define BUILD_MAX_EXTDRIVE 16 // Number of bytes the smbios may be and still live in the f-segment -- 2.35.1

2 1

[PATCH] MP: fix mptable interrupt source generation for pci devices
by Jay Khandkar 22 Apr '22

22 Apr '22

Set the correct IOAPIC INTIN pin number for pci bus interrupt sources during MP spec table generation (on emulators). Currently, the pin number is set to the interrupt line field in the device's configuration space, which is set to either IRQ 10 or 11 as the boot rom driver expects. This works since qemu maps all ISA compatible PIC IRQs onto IOAPIC pins 0-15, including PIRQs. But it will break if, for some reason, the IRQ is routed to something other than the INTLINE value using, for eg. ACPI _CRS. This patch ensures the pin number is set to the correct value (16-23) that the INTx pin is routed to in APIC mode, in agreement with the ACPI _PRT provided routing. Tested on a Linux 5.17.2 guest on qemu with the pci=nomsi and acpi=noirq boot parameters to force MP table parsing for interrupt sources. Signed-off-by: Jay Khandkar <jaykhandkar2002(a)gmail.com> --- src/fw/mptable.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/src/fw/mptable.c b/src/fw/mptable.c index 47385cc..3a7b02f 100644 --- a/src/fw/mptable.c +++ b/src/fw/mptable.c @@ -18,6 +18,33 @@ #include "util.h" // MaxCountCPUs #include "x86.h" // cpuid +/* table to obtain IOAPIC INTIN pin # for a certain pci slot and pin */ + +/* daisy chaining in line with acpi _PRT */ +#define SLOT_GSIE {0x14, 0x15, 0x16, 0x17} +#define SLOT_GSIF {0x15, 0x16, 0x17, 0x14} +#define SLOT_GSIG {0x16, 0x17, 0x14, 0x15} +#define SLOT_GSIH {0x17, 0x14, 0x15, 0x16} +#define SLOT_GSIA {0x10, 0x11, 0x12, 0x13} + +u8 pirq_intin[32][4] = { SLOT_GSIE, SLOT_GSIF, SLOT_GSIG, SLOT_GSIH, + SLOT_GSIE, SLOT_GSIF, SLOT_GSIG, SLOT_GSIH, + SLOT_GSIE, SLOT_GSIF, SLOT_GSIG, SLOT_GSIH, + SLOT_GSIE, SLOT_GSIF, SLOT_GSIG, SLOT_GSIH, + SLOT_GSIE, SLOT_GSIF, SLOT_GSIG, SLOT_GSIH, + SLOT_GSIE, SLOT_GSIF, SLOT_GSIG, SLOT_GSIH, + SLOT_GSIE, + + /* INTA -> PIRQA for slot 25 - 31, but 30 + see the default value of D<N>IR */ + SLOT_GSIA, SLOT_GSIA, SLOT_GSIA, SLOT_GSIA, + SLOT_GSIA, + + /* PCIe->PCI bridge. use PIRQ[E-H] */ + SLOT_GSIE, + + SLOT_GSIA }; + void mptable_setup(void) { @@ -114,7 +141,6 @@ mptable_setup(void) if (pci_bdf_to_bus(bdf) != 0) break; int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN); - int irq = pci_config_readb(bdf, PCI_INTERRUPT_LINE); if (pin == 0) continue; if (dev != pci_bdf_to_busdev(bdf)) { @@ -131,7 +157,7 @@ mptable_setup(void) intsrc->srcbus = pci_bdf_to_bus(bdf); /* PCI bus */ intsrc->srcbusirq = (pci_bdf_to_dev(bdf) << 2) | (pin - 1); intsrc->dstapic = ioapic_id; - intsrc->dstirq = irq; + intsrc->dstirq = pirq_intin[pci_bdf_to_dev(bdf)][pin - 1]; intsrc++; } -- 2.35.2

6 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS April 2022