SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] [coreboot] [SimNow] PORT_IRQ_STAT register is 0 in ahci_port_setup
by Kevin O'Connor 08 Mar '13

08 Mar '13

On Fri, Mar 08, 2013 at 11:48:57AM +0800, WANG Siyuan wrote: > According to this piece of code in src/ahci.c, seabios fails to set > DMA or PIO on ahci. PORT_IRQ_STAT is 0. Thanks. Can you send a patch with the proposed fix? -Kevin

2 1

Re: [SeaBIOS] [Qemu-devel] problems with freeBSD
by Aurelien Jarno 08 Mar '13

08 Mar '13

On Wed, Mar 06, 2013 at 08:21:11AM +0000, Dietmar Maurer wrote: > Using qemu 1.4.0: > > # qemu -hda test.raw -m 512 -cdrom pfSense-LiveCD-2.0.2-RELEASE-amd64-20121207-2239.iso > > Results in: > > trap 12: page fault while in kernel mode > ... > stopped at x86bios_emu_rdw+0x2f: movzwl (%rbx),%eax > > Any ideas? Can somebody reproduce that? > > To get the FreeBSD VM boot use the console, enter the boot loader, then: > # set hint.atkbd.0.disabled="1" > # boot > > But that disables the keyboard. I was actually digging about that problem. It is indeed present in version 1.4.0, but is fixed in the current git master. The problem is actually not directly in QEMU but in seabios, the update to version 1.7.2.1 commit 5c75fb10) fixes the issue. Maybe it is worth cherry-picking it into stable-1.4 (hence the Cc:). In the meantime using bios.bin from master with QEMU version 1.4.0 should also fix the issue. What is strange is the seabios commit fixing the issue: commit 4219149ad2b783abfa61e80e9e9f6910db0c76c9 Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Sun Feb 17 10:56:10 2013 -0500 build: Don't require $(OUT) to be a sub-directory of the main directory. Remove references to "../" and "out/" from the build so that "make OUT=/a/b/c/" will work. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> Maybe Kevin has an explanation? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien(a)aurel32.net http://www.aurel32.net

8 16

Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
by Gerd Hoffmann 08 Mar '13

08 Mar '13

Hi, > In general having blobs in our allegedly source tarball is pretty > ugly. Either it's a source release or it isn't. We can do a > release-of-blobs tarball too if we want, but it doesn't need > to be in the source tarball This is easily doable, just an update to scripts/make-release to spew two tarballs (one source, one blobs). We probably want update the build process to build the blobs by default (if the compilers needed are installed). Blueswirl started that already for sparc firmware I think. > and it doesn't need to be in git > either IMHO. That one is a bit more tricky. The big advantage git has here is that the update of a blob is not different from other updates. It is just a pull request. Keeping source+binaries in sync is easy too: we can update submodule hash + blobs with a single git commit. The process needs to stay simple, otherwise we'll risk that the blobs we provide will bitrot ... cheers, Gerd

4 7

Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
by Aurelien Jarno 08 Mar '13

08 Mar '13

On Fri, Mar 08, 2013 at 12:03:15AM +0800, Peter Maydell wrote: > On 7 March 2013 23:56, Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > Peter Maydell wrote: > >> In general having blobs in our allegedly source tarball is pretty > >> ugly. Either it's a source release or it isn't. We can do a > >> release-of-blobs tarball too if we want, but it doesn't need > >> to be in the source tarball > > > > This is easily doable, just an update to scripts/make-release to spew > > two tarballs (one source, one blobs). > > > > We probably want update the build process to build the blobs by default > > (if the compilers needed are installed). Blueswirl started that already > > for sparc firmware I think. > > Earlier in this thread it's been stated that this often produces > subtly broken blobs... > Would it be possible to have a testsuite to validate such blobs. For example the breakage which happens recently is due to the size of the bios reaching 128kB. This is something easy to check. On the QEMU side, we should definitely have an autotest system trying to boot a few guests (and if possible with some !linux) to detect such issues. That's not something easy to do, maybe that could be a good GSoC project? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien(a)aurel32.net http://www.aurel32.net

3 2

Re: [SeaBIOS] [coreboot] [SimNow] PORT_IRQ_STAT register is 0 in ahci_port_setup
by Kevin O'Connor 08 Mar '13

08 Mar '13

On Thu, Mar 07, 2013 at 04:59:43PM +0800, WANG Siyuan wrote: > Hi, > I am trying to boot a hard disk image using coreboot and seabios on > SimNow Simulator. > The system stops at seabios stage. > > PORT_CMD_START fails in function ahci_port_setup (seabios/src/ahci.c), > Then I traced into function ahci_command (seabios/src/ahci.c), I found > the value of register ORT_IRQ_STAT is always 0: > intbits = ahci_port_readl(ctrl, pnr, PORT_IRQ_STAT); > intbits returns 0 all the time, so system stops here until time out. > > Any comments would be appreciated. There is a 32 second timeout in that code (which may be a longer wall time if run under a simulator) - are you sure it didn't eventually time out. As to why it is taking so long - could be an error in the simulator or in the seabios driver. You could try disabling the ahci code in seabios via kconfig. -Kevin

2 2

Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
by Dietmar Maurer 07 Mar '13

07 Mar '13

