coreboot February 2014

coreboot@coreboot.org

52 participants
148 discussions

Re: [coreboot] Setting up build environment
by Idwer Vollering 10 Feb '14

10 Feb '14

Adding seabios at seabios dot org to the recipients. 2014-02-10 0:47 GMT+01:00 Andy Pont <andy.pont(a)sdcsystems.com>: > Hello! > >> Apparently CentOS installs, or will install, a really old version of >> iasl; here you'll see that they (still) use >> iasl-20090123-3.1.el6.x86_64: >> http://mirror.centos.org/centos/6.5/os/x86_64/Packages/ while the xgcc >> version is 20130626. > > After doing some poking around it appears that IASL doesn't like the fact > that my home directory is /home/andy.pont and I assume that it is the dot > that is upsetting it as if I clone coreboot into a subdirectory under > /home/andy then the default configuration builds correctly. > > Thanks for your help and guidance, it is much appreciated. > > Andy. > Actually, this happens when you clone coreboot into a dir where its parent dir has a dot in it, and compile for any board without touching the payload defaults: python ./tools/acpi_extract.py /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst > /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.off Traceback (most recent call last): File "./tools/acpi_extract.py", line 221, in <module> for line in fileinput.input(): File "/usr/lib/python2.7/fileinput.py", line 252, in next line = self.readline() File "/usr/lib/python2.7/fileinput.py", line 344, in readline self._file = open(self._filename, self._mode) IOError: [Errno 2] No such file or directory: '/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst' make[2]: *** [/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.hex] Error 1 make[1]: *** [build] Error 2 make: *** [seabios] Error 2 rm build/cbfs/fallback/romstage_null.elf build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c

1 0

Re: [coreboot] Setting up build environment
by Andy Pont 10 Feb '14

10 Feb '14

Hello! > Apparently CentOS installs, or will install, a really old version of > iasl; here you'll see that they (still) use > iasl-20090123-3.1.el6.x86_64: > http://mirror.centos.org/centos/6.5/os/x86_64/Packages/ while the xgcc > version is 20130626. After doing some poking around it appears that IASL doesn't like the fact that my home directory is /home/andy.pont and I assume that it is the dot that is upsetting it as if I clone coreboot into a subdirectory under /home/andy then the default configuration builds correctly. Thanks for your help and guidance, it is much appreciated. Andy.

1 0

Re: [coreboot] Setting up build environment
by Idwer Vollering 10 Feb '14

10 Feb '14

2014-02-09 20:05 GMT+01:00 Andy Pont <andy.pont(a)sdcsystems.com>: > Hello Idwer, 8< > I have noticed that whenever I call make it gives a warning about not having > a compiler for aarch64-elf and also complains about not having an IASL > compiler and suggesting that I install the one that comes with CentOS. You do not need aarch64-elf to compile for qemu, but you can leave the built binaries around. Apparently CentOS installs, or will install, a really old version of iasl; here you'll see that they (still) use iasl-20090123-3.1.el6.x86_64: http://mirror.centos.org/centos/6.5/os/x86_64/Packages/ while the xgcc version is 20130626. --- Another possible solution is to compile SeaBIOS manually: $ git clone https://github.com/KevinOConnor/seabios.git seabios_github && cd seabios_github $ make menuconfig <choose coreboot as the hardware target, then exit> $ make IASL=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/iasl Then adjust the coreboot configuration so that it uses the manually compiled ELF, found in seabios_github/out/bios.bin.elf and run 'make' again in the coreboot directory. > > Thanks, > > Andy. >

1 0

Re: [coreboot] Setting up build environment
by Andy Pont 09 Feb '14

09 Feb '14

Hello Idwer, > Which version of python are you using here? My build box uses 2.7.6 I am using the default versions of tools that come with CentOS 6.5 so host gcc is version 4.4.7 and Python is version 2.6.6. I fired up my old 32bit Debian box which has Python 2.6.2 and host gcc version and it builds the same default coreboot configuration without any problems - albeit slowly as it is a single core 1.2GHz machine! The command that fails is: /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/iasl -Pn -vs -l -tc -p /home/andy.pont/Software/coreboot/build/seabios/out/acpi-dsdt /home/andy.pont/Software/coreboot/build/seabios/out/acpi-dsdt.dsl.i Which generates: Error 6092 - Could not open file "(null)" (Permission denied) Playing about with this command on the command line removing the -p /home/andy.pont/Software/coreboot/build/seabios/out/acpi-dsdt option will make the command execute correctly. > Can you show the content of .xcompile, found in the top directory > where you cloned coreboot into? .xcompile is as follows: =================== START =================== # x86 TARCH_SEARCH= /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf- i386-elf- i386-linux-gnu- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-eabi- i386-eabi- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/x86_64-elf- x86_64-elf- x86_64-linux-gnu- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/x86_64-eabi- x86_64-eabi- # elf32-i386 toolchain (/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf-gcc) CC_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf-g cc -Wno-unused-but-set-variable -Wa,--divide -fno-stack-protector -Wl,--build-id=none CPP_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf- cpp AS_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf-a s LD_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf-l d NM_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf-n m OBJCOPY_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386- elf-objcopy OBJDUMP_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386- elf-objdump READELF_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386- elf-readelf STRIP_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-el f-strip AR_i386:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/i386-elf-a r # armv7 TARCH_SEARCH= /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7a-elf- armv7a-elf- armv7a-linux-gnu- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7a-eabi- armv7a-eabi- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-elf- armv7-a-elf- armv7-a-linux-gnu- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-eabi- armv7-a-eabi- # elf32-littlearm toolchain (/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-eabi-gcc) CC_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-e abi-gcc -Wno-unused-but-set-variable -fno-stack-protector -Wl,--build-id=none CPP_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a- eabi-cpp AS_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-e abi-as LD_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-e abi-ld NM_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-e abi-nm OBJCOPY_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv 7-a-eabi-objcopy OBJDUMP_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv 7-a-eabi-objdump READELF_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv 7-a-eabi-readelf STRIP_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7- a-eabi-strip AR_armv7:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/armv7-a-e abi-ar # aarch64 TARCH_SEARCH= /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/aarch64-elf- aarch64-elf- aarch64-linux-gnu- /home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/aarch64-eabi- aarch64-eabi- IASL:=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/iasl # native toolchain HOSTCC:=gcc =================== END =================== I have noticed that whenever I call make it gives a warning about not having a compiler for aarch64-elf and also complains about not having an IASL compiler and suggesting that I install the one that comes with CentOS. Thanks, Andy.

1 0

LinuxTag in Berlin from May 8–10, 2014
by Paul Menzel 08 Feb '14

08 Feb '14

Dear coreboot folks, just a short announcement that after FOSDEM last weekend the next free software event (in Europe(?)) is going to be LinuxTag in Berlin from May 8–10, 2014. The location is going to be different this year. Since several years it won’t be happening at Messe Berlin but at STATION BERLIN [2]. So please mark that in your calender and let’s see what we can come up with coreboot wise for that event. Thanks, Paul [1] http://linuxtag.de/2014/en/ [2] http://www.station-berlin.de/en/location_directions/location.html

3 2

Re: [coreboot] LinuxTag in Berlin from May 8-10, 2014
by Peter Stuge 08 Feb '14

08 Feb '14

ron minnich wrote: > I hope it is a different group running it. If it's the same group, > prepare for frustration in the arrangements ... I've been taking coreboot to LinuxTag since 2007 and haven't had too many issues; the organizers do a good job, but they're all volunteers. Previous years Messe Berlin (the fairground company) has been sponsoring LinuxTag with exhibition halls and booth furniture. This year it's a different location and Messe Berlin isn't involved at all. Everything is handled by the main organizers. I think this change has great potential and can mean a much smoother ride for everyone involved. My impression of Messe Berlin over the years is that they're pretty bureacratic. //Peter

1 0

Re: [coreboot] HP Chromebook 14 (Falco)
by ron minnich 08 Feb '14

08 Feb '14

On Sat, Feb 8, 2014 at 2:01 PM, Gregg Levine <gregg.drwho8(a)gmail.com> wrote: > Once when trying to build a kernel that was closer to the term unique > rather then the generic one that normally traveled with one of my > systems, I came across references to certain items that had Google's > fingerprints on it. I asked about it here, and sure enough the > response was that it was invented for the Google servers, and was sent > as contribution to the Linux Kernel community. Which pretty much makes my point; that code was doubtless in use for quite some time before release. It's the way it works, not just at Google. Companies develop and perfect this stuff, and release comes later, and upstreaming is never a small effort. ron

1 0

Re: [coreboot] HP Chromebook 14 (Falco)
by Gregg Levine 08 Feb '14

08 Feb '14

Hello! For what's worth since at the moment I'm a spectator and sometimes comments maker, I agree. Once when trying to build a kernel that was closer to the term unique rather then the generic one that normally traveled with one of my systems, I came across references to certain items that had Google's fingerprints on it. I asked about it here, and sure enough the response was that it was invented for the Google servers, and was sent as contribution to the Linux Kernel community. I wasn't able to make my unique kernel work, but it was an interesting job. And I'm still interested in figuring out further how I can contribute to this particular example of software running hardware properly. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Sat, Feb 8, 2014 at 4:03 PM, ron minnich <rminnich(a)gmail.com> wrote: > On Sat, Feb 8, 2014 at 8:30 AM, Peter Stuge <peter(a)stuge.se> wrote: >> ron minnich wrote: > >> I disagree. I do think it means that the project isn't fitting its >> contributors so well. Note that I am explicitly not saying and not >> thinking that it is a failure of any contributor. > > If you have some idea, then propose it. Best to propose something then > just say "this is wrong". > >> >> If the project could change to work somehow differently and that >> would help contributors then I think that's something we should >> consider identifying and doing. > > who is the "we" here? Who identifies, and what do they do? And how do > you manage the fact that companies may do development that for a > number of reasons can not be released immediately? > >> >> >>> It's a natural consequence of the fact that companies can't always >>> immediately push all their work upstream. >> >> What's the difference from Linux kernel development again? > > Nothing. Most companies I know of that use Linux, and contribute to > upstream, deal with the issue of upstream vs. what is done in the > company and the time delay involved. They have the same time delta > issue with their internal patches vs. upstream. So we're not > different. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] HP Chromebook 14 (Falco)
by Peter Stuge 08 Feb '14

08 Feb '14

ron minnich wrote: > > That sounds like upstream has failed completely. > > there is a delta in time between when it is working in > the chromium repo and it makes it to upstream. .. > We've always had this situation. It's not new. That just means that we haven't improved in a very long time. :\ > It's just plain wrong to characterize this as a failure. I disagree. I do think it means that the project isn't fitting its contributors so well. Note that I am explicitly not saying and not thinking that it is a failure of any contributor. If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing. > It's a natural consequence of the fact that companies can't always > immediately push all their work upstream. What's the difference from Linux kernel development again? > Expecting anything else is unrealistic. I don't think expectations are too usefule but I think it's what we should strive towards? //Peter

4 3

Re: [coreboot] HP Chromebook 14 (Falco)
by Peter Stuge 08 Feb '14

08 Feb '14

ron minnich wrote: > Your BEST bet to start is to use the chromium development environment, > and the sources we use, rather than upstream That sounds like upstream has failed completely. What would need to change in upstream to avoid this waste of time? //Peter

2 1

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2014