coreboot February 2014

coreboot@coreboot.org

52 participants
148 discussions

Annoying DUET UEFI failures
by Anthony Ross 13 Feb '14

13 Feb '14

Hello All Well sometime back I had successfully build the DuetPkg on both IA32 & X64 architectures. Futher experimenting I came across the build32.sh which enabled me to prepare the efiloaders & floppy images without the need to follow their manual setups. Well after setting up my USB flash for DUET & booting I faced a freeze problem like a hyphen in the left side corner. It would get stuck there until I restarted & so I was unable to figure the problem at all. However getting to qemu to boot it seemed just successful & capturing debugging messages was just useless. Thus Goggling a bit I came across rod books a BIOS to UEFI Transformation wherein it was mentioned that one of the versions may succeed i.e. either 2.1 or 2.3.1 so I figured out it between EDK_UEFI64 & UDK_X64 (resp) & decided to go with the 2.1 version & there it just booted successfully. I dont know why there is a failure between EDK_UEFI64 & UDK_X64. I had last time falsely implicated it to be a EM64T error which I had noticed on Oracles VM Box but my processor (Intel Pentium D) readily supports it. By the way this how I had set up the USB. I followed Migles BootDuet<https://github.com/migle/BootDuet/blob/master/INSTALL> user#cd BootDuet user# dd if=/dev/zero of=/dev/sdb bs=3M count=1 && cfdisk.gnu /dev/sdb Under which I created a msdos table, setting up a fat32 partition & 'boot' & 'lba' flags user#make lba64 user# make DEVICE=/dev/sdb1 install-bd32_64 then disconnected my USB & reconnecting user# mount /dev/sdb1 /mnt/windows && ./copy_duet_files.sh /mnt/windows/ UDK_X64 I hope so someone on this mailing list would help me solve my problem. I know that I should have posted this on the edk2 mailing list but since the DUET setup has been a part of the coreboot development I decided to ask for help here. Regards Neo

1 0

Re: [coreboot] Error while creating FILO payload
by Gelip 13 Feb '14

13 Feb '14

Use coreboot v4, change FILO repo from svn to git clone http://review.coreboot.org/p/filo.git and disable USB support.

1 0

The fallacy of the CONFIG_* plague
by mrnuke 13 Feb '14

13 Feb '14

=== START_TLDR /* Skip to END_TLDR if you're short on time */ === It seems that we're using "#if CONFIG_" like free coffee and cookies in a conference. Without thinking too much of it. And we're using very much of this in generic code, which is, as I will point out why shortly, a very bad idea. It wouldn't matter as much if we only used CONFIGs to control the build process, or some mundane board-specific options. One problem is, that we've started using them excessively in generic code. Generic code should be just that, generic. If we need it to behave one way or another, we should do so by the vales we pass it not by board-specific Kconfigs. Take lib/ for example. We should be able to compile, the entire directory into a set of static libraries: * libcorebootlib_rom.i386.a * libcorebootlib_ram.i386.a * libcorebootlib_bootblock.armv7.a * libcorebootlib_rom.armv7.a * libcorebootlib_ram.armv7.a And use those libraries as-are, in every single board and component, without their behavior depending on Kconfigs. I am allowing for stage-specific versioning here due to the joys early init may throw at us. The same reasoning applies to chip-generic code -- basically most things _not_ under src/mainboard/. Case in point: http://review.coreboot.org/#/c/5199/ The intent is to use CONFIG_, not for the purpose of solving a practical problem, but just for the sake of fixing a build failure. It feels like a "if it compiles, let's ship it" mindset. Who cares, really? There is a very practical aspect to lib-izing generic code, and that is the abuild step. We can speed that up tremendously by being smart. ccache helps a bit, but only so much. Another practical aspect is eliminating confusion relating to "what does the code do now, whith _this_ option instead of _that_ option?". === END_TLDR === So, instead of having a generic function doing void function(void) { #if IS_ENABLED(CONFIG_HAVE_LOLLIPOP) printk(BIOS_YUMMY, "Sucking on a lollipop\n"); #else printk(BIOS_SUCKY, "Meanie!!\n"); #endif } We make it dynamically polymorphic: void function(bool has_lollipop) { if (has_lollipop) printk(BIOS_YUMMY, "Sucking on a lollipop\n"); else printk(BIOS_INFO, "Mister stole my lollipop\n"); } Let the mainboard pass the lollipop option instead of Kconfig-izing it. The only place where code flow/values should depend on anything CONFIG_* should be in (tentative list warning): * board-specific code * enabling debug options not used in production code (irrelevant for abuild) * linker scripts * very early init (assembly part of the bootblock) And of course, we use the linker to garbage-collect unused functions for the sake of space. Q.E.D. Thoughts, comments, concerns, paint ideas? Alex

4 8

Re: [coreboot] licensing text
by John Lewis 12 Feb '14

12 Feb '14

On 12/02/14 07:30, ron minnich wrote: > This note is motivated by mr.nuke.me <http://mr.nuke.me>'s recent CLs > with a short-form GPL notice in them. I like that notice but I think it > needs a tweak, then we can just use it everywhere. > > I just got done relicensing a different project under the GPL. In the > process I had to discuss wording and such with Eben Moglen. > > Based on his suggestions the other project ended up with a very standard > form which I've adapted for coreboot. > > In each file, we'd have this to replace the current pile of text. > > "This file is part of Coreboot Project. It is subject to the license Just a couple of minutiae observations. I thought coreboot was supposed to be all lower-case, and shouldn't it read "This file is part of *the* coreboot project" to avoid sounding like you don't have a grasp of English? John.

3 2

Re: [coreboot] Error while creating FILO payload
by Gelip 12 Feb '14

12 Feb '14

Read this: http://www.coreboot.org/pipermail/coreboot/2014-January/076987.html

2 1

Re: [coreboot] licensing text
by mrnuke 12 Feb '14

12 Feb '14

On Tuesday, February 11, 2014 11:30:04 PM ron minnich wrote: > This note is motivated by mr.nuke.me's recent CLs with a short-form GPL > notice in them. I like that notice but I think it needs a tweak, then we > can just use it everywhere. > Which was motivated by some of your gerrit comments. > "This file is part of Coreboot Project. It is subject to the license terms > in the LICENSE file found in the top-level directory of this distribution > and at http://www.coreboot.org/license.html. No part of the Coreboot > Project, including this file, may be copied, modified, propagated, or > distributed except according to the terms contained in the LICENSE file." > > OK, I admit, I painted it because I'm sure the shed will end up with a > different color :-) > Yes, yes, no html formatting in emails etc. etc. but sometimes rules must > be broken. > I had to turn on html in Kmail to see the paint. Now that I can see the paint... 1. One has to consider that every line this text takes is one less line of code that is visible when opening a file. So, is that the absolute minimum we can get to. I've seen a few projects which use a license identifier tag, along with an explanation in the README as to what that tag means and how to interpret it. 2. There's no longer a place to license under GPLv2 or GPLv2+. It's always a nice touch, and a fun step, to decide whether a certain file you wrote should go under v2 or v2+. 3. Re-licensing everything under v2 will piss a lot of people who like the "+". Some of those v2+ contributions are heavily copied from other v2+ projects (read: allwinner from uboot), and I'm not sure that you can simply strip the "+" from the license of such files, as you're potentially misrepresenting the intent of the author(s). > I regret that it contains a URL, but in these dark times, one must make > concessions. > Old text contained both a URL and address. I think this is a step forward. > So, does this work or do people have objections? > I need to keep my reputation as the most annoying guy. Of course I have objections :p. Alex

3 2

Re: [coreboot] licensing text
by Paul Menzel 12 Feb '14

12 Feb '14

Dear Ron, thank you for your proposal. Am Dienstag, den 11.02.2014, 23:30 -0800 schrieb ron minnich: […] > I just got done relicensing a different project under the GPL. In the > process I had to discuss wording and such with Eben Moglen. By the way, which project is this? […] > In each file, we'd have this to replace the current pile of text. > > "This file is part of Coreboot Project. It is subject to the license terms > in the LICENSE file found in the top-level directory of this distribution We currently do not have a `LICENSE` file in our repository. There is only `COPYING` file. “distribution” sounds strange to me. But that is just me I guess. > and at http://www.coreboot.org/license.html. No part of the Coreboot > Project, including this file, may be copied, modified, propagated, or > distributed except according to the terms contained in the LICENSE file." […] > So, does this work or do people have objections? The other things I found were already brought up by others. Thanks, Paul

1 0

Re: [coreboot] licensing text
by mrnuke 12 Feb '14

12 Feb '14

I meant to send this to the list, not Ron alone. Sorry Ron. On Wednesday, February 12, 2014 10:18:33 AM you wrote: > Note that if a file ALREADY has notice in it, then we don't change > anything. So, in the limit, we can start using this new notice for > (e.g.) your stuff and only apply it as we wish. > > That said, would you like to take a pass at the wording? Green, maybe :-) Black and/or white!! * LICENSE_TAG: GPLv2+ (See README in top-level directory for explanation) * LICENSE_TAG: GPLv2 (See README in top-level directory for explanation) * LICENSE_TAG: BSD3c (See README in top-level directory for explanation) * LICENSE_TAG: BSD2c (See README in top-level directory for explanation) * Public domain (See README in top-level directory for explanation) Alex

1 0

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
by Idwer Vollering 12 Feb '14

12 Feb '14

> Thank you for this information. Please indicate the compatible > processor on the motherboard page. See this list: http://en.wikipedia.org/wiki/List_of_AMD_Accelerated_Processing_Unit_microp… I'll add it to the board's wiki page.

1 0

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
by HacKurx 12 Feb '14

12 Feb '14

>> Very odd. I had hoped it was something easy. I wonder what differs for >> Richland (as Idwer said) so that it doesn't work. My best understanding of >> Richland (A10-6800K) is that the memory controller has higher rated speeds >> but should work with Trinity AGESA code, since the Trinity AGESA code >> already had the ability to overclock to 2133 MHz DDR3. >> >> It seems the problem is getting a good debug log with IDSOPT_IDS_ENABLED, >> and that is baffling. I've attached a coreboot image, but please check the >> config and use cbfstool for payloads *before* flashing it. >> >> David >> >> Here is the .config I used. Also, this is a pretty old version of coreboot >> (7bb29d72ab89c300fa899a8cf39803ae8f101ff4). > > The email with the rom attached is too big for the coreboot list, but > HacKurx, please let me know if you try out the rom. > > David Thank you, I tested your rom and I get the same result: coreboot-4.0-4561-g7bb29d7 Wed Jul 24 23:26:25 MDT 2013 starting... BSP Family_Model: 00610f31 cpu_init_detectedx = 00000000 agesawrapper_amdinitreset > The problem is that we don't have Richland AGESA code: > src/vendorcode/amd/agesa/f15rl/ does, unfortunately, not exist. > > Idwer Thank you for this information. Please indicate the compatible processor on the motherboard page. I think tried to contact people from AMD to get the Richland AGESA code. -- Best regards, HacKurx www.hackurx.info

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
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