SeaBIOS September 2022

seabios@seabios.org

6 participants
6 discussions

[PATCH v4 0/4] Make seabios linkable with lld
by Fangrui Song 07 Dec '22

07 Dec '22

Another try after https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/KBHQU4… The only change is the removal of `Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf` since 699a4e5d6919cc8eae5342443025ceb6909dc276 ("ldnoexec: Add script to remove ET_EXEC flag from intermediate build objects") has done the same thing. For your convenience, the patch series is available on https://github.com/MaskRay/seabios/tree/lld Re-sending. I posted this 3 days but got bounced. I have now ensured there is my email address record on (previously not) https://mail.coreboot.org/postorius/lists/seabios.seabios.org/ as well as https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/ Fangrui Song (4): romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr Make rom16.o linkable with lld romlayout32flag.lds: Use `. +=` instead of `. =` test-build.sh: Delete unneeded LD capability test scripts/layoutrom.py | 8 +++++++- scripts/test-build.sh | 42 +----------------------------------------- src/romlayout.S | 2 +- 3 files changed, 9 insertions(+), 43 deletions(-) -- 2.37.0.144.g8ac04bfd2-goog

3 7

[RFC] PCIe-related MTRR inconsistency on Q35
by Alex Olson 29 Sep '22

29 Sep '22

Under SeaBIOS, I'm noticing that not all of the PCIe-related area is marked uncachable in the MTRR settings, at least in the Q35 platform (QEMU). I feel like this is a bug, but I'm not familar with the lore behind Q35 and MTRRs, feedback would be appreciated. The MCFG table contains an entry starting at Q35_HOST_BRIDGE_PCIEXBAR_ADDR (0xb0000000) corresponding to a 256MB area. Later, the mch_mem_addr_setup() routine defines the PCIe window (pcimem_start) starting at 0xc0000000 (Q35_HOST_BRIDGE_PCIEXBAR_ADDR + Q35_HOST_BRIDGE_PCIEXBAR_SIZE). I see in mtrr_setup(), that only a single variable MTRR is configured based solely on pcimem_start and extends to the end of the 4GB boundary. It looks to me that this is probably fine for 440fx, but seems insufficient for Q35. Q35 - original SeaBIOS 1.15.0: # cat /proc/mtrr reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable Q35 - original EFI (ovmf 2202.02) # cat /proc/mtrr reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg01: base=0x0b0000000 ( 2816MB), size= 256MB, count=1: uncachable reg02: base=0x800000000 (32768MB), size=32768MB, count=1: uncachable Thus, for Q35, there is no explict attempt to configure the Q35_HOST_BRIDGE_PCIEXBAR_ADDR area nor any potential the >4GB area used for PCIe I/O. The inherent size restrictions on MTRR mask definitions make a completely generic solution a bit tricky. Attached is a simple patch that enables use of the other variable MTRR registers. I believe solves the issue, but I'm not sure how to test it with a 64-bit PCIe window. In a simple setup, it results in the following: # cat /proc/mtrr reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg01: base=0x0b0000000 ( 2816MB), size= 256MB, count=1: uncachable Is this type of change appropriate? Would it make sense to remove direct use of pcimem_start from the mtrr.c code and just like the PCI code directly register the related range using the new mechanism? Thanks -Alex

2 1

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

change power to del
by Paul Edwards 20 Sep '22

20 Sep '22

I have a Chromebook and I instinctively reach for the del key which doesn't exist, get the power button and switch off my computer. I am running pdos, but freedos has the same problem. Would it be possible for seabios to use acpi to intercept the power button and turn it into a del key? I fully understand that if the user holds down the power button for long enough, like 10 seconds, it will do a forced power off that seabios can't stop. I am happy to live with that limitation. However, because of that limitation I would like another feature. I believe chromeos provides alt backspace as a substitute for del. I would like that logic to also be in seabios so that if I want to hold a del key down for a long time I need to use alt backspace instead of the power button. Putting the logic in seabios will fix lots of OSes, not just pdos and freedos, and I think that is the best place to put this logic. Any thoughts?

1 0

USB keyboard not detected with dGPU with USB Type-C port
by Paul Menzel 10 Sep '22

10 Sep '22

Dear SeaBIOS folks, Do you have any ideas regarding the USB issues with a dedicated GPU device with integrated USB Type-C port plugged in [1]? Kind regards, Paul [1]: https://ticket.coreboot.org/issues/414

2 1

[BUG] Could not read from CDROM (code 0003)
by Petr Cvek 31 Aug '22

31 Aug '22

Hello, I've tried to boot a coreboot supported machine (Kontron 986lcd-m) from CD and it hangs. The drive is correctly identified (AHCI ATAPI). Petr Log follows: Booting from DVD/CD... scsi_is_ready (drive=0x000f5820) disk_op d=0x000f5820 lba=0 buf=0x00000000 count=0 cmd=32 AHCI/2: send cmd ... AHCI/2: ... intbits 0x1, status 0x50 ... AHCI/2: ... finished, status 0x50, OK disk_op d=0x000f5820 lba=17 buf=0x000067a8 count=1 cmd=2 AHCI/2: send cmd ... handle_08 handle_hwpic1 irq=1 ... repeats ... handle_08 handle_hwpic1 irq=1 WARNING - Timeout at ahci_command:153! Boot failed: Could nothandle_08 handle_hwpic1 irq=1 read from CDROM (code 0003) enter handle_18: NULL Booting from Hard Disk... enter handle_13: a=00000201 b=00000000 c=00000001 d=00000080 ds=0000 es=07c0 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=f000 ip=ca99 f=0202 disk_op d=0x000f5870 lba=0 buf=0x00007c00 count=1 cmd=2 AHCI/1: send cmd ... AHCI/1: ... intbits 0x1, status 0x50 ... AHCI/1: ... finished, status 0x50, OK ahci disk read, lba 0, count 1, buf 0x00007c00, rc 0 Booting from 0000:7c00 ... continues with sata hdd ...

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS September 2022