coreboot April 2012

coreboot@coreboot.org

39 participants
459 discussions

Re: [coreboot] Binary blobs in the source tree (was: Re: New patch to review for coreboot: e4fc528 Add the memory reference code binary for sandybridge chipsets)
by Carl-Daniel Hailfinger 17 Apr '12

17 Apr '12

Am 15.04.2012 22:08 schrieb ron minnich: > On Sun, Apr 15, 2012 at 3:49 PM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >> Am 15.04.2012 04:57 schrieb ron minnich: >> It's a slippery slope, though. We call the blob from coreboot and expect >> it to return to coreboot (whether the return is a JMP/RET/... doesn't >> matter). Unless I'm mistaken, we've never done that before, > We've been doing it for almost ten years, first with vga bios and then > with microcode. In the latter case, the microcode was a binary blob > linked in to coreboot which we called. The Intel MRC is actually less > connected, as it is a blob in cbfs. I thought the microcode updates were not executed as binary blobs, but rather uploaded (or banged into a register) into the CPU. >> and if we do >> this now in the official tree, it will be very hard to refuse merging >> chipset init blobs (well, pretty much any init blob), and for some >> chipset/CPU combinations coreboot may turn into a simple blob aggregator >> with PCI init. That's a scenario I'm very afraid of. > it's a danger. It's something we have to watch for. I've made it clear > to the vendors that's not what we want. They seem to be listening. Glad to hear that. > But we can not escape some minimal set of blobs unless we wish to drop > x86 platforms (or most of them) because > it's getting to be impossible to turn on an x86 without these blobs. Is this a problem for all x86 CPU vendors? I don't believe in "name and shame", but at least knowing if there is unaffected hardware would help making an informed decision. By the way, we should really document in the wiki what's going on outside the coreboot code paths before and during startup. > The next blob I have to commit is the ME binary, and that's not even > run by the x86, but by the external RISC CPU. And, you can't turn on > the platform without it. > >> Microcode is conceptually different. It's a stream of bytes you bang >> into some register, you don't execute it as normal code on your CPU. CPU >> microcode is like a network card's internal firmware: outside the scope >> of coreboot. > I see no difference but I'm not really here for a debate. If we can't > come to convergence I'll just make a separate repo.And, I suppose this > means there's no objections to me putting the ME binary blob into the > tree? Now that you're explicitly asking me, I'd like to keep ME/IMC (Management Engine/Internal Management Controller) binary blobs out as well. Rudolf has worked quite a bit on a free IMC firmware for recent AMD chipsets, and there's a faint hope (i.e. wishful thinking) we'll get something like that for Intel as well one day. The same applies to firmware for standalone EC (Embedded Controller) in laptops/servers. >> I heard rumors that the MRC blob is only a stopgap solution because >> there wasn't sufficient time to write+QA RAM init code for the >> sandybridge platform, and such code might materialize later. > That rumor is complete and total random noise (to use a polite word). > You heard it here first. I don't know why people make that stuff up. Wishful thinking maybe? I really hoped the rumor would be true. Probably a classic telephone game: "MRC blob is a hard requirement" -> "would be nice if we had a MRC blob replacement" -> "maybe someone is already working on that" -> "surely somone must be working on that, it's an obvious goal". > So, one more cycle of this discussion and then I'd like to come to a > decision. We've still got lots to do so we can give you all a coreboot > release at the same time the laptop is for sale! I'm all for having a separate git tree with all sorts of helpful/necessary blobs hosted at coreboot.org, because that gives us the option to keep the trees in sync and it also makes coreboot.org the canonical source of everything you might ever want or need for a firmware build. (CPU microcode updates should remain in the main source tree, though.) Regards, Carl-Daniel -- http://www.hailfinger.org/

6 5

blobs
by ron minnich 17 Apr '12

17 Apr '12

Please find here: ssh://review.coreboot.org:29418/blobs.git blobs needed for the two google systems. I will be removing the blob from the coreboot tree today. I hope this helps bring the discussion to a close :-) ron

