SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH 0/6] seabios: update to release 1.9.0
by Gerd Hoffmann 18 Dec '15

18 Dec '15

Hi, seabios 1.9.0 was released in November, missing hard freeze by a few days. Now 2.5 is out of the door and the master branch is open, time to care about the update now, so here we go. The patch series carries the seabios update itself, a few build and config adjustments and acpi cleanups. The update is also available here: git://git.kraxel.org/qemu work/seabios Please test & review, Gerd PS: Pull request will most likely have to wait until january, when I'm back online after xmas and newyear vacation. Gerd Hoffmann (6): seabios: update submodule to release 1.9.0 seabios: update 128k bios config seabios: use new EXTRAVERSION to tag qemu builds seabios: stop updating aml files seabios: update binaries to release 1.9.0 q35: skip q35-acpi-dsdt.aml load if not needed hw/i386/pc_q35.c | 5 ++++- pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes pc-bios/bios.bin | Bin 131072 -> 131072 bytes pc-bios/vgabios-cirrus.bin | Bin 38400 -> 38400 bytes pc-bios/vgabios-qxl.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-stdvga.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-virtio.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-vmware.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios.bin | Bin 38400 -> 38400 bytes roms/Makefile | 7 +++---- roms/config.seabios-128k | 2 ++ roms/seabios | 2 +- 12 files changed, 10 insertions(+), 6 deletions(-) -- 1.8.3.1

3 8

Re: [SeaBIOS] SeaBIOS Digest, Vol 73, Issue 11
by jwang＠whu.edu.cn 18 Dec '15

18 Dec '15

