Patch merged into coreboot/master: e4fc528 Add the memory reference code binary for sandybridge chipsets
the following patch was just integrated into master: commit e4fc5283d5c2e5fe8f75875a8229319696f8990b Author: Ron Minnich rminnich@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@gmail.com
Build-Tested: build bot (Jenkins) at Sat Apr 14 01:36:38 2012, giving +1 Reviewed-By: Peter Stuge peter@stuge.se at Mon Apr 16 01:12:57 2012, giving +2 See http://review.coreboot.org/897 for details.
-gerrit
On Mon, Apr 16, 2012 at 01:13:02AM +0200, gerrit@coreboot.org wrote:
the following patch was just integrated into master: commit e4fc5283d5c2e5fe8f75875a8229319696f8990b Author: Ron Minnich rminnich@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@gmail.com>Build-Tested: build bot (Jenkins) at Sat Apr 14 01:36:38 2012, giving +1 Reviewed-By: Peter Stuge peter@stuge.se at Mon Apr 16 01:12:57 2012, giving +2 See http://review.coreboot.org/897 for details.
-gerrit
?
Luc Verhaegen.
Luc Verhaegen wrote:
the following patch was just integrated into master:
Add the memory reference code binary for sandybridge chipsetsReviewed-By: Peter Stuge peter@stuge.se at Mon Apr 16 01:12:57 2012, giving +2
?
For the first time in history, coreboot now supports the very latest hardware platforms from both AMD and Intel!
I think this is an incredibly exciting development, and adding the MRC is an absolute no-brainer.
Calling vendor reference code hooks for parts of the initialization is not ideal, but it is a lot better than not supporting a platform at all. For industry (which we want to reach) it may actually *be* ideal, since they are already familiar with the way the reference code works, so understanding coreboot becomes just a little bit easier.
I still believe that we the coreboot community can create more innovative init code, as we have done for a decade already, but someone has to do it. So far I don't know of significant effort to create Sandy Bridge/Ivy Bridge memory controller init, but if one is underway then once it is done I would suggest using that by default, and relegating the MRC to an expert Kconfig option.
I think Ron's effort on native Intel graphics init by refactoring KMS drivers is a great idea to have more native init, and it could well be *the* way we will finallyx get rid of the sucky VGA BIOS!
I'm very thankful for the efforts David, Stefan, Ron, and the rest of their team at Google have put into making coreboot a serious alternative for the latest Intel hardware in the industry!
You rock guys!
//Peter
On Mon, Apr 16, 2012 at 05:03:39PM +0200, Peter Stuge wrote:
Luc Verhaegen wrote:
the following patch was just integrated into master:
Add the memory reference code binary for sandybridge chipsetsReviewed-By: Peter Stuge peter@stuge.se at Mon Apr 16 01:12:57 2012, giving +2
?
For the first time in history, coreboot now supports the very latest hardware platforms from both AMD and Intel!
I think this is an incredibly exciting development, and adding the MRC is an absolute no-brainer.
Calling vendor reference code hooks for parts of the initialization is not ideal, but it is a lot better than not supporting a platform at all. For industry (which we want to reach) it may actually *be* ideal, since they are already familiar with the way the reference code works, so understanding coreboot becomes just a little bit easier.
I still believe that we the coreboot community can create more innovative init code, as we have done for a decade already, but someone has to do it. So far I don't know of significant effort to create Sandy Bridge/Ivy Bridge memory controller init, but if one is underway then once it is done I would suggest using that by default, and relegating the MRC to an expert Kconfig option.
I think Ron's effort on native Intel graphics init by refactoring KMS drivers is a great idea to have more native init, and it could well be *the* way we will finallyx get rid of the sucky VGA BIOS!
I'm very thankful for the efforts David, Stefan, Ron, and the rest of their team at Google have put into making coreboot a serious alternative for the latest Intel hardware in the industry!
You rock guys!
//Peter
You just committed a patch that was under heavy discussion, completely ignoring this discussion, and you definitely ruined the outcome of that discussion.
On top of that, you just committed a binary blob to a free software project, a free software project that used to take pride in providing the functionality that that binary blob now provides.
You rock!
Luc Verhaegen.
Luc Verhaegen wrote:
I still believe that we the coreboot community can create more innovative init code, as we have done for a decade already, but someone has to do it. So far I don't know of significant effort to create Sandy Bridge/Ivy Bridge memory controller init, but if one is underway then once it is done I would suggest using that by default, and relegating the MRC to an expert Kconfig option.
you just committed a binary blob to a free software project, a free software project that used to take pride in providing the functionality that that binary blob now provides.
Please read what I wrote above. Focus obviously remains the same for coreboot.
A fact is that there is no commit in Gerrit for native memory controller init for the particular hardware.
When there is one, as I wrote, then I'll be the first to want to replace the MRC binary.
What the MRC does on a high level is well-known. The DDR3 JESD is available to anyone and everyone. If Intel desperately wants to hide some registers for now then I really could not care less.
I do however care a lot about the fact that coreboot can be used on Sandy Bridge and Ivy Bridge platforms now.
coreboot does, and should, take pride in the hardware init done with native code, because the init gets done really well. This is obviously still true for all parts of coreboot which run before and after the MRC, where the resource allocator is no small part.
I agree that coreboot memory init, especially with ECC, has merit, but I don't think it's the pride of coreboot.
As you know, the MRC binary is quite specific to the platform, so it's not at all true that the MRC has taken over a function that other code in coreboot was already doing, as you make it sound.
I would really like to see native init code for the memory controller so please push to Gerrit if you have it, even if it's only in an early stage!
//Peter
On Tue, Apr 17, 2012 at 02:07:48PM +0200, Peter Stuge wrote:
Luc Verhaegen wrote:
I still believe that we the coreboot community can create more innovative init code, as we have done for a decade already, but someone has to do it. So far I don't know of significant effort to create Sandy Bridge/Ivy Bridge memory controller init, but if one is underway then once it is done I would suggest using that by default, and relegating the MRC to an expert Kconfig option.
you just committed a binary blob to a free software project, a free software project that used to take pride in providing the functionality that that binary blob now provides.
Please read what I wrote above. Focus obviously remains the same for coreboot.
A fact is that there is no commit in Gerrit for native memory controller init for the particular hardware.
When there is one, as I wrote, then I'll be the first to want to replace the MRC binary.
What the MRC does on a high level is well-known. The DDR3 JESD is available to anyone and everyone. If Intel desperately wants to hide some registers for now then I really could not care less.
I do however care a lot about the fact that coreboot can be used on Sandy Bridge and Ivy Bridge platforms now.
coreboot does, and should, take pride in the hardware init done with native code, because the init gets done really well. This is obviously still true for all parts of coreboot which run before and after the MRC, where the resource allocator is no small part.
I agree that coreboot memory init, especially with ECC, has merit, but I don't think it's the pride of coreboot.
As you know, the MRC binary is quite specific to the platform, so it's not at all true that the MRC has taken over a function that other code in coreboot was already doing, as you make it sound.
I would really like to see native init code for the memory controller so please push to Gerrit if you have it, even if it's only in an early stage!
//Peter
That still has _you_ going around the people who were discussing this patch and the outcome of that discussion.
Luc Verhaegen.
Luc Verhaegen wrote:
That still has _you_ going around
I went *around* nothing. I'm one of several who can ack and commit a proposed commit, and including a commit takes exactly one submit and one ack, as per our process since forever.
Sorry if anyone feels that I stepped on their toes, but you can bet that I will ack this commit over and over again.
the people who were discussing this patch and the outcome of that discussion.
The discussion wasn't very useful, and was clearly going nowhere. It's very similar to the quarter million line patch submitted for another modern platform. There's very little that needs to be said.
Keep focus on the fact that coreboot now supports current platforms from both AMD and Intel.
//Peter
On Tue, Apr 17, 2012 at 03:04:38PM +0200, Peter Stuge wrote:
Luc Verhaegen wrote:
That still has _you_ going around
I went *around* nothing. I'm one of several who can ack and commit a proposed commit, and including a commit takes exactly one submit and one ack, as per our process since forever.
Sorry if anyone feels that I stepped on their toes, but you can bet that I will ack this commit over and over again.
Then what is the point of review, discussion, heck even a mailing list or gerrit?
the people who were discussing this patch and the outcome of that discussion.
The discussion wasn't very useful, and was clearly going nowhere. It's very similar to the quarter million line patch submitted for another modern platform. There's very little that needs to be said.
That's what you think.
Keep focus on the fact that coreboot now supports current platforms from both AMD and Intel.
//Peter
Then let's just rename coreboot to "Emperor Stuge's little empire", and be done with.
Luc Verhaegen.
-
gerrit＠coreboot.org -
Luc Verhaegen -
Peter Stuge