coreboot September 2015

coreboot@coreboot.org

36 participants
50 discussions

Re: [coreboot] [help]build cbfstool fail with cygwin64
by Kurt Qiao 17 Sep '15

17 Sep '15

hi i finally built pass with define CFLAGS += -std=gnu99 in cbfstool/Makefile TOOLCFLAGS ?= -std=gnu99 in cbfstool/Makefile.inc change cbfstool.c code to : -- if (tolower(suffix[0])=='k') { ++ if (tolower((int)suffix[0])=='k') { -- if (tolower(suffix[0])=='m') { ++ if (tolower((int)suffix[0])=='m') { is there anyway to dynamic define std to gnu99 when detect build with cygwin? 2015-09-15 21:05 GMT+08:00 Kurt Qiao <kurtqqh(a)gmail.com>: > sorry for typo, fix step 1 code: > > so i change my cbfstool.c code to : > -- if (tolower(suffix[0])=='k') { > ++ if (tolower((int)suffix[0])=='k') { > > -- if (tolower(suffix[0])=='m') { > ++ if (tolower((int)suffix[0])=='m') { > > 2015-09-15 21:01 GMT+08:00 Kurt Qiao <kurtqqh(a)gmail.com>: >> do a quick update here, thanks for Stefan, the solution seems part of >> work for me >> >> 1. i changed to cygwin(32bit) due to cygwin64 always got fail, but i >> got same fail with cygwin, so below update i based on cygwin. >> >> 2. default build will error as below, >> HOSTCC cbfstool/cbfstool.o >> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function 'main': >> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error: array >> subscript has type 'char' [-Werror=char-subscripts] >> if (tolower(suffix[0])=='k') { >> ^ >> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1078:5: error: array >> subscript has type 'char' [-Werror=char-subscripts] >> if (tolower(suffix[0])=='m') { >> ^ >> >> so i change my cbfstool.c code to : >> -- if (tolower(suffix[0])=='k') { >> ++ if ((int)tolower(suffix[0])=='k') { >> >> -- if (tolower(suffix[0])=='m') { >> ++ if ((int)tolower(suffix[0])=='m') { >> >> >> 3. patch 11636 works, so build pass util/cbfstool/common.c >> but patch 11637 will fail with function '_fileno' >> HOSTCC cbfstool/fmaptool.o >> HOSTCC cbfstool/cbfs_sections.o >> HOSTCC cbfstool/fmap_from_fmd.o >> HOSTCC cbfstool/fmd.o >> HOSTCC cbfstool/fmd_parser.o >> HOSTCC cbfstool/fmd_scanner.o >> <stdout>: In function 'yy_init_buffer': >> <stdout>:1399:9: error: implicit declaration of function '_fileno' >> [-Werror=implicit-function-declaration] >> cc1: all warnings being treated as errors >> util/cbfstool/Makefile.inc:59: recipe for target >> 'build/util/cbfstool/fmd_scanner.o' failed >> make: *** [build/util/cbfstool/fmd_scanner.o] Error 1 >> >> >> 2015-09-15 2:07 GMT+08:00 Stefan Reinauer <stefan.reinauer(a)coreboot.org>: >>> * Kurt Qiao <kurtqqh(a)gmail.com> [150909 09:42]: >>>> does anyone try cygwin64 to build coreboot in windows7 64bit? >>>> i got fail when build cbfstool with cygwin64. >>> >>> Can you try the following two patches to see if they solve your problem >>> >>> http://review.coreboot.org/11636 Don't use fileno() to get file size >>> http://review.coreboot.org/11637 fmd: Use _fileno() on MINGW >>> >>> Also, if that doesn't work try to replace the MINGW check with something >>> like #if defined (_WIN64) || defined (__CYGWIN64__) instead. >>> >>> (Make sure to run make clean in the cbfstool directory before trying) >>> >>> Stefan

1 0

Kconfig: My clang -print-file-name doesn't output the full path
by Bao, Zheng 17 Sep '15

17 Sep '15

The output of uname on my MacOS. # uname -a Darwin Baos-Mac-Pro.local 13.0.0 Darwin Kernel Version 13.0.0: суббота, 9 ноября 2013 г. 02:42:04 (MSK); root:xnu-2422.1.72_by_bronya_sinetek_anv_rc7/BUILD/obj/RELEASE_X86_64 x86_64 Gcc version: # gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix # gcc -print-file-name=libncurses.dylib libncurses.dylib # ls /usr/lib/libncurses.dylib /usr/lib/libncurses.dylib The ld option -lncurses can link the right library. Is this a bug on my MacOS. If it is, I will stop trying that? Zheng

2 1

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

16 Sep '15

The ASUS KFSN4-DRE fails verification as of commit a0e77384638878ffb8b6a970f4655eb071e8a7c1 The following tests failed: VIDEO_FAILURE Commits since last successful test: a0e7738 abuild: don't complain about missing junit reports for skipped boards 053322f abuild: log bulding tools 098c4a8 abuild: don't create junit tests with empty testclass field See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also 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

coreinfo "General Protection Fault Exception"
by Maxime de Roucy 16 Sep '15

16 Sep '15

Hello, On a pcengines apu1 when I tried to leave coreinfo (press ESC) I get a "General Protection Fault Exception". I attached my .config file of coreinfo (it's the default configuration) and the console output when coreinfo crash. -- Regards Maxime de Roucy

3 4

Re: [coreboot] [help]build cbfstool fail with cygwin64
by Stefan Reinauer 15 Sep '15

15 Sep '15

* Kurt Qiao <kurtqqh(a)gmail.com> [150909 09:42]: > does anyone try cygwin64 to build coreboot in windows7 64bit? > i got fail when build cbfstool with cygwin64. Can you try the following two patches to see if they solve your problem http://review.coreboot.org/11636 Don't use fileno() to get file size http://review.coreboot.org/11637 fmd: Use _fileno() on MINGW Also, if that doesn't work try to replace the MINGW check with something like #if defined (_WIN64) || defined (__CYGWIN64__) instead. (Make sure to run make clean in the cbfstool directory before trying) Stefan

3 2

Re: [coreboot] STACK_SIZE pcengines apu1
by Alex G. 15 Sep '15

15 Sep '15

> In either case it's in AGESA. Of course it's AGESA. Good job on figuring out which part of AGESA (this is usually the hard part). Alex

1 0

unbricking an Acer CB5
by Holger Brunn 15 Sep '15

15 Sep '15

Dear readers, I played with compiling my own coreboot image for my Acer CB5 [1] and failed miserably - the bios is messed up and the device won't boot any more. Now I'm busy following some guides to undo the damage [2], [3] by flashing the original bios again, but given I'm quite clueless about hardware, I'd like to ask you for advice about how to proceed: I ordered a Raspberry PI, some connector cables [4], and then I probably need a clip to connect the chip [5]. My question to you is how to locate the chip? The mainboard looks like that: http://opensource.holgerbrunn.net/debian-on-acer-cb5/images/DSC01629.JPG and the only chip that looks like those in the examples is U37 in the lower right. Is there any way to know beforehand if it's the correct one? And then when connecting the pins, can I look up somewhere what the correct assignment is or is this trial and error? I can't read what is printed on it, but if relevant, I'll get a magnifying glass to post the text. Thank you a lot in advance, and be sure that I won't come back whining if anything goes wrong and I fry the chip following your advice - that's entirely my fault then. I'll log the process on the above website if successful so that the next person messing this up won't have to bother you. Regards, Holger Links: [1] https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… [2] http://www.tnhh.net/2014/08/25/unbricking-chromebook-with-beaglebone.html [3] https://johnlewis.ie/unbricking-a-samsung-series-5-550-chromebook [4] https://www.conrad.nl/nl/raspberry-pi-verbindingskabel-rb-cb5-025-bont-bana… [5] http://www.digikey.nl/product-detail/en/5250/501-1311-ND/745102

2 3

Re: [coreboot] STACK_SIZE pcengines apu1
by Kyösti Mälkki 11 Sep '15

11 Sep '15

On pe, 2015-09-11 at 15:49 -0500, Aaron Durbin wrote: > On Fri, Sep 11, 2015 at 3:36 PM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: > > Dear coreboot folks, > > > > > > Am Donnerstag, den 10.09.2015, 16:25 -0700 schrieb Julius Werner: > >> I'd bet it's just a single large allocation somewhere. You can try adding > >> > >> CFLAGS_ramstage += -Wstack-usage=1024 > >> > >> somewhere in coreboot/Makefile.inc and then clean+rebuild your code while > >> passing '-k' to make. You'll get a bunch of compiler warnings, and one of > >> them is likely to be the culprit. > > > > It looks like that Julius was dead on! Building the similar ASRock > > E350M1 with the modification proposed by Julius, building stops with > > the error below. > > > > ``` > > $ make > > […] > > CC northbridge/amd/agesa/oem_s3.ramstage.o > > src/northbridge/amd/agesa/oem_s3.c: In function 'OemS3Save': > > src/northbridge/amd/agesa/oem_s3.c:118:14: error: stack usage might be 4144 bytes [-Werror=stack-usage=] > > AGESA_STATUS OemS3Save(void *vS3SaveParams) > > ^ > > ``` > > Fun. 4KiB buffer on the stack for the win. > > $ git grep S3_DATA_MTRR_SIZE -- src/northbridge/amd/agesa/ | grep define > src/northbridge/amd/agesa/oem_s3.c:#define S3_DATA_MTRR_SIZE > 0x1000 > Yeah, my bad. I overlooked stack usage while wondering if those MTRRs really need to be backed up in SPI in the first place. http://review.coreboot.org/#/c/11633/ Thanks, Kyösti

1 0

Berlin User Group Meeting 21.Sep
by Alexander Couzens 11 Sep '15

11 Sep '15

Hi folks, I'm starting a User Group in Berlin. The first meeting will take place on 21. Sep. in the CCCB. For more information about the location take a look on https://berlin.ccc.de/wiki/Club_Discordia Best, lynxis PS: Yes it's Monday evening and it's open for everyone. -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)jabber.ccc.de mobile: +4915123277221

1 1

Re: [coreboot] STACK_SIZE pcengines apu1
by Paul Menzel 11 Sep '15

11 Sep '15

Dear coreboot folks, Am Donnerstag, den 10.09.2015, 16:25 -0700 schrieb Julius Werner: > I'd bet it's just a single large allocation somewhere. You can try adding > > CFLAGS_ramstage += -Wstack-usage=1024 > > somewhere in coreboot/Makefile.inc and then clean+rebuild your code while > passing '-k' to make. You'll get a bunch of compiler warnings, and one of > them is likely to be the culprit. It looks like that Julius was dead on! Building the similar ASRock E350M1 with the modification proposed by Julius, building stops with the error below. ``` $ make […] CC northbridge/amd/agesa/oem_s3.ramstage.o src/northbridge/amd/agesa/oem_s3.c: In function 'OemS3Save': src/northbridge/amd/agesa/oem_s3.c:118:14: error: stack usage might be 4144 bytes [-Werror=stack-usage=] AGESA_STATUS OemS3Save(void *vS3SaveParams) ^ ``` Thanks, Paul

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2015