SeaBIOS

seabios@seabios.org

3770 discussions

Re: [PATCH 1/1] virtio-blk: Fix incorrect type conversion in virtio_blk_op()
by Xiaofei 11 Nov '22

11 Nov '22

On Fri, 11 Nov 2022 09:35:19 +0800 Fei Xiao <hbuxiaofei(a)gmail.com> wrote: > [Cc: +Andy] > > Dear Xiaofei, > > > Thank you very much for the patch. > > Am 10.11.22 um 06:34 schrieb Xiaofei: > > When using spdk aio bdev driver, the qemu command line like > > this: > > Please remove the leading spaces in the line above. > > > qemu-system-x86_64 \ > > -chardev socket,id=char0,path=/tmp/vhost.0 \ > > -device vhost-user-blk-pci,id=blk0,chardev=char0 \ > > ... > > > > Boot failure message as below: > > Ditto. > > > e820 map has 7 items: > > 0: 0000000000000000 - 000000000009fc00 = 1 RAM > > 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED > > 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > > 3: 0000000000100000 - 000000007ffdd000 = 1 RAM > > 4: 000000007ffdd000 - 0000000080000000 = 2 RESERVED > > 5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED > > 6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED > > enter handle_19: > > NULL > > Booting from Hard Disk... > > Boot failed: could not read the boot disk > > Is this a regression in commit a05af290bac5 (virtio-blk: split large > IO according to size_max). If so, maybe add > > Fixes: a05af290bac5 ("virtio-blk: split large IO according to > size_max") > > > Signed-off-by: Xiaofei <hbuxiaofei(a)gmail.com> > > --- > > src/hw/virtio-blk.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c > > index 9b4a05a..ce3265e 100644 > > --- a/src/hw/virtio-blk.c > > +++ b/src/hw/virtio-blk.c > > @@ -92,7 +92,7 @@ virtio_blk_op(struct disk_op_s *op, int write) > > u16 blk_num_max; > > > > if (vdrive->drive.blksize != 0 && max_io_size != 0) > > - blk_num_max = (u16)max_io_size / vdrive->drive.blksize; > > + blk_num_max = (u16)(max_io_size / vdrive->drive.blksize); > > else > > /* default blk_num_max if hardware doesnot advise a > > proper > value */ > > blk_num_max = 64; > > Acked-by: Paul Menzel <pmenzel(a)molgen.mpg.de> > > > Kind regards, > > Paul > > > -- > > 2.27.0 > > > > _______________________________________________ > > SeaBIOS mailing list -- seabios(a)seabios.org > > To unsubscribe send an email to seabios-leave(a)seabios.org Thanks for your suggestion, this is indeed a bug of patch a05af290bac5. I will remove useless leading spaces. Regards, Xiaofei

1 0

[PATCH 1/1] virtio-blk: Fix incorrect type conversion in virtio_blk_op()
by Xiaofei 10 Nov '22

10 Nov '22

When using spdk aio bdev driver, the qemu command line like this: qemu-system-x86_64 \ -chardev socket,id=char0,path=/tmp/vhost.0 \ -device vhost-user-blk-pci,id=blk0,chardev=char0 \ ... Boot failure message as below: e820 map has 7 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000007ffdd000 = 1 RAM 4: 000000007ffdd000 - 0000000080000000 = 2 RESERVED 5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED 6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED enter handle_19: NULL Booting from Hard Disk... Boot failed: could not read the boot disk Signed-off-by: Xiaofei <hbuxiaofei(a)gmail.com> --- src/hw/virtio-blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index 9b4a05a..ce3265e 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -92,7 +92,7 @@ virtio_blk_op(struct disk_op_s *op, int write) u16 blk_num_max; if (vdrive->drive.blksize != 0 && max_io_size != 0) - blk_num_max = (u16)max_io_size / vdrive->drive.blksize; + blk_num_max = (u16)(max_io_size / vdrive->drive.blksize); else /* default blk_num_max if hardware doesnot advise a proper value */ blk_num_max = 64; -- 2.27.0

3 2

PCIe ECAM space
by Ugo Cirmignani 10 Nov '22

10 Nov '22

Hello, I would like to read the MAC address from PCIe ECAM space under SeaBIOS, I have been able to read from the PCI standard registers with the pci_config_read(w-l-b) functions, but I have seen that there are no functions to read from the ECAM space. According to the PCIe standards there is a base address and an offset for each PCIe device where to read from, but it seems there are no examples or other implementation in the source codes except for QEMU. Any help would be appreciated. Regards Ugo

