On Wed, Jan 7, 2009 at 12:45 AM, ron minnich rminnich@gmail.com wrote:
On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
As long as CAR is active, we don't want the cacheable area (CAR+ROM) to be bigger than the cache to prevent cache evictions of CAR contents.
Ah, that explains the reboots I'm seeing if the lar isn't zero-filled.
That means we can cache the boot block and maybe initram. In that situation, having initram directly before the boot block is a huge speed benefit. Once CAR is no longer active, we immediately want to mark the whole ROM and RAM as cacheable to speed up decompression.
Yes. And you want to have those MTRRs in a state that they'll be correct even if the OS you boot doesn't touch them.
One logical place is at the end of initram. I'd like to get the discussion to some agreement on where this code should be, and then we can worry about writing the code. Maybe I am missing part of the discussion but we seem to be going in circles at times :-)
Probably my fault, I've just been skimming through the list the last couple months while I was in class, and I head back next week, so I'd like to get this running before then ;) Although the end of initram makes sense (I was going to tuck it into disable_car()), if we only mark the first couple MB of ram and all of ROM as cachable there (some safe value that every system should have and coreboot will always fit inside) and then mark all of it later when we add the ram resources, we eliminate the need for chipset-specific code to tell coreboot the ram size twice. Does that make sense, or will it just complicate things more?
As for the CAR+ROM area caching, no argument; what I think we're
saying is we may need the ability to control where a LAR file ends up in ROM so we can limit the cacheable area. Does that make sense?
Perfect sense.
Thanks, Corey