1 0

Patch merged into coreboot/master: e4fc528 Add the memory reference code binary for sandybridge chipsets
by gerrit＠coreboot.org 17 Apr '12

17 Apr '12

the following patch was just integrated into master: commit e4fc5283d5c2e5fe8f75875a8229319696f8990b Author: Ron Minnich <rminnich(a)gmail.com> Date: Thu Apr 12 04:26:22 2012 -0700 Add the memory reference code binary for sandybridge chipsets This binary is required for anyone who wishes to build a sandybridge mainboard. Change-Id: I779ef5e2b77166b81cb05eada37291368e74fbb6 Signed-off-by: Ron Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Sat Apr 14 01:36:38 2012, giving +1 Reviewed-By: Peter Stuge <peter(a)stuge.se> at Mon Apr 16 01:12:57 2012, giving +2 See http://review.coreboot.org/897 for details. -gerrit

3 7

Re: [coreboot] [SPAM] Re: Binary blobs in the source tree (was: Re: New patchto review for coreboot: e4fc528 Add the memory reference codebinary for sandybridge chipsets)
by Xavi Drudis Ferran 17 Apr '12

17 Apr '12

On Tue 17/04/12 04:53 , Peter Stuge <peter(a)stuge.se> wrote: > > You imply that you experience a change in direction, but as I tried > to make clear already in my last email, I do not consider coreboot > to have changed direction at all. The recent progress is a leap > forward; as already confirmed by Andrew, coreboot is more valuable > with Sandy Bridge support. > We disagree about change of directions. We agree that the value of coreboot is different with or without that blob. I prefer the previous value. My preference is of no particular concern since I don't have commit rights and tend to seek consensus more than clearness of my own preferences. > > if coreboot starts filling with blobs it will be just another BIOS, > > only somewhat delayed or playing catchup with some features. > > I'm not sure if you realize how absurd that is. In case you didn't > notice, coreboot has been playing catchup with all hardware for the > first 12 years. > And I guess it will still play catchup with blobs. When AMD started commiting lots of code for their chipsets this didn't magically create implementations for all the AMD enabled motherboards out there. Before the blob, it was a catchuper which had the unique value that was free and could be modified and understood. After the blob it won't have this value, just like most BIOSes, and will still be a catchuper. It will just be trying to catch up with a bigger slice of available hardware. But I'm playing too much devil advocate. If the blob was free software the new hardware support would be much welcome. > You may think that 12 years is a long time for a project, but in fact > coreboot is only since a year or so, when AMD announced their > support, starting to grow up, and even then there are many things > that desperately require your contributions to increase it's success. > I want to thank AMD for their support. But I also want to thank all people that worked in coreboot those 12 years. AMD may not have come without them. > OR - you can go to a vendor and pay them for the service of doing it > on your behalf. Currently there exists no such service for coreboot, > but the more popular coreboot becomes the more likely it is that such > a service provider (or several!) will appear. > > YOU have to research details to ensure that YOUR requirements are met. > > Blobs do not change this fundamental fact in any way. Blobs reduce the set of people able to adapt them to just one party. Blobs provide functionality that may discourage some people to implement free alternatives (fortunately you try to compensate by encouraging people to do so). > If there are no > blobs then your "zero blobs" requirement is very easy to check off > the list of requirements, while other metrics such as "computational > performance" or "power consumption" remain exactly as difficult to > check. > If there are blobs you still have to measure performace or power. > You have no right to spit on coreboot (which is what you say that you > would do if it became "a blob loader") just because one part of it > solves problems which you do not want to solve, while other parts > solve exactly the problems you do want to solve. > Sorry. I didn't mean to spit on coreboot, just on some options about its future. But I didn't mean to spit at all. I just didn't feel commited enough to be more polite than some rushed people. Maybe I wasn't just polite enough. Sorry about that. > Further, as Ron already pointed out - and as you know from your > experience with PC bootstrapping, you can't really ignore that many > coreboot systems already depend on another blob during startup - the > VGA BIOS. It's not really related to coreboot, but to the way the PC > platform is expected to work by PC operating systems. > Nonfree VGA BIOSes are not distributed with coreboot as far as I know. I would have objected just the same to committing nonfree VGA BIOSes. I wish one can do without them, but I haven't claimed that's possible. > > it will be like what linux has become, you no longer know much by > > the statement that linux runs on something. If android is free > > software > > Who has said that Android is free software? That's stupid. If you > want to discuss Linux not being free enough then you can always try > to take it up with Linus. > I was just trying to show examples of projects that include free and nonfree parts and achieve what you seek: support for more hardware. And I hinted at what I don't like from them, that they make really hard to tell free from nonfree apart. > > Coreboot may choose to go that route > > Third time: coreboot has never changed direction and I do not see any > reason to do so in the future. > Coreboot is not yourself only. It's very likely more yourself than myself, but you can't just decide it on your own. And there are other people objecting, maybe with a better attitude than myself. > that fit their needs. You can pretend that coreboot actually does not > support Sandy Bridge and Ivy Bridge at all, and you are still golden! > A free software project is some people trying to work together to achieve some goal. When you use a free software project you have some work already done for you. Keeping the code free, legaly sound and testing it with different hardware is an important work that I appreciate in free software projects. Projects which mix free and nonfree parts and require users to identify the nonfree parts, learn what they support and pretend they aren't there, don't provide this work done and I miss it. > Indeed it is. What you write is extremely offensive. You are > disrespecting the magnitude and excellence of the work that has been > contributed to the coreboot project by the Chromebook team and I just > find that to be really really poor form, regardless of your reasons. > I didn't mean to offend anyone. If I did I apologise. I just want the work of all previous committers to a truly free software project to be respected. I may be attributing intentions to others, but I'll have to make do with that until I learn mind reading. > > Does someone else besides intel and google have permission to > > distribute the blobs? > > Please see > http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure > > I expect you to actually have solid knowledge of this already, since > you have already sent contributions. > You can rest. I stand by my sign off. My contribution was a) small b) possibly replaceable with later code by AMD c) safe to sign off to the best of my knowledge. This assumes the code present in coreboot before my changes was legally safe, since my contribution is a derived work of it, but I didn't do any legal audit of code already in the repository. Now that you pointed this out, let me quote that page: License Issues * Contributed code must be GPL'd (preferrably 'GPLv2 or any later version', but 'GPLv2' is fine, too). At the very minimum the code must have a GPL-compatible license. My understanding of a GPL-compatible license is one that in particular allows anyone with the binary to obtain the source from the distributor. Mr. Ron Minnich, please, I downloaded e4fc5283d5c2e5fe8f75875a8229319696f8990b and can't find the licence, can you specify which GPL-compatible license it is under ? Can you please provide the source code ? > > coreboot users have usually assumed they had permission to > > distribute the tree freely under GPL, > > You speak for all of them? I am sure that you realize how absurd > that is. Noone can claim anything on behalf of "coreboot users." > In the same message you linked to a page that demands each contribution to be signed off, defines sign off as a process whereby the contributor grants or certifies the availability of an open source license and the open source license is further constrained to a GPL-compatible license, preferably GPLv2 or later. GPL-compatible licenses grant the right to distribute the licensed material. By "freely distributing" I meant distributing under some conditions that keep the software free. In the sense I meant, a tree full of GPL licensed content can be "freely distributed". By "freely distributed" I didn't mean unconstrained by the GPL. I'm sorry for any misunderstanding. Mr. Stuge, can people assume the page you just sent to accurately describe this project ? > > Ask away about anything that is unclear! Thanks. I'm trying. > Reality check. Vendors are not fighting each other over who can be > more compatible with coreboot. For 12 years coreboot has been chasing > hardware. You need to understand the full impact of this. > Reality check. The fact that google wants to buy millions of chromebooks and their available firmware does not fit their requirements, so they want to use coreboot with a blob for some hardware models will not magically lead every OEM to implement coreboot for their systems. A new system will be added, the legal clarity of the project will be compromised, and people will still wait for the next volunteer to port a similar board replacing or working around the blob if the hardware requires it. > > if you can't even rely on a FSF priority project to get free > > software. > > As I am sure that you already know, coreboot is not an FSF project. > Sorry for writing too loosely. I meant : "If you can't even rely in a project that appears in the FSF's high priority projects list to get free software." See http://www.fsf.org/campaigns/priority-projects/ The fact that FSF asked people to help coreboot does not mean that coreboot is a FSF project. I didn't mean it. I just meant that I expected them to ask support only for free software (and I believe they're not aware of the issue or are waiting for a resolution before editing that page). > I will not bother biting on this last piece of flame bait. I am > confident that you understand that coreboot is more free than your > other options. If it's not free enough for you at this time then > please either go away or please help us out. In any case you are > *NOT* helping by complaining. > Very clear, mister. I hope I can help by asking for license clarification. That's hopefully more constructive than talking about pride, half-bakeness or likeliness of future hardware support.

