coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

Re: [coreboot] QEMU build failure in master
by Timothy Pearson 06 May '15

06 May '15

On 05/06/2015 11:41 AM, Aaron Durbin wrote: > That's probably my fault. I was under the impression monotonic_timer > was a first class citizen now (I at least recall someone doing that) I > thought wrong? > > You could add the following in the beginning of that function: > > if (!IS_ENABLED(CONFIG_HAVE_MONOTONIC_TIMER) > return 0; > > I need to look at your logs to know the build failure. > While I don't have the entire log available right now, this was the important part: coreboot/src/lib/timestamp.c:184: undefined reference to `timer_monotonic_get' There were no other errors, and no other warning output except from iasl (as usual). It looks like timer_monotonic_get may not be available on QEMU, which means your fix wouldn't work unless the entire block was #ifdefed out. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Re: [coreboot] QEMU build failure in master
by Aaron Durbin 06 May '15

06 May '15

On Wed, May 6, 2015 at 9:41 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson > <tpearson(a)raptorengineeringinc.com> wrote: >> On 05/06/2015 06:54 AM, Patrick Georgi wrote: >>> >>> 2015-05-05 21:49 GMT+02:00 Timothy >>> Pearson<tpearson(a)raptorengineeringinc.com>: >>>> >>>> While working on the test system earlier today I noticed that QEMU builds >>>> are currently failing with the following error: >>>> >>>> coreboot/src/lib/timestamp.c:184: undefined reference to >>>> `timer_monotonic_get' >>>> >>>> Builds using the same configuration were working yesterday. The >>>> KFSN4-DRE >>>> does not appear to be affected at this time. >>> >>> Regarding build failures we should be covered (at least for default >>> configurations). >>> When looking at http://qa.coreboot.org/job/coreboot/, I don't see this >>> error. >>> >>> >>> Patrick >> >> >> Granted, the test stand configuration has more options enabled for more test >> coverage. My question at this point is: are timestamps a supported option >> for QEMU systems? The test stand sets COLLECT_TIMESTAMPS=y, and this was >> working until a day ago. >> >> This is the commit that broke the QEMU build: >> http://review.coreboot.org/10104 >> > > That's probably my fault. I was under the impression monotonic_timer > was a first class citizen now (I at least recall someone doing that) I > thought wrong? > > You could add the following in the beginning of that function: > > if (!IS_ENABLED(CONFIG_HAVE_MONOTONIC_TIMER) > return 0; I see the error in your original email... coreboot/src/lib/timestamp.c:184: undefined reference to `timer_monotonic_get' Does your qemu build have a timestamp_get() defined? $ git grep timestamp_get | grep void src/arch/arm/armv7/timestamp.c:uint64_t timestamp_get(void) src/arch/arm64/timestamp.c:uint64_t timestamp_get(void) src/arch/x86/lib/timestamp.c:uint64_t timestamp_get(void) src/include/timestamp.h:uint64_t timestamp_get(void); src/lib/timestamp.c:uint64_t __attribute__((weak)) timestamp_get(void) src/soc/imgtec/pistachio/monotonic_timer.c:uint64_t timestamp_get(void) That's what I see. Presumably your qemu build is using the one in src/arch/x86/lib/timestamp.c. Do you have a config I can use to try and reproduce? The weak symbol might be picked up inappropriately. If that's the case then... did I ever say how much I don't like our linking process? > > I need to look at your logs to know the build failure. > >> Thanks! >> >> -- >> Timothy Pearson >> Raptor Engineering >> +1 (415) 727-8645 >> http://www.raptorengineeringinc.com >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] QEMU build failure in master
by Timothy Pearson 06 May '15

06 May '15

