coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 15 May '15

15 May '15

The ASUS KFSN4-DRE fails verification as of commit 9d45d6975ccdae7253c75259e1885b68186ce83d The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: 9d45d69 ibexpeak: Merge common NVS init a3565ae spi_flash: document expected return values d4a72f7 console: Bring back newline translation 2d3964e superio: Replace the indexed I/O functions d3b194e bd82x6x, ibexpeak: Support fully locking ROM on S3 resume. <109 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

REACTS standalone test systems available for purchase
by Timothy Pearson 14 May '15

14 May '15

All, As there has been some interest in the REACTS system on and off list, I am copying the press release here: ======================================================================== Raptor Engineering is pleased to officially announce the addition of the Raptor Engineering Automated Coreboot Test System (REACTS) to our existing product lineup! Please find detailed product information and documentation on our website at: https://secure.raptorengineeringinc.com/content/REACTS/intro.html This is the same REACTS testing software that reports to the coreboot mailing list, board-status repository, and Gerrit. It has been bundled with a small system management utility and packaged into an easy to use, self-contained system. This system is specifically designed for users who want to continuously verify functionality of specific hardware without the hassle of setting up and maintaining the requisite support services. To allow flexibility in test stand configuration, or for those who just want to create their own system, the REACTS test software itself is available to REACTS customers, licensed under the GNU Affero General Public License v3! Some restrictions apply, see the product page for full details. For a limited time, take $3,000 USD off the list price of your first REACTS system purchase with the following promotional code: COREBOOTREACTS15 This offer will expire June 1, 2015, so act now to secure introductory pricing on this item. Individuals wishing to offer public test results for certain hardware may qualify for discounted or free annual licensing. Contact Raptor Engineering at sales(a)raptorengineeringinc.com with a description of the hardware you would like to test for more information. Raptor Engineering is also offering coreboot testing as a service! Contact us with the hardware you would like tested, along with any requirements such as whether the test results would be public or private, and we will be glad to provide a quote. ======================================================================== Please let me know if you have any questions! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

1 0

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 13 May '15

13 May '15

The ASUS KFSN4-DRE fails verification as of commit e7db9dd2a0d42e48186f98a43221cb97051c0cdc The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: e7db9dd 3rdparty/blobs: Move submodule marker forward 3dc60c5 vboot: fix die() hang for recovery path a6a566b amd/pi: Move AGESA cbfs access into the wrapper 6310ccc cbfstool: Don't typedef the comp_algo enum 67d5998 cbfstool: Support top-aligned addresses for new-format images <96 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure
by Timothy Pearson 13 May '15

13 May '15

On 05/13/2015 09:56 AM, Aaron Durbin via coreboot wrote: > On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin<adurbin(a)google.com> wrote: >> On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot >> Test Stand<no-reply(a)raptorengineeringinc.com> wrote: >>> The QEMU x86_64 Q35 fails verification as of commit 0a50d9b35334d03f13b38e21497ba0aae8b16712 >>> >>> The following tests failed: >>> ACPI_DSDT_ACCESS_FAILURE >>> ACPI_SSDT_ACCESS_FAILURE >>> DMIDECODE_ACCESS_FAILURE >>> CBMEM_CONSOLE_ACCESS_FAILURE >>> CBMEM_TIMESTAMP_ACCESS_FAILURE >>> CBMEM_OBJECT_TABLE_ACCESS_FAILURE >>> > > All those are empty including dmesg. Was this a flaky test run? > > ======================================================= > CBMEM timestamps > ======================================================= > > ======================================================= > CBMEM object table > ======================================================= > > ======================================================= > CBMEM log > ======================================================= > > ======================================================= > dmesg > ======================================================= > > ======================================================= > dmidecode > ======================================================= > > ======================================================= > ACPI DSDT > ======================================================= > > ======================================================= > ACPI SSDT > ======================================================= > > ======================================================= > RS232 log > ======================================================= > > >>> Commits since last successful test: >>> 0a50d9b libpayload: x86: correct types used for IO >> >> I was curious about this... I'll take a look at the log. >> >>> >>> See attached log for details >>> >>> This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand >>> Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information >>> >>> Please contact Timothy Pearson at Raptor Engineering<tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot > Yes it was, and of course it happened overnight. I was testing a different configuration and it doesn't seem to have worked at all... Sorry for the noise! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

