SeaBIOS January 2021

seabios@seabios.org

6 participants
4 discussions

[PATCH v3 0/5] Make seabios linkable with lld

by Fangrui Song

This patch series make seabios linkable with lld. This is beneficial for FreeBSD ports as well https://svnweb.freebsd.org/ports/head/misc/seabios/Makefile as they can drop an LLD_UNSAFE As a maintainer of lld ELF, I have triaged numerous pieces of software. seabios is the only one making use of This drops the only instance https://sourceware.org/bugzilla/show_bug.cgi?id=12726 1, 2, 3 and 4 are really independent and can be applied in arbitrary order. 5 depends on 4. I originally combined 4 and 5 and that was why I don't think a patch series made sense. Fangrui Song (5): romlayout.S: Add missing SHF_ALLOC flag to .fixedaddr.\addr Make rom16.o linkable with lld Makefile: Change ET_EXEC to ET_REL so that lld can link bios.bin.elf romlayout32flag.lds: Use `. +=` instead of `. =` test-build.sh: Delete unneeded LD capability test Makefile | 4 ++++ scripts/layoutrom.py | 13 ++++++++++--- scripts/test-build.sh | 42 +----------------------------------------- src/romlayout.S | 2 +- 4 files changed, 16 insertions(+), 45 deletions(-) -- 2.26.0.292.g33ef6b2f38-goog

2 months, 1 week

[PATCH] AHCI: The attached ATA device cannot be detected when binding AHCI controller to Virtual Machine

by RunaGuo-oc＠zhaoxin.com