> -----原始邮件----- > 发件人: seabios-request(a)seabios.org > 发送时间: 2015年12月18日星期五 > 收件人: seabios(a)seabios.org > 抄送: > 主题: SeaBIOS Digest, Vol 73, Issue 11 > > Send SeaBIOS mailing list submissions to > seabios(a)seabios.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.seabios.org/mailman/listinfo/seabios > or, via email, send a message with subject or body 'help' to > seabios-request(a)seabios.org > > You can reach the person managing the list at > seabios-owner(a)seabios.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SeaBIOS digest..." > > > Today's Topics: > > 1. Re: [Qemu-devel] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load > if not needed (Marcel Apfelbaum) > 2. Re: [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if not > needed (Eduardo Habkost) > 3. Re: SeaBIOS recognising USB 3.0 on boot works - partly > (Kevin O'Connor) > 4. Re: SeaBIOS Digest, Vol 72, Issue 33 (Kevin O'Connor) > 5. Re: Qemu-kvm VM halt at allocate VGA stack when continuously > reset VM (Kevin O'Connor) > 6. Re: Qemu-kvm VM halt at allocate VGA stack when continuously > reset VM (Xulei (Stone)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Dec 2015 18:49:05 +0200 > From: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> > To: Gerd Hoffmann <kraxel(a)redhat.com>, qemu-devel(a)nongnu.org > Cc: Eduardo Habkost <ehabkost(a)redhat.com>, "Michael S. Tsirkin" > <mst(a)redhat.com>, seabios(a)seabios.org, Paolo Bonzini > <pbonzini(a)redhat.com>, Richard Henderson <rth(a)twiddle.net> > Subject: Re: [SeaBIOS] [Qemu-devel] [PATCH 6/6] q35: skip > q35-acpi-dsdt.aml load if not needed > Message-ID: <5672E781.1010802(a)gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > M > On 12/17/2015 12:40 PM, Gerd Hoffmann wrote: > > Only old machine types which don't use the acpi builder (qemu 1.7 + older) > > have to load that file for proper acpi support. > > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > hw/i386/pc_q35.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > index 133bc68..727269e 100644 > > --- a/hw/i386/pc_q35.c > > +++ b/hw/i386/pc_q35.c > > @@ -129,7 +129,10 @@ static void pc_q35_init(MachineState *machine) > > } > > > > pc_cpus_init(pcms); > > - pc_acpi_init("q35-acpi-dsdt.aml"); > > + if (!has_acpi_build) { > > + /* only machine types 1.7 & older need this */ > > Actually 1.6 and older, right? (I might be wrong) > > > + pc_acpi_init("q35-acpi-dsdt.aml"); > > + } > > > > kvmclock_create(); > > > > > > It looks OK to me. > > Reviewed-by: Marcel Apfelbaum <marcel(a)redhat.com> > > Thanks, > Marcel > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Dec 2015 15:22:46 -0200 > From: Eduardo Habkost <ehabkost(a)redhat.com> > To: Gerd Hoffmann <kraxel(a)redhat.com> > Cc: qemu-devel(a)nongnu.org, seabios(a)seabios.org, Paolo Bonzini > <pbonzini(a)redhat.com>, Richard Henderson <rth(a)twiddle.net>, "Michael > S. Tsirkin" <mst(a)redhat.com>, Igor Mammedov <imammedo(a)redhat.com> > Subject: Re: [SeaBIOS] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if > not needed > Message-ID: <20151217172246.GQ3774(a)thinpad.lan.raisama.net> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 17, 2015 at 11:40:49AM +0100, Gerd Hoffmann wrote: > > Only old machine types which don't use the acpi builder (qemu 1.7 + older) > > have to load that file for proper acpi support. > > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > hw/i386/pc_q35.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > index 133bc68..727269e 100644 > > --- a/hw/i386/pc_q35.c > > +++ b/hw/i386/pc_q35.c > > @@ -129,7 +129,10 @@ static void pc_q35_init(MachineState *machine) > > } > > > > pc_cpus_init(pcms); > > - pc_acpi_init("q35-acpi-dsdt.aml"); > > + if (!has_acpi_build) { > > + /* only machine types 1.7 & older need this */ > > + pc_acpi_init("q35-acpi-dsdt.aml"); > > + } > > This conflicts with: > > Subject: [Qemu-devel] [PATCH v3 0/6] pc: Initialization and compat function cleanup > Date: Tue, 1 Dec 2015 20:58:02 -0200 > Message-Id: <1449010688-19205-1-git-send-email-ehabkost(a)redhat.com> > > But rebasing it is very simple (just replace has_acpi_build with > pcmc->has_acpi_build). > > But I would prefer to finally apply the series that deletes > pc-q35-2.3 and older (submitted in August), so we just can delete > this code. > > -- > Eduardo > > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Dec 2015 17:17:17 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: edward wandasiewicz <0.w3ntd(a)gmail.com> > Cc: seabios(a)seabios.org, John Lewis <jlewis(a)johnlewis.ie> > Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - > partly > Message-ID: <20151217221717.GA8967(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Dec 14, 2015 at 07:02:14PM -0500, Kevin O'Connor wrote: > > The double detection looks like the controller doing something weird. > > I need to look closer at the spec, but I don't think I'll be able to > > do that until later in the week. > > After reviewing the spec I have a guess to what is occurring. Can you > pull the "testing" branch again and retry? > > -Kevin > > > > ------------------------------ > > Message: 4 > Date: Thu, 17 Dec 2015 17:22:56 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: Wim Vervoorn <wvervoorn(a)eltan.com> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org>, Stefan Berger > <stefanb(a)us.ibm.com> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 > Message-ID: <20151217222256.GA9447(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > Hello, > > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS. > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > plans to support TPM 2.0 in the future. > > I'm not aware of any plans. > > -Kevin > > > > ------------------------------ > > Message: 5 > Date: Thu, 17 Dec 2015 17:28:52 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: "Xulei (Stone)" <stone.xulei(a)huawei.com> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> > Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when > continuously reset VM > Message-ID: <20151217222851.GB9447(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 17, 2015 at 05:28:23AM +0000, Xulei (Stone) wrote: > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > > On one of my host, this problem never happens while on another, it's > > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > > wrong printing handle_smp log. > > > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > At first glance, this sounds like there is a level based interrupt > enabled somewhere and after a reset the apic isn't disabled. It > doesn't seem like a seabios issue - as seabios doesn't really use the > apic. I'd raise it on the qemu list. > > -Kevin > > > > ------------------------------ > > Message: 6 > Date: Fri, 18 Dec 2015 00:02:04 +0000 > From: "Xulei (Stone)" <stone.xulei(a)huawei.com> > To: Mohammed Gamal <mohammed.gamal(a)profitbricks.com>, "Kevin O'Connor" > <kevin(a)koconnor.net> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> > Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when > continuously reset VM > Message-ID: > <8E78D212B8C25246BE4CE7EA0E645FE52E0888(a)SZXEMI504-MBS.china.huawei.com> > > Content-Type: text/plain; charset="utf-8" > > Thanks for Gamal's and Kevin's reply. > Here i'd like to provide more information: > - My VM is running under KVM (KMOD 3.6); > - qmp returns: > virsh # qemu-monitor-command hrg_sles11_sp3_64_2U_ide --pretty '{"execute":"query-kvm"}' > { > "return": { > "enabled": true, > "present": true > }, > "id": "libvirt-18099" > } > - kmod ftrace returns: > > <...>-113789 [014] 858323.684996: kvm_emulate_insn: f0000:9:ff ff (real) > <...>-113789 [014] 858323.684996: kvm_inj_exception: #UD (0x0) > <...>-113789 [014] 858323.684996: kvm_entry: vcpu 0 > <...>-113789 [014] 858323.684997: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 > > <...>-113789 [014] 858323.684997: kvm_emulate_insn: f0000:9:ff ff (real) > <...>-113789 [014] 858323.684997: kvm_inj_exception: #UD (0x0) > <...>-113789 [014] 858323.684998: kvm_entry: vcpu 0 > <...>-113789 [014] 858323.684998: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 > > So, it seems at some points, guest executes an invalid opcode triggering kmod injects exception UD > and seabios handle this exception through handle_hwpic1. > > Any idea? > >Hi Xulei, > > > >i have a few questions about the problem you're experiencing, since I do see something similar: > > > >- Is your VM running under KVM? > >- If yes, does the KVM process show any register dumps or failure messages? > >- What's the output of: > >$ virsh qemu-monitor-command devstack --pretty '{"execute":"query-kvm"}' > >when seabios fails to load? > > > >Regards, > >Mohammed > > > > > > > >On Thu, Dec 17, 2015 at 6:28 AM, Xulei (Stone) <stone.xulei(a)huawei.com> wrote: > > > > > > > > >On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: > > >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and > > >> I have tested for 1 day with continuously resetting, it seems works well! > > >> Does following patch have some side effects? > > > > > >Thanks. I'll be traveling for the next two weeks. I'll take a look > > >when I return. > > > > > > > Hi, Kevin: > > Welcome journey back! I keep on this problem for about 1 month. Here, > > I provide some detail information and wish you could pay a little time > > thinking about this. > > > > My test script is very easy: > > > > #!/bin/bash > > vmname=$1 > > while [ 1 ] > > do > > virsh reset $vmname & > > virsh reset $vmname & > > sleep 5 > > done > > > > > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > > On one of my host, this problem never happens while on another, it's > > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > > wrong printing handle_smp log. > > > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > > > ==========bad SeaBIOS log========= > > [2015-12-17 12:37:30] In 32bit resume > > [2015-12-17 12:37:30] =====Attempting a hard reboot==== > > [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) > > [2015-12-17 12:37:30] No Xen hypervisor found. > > [2015-12-17 12:37:30] Running on QEMU (i440fx) > > [2015-12-17 12:37:30] Running on KVM > > [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] > > [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) > > [2015-12-17 12:37:30] Found QEMU fw_cfg > > [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] > > [2015-12-17 12:37:30] Moving pm_base to 0x600 > > [2015-12-17 12:37:30] boot order: > > [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 > > [2015-12-17 12:37:30] 2: HALT > > [2015-12-17 12:37:30] maininit > > [2015-12-17 12:37:30] platform_hardware_setup > > [2015-12-17 12:37:30] init pic > > [2015-12-17 12:37:30] pic_setup > > [2015-12-17 12:37:30] pic_reset > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] CPU Mhz=3304 > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] === PCI bus & bridge init === > > [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 > > [2015-12-17 12:37:30] === PCI device probing === > > [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) > > [2015-12-17 12:37:30] === PCI new allocation pass #1 === > > [2015-12-17 12:37:30] PCI: check devices > > [2015-12-17 12:37:30] === PCI new allocation pass #2 === > > [2015-12-17 12:37:30] PCI: IO: c000 - c02f > > [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 > > [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] > > [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] > > [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 > > [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c > > [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 > > [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 > > [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 > > [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA > > [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! > > [2015-12-17 12:37:30] i?f[cf_^ifd_=f3 > > [2015-12-17 12:37:30] ?f[f^f_f]f??^X?<90>Found 4 cpu(s) max supported 4 cpu(s) > > [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 > > [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 > > [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 > > [2015-12-17 12:37:31] Scan for VGA option rom > > [2015-12-17 12:37:31] Running option rom at c000:0003 > > [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) > > [2015-12-17 12:37:31] enter vga_post: > > [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 > > [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 > > [2015-12-17 12:37:31] cirrus init > > [2015-12-17 12:37:31] cirrus init 2 > > [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > ... always hanle_hwpic1 irq=0, never ends anymore... > > > > >-Kevin > > _______________________________________________ > > SeaBIOS mailing list > > SeaBIOS(a)seabios.org > > http://www.seabios.org/mailman/listinfo/seabios > > > > > > > > > >-- > > > >Mohammed Gamal > >Software Engineer > > > >ProfitBricks GmbH > >Greifswalder Stra?e 207 > >D - 10405 Berlin > > > >Tel: +49 30 577 008 20 > >Email: mohammed.gamal(a)profitbricks.com <mailto:axel.herr@profitbricks.com> > > > >Web: http://www.profitbricks.de > > > >Sitz der Gesellschaft: Berlin. > >Registergericht: Amtsgericht Charlottenburg, HRB 125506B. > >Gesch?ftsf?hrer: Andreas Gauger, Achim Weiss. > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ------------------------------ > > End of SeaBIOS Digest, Vol 73, Issue 11 > *************************************** -- Best Wishes! *********************************************************************************************** Juan Wang Computer School, Wuhan University Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education Mobile Phone : 18986213038 E-Mail : jwang(a)whu.edu.cn ***********************************************************************************************

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 18 Dec '15