1 0

Patch merged into coreboot/master: 705d2ea Intel e7505: handlers for undocumented registers
by gerrit＠coreboot.org 17 Apr '12

17 Apr '12

the following patch was just integrated into master: commit 705d2eac86a12704489033c5a115ae8bae43f6f5 Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Thu Apr 12 22:46:23 2012 +0300 Intel e7505: handlers for undocumented registers Makes the code a bit more readable, IMO. There is no clean way to implement this as the affected registers are undocumented. Seems ROMCC cannot handle the enum. Also any of my future changes would not be even abuild tested as there is no longer a board with ROMCC and this chipset. E7505 chipset is CAR only from now on. Change-Id: I0e2d8ba0c7ed7cce46d9eafb8d8badf04cf75f7a Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> See http://review.coreboot.org/895 for details. -gerrit

1 0

Patch merged into coreboot/master: 1576dc1 kconfig: Improve 'General setup' menu docs.
by gerrit＠coreboot.org 17 Apr '12

17 Apr '12

the following patch was just integrated into master: commit 1576dc110e01f397853aeb828483f71603a57fa8 Author: Uwe Hermann <uwe(a)hermann-uwe.de> Date: Thu Apr 12 22:00:03 2012 +0200 kconfig: Improve 'General setup' menu docs. - Add documentation for COMPILER_GCC, and COMPILER_LLVM_CLANG. - SCANBUILD_ENABLE, CCACHE: Amend documentation. - SCANBUILD_REPORT_LOCATION: Document default dir, names of scan-build dirs. - INCLUDE_CONFIG_FILE: Add more verbose docs, show how to use it. - Fix typos/cosmetics/indentation, improve wording on some items. Change-Id: I6b67b2c777868e4421405caaffe6631e69dddad2 Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Reviewed-By: Patrick Georgi <patrick(a)georgi-clan.de> at Tue Apr 17 10:56:15 2012, giving +2 See http://review.coreboot.org/893 for details. -gerrit

1 0

coreboot/Flashrom: Sponsor needed for promotion for LinuxTag or any other IT fair, trade show, conference
by Paul Menzel 17 Apr '12

17 Apr '12

Dear coreboot and Flashrom folks, the idea is to give out flash chips for free to people (LinuxTag in Berlin from May 23rd to 26th) asking them to test Flashrom and try coreboot. Where the flash chips are given away, at the coreboot or Flashrom booth or at the sponsor’s booth does not matter much. Reason ------ In my experience having to buy flash chips (or a programmer) is the biggest hurdle to development or testing. Although 20 € for shipping and such is not *that* much it seems to be for some people. Additionally since mostly you cannot buy such things in the shop around the corner it is quite time consuming to shop online. Benefits -------- For coreboot it could mean just telling people to build an image similar to their board, switch the chip, flash the image to the given chip and then test it. So because people coming home having means to try coreboot (more) easily will get them to the project. For Flashrom people could test if their mainboard supports all operations, especially erase and wrote, so we could better coverage of mainboard support [1]. Of course only for boards supporting the given away chip. Type of chip ------------ I have not much of a clue, but I guess the flash chip should have DIP8 form factor and support the SPI protocol. The size should be 16 or 32 Mb MBit. Help is needed here for suggestions. Quantity and Price ------------------ 500 or 1000 chip should be a reasonable amount to get. One developer (in Europe?) (going to most fairs) could store them and if there is another event (in Europe) the developer will not attend then he could mail a certain amount of chips to developers attending that event. On IRC scientes found an offer for order of 1000+ pieces for an 32Mbit chip for $1.77 for a piece. Therefore getting 1000 chips would cost 2000 $/€. Money and sponsors ------------------ It would be great if a company or organization would be willing to finance that project. Maybe the developers who work at company/organizations doing coreboot or Flashrom work or deployment could lobby for the support in their company/organization. Besides good press coverage and improved reputation I write up some arguments for some companies or organizations. ### AMD ### Although a statement was made to support coreboot and code for chipset support is contributed, board ports are lacking. Making it easy for people to port coreboot to more AMD boards and by doing so also fix bug or clean up the code should be in AMD’s interest. ### Intel ### The known reasons apply. Now that the coreboot team at Google made the Sandy Bridge port for their Chromebooks [3], it easier than ever to make a port for other Intel boards with that chipset. ### Google ### Just plain Free Software principle. By having people work with or try out coreboot, code Google uses will be tested and improved. Also Google doing Flashrom development more testing would be beneficial in that area too. ### Microsoft, Ubuntu and other Free Software distributions ### Having a BIOS replacement which takes less time to initialize the hardware and let the operating system take over, will (indirectly) improve the experience of their users. ### FSF (Free Software Foundation) ### As coreboot is a high priority project at the FSF they could support such promotions financially. ### BSI (Bundesamt für Sicherheit in der Informationstechnik) ### Having companies and citizens using coreboot will be lead to more secure systems, since coreboot being free software it can be audited by everyone and updates do not depend on the willingness of the vendor. It would be awesome if we could get that project going. I am curious how it will turn out. Thanks, Paul [1] http://flashrom.org/Supported_hardware#Supported_mainboards [2] http://flashrom.org/Technology [3] http://blogs.coreboot.org/blog/2012/04/02/google-releases-sandybridge-suppo… [4] http://www.fsf.org/campaigns/priority-projects/

3 2

Patch merged into coreboot/master: fcb4358 More portable s3 scratch space creation
by gerrit＠coreboot.org 17 Apr '12

17 Apr '12

the following patch was just integrated into master: commit fcb4358908704fa31adc3eb051692307fc2a89ce Author: Patrick Georgi <patrick.georgi(a)secunet.com> Date: Thu Apr 12 15:03:22 2012 +0200 More portable s3 scratch space creation echo -n isn't portable. echo -e isn't portable. that bash loop isn't portable. So let's try something else. Change-Id: Ie73aa1c09d90c11a5c4952a332d4c2058390b5db Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> Reviewed-By: Patrick Georgi <patrick(a)georgi-clan.de> at Tue Apr 17 08:59:19 2012, giving +2 See http://review.coreboot.org/889 for details. -gerrit

1 0

Patch set updated for coreboot: 6a7857a Do not produce temp s3.rom if HAVE_ACPI_RESUME is no.
by Zheng Bao 17 Apr '12

17 Apr '12

Zheng Bao (zheng.bao(a)amd.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/902 -gerrit commit 6a7857a7b7f69b7979886598a31da0fdeeb8b4c3 Author: zbao <fishbaozi(a)gmail.com> Date: Tue Apr 17 11:33:27 2012 +0800 Do not produce temp s3.rom if HAVE_ACPI_RESUME is no. s3.rom is useless for all the other boards which S3 resume is not validated. Yes, sooner or later when CBFS is able to allocated an area, the s3.rom is no longer needed. But currently, other boards don't want to be bothered. It is not just for AGESA. AFAICS, all AMD boards need it. This feature, I believe, is needed by all the later boards which support S3 resume. It will be moved to a upper level folder then. Change-Id: I12693e9556ca6f8e0d80b2ab2dca5c85bdb97685 Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Signed-off-by: zbao <fishbaozi(a)gmail.com> --- src/southbridge/amd/Makefile.inc | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/southbridge/amd/Makefile.inc b/src/southbridge/amd/Makefile.inc index 2cdca29..01675ac 100644 --- a/src/southbridge/amd/Makefile.inc +++ b/src/southbridge/amd/Makefile.inc @@ -15,14 +15,16 @@ subdirs-$(CONFIG_SOUTHBRIDGE_AMD_CIMX_SB700) += cimx subdirs-$(CONFIG_SOUTHBRIDGE_AMD_CIMX_SB800) += cimx subdirs-$(CONFIG_SOUTHBRIDGE_AMD_CIMX_SB900) += cimx +ifeq ($(CONFIG_HAVE_ACPI_RESUME), y) + $(obj)/s3.rom: echo " S3 NVRAM 0xffff0000 (S3 storage area)" echo -ne '\xFF' > $@ for ((i=0;i<20479;i++)) do echo -ne '\xFF' >> $@ ; done -ifeq ($(CONFIG_HAVE_ACPI_RESUME), y) cbfs-files-y += s3nv s3nv-file := $(obj)/s3.rom s3nv-position := 0xffff0000 s3nv-type := raw -endif + +endif # CONFIG_HAVE_ACPI_RESUME == y

1 0

New patch to review for coreboot: 25c9c62 Do not produce temp s3.rom if HAVE_ACPI_RESUME is no.
by Zheng Bao 17 Apr '12

17 Apr '12

Zheng Bao (zheng.bao(a)amd.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/902 -gerrit commit 25c9c627957b5954ee7e473e3caeced28dbb7215 Author: zbao <fishbaozi(a)gmail.com> Date: Tue Apr 17 11:16:23 2012 +0800 Do not produce temp s3.rom if HAVE_ACPI_RESUME is no. s3.rom is useless for all the other boards which S3 resume is not validated. Yes, sooner or later when CBFS is able to allocated an area, the s3.rom is no longer needed. But currently, other boards don't want to be bothered. Change-Id: I12693e9556ca6f8e0d80b2ab2dca5c85bdb97685 Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Signed-off-by: zbao <fishbaozi(a)gmail.com> --- src/southbridge/amd/Makefile.inc | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/southbridge/amd/Makefile.inc b/src/southbridge/amd/Makefile.inc index 2cdca29..01675ac 100644 --- a/src/southbridge/amd/Makefile.inc +++ b/src/southbridge/amd/Makefile.inc @@ -15,14 +15,16 @@ subdirs-$(CONFIG_SOUTHBRIDGE_AMD_CIMX_SB700) += cimx subdirs-$(CONFIG_SOUTHBRIDGE_AMD_CIMX_SB800) += cimx subdirs-$(CONFIG_SOUTHBRIDGE_AMD_CIMX_SB900) += cimx +ifeq ($(CONFIG_HAVE_ACPI_RESUME), y) + $(obj)/s3.rom: echo " S3 NVRAM 0xffff0000 (S3 storage area)" echo -ne '\xFF' > $@ for ((i=0;i<20479;i++)) do echo -ne '\xFF' >> $@ ; done -ifeq ($(CONFIG_HAVE_ACPI_RESUME), y) cbfs-files-y += s3nv s3nv-file := $(obj)/s3.rom s3nv-position := 0xffff0000 s3nv-type := raw -endif + +endif # CONFIG_HAVE_ACPI_RESUME == y

1 0

← Newer
1
...
20
21
22
23
24
25
26
...
46
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 April 2012