When binding AHCI controller to virtual machine, the attached ATA device cannot be recognized for the following reason: The first Identify PACKET CMD will be failed without dobut which will lead PORT_IRQ_TF_ERR be set in PxIS due to ERR bit set to 1 in D2H Register FIS(PxTFD.STS.ERR=1). In this case, the first CMD will be timeout for seabios only polling PORT_IRQ_D2H_REG_FIS & PORT_IRQ_PIOS_FIS before triggering error handling which leads AHCI controller is an error state, then the second IDENTIFY CMD cannot be issued by AHCI controller, no ATA device will be detected. In AHCI spec HBA Port State Machine section(5.3.8.1 and 5.3.16.5), we can see this sequence: RegFIS:Entry --> ERR:FatalTaskfile (PxTFD.STS.ERR=1) --> ERR:WaitForClear, no entry for PORT_IRQ_D2H_REG_FIS/PORT_IRQ_PIOS_FIS to be set at this time. May be we can also add PORT_IRQ_TF_ERR bit check when polling command completion status? fail log: 02.386: |bffa6000| AHCI/1: link up 02.387: |bffa6000| AHCI/1: send cmd ... 02.387: |bffa7000| phys_free bffa9c00 (detail=0xbffaa320) 02.396: |bffa7000| phys_free bffaa200 (detail=0xbffaa1d0) 02.396: |bffa7000| phys_free bffaa000 (detail=0xbffaa1a0) 02.396: |bffa7000| phys_free bffaa380 (detail=0xbffaa350) 02.400: \bffa7000/ End thread 02.401: phys_free bffa7000 (detail=0xbffaa170) 34.391: |bffa6000| WARNING - Timeout at ahci_command:153! 34.392: |bffa6000| AHCI/1: send cmd ... 66.397: |bffa6000| WARNING - Timeout at ahci_command:153! Signed-off-by: zhaoxin\runaguooc <RunaGuo-oc(a)zhaoxin.com> --- src/hw/ahci.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/hw/ahci.c b/src/hw/ahci.c index d45b430..bab5c35 100644 --- a/src/hw/ahci.c +++ b/src/hw/ahci.c @@ -104,7 +104,7 @@ static void ahci_port_writel(struct ahci_ctrl_s *ctrl, u32 pnr, u32 reg, u32 val static int ahci_command(struct ahci_port_s *port_gf, int iswrite, int isatapi, void *buffer, u32 bsize) { - u32 val, status, success, flags, intbits, error; + u32 val, status, success, flags, intbits, error, tf; struct ahci_ctrl_s *ctrl = port_gf->ctrl; struct ahci_cmd_s *cmd = port_gf->cmd; struct ahci_fis_s *fis = port_gf->fis; @@ -148,6 +148,14 @@ static int ahci_command(struct ahci_port_s *port_gf, int iswrite, int isatapi, error = GET_LOWFLAT(fis->rfis[3]); break; } + + if(intbits & PORT_IRQ_TF_ERR){ + tf = ahci_port_readl(ctrl,pnr,PORT_TFDATA); + status = tf & 0xff; + error = tf & 0xff00; + break; + } + } if (timer_check(end)) { warn_timeout(); -- 2.17.1

6 months, 3 weeks

[PATCH 1/4] pci: Allow scanning pci bus number up to 255 in CSM mode

by Bin Gao

On real hardware especially server platforms, there might be multiple root buses, thus pci bus number could run up to 255. This patch fixed pci_probe_devices() by allowing to scan all 256 pci bus numbers(0-255). Signed-off-by: Bin Gao <gaobin(a)amazon.com> --- src/hw/pcidevice.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/hw/pcidevice.c b/src/hw/pcidevice.c index 8853cf7..8d9c401 100644 --- a/src/hw/pcidevice.c +++ b/src/hw/pcidevice.c @@ -26,6 +26,14 @@ pci_probe_devices(void) struct hlist_node **pprev = &PCIDevices.first; int extraroots = romfile_loadint("etc/extra-pci-roots", 0); int bus = -1, lastbus = 0, rootbuses = 0, count=0; + + // There might be multiple PCI root buses on physical hardware especially + // server platforms, thus bus number could run up to the top value, + // i.e. 0xff. Setting extraroots to 0xff to ensure we can enumerate all + // PCI bus numbers. + if (CONFIG_CSM) + extraroots = 0xff; + while (bus < 0xff && (bus < MaxPCIBus || rootbuses < extraroots)) { bus++; int bdf; -- 2.17.1

8 months, 3 weeks

CDOS 386 keyboard handling

by LE LIEGARD, Stephane

Hello, Host : centos 7 Guest : Concurrent DOS 386 v3.00 (problem also happen on DOS 3.0) QEMU : v5.1.0 Virtualbox : v6.1.14 Seabios : seabios-rel-1.13.0 I first started to run some tests to debug the alt-gr behavior, and I ended up noticing something strange. This issue is the same as this one: https://bugs.launchpad.net/qemu/+bug/1574246 So I have an old computer with CDOS installed directly on it (i486-DX2 processeur), and I have to virtualize it with QEMU. Lets call this computer “antique”. When I run the command ‘n’ in cdos, I select French and I install AZERTY 102 keys 8 bit keyboard. Then when i press alt-gr + 3, on antique and vbox it display ‘#’, but on QEMU ,it doesn’t, it print the gibberish ^@ sequence. So VBox handle keyboard input properly, but not qemu. I investigated to see if the problem was how QEMU interpret the alt-gr, and I thought it was, because the flags set in registers AH and AL when I press alt-gr are the same as when I press Alt (AH=0x2, AL=0x8) according to this site: http://helppc.netcore2k.net/table/bda : AH – 40:18 AL – 40:17 So I launched qemu and vbox in debug mode, with gdb for qemu and the included debbuger for vbox. By breaking on 0xF000:0xFFF0 and inspecting the IVT, I could see that CDOS replaces the IRQ handler because the address stored at 0x24 (irq 9) change after I resume execution, and when I inspect the machine code at 0xAF:0x618 (address of the IRQ 9 stored in 0x24 after cdos has started), it’s the same on qemu and vbox. The behavior and scancodes received are the same on QEMU and VBox in the CDOS irq 1 handler. I break on the respective BIOS irq 1 handler, called from the CDOS irq 1 handler, and at this point the byte read on 0x60 differs. Exemple for alt-gr, so 0xE038: * … * %000000000000113f e4 60 in AL, 060h // CDOS read 0xE0 from port 0x60 * … * CDOS call bios handler * … * %00000000000fe987 e4 60 in AL, 060h // VBOX bios read 0xE0, QEMU bios read 0x38 * … I didn’t see any command from CDOS irq 1 handler that would tell the PS2 controller to refeed the last byte read on the port 0x60, and all the BIOS does before the read is to deactivate the keyboard by writing 0xAD to port 0x64, so I think the issue could be from how the ps2 controller is emulated on QEMU. Somehow, VBOX knows that it has to keep the value in it’s output buffer after the first read, or maybe some kind of timer, idk. I join to this mail the asm of the CDOS irq 1 handler that I extracted from the debugger. If someone could help me to create a fix, even not official, that we could use on our project. Thanks a lot. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

9 months, 2 weeks

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS January 2021