1 1

Re: [coreboot] coreboot debugging with qemu-x86
by Gerd Hoffmann 13 May '15

13 May '15

On Sa, 2015-05-09 at 16:28 +0530, Saket Sinha wrote: > HI Ajay, > > > Try giving > > -m 1g > > > > > Doesn't help. Same output. > > > saket@saket-Notebook-PC:~/coreboot$ qemu-system-x86_64 -L . -bios > build/coreboot.rom -nographic > qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000a0000 > > EAX=00000001 EBX=00000000 ECX=00000000 EDX=00000663 > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fffa > EIP=0009ffd6 EFL=00000082 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0000 00000000 0000ffff 00009300 > CS =0000 00000000 0000ffff 00009b00 No, its not the same output. Quoting original post: EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ^^^^^^^^ ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 ^^^^ That is the reset vector, i.e. something going seriously wrong on the very first instruction executed. rom image being garbage or something like that. Check your build environment. Broken toolchain? Disk full? The new crash is at some completely different place, so coreboot at least starts executing. Try this ... qemu -bios coreboot.rom \ -chardev stdio,id=log \ -device isa-debugcon,iobase=0x402,chardev=log ... to see the coreboot log (assuming coreboot comes far enough to actually produce log output). cheers, Gerd

2 1

Re: [coreboot] (no subject)
by Nick 13 May '15

13 May '15

Sorry for not adding a subject to this thread - realized the second after I hit send :) I made some progress by manually adding IOAPIC #4 (assuming its address is fixed) - Linux kernel does not panic anymore and some IRQ routing started working, but there are still some issues. I'm still wondering why the detection code used on other MCP-55 boards fails. On Wed, May 13, 2015 at 12:15 PM, Nick <nochristrequired(a)gmail.com> wrote: > Hi, > > I'm looking for a little advice (or steering in the right direction) in > regards to IOAPICs and how Coreboot manages detection. I have two MCP-55 > chipsets just like the nVidia l1_2pvv board. > > When I boot Linux under the *vendor bios* with apic debugging enabled, I > can see that I have two IOAPICs- > > [ 0.000000] IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI > 0-23 > [ 0.000000] IOAPIC[1]: apic_id 5, version 17, address 0xb0400000, GSI > 24-47 > > And, when I boot using Coreboot*,* I have only one- > > [ 0.000000] IOAPIC[0]: apic_id 5, version 17, address 0xf4340000, GSI > 0-23 > > Now, I'm sure this output is coming from the MP Table which Linux is > reading back. > > In mptable.c a lot of the MCP-55 boards share this detection code for > building the MP Table. Mine will only enter the if statement for bus_mcp55b. > > get_bus_conf(); > sbdn = sysconf.sbdn; > m = sysconf.mb; > > > dev = dev_find_slot(m->bus_mcp55, PCI_DEVFN(sbdn+ 0x1,0)); > if (dev) { > res = find_resource(dev, PCI_BASE_ADDRESS_1); > if (res) > smp_write_ioapic(mc, m->apicid_mcp55, 0x11, res->base); > > > if (m->bus_mcp55b) { > dev = dev_find_slot(m->bus_mcp55b, PCI_DEVFN(m->sbdnb + 0x1,0)); > if (dev) { > res = find_resource(dev, PCI_BASE_ADDRESS_1); > if (res) > smp_write_ioapic(mc, m->apicid_mcp55b, 0x11, res->base); > > So, my question is - what is responsible for detecting the IOAPICs? Is > there some configuration somewhere which I may be missing? Any tips for > where to look? > > Here's a full output from Coreboot and the Linux kernel(apic=debug > show_lapic=all): *http://pastebin.com/PMVtt6hU > <http://pastebin.com/PMVtt6hU>* > > Here's Linux kernel output from the vendor bios:* http://pastebin.com/VscyMxM2 > <http://pastebin.com/VscyMxM2>* (MPTable @ line 110.) > > Thanks in advance! > > -Nick > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

(no subject)
by Nick 13 May '15

13 May '15

Hi, I'm looking for a little advice (or steering in the right direction) in regards to IOAPICs and how Coreboot manages detection. I have two MCP-55 chipsets just like the nVidia l1_2pvv board. When I boot Linux under the *vendor bios* with apic debugging enabled, I can see that I have two IOAPICs- [ 0.000000] IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23 [ 0.000000] IOAPIC[1]: apic_id 5, version 17, address 0xb0400000, GSI 24-47 And, when I boot using Coreboot*,* I have only one- [ 0.000000] IOAPIC[0]: apic_id 5, version 17, address 0xf4340000, GSI 0-23 Now, I'm sure this output is coming from the MP Table which Linux is reading back. In mptable.c a lot of the MCP-55 boards share this detection code for building the MP Table. Mine will only enter the if statement for bus_mcp55b. get_bus_conf(); sbdn = sysconf.sbdn; m = sysconf.mb; dev = dev_find_slot(m->bus_mcp55, PCI_DEVFN(sbdn+ 0x1,0)); if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_1); if (res) smp_write_ioapic(mc, m->apicid_mcp55, 0x11, res->base); if (m->bus_mcp55b) { dev = dev_find_slot(m->bus_mcp55b, PCI_DEVFN(m->sbdnb + 0x1,0)); if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_1); if (res) smp_write_ioapic(mc, m->apicid_mcp55b, 0x11, res->base); So, my question is - what is responsible for detecting the IOAPICs? Is there some configuration somewhere which I may be missing? Any tips for where to look? Here's a full output from Coreboot and the Linux kernel(apic=debug show_lapic=all): *http://pastebin.com/PMVtt6hU <http://pastebin.com/PMVtt6hU>* Here's Linux kernel output from the vendor bios:* http://pastebin.com/VscyMxM2 <http://pastebin.com/VscyMxM2>* (MPTable @ line 110.) Thanks in advance! -Nick

1 0

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure
by Aaron Durbin 13 May '15

13 May '15

On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot > Test Stand <no-reply(a)raptorengineeringinc.com> wrote: >> The QEMU x86_64 Q35 fails verification as of commit 0a50d9b35334d03f13b38e21497ba0aae8b16712 >> >> The following tests failed: >> ACPI_DSDT_ACCESS_FAILURE >> ACPI_SSDT_ACCESS_FAILURE >> DMIDECODE_ACCESS_FAILURE >> CBMEM_CONSOLE_ACCESS_FAILURE >> CBMEM_TIMESTAMP_ACCESS_FAILURE >> CBMEM_OBJECT_TABLE_ACCESS_FAILURE >> All those are empty including dmesg. Was this a flaky test run? ======================================================= CBMEM timestamps ======================================================= ======================================================= CBMEM object table ======================================================= ======================================================= CBMEM log ======================================================= ======================================================= dmesg ======================================================= ======================================================= dmidecode ======================================================= ======================================================= ACPI DSDT ======================================================= ======================================================= ACPI SSDT ======================================================= ======================================================= RS232 log ======================================================= >> Commits since last successful test: >> 0a50d9b libpayload: x86: correct types used for IO > > I was curious about this... I'll take a look at the log. > >> >> See attached log for details >> >> This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand >> Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information >> >> Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

QEMU x86_64 Q35 Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 13 May '15

13 May '15

The QEMU x86_64 Q35 fails verification as of commit 0a50d9b35334d03f13b38e21497ba0aae8b16712 The following tests failed: ACPI_DSDT_ACCESS_FAILURE ACPI_SSDT_ACCESS_FAILURE DMIDECODE_ACCESS_FAILURE CBMEM_CONSOLE_ACCESS_FAILURE CBMEM_TIMESTAMP_ACCESS_FAILURE CBMEM_OBJECT_TABLE_ACCESS_FAILURE Commits since last successful test: 0a50d9b libpayload: x86: correct types used for IO See attached log for details This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

2 1

build error: fmd_scanner.l:47: error: declaration of ‘input’ shadows a global declaration
by WANG Siyuan 13 May '15

13 May '15

Hi, When I build olivehillplus, I got this error: fmd_scanner.l: In function ‘parse_integer’: fmd_scanner.l:47: error: declaration of ‘input’ shadows a global declaration <stdout>:1192: error: shadowed declaration is here fmd_scanner.l: In function ‘copy_string’: fmd_scanner.l:74: error: declaration of ‘input’ shadows a global declaration <stdout>:1192: error: shadowed declaration is here make: *** [build/util/cbfstool/fmd_scanner.o] Error 1 Where is the problem? Thank you very much.

1 1

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2015