SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[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 20 Feb '16

20 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 19 Feb '16

19 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 17 Feb '16

17 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 16 Feb '16

16 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

Re: [SeaBIOS] Chromebook doesn't boot BSD
by Ronny Schneider 15 Feb '16

15 Feb '16

> Am 15.02.2016 um 15:40 schrieb edward wandasiewicz <0.w3ntd(a)gmail.com>: > > On Sun, Feb 14, 2016 at 11:02 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Sun, Feb 14, 2016 at 08:30:47PM +0100, Ronny Schneider wrote: >>>> Am 14.02.2016 um 19:29 schrieb Kevin O'Connor <kevin(a)koconnor.net>: >>>> On Sun, Feb 14, 2016 at 06:04:16PM +0100, Ronny Schneider wrote: >>>>> Hello there, >>>>> >>>>> i have a Toshiba Chromebook 2 (CB30-B-104) with a flashed on SeaBIOS by the script from John Lewis: https://johnlewis.ie/custom-chromebook-firmware/rom-download/ >>>>> >>>>> Linux is running very well but i want to see OpenBSD 5.8 on this laptop. But it’s not working, neither do FreeBSD 10.2, NetBSD 7.0 or DragonFly 4.2. The boot stops at the point where the kernel wants to mount the root-filesystem. I even copied an installed OpenBSD-System from an usb-stick onto the emmc-flash of the chromebook but it’s not working. >>>>> >>>>> I googled arround and found out the problem is not unknown among the Chromebook Pixel. So i thought i could help a little by providing my cbmem-bootlog for my machine: http://pastebin.com/asLqar5q >>>>> If i can do more to see OpenBSD booting on this laptop, please let me know :-) >>>> >>>> When you say "it's not working" - what happens - does the machine hang or does it attempt to reboot? >>>> If it hangs, are you sure the machine is really stuck instead of just the display not working? >>> >>> The Display is working all the time. Using NetBSD, it also applies the native resolution of the panel. >>> >>>> If it hangs, can you provide all the information on the screen prior to the hang. >>> >>> I used the amd64 install-images on an 64GB USB3-Stick for the following pictures. If you want me to copy the installer-images onto the mmc of the chromebook, tell me please. >>> >>> With FreeBSD 11 it freezes. The machine hangs at the moment the kernel tries to mount the root-filesystem and does not respond to any keypress anymore. I have to shutdown the chromebook by keep pressing on the powerbutton for a few seconds. >>> Image: http://bilderhochladen.org/i/SFrHFStWws/ >>> >>> With OpenBSD 5.8 it „stalls“. The Cursor is blinking but nothing more happens. Although the chromebook shuts down when the powerbutton is pressed. >>> Image: http://bilderhochladen.org/i/4jFRYDYO11/ >>> >>> With NetBSD 7.0 it „stalls“ too. The Cursor is not blinking but i can enter a „root device“. If nothing is entered it gives me the choice of either „ddb“, „halt“ or „reboot“. „Halt" and „Reboot" are working properly, the machine shuts down or reboots correctly. >>> Image 1: http://bilderhochladen.org/i/zgq1usG2Ri/ >>> Image 2: http://bilderhochladen.org/i/EqVSDbn25x/ >>> >>> With Dragonfly 4.2 the kernel stops at the moment it tries to mount the root-filesystem and asks me to enter the device. The machine has to be shut down via holding the powerbutton for a few seconds. >>> Image 1: http://bilderhochladen.org/i/TRIdjee9VP/ >>> Image 2: http://bilderhochladen.org/i/khPrwt4P0C/ >>> >> >> So if I understand correctly, you are attempting to launch BSD install >> media from a USB drive, and the installer fails to start? >> >> This doesn't look like a typical SeaBIOS issue > > Try OpenBSD snapshots. > > You're findings on the Toshiba Chromebook 2 may vary from what I found > with the Chromebook Pixel 2015. > > bsd.rd - you cant directly boot a bsd.rd kernel as it doesn't load > inteldrm. VGA only, but there's no VGA 800x600 resolution for SeaBIOS > to use, hence no dmesg output. It does boot, but you don't see the > screen changes. > > bsd - snapshots only - will load inteldrm > > bsd 5.8 - will not load inteldrm > > It will load the kernel (bsd snapsots) but won't display any dmesg > output, until the kernel finds inteldrm, then it will output dmesg and > hey presto, we've booted up. > > If you want to update OpenBSD bsd, I use arch Linux and boot bsd.rd > through qemu. > > This patch > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/i915/i915_drv.… > > Revision 1.95 fixes this issue, hence snapshots only. > > This only refers to the Chromebook Pixel 2015 only. > > If we run > > $ vbeinfo > > in grub2, we only get one resolution available, of 1280 x 850 x 16. No > 800 x 600, so no dmesg output till inteldrm hits. > > Coolstar organisation on Google+ (search coreboot Google+) has found a > patch for Coreboot to fix this resolution problem at boot,. > > I used > > http://goo.gl/9sgchs > > from https://wiki.archlinux.org/index.php/Chrome_OS_devices > > to repartition the SSD on the Pixel 2015, install Arch, Grub2 & > OpenBSD keeping ChromeOS too for updates to Coreboot & SeaBIOS. > > You can install OpenBSD to the SSD and write the MBR (no Grub > installed) and it will boot up via Ctrl-L keeping ChromeOS via Ctrl-D. > But you need another OS to boot bsd.rd via qemu to update files from > snapshots/amd64 to upgrade OpenBSD going forward. > > Haven't tried the other BSD's. > > Edward. I tried the latest OpenBSD snapshot 5.9 and it doesn’t work - neither using USB-Stick nor SD-Card. The latest snapshots from FreeBSD, NetBSD and DragonFlyBSD also do not work. >> - it looks more like the various BSD kernels don't like the USB controller and/or USB drive on your machine. Have you tried using a different type of USB drive for the install media? It's also possible there's something in the ACPI tables that coreboot provides that is confusing the BSDs. I tried several usb-sticks and sd-cards. Every time the same result: it doesn’t work. If i boot NetBSD without ACPI-support the screen turns black and stays this way until the machine is shut down. >> Your logs seem to indicate you also have an eMMC and an SD card. Have you tried placing the install media on an SD card instead of USB? That’s right. The main storage device of this Chromebook is an eMMC. Booting from SD card is working if it is a linux. BSD won’t start from. The same results as using an usb stick. >> Another thing you could do is launch the install media with the same verson of SeaBIOS on QEMU emulating an XHCI drive and SD drive - just to see if it's possible to reproduce outside of your particular >> machine. See below. Using QEMU it is working flawlessly, wether the SeaBIOS version is 1.8, 1.9 or 1.9.1 (which i compiled myself). So it really seems to be a problem with the BSDs. Greetings, — Ronny

3 2

Chromebook doesn't boot BSD
by Ronny Schneider 15 Feb '16

15 Feb '16

Hello there, i have a Toshiba Chromebook 2 (CB30-B-104) with a flashed on SeaBIOS by the script from John Lewis: https://johnlewis.ie/custom-chromebook-firmware/rom-download/ Linux is running very well but i want to see OpenBSD 5.8 on this laptop. But it’s not working, neither do FreeBSD 10.2, NetBSD 7.0 or DragonFly 4.2. The boot stops at the point where the kernel wants to mount the root-filesystem. I even copied an installed OpenBSD-System from an usb-stick onto the emmc-flash of the chromebook but it’s not working. I googled arround and found out the problem is not unknown among the Chromebook Pixel. So i thought i could help a little by providing my cbmem-bootlog for my machine: http://pastebin.com/asLqar5q If i can do more to see OpenBSD booting on this laptop, please let me know :-) Thank you very much! Greetings, — Ronny Schneider

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS