SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] Serial keyboard support?
by Kevin O'Connor 26 Feb '16

26 Feb '16

On Thu, Feb 25, 2016 at 10:02:34AM -0800, Dustin Brazeau wrote: > As far as I can tell SeaBIOS does not currently support keyboard input over > serial. I was wondering if there is an unofficial patch that could add > support for this before I start looking into implementing it myself. Thanks. For traditional serial ports, sgabios generally fills that role. See the SeaBIOS coreboot wiki for info on sgabios: http://www.coreboot.org/SeaBIOS#Adding_sgabios_support -Kevin

1 0

Serial keyboard support?
by Dustin Brazeau 26 Feb '16

26 Feb '16

As far as I can tell SeaBIOS does not currently support keyboard input over serial. I was wondering if there is an unofficial patch that could add support for this before I start looking into implementing it myself. Thanks.

1 0

[PATCH] ld: fix .text section address alignment
by Roger Pau Monne 24 Feb '16

24 Feb '16

According to the output from readelf, the .text section should be aligned to 16: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] (null) NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 000de300 000300 021d00 00 AX 0 0 16 [...] This however doesn't seem to be enforced when the relocations are generated. The following patch tries to address this by making sure the space used for the relocations it also aligned to the same value as the .text section. Signed-off-by: Roger Pau Monné <roger.pau(a)citrix.com> Reported by: Ed Maste <emaste(a)FreeBSD.org> --- Cc: Kevin O'Connor <kevin(a)koconnor.net> --- scripts/layoutrom.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/layoutrom.py b/scripts/layoutrom.py index b976fb0..5534a9e 100755 --- a/scripts/layoutrom.py +++ b/scripts/layoutrom.py @@ -397,7 +397,7 @@ def writeLinkerScripts(li, out16, out32seg, out32flat): + strRelocs("_reloc_rel", "code32init_start", relrelocs) + strRelocs("_reloc_init", "code32flat_start", initrelocs)) numrelocs = len(absrelocs + relrelocs + initrelocs) - sec32all_start -= numrelocs * 4 + sec32all_start -= alignpos(numrelocs * 4, li.sec32low_align) filesections32flat = getSectionsFileid(li.sections, '32flat') out = outXRefs([], exportsyms=li.varlowsyms , forcedelta=li.final_sec32low_start-li.sec32low_start) -- 2.5.4 (Apple Git-61)

4 8

Re: [SeaBIOS] AHCI: Set transfer mode according to the capabilities of connected drive
by Kevin O'Connor 21 Feb '16

21 Feb '16

On Mon, Feb 15, 2016 at 12:00:48PM +0000, Zeh, Werner wrote: > Hi Kevin. > > We had some issues with some connected AHCI devices in SeaBIOS. We > have connected some CF-Cards by using a simple SATA<->IDE bridge to > the mainboard and in some cases, the drive (which is the CF-card) > was not recognized correctly. After some deeper analysis we found > that SeaBIOS does not set up the transfer rate which is used to > communicate to the drive. The supported transfer rate can be found > in the data structure which is delivered by IDENTIFY_DEVICE command. > > So in our error cases the default transfer rate was too high and > therefore data error has occurred. I have attached a patch which > will deal with this case on AHCI controllers. Maybe you can push > this patch to mainline or at least have a look at it. > > Up to now I have verified the function of this patch with the latest > master branch of SeaBIOS and a Broadwell-DE CPU. I have used PIO4, > default PIO, Multiword-DMA2 and several Ultra-DMA CF-cards to ensure > that all three paths work properly. > > BTW: I am not that familiar with code style in SeaBIOS. If I made > some formal mistakes, feel free to correct them. Thanks. I'm not that familiar with the AHCI internals. Gerd, would you be able to review? -Kevin

2 1

Error while compiling Seabios for Arch Linux ARM
by Xavier de Rauville 20 Feb '16

20 Feb '16