2 1

Fails to make/build on ubuntu '-mdisable-fpregs'
by Craig Lalley 11 Oct '22

11 Oct '22

I would like to work with the seabios-hppa, but I can't seem to get it to build. It fails with a compiler command line option -mdisable-fpregs I am using GCCCraig@Ubuntu-VM:~/KVM/HPUX/seabios-hppa$ gcc --versiongcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc. craig@Ubuntu-VM:~/KVM/HPUX$ git clone https://github.com/hdeller/seabios-hppa.gitCloning into 'seabios-hppa'... remote: Enumerating objects: 18038, done. remote: Counting objects: 100% (1740/1740), done. remote: Compressing objects: 100% (596/596), done. remote: Total 18038 (delta 1178), reused 1695 (delta 1141), pack-reused 16298 Receiving objects: 100% (18038/18038), 4.17 MiB | 5.70 MiB/s, done. Resolving deltas: 100% (14315/14315), done. craig@Ubuntu-VM:~/KVM/HPUX$ cd seabios-hppa/ craig@Ubuntu-VM:~/KVM/HPUX/seabios-hppa$ make menuconfig craig@Ubuntu-VM:~/KVM/HPUX/seabios-hppa$ make parisc DIRS="" make -f Makefile.parisc all Build Kconfig config file # # configuration written to /home/craig/KVM/HPUX/seabios-hppa/.config # Version: seabios-hppa-v6-0-g458626c4-dirty-20221010_171647-Ubuntu-VM Compile checking out/head.o cc: error: unrecognized command-line option '-mdisable-fpregs' make[1]: *** [Makefile.parisc:148: out/head.o] Error 1 make: *** [Makefile:110: parisc] Error 2 craig@Ubuntu-VM:~/KVM/HPUX/seabios-hppa$ If I remove the -mdisable-fpregs, I get a LOT of errors. What am I doing wrong? QEMU-HPPA builds with no problems. Any help is appreciated. Regards, -Craig

1 0

[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 01 Sep '22

01 Sep '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

Re: Animated GIF bootsplash: Failure to decode ImageMagick generated GIFs (invalid GIF signature)
by Paul Menzel 29 Aug '22

29 Aug '22

Dear Michael, Am 23.08.22 um 16:30 schrieb Michael Bacarella: > On Tue, Aug 23, 2022 at 12:06 AM Paul Menzel wrote: >> Am 22.08.22 um 21:23 schrieb Michael Bacarella: >>> On Sat, Aug 20, 2022 at 11:45 PM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> >>>> Thank you for implementing this. If you send a patch, I can test on real >>>> hardware. >> >> […] >> >>> Patch attached. I replied here rather than with a new email with a PATCH subject >>> because I don't consider it ready to merge, more like a POC. >>> >>> Also I'm using gmail, hope I don't embarrass myself. >> >> Unfortunately, Gmail wraps lines after 72(?) characters so the diff is >> malformed. Maybe attach the file generated by `git format-patch -1`? > > My apologies. Attached here. I noticed another thing, that GIFs created by ImageMagick’s convert cannot be decoded. With your converted example image [1] $ dpkg -l imagemagick […] ii imagemagick 8:6.9.11.60+dfsg-1.3+b3 amd64 image manipulation programs -- binaries $ convert bootsplash.gif -resize 1280x1024+32 bootsplash2.gif $ identify bootsplash2.gif bootsplash2.gif[0] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 0.000u 0:00.001 bootsplash2.gif[1] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 0.000u 0:00.000 bootsplash2.gif[2] GIF 1280x960 1280x960+0+0 8-bit sRGB 256c 2.05915MiB 0.000u 0:00.000 or bb.gif [2] $ identify bb.gif bb.gif[0] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[1] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[2] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[3] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[4] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[5] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[6] GIF 100x100 100x100+0+0 8-bit sRGB 2c 0.000u 0:00.000 bb.gif[7] GIF 100x100 100x100+0+0 8-bit sRGB 2c 1446B 0.000u 0:00.000 I get: Decoding bootsplash.gif invalid GIF signature gif_decode failed with return code -1... Kind regards, Paul [1]: https://michael.bacarella.com/bootsplash.gif [2]: https://www.opensourcecook.in/sites/default/files/bb.gif

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
377
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS