coreboot December 2013

coreboot@coreboot.org

40 participants
108 discussions

Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 26eaf9d Family14: Add support for solder-down DDR memory
by Peter Stuge 15 Dec '13

15 Dec '13

Dave Frodin wrote: > The reading of the SPD will no longer be in the northbridge/ path > but will be in a lib function. Where will it read from? Please don't answer just half of the comments. What about devicetree.cb? //Peter

2 1

Re: [coreboot] Removing microcode updates from blobs
by Peter Stuge 14 Dec '13

14 Dec '13

ron minnich wrote: > > I do not understand why you are against moving microcodes to blobs.git. > > because we have something that works today That is, unfortunately, quite telling. >:( I would hope that the coreboot community as a whole strives for a whole lot better than "works" thank you very much. > I can not see how moving the microcode to a separate repo improves > the situation. Even if one ignores the completely obvious technical advantage of unifying this aspect of coreboot code and the merely potential legal benefit for stupid downstreams that will never understand that what you have done is already kosher, the change will improve the situation on the IRC channel, which is in itself worthwhile. ron minnich wrote: > ok, ok, removing -2. Doesn't mean I like it Thank you! //Peter

1 0

Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 26eaf9d Family14: Add support for solder-down DDR memory
by mrnuke 14 Dec '13

14 Dec '13

On 12/14/2013 01:06 PM, Dave Frodin wrote: > Thanks everybody for the review and comments. > I'm going to push a new commit that does what needs to be done in > hopefully a better way. > The reading of the SPD will no longer be in the northbridge/ path but will > be in a lib function. > > Thanks, > Dave > I'll be looking forward to that "Patch set updated" email. :) A;ex

1 0

Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 26eaf9d Family14: Add support for solder-down DDR memory
by Paul Menzel 14 Dec '13

14 Dec '13

Dear Dave, dear coreboot folks, hopefully this can be discussed and agreed upon more quickly on the list. Am Samstag, den 14.12.2013, 01:25 +0100 schrieb Dave Frodin: > Dave Frodin (dave.frodin(a)se-eng.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/4532 > > commit 26eaf9ded8eac82dff31dc546f5e1c84c5e63063 > Author: Dave Frodin <dave.frodin(a)se-eng.com> > Date: Wed Dec 11 13:28:25 2013 -0700 > > Family14: Add support for solder-down DDR memory > > Normally the memory configuration/settings would be > read from a DIMM/SODIMMs SPD. This change adds support > for solder-down memory that doesn't have a SPD. The > data that would normally be read from the SPD instead > comes from a file. > > Change-Id: Ic10b0c5ca16cbc6af9400ef706392adcb151ac97 > Signed-off-by: Dave Frodin <dave.frodin(a)se-eng.com> > --- > src/northbridge/amd/agesa/Kconfig | 12 +++++ > src/northbridge/amd/agesa/family14/dimmSpd.c | 75 ++++++++++++++++++++++++++++ > 2 files changed, 87 insertions(+) Are there boards in the tree with hard-coded memory configuration/settings? > diff --git a/src/northbridge/amd/agesa/Kconfig b/src/northbridge/amd/agesa/Kconfig > index d5c039f..5af88f7 100644 > --- a/src/northbridge/amd/agesa/Kconfig > +++ b/src/northbridge/amd/agesa/Kconfig > @@ -2,6 +2,7 @@ > # This file is part of the coreboot project. > # > # Copyright (C) 2011 - 2012 Advanced Micro Devices, Inc. > +# Copyright (C) 2013 Sage Electronic Engineering, LLC > # > # This program is free software; you can redistribute it and/or modify > # it under the terms of the GNU General Public License as published by > @@ -31,6 +32,17 @@ config S3_VGA_ROM_RUN > bool > default n > > +config DDR3_SOLDERED_DOWN > + bool > + default n In my opinion such an option should be introduced globally and not just for AMD. Especially as the name does not included »AMD«. > + > +config PATH_TO_DDR3_SPD > + string > + default "" > + help > + This is the path from where it is being used/built to where > + it is stored. I have no idea how much data such a file contains. If it is rather small can it be put into `devicetree.cb` directly? […] Thanks, Paul PS: Dave, Bruce, sorry for sending the message to you twice.

4 3

CBFS: File 'pci10ec, 8139.rom' is of type 50, but we requested 30
by Gelip 14 Dec '13

14 Dec '13

I try boot PC without payload. In make menuconfig have selected this options: Devices: Run VGA Option ROMs Run non-VGA Option ROMs VGA BIOS -> Add a VGA BIOS image (SC4-F400.BIN) (5333,8a20) PXE ROM: (gpxe.rom) or (rtspxe_m.lom) (10ec,8139) PC boot and have only flash cursor '_' on screen and in debug have this message: "CBFS: File 'pci10ec,8139.rom' is of type 50, but we requested 30." How make gpxe.rom type 30 or how change request type to 50? Does possible insert Legacy Option ROM (ISA) ?

1 0

Re: [coreboot] Removing microcode updates from blobs
by ron minnich 14 Dec '13

14 Dec '13

ok, ok, removing -2. Doesn't mean I like it, but I'm willing to accept that I'm probably wrong (again :-) ron

1 0

Re: [coreboot] Removing microcode updates from blobs
by Kyösti Mälkki 14 Dec '13

14 Dec '13

On 12/14/2013 05:44 AM, ron minnich wrote: > Scott, I don't see the point of this change either. > > In the beginning, we had no microcode in coreboot, per the main goal: > let linux do it. We just let Linux do the update. Not our problem. > > At some point, ca. 2005 or so, we had to let the blobs in because many > of the new CPUs are *broken* without the microcode update: the > microcode that comes embedded in the CPU must be updated or you'll get > some real problems, and possibly not even get through firmware. > > As you point out, this is nothing like the VGA BIOS issue. > > So, sure, it's pure to build without the microcode blob, which means > in reality that you're deciding to use the microcode blob *already > embedded in the CPU*. And, on many new CPUs, the one that comes with > the CPU has issues that mean you won't get past DRAM init. And, if you > do get past DRAM init and boot, you've got a CPU that may have subtle > errors and corrupt memory. Oh, joy. > > I guess I don't understand why people feel better being able to build > a firmware image which will boot the CPU in a broken mode. > > ron > I do not understand builds without microcode updates either, but there are the legal aspects to concern. Microcode update files downloaded from Intel or AMD sites may contain licensing terms not compatible with GPLv2. Those original license texts have not been enclosed in the same commit with microcode update when they were submitted to coreboot.git repository and for some cases they may not have allowed redistribution in any form. If you are a vendor planning to distribute system with pre-installed coreboot, GPLv2 would dictate that sources and the toolchain need to be available for download. The best solution would be to push to coreboot.git, while the next best would be to host their own public repository. This is where missing or incompatible licensing for files files in coreboot.git may become a show-stopper. Quoting from FSP review : http://review.coreboot.org/#/c/4016/ Ronald G. Minnich Nov 25 20:15 "And, in fact, vendors over time have shown us they are sensitive on this issue. Keeping it (microcode) in cbfs removes their worries." With this quote, I do not understand why you are against moving microcodes to blobs.git. I also do not understand why you approved this patch to be submitted to coreboot.git without the (required) microcode update files. Kyösti

2 1

Re: [coreboot] Removing microcode updates from blobs
by Vladimir 'φ-coder/phcoder' Serbinenko 14 Dec '13

14 Dec '13

On 14.12.2013 07:59, ron minnich wrote: > On Fri, Dec 13, 2013 at 10:46 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > > What's the point? Why not just enlighten them? I just can not understand this. Some distros have a policy of putting free and non-free components in separate repositories (E.g Debian contrib/free vs non-free) and having appropriate dependencies to show that free package needs something non-free. I'd hate to see coreboot land in some "non-free" repo over microcode issues, it would send wrong message.

1 0

Re: [coreboot] Removing microcode updates from blobs
by mrnuke 14 Dec '13

14 Dec '13

On 12/14/2013 12:36 AM, ron minnich wrote: > And I think it even worse to put the microcode blobs in a location in > the tree that implies, by its existence, that you can build without > them and get a more free, working firmware image. > You can't have a working build on a bunch of recent hardware without blobs. So the assumption that you can build without blobs is false. Pure and simple.

3 2

Re: [coreboot] Removing microcode updates from blobs
by Patrick Georgi 14 Dec '13

14 Dec '13

Am 14.12.2013 06:24, schrieb Gabe Black: > If you don't want to hear it, ignore it. That's rude. It works if you don't care at all for the people with that (somewhat weird) opinion, but there are a number of contributors that are uneasy about these binary things. The point isn't to break things for everyone, and that isn't what the patches are doing. In fact, the first half consolidates a number of different ucode update mechanisms and standardizes them to the way that your team introduced to coreboot. What it does, it drops the other mechanisms. A plus in my book, for the simple reason that we can simplify coreboot in that area. The second half, the "move bits to blobs.git" part, comes mostly for free. It's transparent to anyone on current Intel chipsets given that they can't even boot images built without that repository. As in, at all. So there's solid technical reason. There's one thing less to commplain about in coreboot (I dislike having my stuff being blamed for hardware faults due to other people's lazy product engineering). What's not to like? And funnily, most of the people who chimed in aren't even affected. > We shouldn't break things just > so people with mistaken opinions are happy, nor how long it took to > rearrange things into a broken state. I'll keep that in mind for the next x86 binary that comes our way... Patrick

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2013