On 05/06/2015 06:54 AM, Patrick Georgi wrote: > 2015-05-05 21:49 GMT+02:00 Timothy Pearson<tpearson(a)raptorengineeringinc.com>: >> While working on the test system earlier today I noticed that QEMU builds >> are currently failing with the following error: >> >> coreboot/src/lib/timestamp.c:184: undefined reference to >> `timer_monotonic_get' >> >> Builds using the same configuration were working yesterday. The KFSN4-DRE >> does not appear to be affected at this time. > Regarding build failures we should be covered (at least for default > configurations). > When looking at http://qa.coreboot.org/job/coreboot/, I don't see this error. > > > Patrick Granted, the test stand configuration has more options enabled for more test coverage. My question at this point is: are timestamps a supported option for QEMU systems? The test stand sets COLLECT_TIMESTAMPS=y, and this was working until a day ago. This is the commit that broke the QEMU build: http://review.coreboot.org/10104 Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Soft-Reset when "enabling resources" on Sun Ultra 40 M2
by Nick 06 May '15

06 May '15

Hi, I'm encountering a soft-reset when "enabling resources." It occurs on the same link / device each time - dev fun 6.0 on MCP55 - which is a PCI 33Mhz bus connected to an on-board Firewire controller. I added some text at the end of the loop to make sure it was crashing on 6.0 and not 6.1. It never loops after trying to enable 6.0. Here's my console output: http://pastebin.com/15hVB9bu Here's an image showing the various devices on this motherboard and their PCI addresses: http://ibin.co/20n6DtSrgZSv The board is a Sun Ultra 40 M2 which I'm trying to get working with Coreboot. Any ideas or suggestions would be appreciated as I'm sitting here scratching my head wondering what to try next. :) Thanks in advance! -Nick

1 0

QEMU build failure in master
by Timothy Pearson 06 May '15

06 May '15

All, While working on the test system earlier today I noticed that QEMU builds are currently failing with the following error: coreboot/src/lib/timestamp.c:184: undefined reference to `timer_monotonic_get' Builds using the same configuration were working yesterday. The KFSN4-DRE does not appear to be affected at this time. Right now the test stand does not send warnings to the list about build failures in master. Is this something that the community would like to see enabled? Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Re: [coreboot] u-boot as coreboot payload on qemu-x86
by Ajoy Das 05 May '15

05 May '15

what is the difficulty u r facing ? yes it is suppose to work Thanks Ajoy On Tue, May 5, 2015 at 7:39 PM, Saket Sinha <saket.sinha89(a)gmail.com> wrote: > Hi, > > I am trying to run u-boot as a coreboot payload on qemu-x86.Currently > facing some difficulty in the process. > > Has anyone tried running u-boot as a coreboot payload on qemu-x86 before? > > Regards, > Saket Sinha > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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

05 May '15

The ASUS KFSN4-DRE fails verification as of commit 29ed46caccd5cea8401c5d133895fa3a9d6f5030 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: 29ed46c 3rdparty/vboot: Add vboot 26e24cc 3rdparty: move to 3rdparty/blobs f4f0287 3rdparty: Move to blobs b9cd5ec sandy/ivy boards: Rename defines from onboard.h for ACPI 168eda5 arch/arm64: provide boot_cpu() <24 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

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

05 May '15

The QEMU x86_64 Q35 fails verification as of commit 8ccdeaeb207031eea3881511acfaf3e949678f74 The following tests failed: CBMEM_TIMESTAMP_ACCESS_FAILURE CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: 8ccdeae haswell: Link stage_cache_external_region into ramstage, too 634899c resource: Adjust memory resources high earlier e6a9290 resource: Enhance resource reporting 134b616 resource: Report correct secondary resource window ade2c5e winent/mb6047: symbolic arguments for acpi_create_madt_lapic_nmis() <8 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 boot 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

3 2

u-boot as coreboot payload on qemu-x86
by Saket Sinha 05 May '15

05 May '15

Hi, I am trying to run u-boot as a coreboot payload on qemu-x86.Currently facing some difficulty in the process. Has anyone tried running u-boot as a coreboot payload on qemu-x86 before? Regards, Saket Sinha

1 0

Re: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)
by Patrick Georgi 04 May '15

04 May '15

2015-05-03 23:12 GMT+02:00 Emilian Bold <emilian.bold(a)gmail.com>: > I'm curious, is there some Coreboot Foundation that would gather this money > and purchase the copyright or would Raptor just somehow crowd-fund this > money to license their work as GPLv2 while keeping the copyright? With coreboot there's no organization and no copyright assignment. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

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