> In general having blobs in our allegedly source tarball is pretty ugly. Either it's a > source release or it isn't. We can do a release-of-blobs tarball too if we want, > but it doesn't need to be in the source tarball and it doesn't need to be in git > either IMHO. I think it is very convenient to have that in git, because everyone can test with the same binary - to detect error like this one.

1 0

Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
by Michael Tokarev 07 Mar '13

07 Mar '13

07.03.2013 10:12, Doug Goldstein wrote: > On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge <peter(a)stuge.se> wrote: >> Yeah, it is very common. Lots of distributions patch their >> toolchains such that they don't compile firmware code correctly. >> >> Firmware isn't a common target, so I understand that it happens. >> >> For coreboot we recommend to build a vanilla toolchain using known >> good versions. We also have a script to do that. (The script is at >> util/crossgcc/buildgcc in the coreboot repo.) [] > Not sure if you or Kevin builds the coreboot images at > http://code.coreboot.org/p/seabios/downloads/, but would you guys > consider building point release as well (e.g. 1.7.2.1), if yes then my > next question... > > The rest of the ML, > > Would qemu consider using those blobs rather than different developers > using their distro toolchain to build up a random commit ID. I say > random only because often qemu releases ship with a non-release > seabios. > > In this past there's been other issues related to seabios + qemu, that > I've solved in Gentoo by simply using the coreboot seabios images > after some troubleshooting help from Peter. Similarly our Ubuntu > OpenStack machines at work had quirks resolved by dropping the > coreboot seabios images on them. Just a note, or an "alternative opinion", so to say. In Debian, we have a social contract which, among other things, ensures that the binaries you, as a user, get, comes with source which you can modify on the system you installed. This requires, for example, that all binaries shipped are actually built from the corresponding source, and that no blobs from whatever other sources are used, ever. We don't even ship any upstream blobs in the debian qemu _source_ package: we repack upstream qemu.tar.gz by removing these blobs. So from this PoV, it'd be better if upstream didn't ship any blobs at all, -- we wont need to repack the upstream .tar.gz ;) FWIW, prpbably we were lucky so far: we had almost no issues with (mis)compiling of various ROM codes (bochsbios, seabios, vgabios, pxe roms, various sparc/ppc firmware etc) using toolchains provided by Debian. Thanks, /mjt

3 3

[SimNow] PORT_IRQ_STAT register is 0 in ahci_port_setup
by WANG Siyuan 07 Mar '13

07 Mar '13

Hi, I am trying to boot a hard disk image using coreboot and seabios on SimNow Simulator. The system stops at seabios stage. PORT_CMD_START fails in function ahci_port_setup (seabios/src/ahci.c), Then I traced into function ahci_command (seabios/src/ahci.c), I found the value of register ORT_IRQ_STAT is always 0: intbits = ahci_port_readl(ctrl, pnr, PORT_IRQ_STAT); intbits returns 0 all the time, so system stops here until time out. Any comments would be appreciated. -- Yours sincerely, WANG Siyuan

1 0

Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
by Peter Maydell 07 Mar '13

07 Mar '13

On 7 March 2013 14:12, Doug Goldstein <cardoe(a)gentoo.org> wrote: > On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge <peter(a)stuge.se> wrote: >> For coreboot we recommend to build a vanilla toolchain using known >> good versions. We also have a script to do that. (The script is at >> util/crossgcc/buildgcc in the coreboot repo.) > Would qemu consider using those blobs rather than different developers > using their distro toolchain to build up a random commit ID. I say > random only because often qemu releases ship with a non-release > seabios. The right way to fix this is for QEMU to stop shipping binary BIOS blobs in its source tarballs. Instead the developers of the BIOS should release them separately with an appropriate testing and release process which ensures that they're compiled with whichever toolchain is required. (just my opinion of course, which I state mostly to give people something to disagree with...) -- PMM

1 0

Build errors with Clang 3.2: src/ioport.h:126:18: error: invalid operand for instruction
by Paul Menzel 07 Mar '13

07 Mar '13

Dear SeaBIOS folks, using Debian Sid/unstable and Clang 3.2 from Debian experimental $ clang --version Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2) Target: i386-pc-linux-gnu Thread model: posix to build SeaBIOS, Clang throws the following errors. $ git show commit f465e1ec1b01826100c92b890487a2ab09bfe2c1 Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Sat Feb 23 21:33:36 2013 -0500 Minor - introduce numeric defines for the IVT offset of hw irqs. $ make menuconfig # coreboot chosen, see attached $ CC=clang make […] In file included from src/ata.c:9: src/ioport.h:126:18: error: invalid operand for instruction asm volatile("rep outsw %%es:(%%esi), (%%dx)" ^ <inline asm>:1:12: note: instantiated into assembly here rep outsw %es:(%esi), (%dx) ^~~~~~~~~~ In file included from src/ata.c:9: src/ioport.h:113:18: error: invalid operand for instruction asm volatile("rep insw (%%dx), %%es:(%%edi)" ^ <inline asm>:1:11: note: instantiated into assembly here rep insw (%dx), %es:(%edi) ^~~~~ 2 errors generated. make: *** [out/ata.o] Fehler 1 I have no clue about assembler programming, so before reporting both errors to the Clang project, as it works with GCC, I want to make sure that Clang is mistaken here. Thanks, Paul

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS