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