On Wed, Jan 7, 2009 at 1:35 AM, Corey Osgood corey.osgood@gmail.com wrote:
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?
And actually, we already have a config variable and function to do that in stage1, the following should make it work (this is inside stage1_phase3). All that would be left would be to teach ram_resource to re-set the mtrrs, or use the mtrr setup functions I pulled in from v2. The next question concerns that though, everything I can find suggests that coreboot uses the range from 0MB-CBMEMK. What happens if/when it hits a reserved range? IE the range from 768k-1MB which is always reserved on vt8237r, IIRC.
Thanks, Corey
Index: arch/x86/stage1.c =================================================================== --- arch/x86/stage1.c (revision 1101) +++ arch/x86/stage1.c (working copy) @@ -332,6 +332,10 @@ /* Provide an easy way to check whether RAM is available. */ global_vars()->ram_available = 1;
+#ifdef CONFIG_MTRR + cache_cbmem(MTRR_TYPE_WRBACK); +#endif + // location and size of image. init_archive(&archive);
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