18 Dec '15

Thanks for Gamal's and Kevin's reply. Here i'd like to provide more information: - My VM is running under KVM (KMOD 3.6); - qmp returns: virsh # qemu-monitor-command hrg_sles11_sp3_64_2U_ide --pretty '{"execute":"query-kvm"}' { "return": { "enabled": true, "present": true }, "id": "libvirt-18099" } - kmod ftrace returns: <...>-113789 [014] 858323.684996: kvm_emulate_insn: f0000:9:ff ff (real) <...>-113789 [014] 858323.684996: kvm_inj_exception: #UD (0x0) <...>-113789 [014] 858323.684996: kvm_entry: vcpu 0 <...>-113789 [014] 858323.684997: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 <...>-113789 [014] 858323.684997: kvm_emulate_insn: f0000:9:ff ff (real) <...>-113789 [014] 858323.684997: kvm_inj_exception: #UD (0x0) <...>-113789 [014] 858323.684998: kvm_entry: vcpu 0 <...>-113789 [014] 858323.684998: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 So, it seems at some points, guest executes an invalid opcode triggering kmod injects exception UD and seabios handle this exception through handle_hwpic1. Any idea? >Hi Xulei, > >i have a few questions about the problem you're experiencing, since I do see something similar: > >- Is your VM running under KVM? >- If yes, does the KVM process show any register dumps or failure messages? >- What's the output of: >$ virsh qemu-monitor-command devstack --pretty '{"execute":"query-kvm"}' >when seabios fails to load? > >Regards, >Mohammed > > > >On Thu, Dec 17, 2015 at 6:28 AM, Xulei (Stone) <stone.xulei(a)huawei.com> wrote: > > > > >On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: > >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and > >> I have tested for 1 day with continuously resetting, it seems works well! > >> Does following patch have some side effects? > > > >Thanks. I'll be traveling for the next two weeks. I'll take a look > >when I return. > > > > Hi, Kevin: > Welcome journey back! I keep on this problem for about 1 month. Here, > I provide some detail information and wish you could pay a little time > thinking about this. > > My test script is very easy: > > #!/bin/bash > vmname=$1 > while [ 1 ] > do > virsh reset $vmname & > virsh reset $vmname & > sleep 5 > done > > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > On one of my host, this problem never happens while on another, it's > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > wrong printing handle_smp log. > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > ==========bad SeaBIOS log========= > [2015-12-17 12:37:30] In 32bit resume > [2015-12-17 12:37:30] =====Attempting a hard reboot==== > [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) > [2015-12-17 12:37:30] No Xen hypervisor found. > [2015-12-17 12:37:30] Running on QEMU (i440fx) > [2015-12-17 12:37:30] Running on KVM > [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] > [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) > [2015-12-17 12:37:30] Found QEMU fw_cfg > [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] > [2015-12-17 12:37:30] Moving pm_base to 0x600 > [2015-12-17 12:37:30] boot order: > [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 > [2015-12-17 12:37:30] 2: HALT > [2015-12-17 12:37:30] maininit > [2015-12-17 12:37:30] platform_hardware_setup > [2015-12-17 12:37:30] init pic > [2015-12-17 12:37:30] pic_setup > [2015-12-17 12:37:30] pic_reset > [2015-12-17 12:37:30] enable_hwirq > [2015-12-17 12:37:30] CPU Mhz=3304 > [2015-12-17 12:37:30] enable_hwirq > [2015-12-17 12:37:30] enable_hwirq > [2015-12-17 12:37:30] === PCI bus & bridge init === > [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 > [2015-12-17 12:37:30] === PCI device probing === > [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) > [2015-12-17 12:37:30] === PCI new allocation pass #1 === > [2015-12-17 12:37:30] PCI: check devices > [2015-12-17 12:37:30] === PCI new allocation pass #2 === > [2015-12-17 12:37:30] PCI: IO: c000 - c02f > [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 > [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] > [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] > [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 > [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 > [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c > [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 > [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 > [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 > [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 > [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 > [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA > [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! > [2015-12-17 12:37:30] ièf[cf_^ifd_=f3 > [2015-12-17 12:37:30] èf[f^f_f]fÃÍ^XË<90>Found 4 cpu(s) max supported 4 cpu(s) > [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 > [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 > [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 > [2015-12-17 12:37:31] Scan for VGA option rom > [2015-12-17 12:37:31] Running option rom at c000:0003 > [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) > [2015-12-17 12:37:31] enter vga_post: > [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 > [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 > [2015-12-17 12:37:31] cirrus init > [2015-12-17 12:37:31] cirrus init 2 > [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > ... always hanle_hwpic1 irq=0, never ends anymore... > > >-Kevin > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > > > >-- > >Mohammed Gamal >Software Engineer > >ProfitBricks GmbH >Greifswalder Straße 207 >D - 10405 Berlin > >Tel: +49 30 577 008 20 >Email: mohammed.gamal(a)profitbricks.com <mailto:axel.herr@profitbricks.com> > >Web: http://www.profitbricks.de > >Sitz der Gesellschaft: Berlin. >Registergericht: Amtsgericht Charlottenburg, HRB 125506B. >Geschäftsführer: Andreas Gauger, Achim Weiss.

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Kevin O'Connor 18 Dec '15

18 Dec '15

On Thu, Dec 17, 2015 at 05:28:23AM +0000, Xulei (Stone) wrote: > 1. This problem seems have relations with PIC irq0 and host CPU feature: > On one of my host, this problem never happens while on another, it's > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > wrong printing handle_smp log. > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). At first glance, this sounds like there is a level based interrupt enabled somewhere and after a reset the apic isn't disabled. It doesn't seem like a seabios issue - as seabios doesn't really use the apic. I'd raise it on the qemu list. -Kevin

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 17 Dec '15

17 Dec '15

>On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and >> I have tested for 1 day with continuously resetting, it seems works well! >> Does following patch have some side effects? > >Thanks. I'll be traveling for the next two weeks. I'll take a look >when I return. > Hi, Kevin: Welcome journey back! I keep on this problem for about 1 month. Here, I provide some detail information and wish you could pay a little time thinking about this. My test script is very easy: #!/bin/bash vmname=$1 while [ 1 ] do virsh reset $vmname & virsh reset $vmname & sleep 5 done 1. This problem seems have relations with PIC irq0 and host CPU feature: On one of my host, this problem never happens while on another, it's very easy to happen (both of hosts have the same kmod,qemu,libvirt and SeaBIOS, SeaVGABIOS, except for the CPU feature). 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something wrong printing handle_smp log. 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). ==========bad SeaBIOS log========= [2015-12-17 12:37:30] In 32bit resume [2015-12-17 12:37:30] =====Attempting a hard reboot==== [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) [2015-12-17 12:37:30] No Xen hypervisor found. [2015-12-17 12:37:30] Running on QEMU (i440fx) [2015-12-17 12:37:30] Running on KVM [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) [2015-12-17 12:37:30] Found QEMU fw_cfg [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] [2015-12-17 12:37:30] Moving pm_base to 0x600 [2015-12-17 12:37:30] boot order: [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 [2015-12-17 12:37:30] 2: HALT [2015-12-17 12:37:30] maininit [2015-12-17 12:37:30] platform_hardware_setup [2015-12-17 12:37:30] init pic [2015-12-17 12:37:30] pic_setup [2015-12-17 12:37:30] pic_reset [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] CPU Mhz=3304 [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] === PCI bus & bridge init === [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 [2015-12-17 12:37:30] === PCI device probing === [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) [2015-12-17 12:37:30] === PCI new allocation pass #1 === [2015-12-17 12:37:30] PCI: check devices [2015-12-17 12:37:30] === PCI new allocation pass #2 === [2015-12-17 12:37:30] PCI: IO: c000 - c02f [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! [2015-12-17 12:37:30] ièf[cf_^ifd_=f3 [2015-12-17 12:37:30] èf[f^f_f]fÃÍ^XË<90>Found 4 cpu(s) max supported 4 cpu(s) [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 [2015-12-17 12:37:31] Scan for VGA option rom [2015-12-17 12:37:31] Running option rom at c000:0003 [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) [2015-12-17 12:37:31] enter vga_post: [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 [2015-12-17 12:37:31] cirrus init [2015-12-17 12:37:31] cirrus init 2 [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 ... always hanle_hwpic1 irq=0, never ends anymore... >-Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz 14 Dec '15

14 Dec '15

On Sun, Dec 13, 2015 at 9:05 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > Hooray, it works... minus 2 scenarios :( > > With both Philips USB and Mushkin USB attached, and I perform a cold boot > > 1. YES - USB 3 & USB 3 - once each (Philips & Mushkin) > > cbmem.yes.both.USB3.USB3.gz > > 2. NO - USB 3 & USB 3 - once each (Philips & Muskin) - but double > Philips showing > > cbmem.yes.both.USB3.USB3.DoublePhilips.gz > > 3. YES - USB 3 & Type C - once each (Philips & Mushkin) > > cbmem.yes.both.USB3.TypeC.gz > > I can't get a double Philips to appear > > 4. YES - Type C & Type C - once each (Philips & Mushkin) > > cbmem.yes.both.TypeC.TypeC.gz > > 5. NO - Type C & Type C - one Philiips & no Mushkin > > I forgot to save > > $ cbmem -c > > and now can't replicate it. :( > > When I do, I will post output. When attempting a cold boot - shutdown - cold boot - shutdown - cold boot - shutdown - .... It seems the list of bootable devices can change order, yet the devices are plugged into the same ports all the time, and never unplugged. We can get 1. SSD 2. Philips USB 3. Mushkin USB or 1. SSD 2. Mushkin USB 3. Philips USB I think scenario 5 is special case of the above, former, but no Mushkin 1. SSD 2. Philips USB Hope this helps. Edward. > > Edward. > > On Sun, Dec 13, 2015 at 7:53 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Sun, Dec 13, 2015 at 10:49:30AM +0000, edward wandasiewicz wrote: >>> With both the Philips USB and Mushkin USB plugged in on boot, I'm >>> still getting 4 different scenarios appearing. >>> >>> 1. Philips Only >>> 2. Mushkin Only >>> 3. Both recognised - listed once and once only >>> 4. Both recognised - Mushkin once, but the Philips listed twice >>> >>> I've attached >>> >>> $cbmem -c >>> >>> for each scenario >> >> Thanks. It looks like the usb code wasn't waiting for USB3 devices to >> be "enabled" before trying to talk to them. Can you pull down the >> "testing" branch again and retry? >> >> Also, the logs are quite large and they are exceeding the mailing list >> limits - going forward can you gzip the logs and attach them to your >> emails. >> >> -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 14 Dec '15

14 Dec '15

On Sun, Dec 13, 2015 at 10:49:30AM +0000, edward wandasiewicz wrote: > With both the Philips USB and Mushkin USB plugged in on boot, I'm > still getting 4 different scenarios appearing. > > 1. Philips Only > 2. Mushkin Only > 3. Both recognised - listed once and once only > 4. Both recognised - Mushkin once, but the Philips listed twice > > I've attached > > $cbmem -c > > for each scenario Thanks. It looks like the usb code wasn't waiting for USB3 devices to be "enabled" before trying to talk to them. Can you pull down the "testing" branch again and retry? Also, the logs are quite large and they are exceeding the mailing list limits - going forward can you gzip the logs and attach them to your emails. -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 10 Dec '15

10 Dec '15

On Fri, Dec 04, 2015 at 09:04:35PM +0000, edward wandasiewicz wrote: > Here's what happens with x1 Philips USB attached and x1 Mushkin > attached, and we cold boot with Kevin's patched SeaBIOS > > FIXED - when Philips drive is detected, it appears only once and once > only in the list of bootable devices - cbmem -c attached > > BROKE - the Mushkin drive hardly ever gets detected - Google ChromeOS > recovery SeaBIOS would always find it > > BROKEN - when Mushkin drive is detected, only the Mushkin is showing > in the list, no Philips in the list of bootable devices - cbmem -c > attached (reboot following a cold boot with Philips only showing) > > Sometimes Mushkin will appear on a cold boot - not very often, with no > Philips showing in the list, with both devices plugged in on boot up. [...] > |7cddd000| xhci_address: enable slot: got slotid 1 > |7cddd000| xhci_cmd_address_device: slotid 1 > |7cddd000| xhci_trb_queue: ring 0x7ce39d00 [nidx 2, len 0] > |7cddd000| xhci_process_events: ring 0x7ce39d00 [trb 0x7ce39d10, evt > 0x7ce39e00, type 33, eidx 2, cc 4] > |7cddd000| xhci_cmd_disable_slot: slotid 1 > |7cddd000| xhci_trb_queue: ring 0x7ce39d00 [nidx 3, len 0] > |7cddd000| xhci_process_events: ring 0x7ce39d00 [trb 0x7ce39d20, evt > 0x7ce39e00, type 33, eidx 3, cc 1] > |7cddd000| xhci_address: disable failed (cc 1/4) It looks like I messed up the error check on the patch. I uploaded a new patch. Can you clone the "testing" branch again and retry? Thanks, -Kevin

1 0

[PATCH] fw/pci: do not automatically allocate IO region for PCIe bridges
by Marcel Apfelbaum 07 Dec '15

07 Dec '15

PCIe downstream ports (Root Ports and switches Downstream Ports) appear to firmware as PCI-PCI bridges and a 4K IO space is allocated for them even if there is no device behind them requesting IO space, all that for hotplug purpose. However, PCIe devices can work without IO, so there is no need to allocate IO space for hotplug. Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- Notes: - This patch fixes a 15 PCIe Root ports limitation when used with virtio pci-express devices having no IO space requirements: <qemu cmd line> -M q35 `for i in {1..15}; do echo -device ioh3420,chassis=$i,id=b$i -device virtio-net-pci,bus=b$i,disable-legacy=on; done` - There is a patch on QEMU devel list that tackles the problem from another angle by allowing PCIe downstream ports to not forward IO requests. https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04478.html - The mentioned patch is of course not enough and also requires management software intervention. Thanks, Marcel src/fw/pciinit.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 7b8aab7..4b37792 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -736,7 +736,9 @@ static int pci_bios_check_devices(struct pci_bus *busses) if (pci_region_align(&s->r[type]) > align) align = pci_region_align(&s->r[type]); u64 sum = pci_region_sum(&s->r[type]); - if (!sum && hotplug_support) + int res_opt = (type == PCI_REGION_TYPE_IO) && + pci_find_capability(s->bus_dev, PCI_CAP_ID_EXP, 0); + if (!sum && hotplug_support && !res_opt) sum = align; /* reserve min size for hot-plug */ u64 size = ALIGN(sum, align); int is64 = pci_bios_bridge_region_is64(&s->r[type], -- 2.1.0

2 2

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 05 Dec '15

05 Dec '15

On Fri, Dec 04, 2015 at 07:08:50PM +0000, edward wandasiewicz wrote: > On 4 Dec 2015 7:04 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > > > > On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > > > @ John > > > > > > Is the work on SeaVGABIOS for CBFS work under construction for the > > > Broadwell based Pixel 2015? > > > > > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > > > > > CBFSTOOL=cbfstool > > > PAYLOAD=out/bios.bin.elf > > > PAYLOADVGA=out/vgabios.bin > > [...] > > > # > > > # Add SeaVGABIOS to CBFS > > > # > > > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t > optionrom > > > > > > Question - if it is work under construction, the above may or may not > > > show any VGA output? i.e. black screen > > > > > > Or give it a whirl, and I may surprise myself? > > > > > > Or stick with > > > > > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > > > > > ORIGCBFSFILE=orig-seabios.cbfs > > > > > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > > > > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > > > > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t > optionrom > > > > The logs you sent me seemed to indicate that SeaVGABIOS was running, > > This means use vgaroms/seavgabios.rom > > and leave commented parts in a commented state - no need for > pci8086,0a06.rom parts Yes. -Kevin

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS