coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

by Wim Vervoorn

Hello Wolfgang, It is correct that you can't use this right away but the memory configurations can be made. We have done this for several FT3B SoC based boards. We can do this for your board as well. Please contact me off-line if you are interested. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn(a)eltan.com W : http://www.eltan.com "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Wolfgang Kamp - datakamp Sent: Thursday, May 07, 2015 3:19 PM To: coreboot(a)coreboot.org Subject: [coreboot] AGESA PI for Olivehill+ Hi Bruce, is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC? For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3. Regards, Wolfgang

5 years, 4 months

AGESA PI for Olivehill+

by Wolfgang Kamp - datakamp

Hi Bruce, is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC? For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3. Regards, Wolfgang

5 years, 4 months

ASUS KFSN4-DRE Automated Test Failure

by Raptor Engineering Automated Coreboot Test Stand

The ASUS KFSN4-DRE fails verification as of commit b2aee6f2e7c61ae87ddfdab00c22775313603981 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: b2aee6f vboot2: Replace hard coded 'fallback' prefix with Kconfig variable b4a6ca9 imgtec/pistachio: Add comment on the unusual memory layout c6e1f8a Add MAINTAINERS file 0ff13d9 Drop lbtdump, like it's 2007 7d89849 Drop dumpmcrr <35 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

5 years, 4 months

Problem with USB keyboard

by Anteja Vuk-Maček

Hi, I'm begin with coreboot and seaBIOS. I have the problem with USB keyboard and mouse. When I boot the firmware my keyboard and mouse don't work. I use : coreboot, payload seaBios, MinnowMax board Problem: What I need to do for correct a firmware? Best regards, *Anteja *

5 years, 4 months

Problem with USB keyboard and mouse

by Anteja Vuk Macek

5 years, 4 months

Re: [coreboot] Soft-Reset when "enabling resources" on Sun Ultra 40 M2

by Rudolf Marek

Hi, Sorry just a quick note, I need to go now. Usually it happens when resources assigned are wrong (like overlapping local APIC or the area ffexxxx which is used to deliver IRQs. CHeck resource allocation. I assume your problem happens when you enable the bridge decoding. Thanks Rudolf

5 years, 4 months

Re: [coreboot] QEMU build failure in master

by Timothy Pearson

On 05/06/2015 12:05 PM, Aaron Durbin wrote: > On Wed, May 6, 2015 at 9:54 AM, Aaron Durbin<adurbin(a)google.com> wrote: >> On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson >> <tpearson(a)raptorengineeringinc.com> wrote: >>> On 05/06/2015 11:46 AM, Aaron Durbin wrote: >>>> >>>> On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson >>>> <tpearson(a)raptorengineeringinc.com> wrote: >>>>> >>>>> 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; >>>>>> > > > This patch does make it work with your config: > > diff --git a/src/lib/timestamp.c b/src/lib/timestamp.c > index 0c9c884..4b5f4d4 100644 > --- a/src/lib/timestamp.c > +++ b/src/lib/timestamp.c > @@ -180,6 +180,9 @@ uint64_t __attribute__((weak)) timestamp_get(void) > { > struct mono_time t1, t2; > > + if (!IS_ENABLED(CONFIG_HAVE_MONOTONIC_TIMER)) > + return 0; > + > mono_time_set_usecs(&t1, 0); > timer_monotonic_get(&t2); > > > I also confirmed it is using the implementation from > src/arch/x86/lib/timestamp.c. So I'm not sure why the original link > failed... Your earlier explanation seems sound and the patch looks reasonable, so if you want to push it up to Gerrit I'll be happy to +1 it. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

5 years, 4 months

Re: [coreboot] QEMU build failure in master

by Aaron Durbin

On Wed, May 6, 2015 at 9:54 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson > <tpearson(a)raptorengineeringinc.com> wrote: >> On 05/06/2015 11:46 AM, Aaron Durbin wrote: >>> >>> On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson >>> <tpearson(a)raptorengineeringinc.com> wrote: >>>> >>>> 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; >>>>> This patch does make it work with your config: diff --git a/src/lib/timestamp.c b/src/lib/timestamp.c index 0c9c884..4b5f4d4 100644 --- a/src/lib/timestamp.c +++ b/src/lib/timestamp.c @@ -180,6 +180,9 @@ uint64_t __attribute__((weak)) timestamp_get(void) { struct mono_time t1, t2; + if (!IS_ENABLED(CONFIG_HAVE_MONOTONIC_TIMER)) + return 0; + mono_time_set_usecs(&t1, 0); timer_monotonic_get(&t2); I also confirmed it is using the implementation from src/arch/x86/lib/timestamp.c. So I'm not sure why the original link failed...

5 years, 4 months

Re: [coreboot] QEMU build failure in master

by Timothy Pearson

On 05/06/2015 11:46 AM, Aaron Durbin wrote: > On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson > <tpearson(a)raptorengineeringinc.com> wrote: >> 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. > > The compiler would throw out that code not used using dead code elimination. All right, I wasn't sure if we wanted to rely on that or not. It "feels" fragile at first glance, and might provide an unpleasant surprise down the line to a programmer less familiar with the internal workings of compilers. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

5 years, 4 months

Re: [coreboot] QEMU build failure in master

by Timothy Pearson

On 05/06/2015 11:45 AM, Aaron Durbin wrote: > On Wed, May 6, 2015 at 9:41 AM, Aaron Durbin<adurbin(a)google.com> wrote: > > 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? I'm not sure. The failing builds have long since been destroyed by other test runs from Gerrit, so I'd need to build this on a different machine to check. > $ 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? Configuration file attached. As I mentioned before, this file worked fine until the recent commit. I haven't analysed the problem in any detail except to find the offending commit, so it is quite possible the configuration file still needs an update. Thanks! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

5 years, 4 months

← Newer
1
...
6
7
8
9
10
11
12
Older →

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2015