Greetings I am currently trying to compile Seabios for Arch Linux ARM and I've encountered an error during the compilation that appears to be caused by a misconfiguration in the file downloaded from here: http://code.coreboot.org/p/seabios/downloads/get/seabios-1.9.0.tar.gz I have attached a log containing the entire stdout and stderr stream output for Arch Linux's makepkg command but I think these might be the only lines of interest: Compile checking out/src/misc.o cc -Iout/ -Isrc -Os -MD -g -Wall -Wno-strict-aliasing -Wold-style-definition -Wtype-limits -m32 -march=i386 -mregparm=3 -mpreferred-stack-boundary=2 -minline-all-stringops -fomit-frame-pointer -freg-struct-return -ffreestanding -fno-delete-null-pointer-checks -ffunction-sections -fdata-sections -fno-common -fno-merge-constants -fno-stack-protector -fstack-check=no -DMODE16=0 -DMODESEGMENT=0 -c src/misc.c -o out/src/misc.o cc: error: unrecognized argument in option '-march=i386' cc: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc iwmmxt iwmmxt2 native cc: error: unrecognized command line option '-m32' cc: error: unrecognized command line option '-mregparm=3' cc: error: unrecognized command line option '-mpreferred-stack-boundary=2' cc: error: unrecognized command line option '-minline-all-stringops' Makefile:133: recipe for target 'out/src/misc.o' failed The files Arch Linux uses to compile Seabios can be found here if needed: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/… Can anyone help me get this error fixed? If a developer reads this and there is a bug in the code, would it be possible to fix it? Help will be greatly appreciated. Kind regards Xavier de Rauville

4 4

Re: [SeaBIOS] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU
by Alex Williamson 18 Feb '16

18 Feb '16

On Wed, 17 Feb 2016 11:09:49 +0000 "Tian, Kevin" <kevin.tian(a)intel.com> wrote: > > From: Alex Williamson > > Sent: Wednesday, February 17, 2016 5:39 AM > > > > QEMU provides two fw_cfg files to support IGD. The first holds the > > OpRegion data which holds the Video BIOS Table (VBT). This needs to > > be copied into reserved memory and the address stored in the ASL > > Storage register of the device at 0xFC offset in PCI config space. > > The OpRegion is generally 8KB. This file is named "etc/igd-opregion". > > > > The second file tells us the required size of the stolen memory space > > for the device. This is a dummy file, it has no backing so we only > > allocate the space without copying anything into it. This space > > requires 1MB alignment and is generally either 1MB or 2MB, depending > > on the hardware config. If the user has opted in QEMU to expose > > additional stolen memory beyond the GTT (GGMS), the GMS may add an > > additional 32MB to 512MB. The base address of the reserved memory > > allocated for this is written back to the Base Data of Stolen Memory > > register (BDSM) at PCI config offset 0x5C on the device. This file is > > named "etc/igd-bdsm". > > What would happen if guest tries to access this range while there is > no actual memory behind? Isn't it more clear to hide stolen memory > at all instead of reporting a dummy range? It's a fw_cfg file, it's not exposed to the guest, the purpose is to convey the size of stolen memory, which the BIOS then allocates as reserved memory and writes back to the BDSM register. It would be more clean to ignore stolen memory, but in cases where we need the vBIOS, such as laptops, where my LCD panel won't turn on without it, we don't have that luxury. The vBIOS programs the device to use stolen memory, at least 1MB, I assume for GTT purposes, and makes use of that for VESA modes. So, we need the vBIOS to support laptop panels, the vBIOS needs stolen memory for GTT space, therefore we need to provide some stolen memory. This support is enabled in QEMU by using a vBIOS, I assume vGPUs won't expose a ROM BAR and therefore won't enable this. Additionally for BDW/SKL+ (gen8+) GPUs, if the user specifies rombar=0 then all of this is disabled, including the hostbridge and ISA bridge manipulation in order to support UPT mode. Thanks, Alex

2 1

Re: [SeaBIOS] INT 1A - PCI Services supported?
by Bob Moore 18 Feb '16

18 Feb '16

Sorry for the bother people. I now see that PCI Services is supported (and configured in my source tree). I am now executing code in the 16 bit handler. Thanks. Bob From: Bob Moore Sent: Tuesday, February 16, 2016 4:50 PM To: 'seabios(a)seabios.org' Subject: INT 1A - PCI Services supported? Hello again, I have a need in my option ROM to interrogate devices identified by the BIOS PCI bus enumeration process. It seems like the most straight forward way to do this would be to use INT 1A assuming seaBios supports PCI 2.0 or later, to search for all instances of devices which I'm interested in. Can anyone confirm whether seaBios supports PCI 2.0 or later? I see a hardcoded org at 0xfe6e in romlayout.S that appears to be the entry to that handler. I've tried using the INT instruction as well as calling directly to 0xf000fe6e. Direct calls result in KVM crash as below. I suspect this is due to not using the proper 16/32 bit call interface. Using INT 1A I don't appear to be going through this code at all. Thanks. Bob Running option rom at ca80:0003 KVM internal error. Suberror: 1 emulation failure EAX=0000b102 EBX=0000ffff ECX=00008547 EDX=000011f8 ESI=00000000 EDI=000058b0 EBP=00000000 ESP=00006e4c EIP=f000fe6e EFL=00010202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =f000 000f0000 ffffffff 00809300 CS =ca80 000ca800 ffffffff 00809b00 SS =0000 00000000 ffffffff 00809300 DS =0000 00000000 ffffffff 00809300 FS =0000 00000000 ffffffff 00809300 GS =0000 00000000 ffffffff 00809300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 000f59c0 00000037 IDT= 00000000 000003ff CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 qemu: terminating on signal 2 Robert (Bob) L Moore Firmware Engineer CIBU Platform o: 719-799-4642 (ext. 244642) robert.moore(a)hgst.com<mailto:robert.moore@hgst.com> [cid:image001.png@01D13689.346E0520] 1975 Research Pkwy, Suite 135 Colorado Springs, CO 80920 www.wdc.com<http://www.wdc.com/> Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

1 0

INT 1A - PCI Services supported?
by Bob Moore 17 Feb '16

17 Feb '16

Hello again, I have a need in my option ROM to interrogate devices identified by the BIOS PCI bus enumeration process. It seems like the most straight forward way to do this would be to use INT 1A assuming seaBios supports PCI 2.0 or later, to search for all instances of devices which I'm interested in. Can anyone confirm whether seaBios supports PCI 2.0 or later? I see a hardcoded org at 0xfe6e in romlayout.S that appears to be the entry to that handler. I've tried using the INT instruction as well as calling directly to 0xf000fe6e. Direct calls result in KVM crash as below. I suspect this is due to not using the proper 16/32 bit call interface. Using INT 1A I don't appear to be going through this code at all. Thanks. Bob Running option rom at ca80:0003 KVM internal error. Suberror: 1 emulation failure EAX=0000b102 EBX=0000ffff ECX=00008547 EDX=000011f8 ESI=00000000 EDI=000058b0 EBP=00000000 ESP=00006e4c EIP=f000fe6e EFL=00010202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =f000 000f0000 ffffffff 00809300 CS =ca80 000ca800 ffffffff 00809b00 SS =0000 00000000 ffffffff 00809300 DS =0000 00000000 ffffffff 00809300 FS =0000 00000000 ffffffff 00809300 GS =0000 00000000 ffffffff 00809300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 000f59c0 00000037 IDT= 00000000 000003ff CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 qemu: terminating on signal 2 Robert (Bob) L Moore Firmware Engineer CIBU Platform o: 719-799-4642 (ext. 244642) robert.moore(a)hgst.com<mailto:robert.moore@hgst.com> [cid:image001.png@01D13689.346E0520] 1975 Research Pkwy, Suite 135 Colorado Springs, CO 80920 www.wdc.com<http://www.wdc.com/> Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

1 0

[SEABIOS] Plans for either 1.9.1 or 1.10.0?
by Ian Campbell 17 Feb '16

17 Feb '16

Hello, The xen.git development branch currently points to SeaBIOS rel-1.9.0, but Roger has tripped over a build issue which is fixed by 3b8c5378dfe2 "build: fix typo in buildversion.py". Is there any plan for either a 1.9.1 or a 1.10.0 in the near future which would include this, so I can roll forward to that? Or if not a 1.9.1 release perhaps for now just a 1.9-stable branch could be created? No problem if not, we'll just track master for a bit until there is a release. Thanks, Ian.

4 8

[RFC PATCH v3 0/3] IGD assignment support for QEMU/vfio
by Alex Williamson 16 Feb '16

16 Feb '16

Turns out that maybe we weren't done with IGD by simply reading a new fw_cfg, copying it into a new reserved memory buffer and writing back to the IGD device. We need another reserved memory buffer for stolen memory. The hardware minimum size is 1MB, naturally aligned, which means we need to be able to actually be able to allocate that. We write the address of the buffer back to the BDSM register on IGD so that QEMU can make use of it when doing fixups on vBIOS config of the device. Previous comments on updating the size of the high memory area suggest that any remaining free memory is returned, so it appears there's no affect of increasing this limit for systems without IGD. Thanks, Alex --- Alex Williamson (3): fw/pci: Add support for mapping Intel IGD OpRegion via QEMU Further increase maximum size of permanent high memory area. fw/pci: Allocate IGD stolen memory src/config.h | 2 +- src/fw/pciinit.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 42 insertions(+), 1 deletion(-)

5 21

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS